I was hesitant to learn Objective-C when iPhones first came out. As time went on, it just became harder to start learning because I felt more and more behind the early-adopters. Thankfully, Apple released Swift in June 2014 and the playing-field was finally leveled.
To get started, I joined a few Swift meetup groups in the San Francsico area. For my first event, I went to an all-day Swift workshop and hackathon, sponsored by the Swift Language Users Group (SLUG). At the workshop, we ported a “To do” application from Objective-C over to Swift. During the hackday that followed, I modified the “To do” app to deduce its internal workings. The end product wasn't fancy, but I learned a lot about which parts of the app corresponded to which parts of the code.
Next, I attended a “Swift Code Golf” meetup, which Thoughtworks hosted in our San Francisco office. This event had nothing to do with golf --- it's just a clever name for using-as-little-code-as-possible to achieve a goal. I found that my experience in Clojure (a functional language) put me well ahead of seasoned Objective-C programmers. Using map, reduce, and filter, my team was able to birdie a bunch of holes.
Since then, I found that forking and cloning Swift apps from Github has been very helpful to understand what working code looks like. Once you have a local copy, you can change things and delete things to see the effects in the iOS simulator. It works great if you're a deductive thinker like me!
Once you feel like you have enough bits and pieces to build a real app, do it! Just-in-time learning is probably the best way of gaining and retaining knowledge. I'm currently building a nutrition app, which has taught me about XCode's storyboard and using API calls, among other things.
It's never too late to start learning something. And, if you start now with Swift, you'll get in at the ground floor. Moreover, if you've got some functional programming skills, you're probably already ahead of the game before you've even started.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.