Diving into Swift Part 1
While I mostly do PHP, I wanted to dive deeper into a more complex software stack and Swift was a good reason to do so: Get into desktop and app development with a modern, readable language and do things that not only live in a browser.
Turns out, the learning cliff is much steeper than in the usual web stack, at least if you want to build something which doesn’t fall neatly into the handful of online tutorial use-cases. Not to put too fine a point on it but a certain CMS with a tad higher learning curve than similar ones is extremely simple in comparison.
Getting started
You need a Mac, otherwise this is pointless. Then you need Xcode from the Mac App Store. Be prepared to shell out $100 each year, if you want to get your code on anything useful, since you’ll need to sign up for the developer program to get your builds signed.
Not essential but pretty nice is the integration OS X Server provides (another $20). If you have that running on, say, a Mac Mini, you can assign build Bots to automatically build and test your application, offloading some work from your local machine, on which you’ll be waiting to compile all the time during development anyway.
I began with a discounted legacy course from Bitfountain, which was fine in general, but I have not come across any material which blew me away, so consider researching and trying out a few budget alternatives before committing to a pricier course. I do think just reading the documentation is insufficent, unless you have a CS degree and a background in comparable languages and software stacks.
First impressions
In a nutshell: It’s challenging, but it’s fun.
Some things are a bit special, such as discovering how Storyboards are connected via drag-and-drop with the code. Tutorials are definitely helpful for things such as this. Nonetheless, it’s pretty straightforward to get a demo application up and running with the boilerplate code Xcode provides and start experimenting from there.
Consider doing the following if you also want to start with this:
- Have a look into the official Swift book to discover some general principles behind the language and usage patterns.
- Consider starting with an iOS application instead of OS X, in my experience the documentation is vastly greater for the former than the latter.
- Have a look at Wenderlich’s tutorial, I’ve found them to be a bit better than the rest. StackOverflow is of course also often helpful / necessary.
Swift 1.2, 2.0, 2.1, …
I initially started experimenting with a version of Swift before 2.0 had come out. This was not perfect timing, since 2.0 broke a lot of things. While Xcode made a valiant attempt to update code which no longer complied with the spec (println is print, etc.), manual intervention is often necessary, especially in terms of error handling and unwrapping optionals (more on that in part 2).
Those changes by themselves are not dealbreakers but it makes googling a solution quite cumbersome. The majority of tutorials and how-tos use Xcode 6.2 or 6.3 (major changes already between those) and earlier Swift versions, which means it will look different and it won’t compile. Xcode does help you in fixing your non-compiling code but it isn’t really fun if you don’t have good examples to learn from and I have often tried three different solution from the web until I came close enough to something which worked after massaging it. Try your search with “$YOURISSUE swift 2”.
The reliance on tutorials / help from the IDE is also one of the reasons why I have not yet given AppCode a real try, before I am minimally capable in this language, though I’d love to use JetBrains better autocompletion support and other niceties.
Alternative uses
Finally, I’m hopeful that open sourcing Swift will bring the language further into other venues, though I haven’t tried it out on Linux, yet. Without good new cross-platform UI libraries I’m skeptical though, if that will ever catch on. However, you aren’t limited to running GUI applications on OS X and iOS, you can also use Swift to generate classic binaries akin to javac, as well as executing it as if it were a script.
In the next post I’ll delve deeper into the specific hurdles I faced when trying to begin building apps.