
Swift, the new way to build iOS Apps. Here's how - markcrazyhorse
http://iosblog.co.uk/tutorials/developing-ios-apps-using-swift-part-1/
======
petilon
How do you specify public vs private members? The language seems to be missing
private/public keywords, and protocols (interfaces) are automatically
generated.

~~~
chrisdevereux
You can't at the moment, but you will be able to soon:
[http://stackoverflow.com/questions/24003918/does-swift-
have-...](http://stackoverflow.com/questions/24003918/does-swift-have-access-
modifiers)

------
Zaheer
I'm aggregating resources to learn Swift for both new/existing iOS devs. Check
it out at:

[http://www.LearnSwift.tips](http://www.LearnSwift.tips)

Mostly for selfish reasons to share it easily with friends.

------
andrewdanks
I think the author misses the point of the `let` keyword. It's not meant as
the equivalent of declaring constants in Objective-C; they're main purpose
isn't to be global and static like constants.

~~~
rubiquity
And yet you've managed to shed no light on how constants should be used in
Swift.

~~~
andrewmunsell
To shed some light on the practice of using `let` vs. `var`, an excerpt from
the book by Apple:

“If a stored value in your code is not going to change, always declare it as a
constant with the let keyword. Use variables only for storing values that need
to be able to change.”

Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks.
[https://itun.es/us/jEUH0.l](https://itun.es/us/jEUH0.l)

~~~
jquave
Thanks Andrew, I am updating the posts as I learn more. We're all still
learning.

------
jpb0104
Quick question. Can Swift be used to build OSX applications?

~~~
chrisdroukas
Yes.

[https://developer.apple.com/library/prerelease/mac/reference...](https://developer.apple.com/library/prerelease/mac/referencelibrary/GettingStarted/LandingPage/index.html#//apple_ref/doc/uid/TP40014345)

------
samirmenon
"programming language called Swift which replaces Objective-C"

Does Swift really _replace_ Objective-C?

~~~
weegee101
No, it doesn't. It is a great way to do 99% of the tasks most developers do.
There is, and always will be, a place for Obj-C on the Macintosh platforms.
Apple recognizes that most developers don't need the verbosity and tight-knit
compatibility with C that Obj-C provides, and that is where Swift comes in.

~~~
pjmlp
I see Objective-C been shown the door if Swift is successful, it just needs a
few iOS and OS X releases, with C left around for the UNIX layer.

Lets say around XCode version 10 gets released.

~~~
weegee101
That is extremely unlikely. Enough so that I would bet money on it.

Swift is targeted at the largest user base of the Obj-C language, the iOS
developers. Obj-C will be around for a long time both for legacy purposes and
because Swift doesn't interop with K&R C (unless that code has an Obj-C
wrapper, like CoreFoundation), and C++ code. Since both Swift and Obj-C
support using Cocoa libraries, any API added to Cocoa will be usable by both,
but Cocoa is only one of many libraries in the Macintosh ecosystem.

Swift will become a replacement for the development the vast majority of
people do, but that doesn't mean that Obj-C is going away. Apple has done
nothing to indicate so; they've really been stressing the point that Swift is
intended as a new tool to work along side your old one (Obj-C).

~~~
pjmlp
I remember Apple representatives promising to a room full of CERN researchers
that the JavaBridge wasn't going away and how Java was a first class language
for Mac OS X development.

~~~
weegee101
This is not even remotely similar to that situation. Obj-C is far more
important & integrated than I think you realize.

~~~
pjmlp
I know Objective-C since 1999, when I had to port some software from NeXT to
Windows, so I do know a few things about it.

From my point of view, many will jump to Swift if given the chance.

~~~
gress
You are misunderstanding - this isn't about which is better. Almost all new
application code will be written in Swif, but swift doesn't bridge between C
and the Swift/obj-c runtime, so Objective-C will continue to be required for
writing the glue layer.

~~~
pjmlp
Yes it does.

[https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/BuildingCocoaApps/InteractingWithCAPIs.html#//apple_ref/doc/uid/TP40014216-CH8-XID_13)

Additionally, this is just version 1.0. So nothing rules out that if Apple
sees the language being widely adopted, other improvements in the FFI area
aren't made.

~~~
gress
I stand corrected, and your argument holds, however there is a great deal of
objective-c code out there, so it will take a long time to go away.

------
jquave
BTW, part 2 is here: [http://jamesonquave.com/blog/developing-ios-apps-using-
swift...](http://jamesonquave.com/blog/developing-ios-apps-using-swift-
tutorial-part-2/)

~~~
grin
And the github project is here: [https://github.com/jquave/Swift-
Tutorial](https://github.com/jquave/Swift-Tutorial)

------
markcrazyhorse
There is an awesome Swift Cheat Sheet and Quick Reference: [http://swift-
cheatsheet.co.uk](http://swift-cheatsheet.co.uk)

------
desireco42
What's the deal with optionals? I am not sure what the use case are.

Seems much better then ObjectiveC

~~~
netcraft
The docs seem to cover it pretty well:
[https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/TheBasics.html#//apple_ref/doc/uid/TP40014097-CH5-XID_428)

But the basic idea around optionals is a much better and cleaner way of
dealing with possible null (nil) values. Lots of other languages have and are
getting optionals.

~~~
desireco42
What was confusing me that they would specify it during initialization.

------
Kidnznet
Free downloadable ebooks can be found there:
[http://www.iphonetransferrecovery.com/Swift/free-
ebooks.html](http://www.iphonetransferrecovery.com/Swift/free-ebooks.html)

------
SarahJune
So is this actually a lot easier to use than Objective-C?

~~~
josephlord
Yes...with caveats. It looks really nice, simpler syntax for the most part but
the type system seems much stronger and I think those not used to functional
languages/type theory may struggle to get complex things running straight
away. But when it does run it should be a lot more robust (so I think it is a
good change).

~~~
gress
I think this is false. Things that are simple in Objective-C will be simpler
in Swift, with better feedback from the compiler.

Things that are complex in objective-c will also be simpler and more robust in
swift.

There _is_ a kind of complex coding using generics and the type system that
would be harder for an inexperienced developer to understand, but that seems
to me to be strictly additive to Objective-C.

~~~
josephlord
I think that Swift is better and will overall be easier (I started may comment
with a "Yes") BUT there will be a fair few casts and use of optional values
needed when integrating anything with the general existing libraries that
would cause a beginner programmer difficulties.

Example 1 - implementing a protocol (AVAudioPlayerDelagate)

You get errors unless you also implement NSObjectProtocol. The easiest way to
do that is to also inherit from NSObject.

Example 2 - typed arrays/dictionaries

You can shove any NSObject in an NSArray or NSDictionary but the Swift arrays
are typed (a good thing) but one that may make some things more difficult for
beginners.

I suspect it is the tip of the iceberg of type related complication. This is a
worthwhile tradeoff for greater safety and despite this Swift will still be
easier to use overall that ObjC in my view.

It may also take a while for the documentation particularly across the
internet to catch up with the quantity of examples for Obj C but this is only
an interim issue.

~~~
gress
I think you're wrong about both of these. Yes, it's true that you need to
inherit from NSObject in some cases, but Cocoa is complex anyway, and this is
not added complexity, so it's not different from objective-c in this regard.

For #2 you are flat out incorrect. Swift arrays can be containers of AnyType,
in which case they interoperate perfectly with NSArray, and this is the
default behavior when working with Cocoa.

Your fear about type related complexity being a real issue seems not to be
justified by your examples.

Compared to dealing with the C based fragility of Objective-C, Swift is simply
better for anything that it can do.

~~~
josephlord
I like Swift and my overall answer is still yes that it is easier to learn
than Objective C and that having to deal with types is worthwhile for the
safety it brings and increased chance that it will do the right thing when it
does run but it is still a barrier to a limited degree.

I remember initially struggling with the stuff in ML in the first year at
university, I got it but I and many others had an initial struggle. I think
that at least for beginners and maybe those coming from runtime duck typed
languages Python, PHP, Ruby etc. it will be more of a barrier than you think.

For #1 in Objective C you inherit from NSObject (or a subclass thereof) for
every class anyway so it is in all the examples and it isn't something that
you need to do especially for a protocol.

For #2 yes of course you can have an array of a generic type but firstly you
need to understand enough about the type system to create your array in that
form and secondly what you get out will <AnyType> objects rather than <id>'s
which get automatically cast to whatever you assign them to. But I do like the
idiom for downcasting using _as?_ :

    
    
      if let movie = item as? Movie {
          println("Movie: '\(movie.name)', dir. \(movie.director)")
      } else if let song = item as? Song {
          println("Song: '\(song.name)', by \(song.artist)")
      }
    

[0] Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks.
[https://itun.es/gb/jEUH0.l](https://itun.es/gb/jEUH0.l)

~~~
gress
Yeah - the central point is that there aren't really caveats about Swift being
simpler than objective-c. It's not perfect, but Objective-C has a much greater
number of rough edges so is strictly harder for new users.

------
red40
Is the extension keyword a form of reflection?

------
TruthSHIFT
Are we allowed to talk about this? Isn't this still under NDA?

~~~
smackfu
The developer web pages are on public URLs that don't have any developer
authentication or headers that say they are non-public information. It would
be quite ironic if registered developers were under an NDA but the public was
not.

[https://developer.apple.com/library/prerelease/ios/documenta...](https://developer.apple.com/library/prerelease/ios/documentation/Swift/Conceptual/Swift_Programming_Language/TheBasics.html#//apple_ref/doc/uid/TP40014097-CH5)

------
_pmf_
Swift is the new Visual Basic.

~~~
sdegutis
Actually it's a lot more like the new C#, which is probably a good thing.

------
meoz
It's again the same boilerplate-code to create something simple as a
tableview. I don't understand why they had to 'invent' a new programming
language for that.

~~~
jameskilton
That's not why they built Swift.

Objective-C is a difficult language to work with and has decades of cruft.
Swift is a start-over, but with Objective-C interop so you still have full
access to the full existing APIs for OSX and iOS. Thus, the same boiler plate.

~~~
matwood
The thing is, understanding Obj-C was never the hard part. For example,
understanding ARC, weak vs. strong (and now unowned [1]), and the various
libraries is what took time and experience. Swift doesn't solve that at all
and in fact offers its own oddities like the below:

“You indicate type methods for classes by writing the keyword class before the
method’s func keyword, and type methods for structures and enumerations by
writing the keyword static before the method’s func keyword.”

Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks.
[https://itun.es/us/jEUH0.l](https://itun.es/us/jEUH0.l)

I do think the new language is neat and will be fun to work in, but it doesn't
solve the parts that tripped up many people when working in Objc.

[1]

    
    
        @lazy var asHTML: () -> String = {
            [unowned self] in
            if let text = self.text {
                return "<\(self.name)>\(text)</\(self.name)>"
            } else {
                return "<\(self.name) />"
            }
        }
    

Excerpt From: Apple Inc. “The Swift Programming Language.” iBooks.
[https://itun.es/us/jEUH0.l](https://itun.es/us/jEUH0.l)

~~~
martingordon
Is there ever a time when you don't want a weak/unowned self in a block?
Perhaps this should be made the default in Swift? (I understand that the
Blocks spec requires all captured variables to be strong unless otherwise
specified.)

