Swift is the future of development on Apple’s platforms. Any developer interested in mobile devices would be well-served by learning this exciting new language. For developers new to the iOS ecosystem, this might seem like a godsend. The common sentiment heard throughout the blogosphere is: death to Objective-C!
While I’m not so certain about Objective-C’s demise, I do think now is a great time to start developing applications in Swift. Here are a few tips that new iOS developers might find useful as they begin their mobile development adventure.
1. Read
Apple has two Swift related books available on iBooks: The Swift Programming Language and Using Swift with Cocoa and Objective-C. Both are invaluable reads. Don’t forget to try the sample code in an Xcode playground! Since the language is still evolving, don’t be surprised if something you read in the manual or another website doesn’t quite match what Xcode is expecting. This is the price you’ll pay for being an early adopter. In the beginning, don’t get bogged down by concepts you don’t understand. Your initial focus should be on making some working code as quickly as possible.
2. Copy
There are already many great resources that provide full Swift applications online. I’ve personally found some of the tutorials on Ray Wenderlich’s site to be very interesting (try Cookie Crunch!). You can start by copying their sample applications or by attempting to implement them piece-by-piece while only using the tutorial as a reference. Initially copying some code has the added benefit of teaching you how to efficiently work within the Xcode environment, while also forcing you to debug things when you make the inevitable typo!
[The completed Cookie Crunch game. Delicious!]
3. Build
It’s important to start building your own applications as quickly as possibly. Pick a simple concept and push it through to completion. Important: do not lose focus and shift from one project to another! The number of people who start projects is immeasurable, while the number that see them through to completion is considerably smaller. Share your completed creation with your friends and then start working on the next one. Your overarching goal should be to get a useful app published on the App Store.
4. Collaborate
Find some interesting events/hackathons that focus on Swift or iOS programming in general. Note that most events fall into two buckets: lectures or hacking. While you're still getting up to speed, focus on the hacking events so you can put your newfound knowledge to work immediately. Lecture-based events can be fun, but until you have some working code, you’ll always run the risk of losing focus and getting discouraged. Additionally, each lecture you attend wastes valuable time that you could spend hacking on your latest creation! Find a group of people as passionate as you are and contribute!
[Another perk...you might even meet Chris Lattner (creator of Swift) at your local Swift group (this happened at the Swift Language User Group recently).]
5. Retrospect
While Swift is certainly the future of development on Apple’s platforms, many of the key libraries and learning resources are likely to be in Objective-C for the foreseeable future. Apple has some great documentation on their Apple Developer site regarding design patterns, human interface guidelines, Xcode, and a variety of other topics — many of which will have examples in Objective-C. Roll up your sleeves and at least learn how to read Objective-C code. If you plan on doing any professional iOS development in the near future, chances are you’ll need to know Objective-C.
The addition of Swift adds one more layer to the already large iOS stack. It would be a mistake to think that Swift will dramatically reduce the complexity of creating an iOS app (the language is just one small part of the overall ecosystem). However, building some hobby apps today in this new language is a great way to get a head start on a skill that is sure to be in demand in the near future.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.