The strong type system in Swift provides enhanced type safety with compile-time checks to prevent errors before they can become runtime crashes (it is better to fix a bug early), and that’s why compile-time error checking is so important.
Apple’s other enhancements include API availability checks for compile time assertions that ensure all source code being used is supported on the current iOS version selected in Xcode. Availability is important for any company that needs to release a public SDK for app developers to integrate into their own apps. Lastly, nullability helps the Objective-C APIs work with Swift’s optional type system and makes the imported Objective-C APIs Swift-like using optional typing information.
Apple’s introduction of Swift 2 does break existing code, yet the latest version 2.1 (as of this writing) is a major leap forward as Swift continues to mature. These breaking code changes are vital to Swift if it is going to become an industry standard in the development world.
Swift was open-sourced in December 2015, when Apple published a road map of upcoming features for Swift 2.2. Apple has also opened the discussion to the development community for the direction of Swift 3.0 and beyond.
In Swift 2, new control flow keywords and language structures allow you to make your intentions clearer using the first line of code you write. This straightforward approach allows you to know what is happening in a block of code and improves your ability to properly maintain your app’s control flow. The
guard keyword enables early exits and protects code logic from having invalid inputs. The
defer keyword allows you to clean up resources when they finish or in the event of an error.
repeat/while loop and the
do scoping continue to provide support for both readability and Apple’s new error handling model, which is driven by programmer intent. Any method declaration (method signature) that is potentially unsafe is marked with the new
throws keyword. Any method call to an unsafe method (one that can throw errors) is marked with the new
try keyword. Error handling in Swift is performant, on par with return statements, unlike Objective-C -- which is one more reason to adopt error handling using Swift for your next app project.
Along with the changes to control flow, Apple has modernized existing APIs for the OS X v10.11, iOS 9, and watchOS 2 SDKs using new language features in Objective-C that enable you to use Objective-C APIs in Swift seamlessly.
What this means for you is that the all-new Swift 2 is ready to use, and everything about it feels like Swift, even if you’re leveraging Apple’s vast Objective-C APIs and extensive SDKs. If you’re not already on board, the time is ripe to start your next app in Swift.
Sign up for CIO Asia eNewsletters.