Last summer, Apple introduced Swift, a brand new programming language. Within minutes of the announcement, all of us here at Nitro were reading through the docs and shouting at each other excitedly as we discovered its features.
We immediately began using it for internal tools and prototypes, and after the language solidified in the fall we began looking at how to use it for production apps. That time finally came early this year.
Our next major product platform will make heavy use of Swift for its iOS client. We?ve found that Swift makes it easier to write asynchronous code and reveals potential problem spots earlier in the development process than previous coding languages.
Here are some reasons we think you should be paying attention to Swift, too:
The latest benchmarks show that Swift runs faster than any programming language on Android devices. It?s faster than the Objective-C language all iOS apps have been built with historically. And it?s nearly as fast as C++.
Swift is also faster to write, once you get used to it.
The syntax is quite a bit simpler, with fewer brackets, abbreviated names for options (“UITableViewCellAccessoryNone” vs. “.None”), and no need to end lines with a semicolon. Plus, it makes working with closures (anonymous functions or blocks) much easier than it is in Objective-C, which is notorious for its confusing syntax. So you can express the same code in fewer, shorter lines.
In addition, the language supports a feature called type inference. For example, in Objective-C you would declare a number by saying “This data structure is intended to hold a number, and that number is 42.” In Swift, you can just say “This data structure holds the number 42,” and it infers that the structure must be intended to hold a number.
More concise code takes less time to write and less time to read, speeding up development and maintenance.
One software shop found that ?40% of the bugs [they] shipped to customers in?the last three years would have been caught immediately using Swift??and the other 60% would have been caught sooner.
Swift is strongly-typed. This means that if you say a piece of data represents a whole number, it always has to be a whole number. If you say it’s a letter, it?s always a letter. Not all languages work this way. Apple?s older Objective-C language, for example, doesn?t promise you that a piece of data that represents a number at one moment won?t turn into a letter the next?or even into nothing at all.
Swift was designed by Apple engineers. With a platform like the App Store to draw data from, they have a great sense of what developers have trouble with, and what causes apps to crash. Swift is designed pragmatically, a rarity for new programming languages. With many languages, like Apple?s Objective-C, you have to remember to always check if data exists and means what you think it means before you work with it. If you forget to do so, the app can crash when it runs. This is especially a problem for apps that talk to remote web services, because their data structures can change at any time. Swift codifies those checks into the language, so it?s impossible to forget to make them.
Swift also stresses using immutability whenever possible. This guarantees that not only is a number always a number, it’s always the same number. This becomes very important when code running on different processing threads needs to refer to the same piece of data and have a guarantee that it won’t change while work is in progress.
It’s the future.
Swift is a language that prepares us for a time when our phones are barely faster than they are today, but have many more cores and many more threads. To split tasks up amongst all those processing units, you?ll need to minimize shared mutable state that would have to be kept in sync across all of them, maintain cleanly defined interfaces and data structures so the system can efficiently map them to shared memory, and use a coding style that encourages chaining functional processes in a pipeline that can be branched and coalesced amongst many threads. Swift, as a language, encourages all of those things.
Technical debt is writing code that you know you will have to rewrite one day. At Swift Summit last month, there was a provocative (and somewhat tongue-in-cheek) slide: ?All Objective-C written now is technical debt.? (The next slide said that all Swift written now is technical debt, too, because the language is still changing so much.) But there is a kernel of truth to the argument. How much longer will Apple continue to release new SDKs for Objective-C? Two years? Five? It probably won?t be forever. We wouldn’t be surprised if Apple starts releasing Swift-only SDKs by 2017, and stops allowing developers to publish Objective-C apps to the store by 2020.
Those who dive into Swift now not only get a head start, they get a chance to make a mark. They get the opportunity to decide what the best practices and styles are for a brand new language. What will idiomatic Swift look like? Will the design patterns of new frameworks be drastically different? Will they be functional? Or even reactive? No one knows, but you can bet we?ll be waiting to find out.
Tell us what you think!
Have you started using Swift?
If so, what have been your experiences and if not, do you plan on using Swift in the future?
About the Author
Jon is a Senior iOS Developer at Nitro Mobile Solutions. When he isn’t curating a fine collection of animated GIFs, he works on iOS apps and frameworks for clients, for proprietary business platforms, and for internal use within the company. His background is in video encoding and analytics. To learn more about Jon, check out his company bio?here.