Swift 4 Release: How to migrate your project to Swift 4 programming language
Swift is an open-source statically typed programming language, introduced by Apple at Worldwide Developers Conference in 2014. Though appeared not so long ago, Swift quickly became the hottest language for iOS app developers and their favorite.
According to Stack Overflow Developer Survey, Swift took the first place as the most loved programming language in 2015 and the second place in this category in 2016.
Noteworthy that the founders take care of constant improvements and updates. The latest update, called Swift 4, came into life on 5th June 2017, and the main focus was made on ABI stability for the standard library and reflection enhancements.
While building on the strengths of Swift 3, Swift 4 programming language provides a higher level of stability and ensures source code compatibility with Swift 3.
What’s more, now iOS Swift development takes less time. Also, a new version adds such features as smart key paths and serialization and has a reduced size of app binaries. But let’s take a closer look at what’s new in Swift 4.
So, what’s new in Swift 4
- Improvements to reflection, Dictionary and Set types’ creation and manipulation
- Adds smart key paths for type-safe key value coding for Swift types
- Enforced exclusive memory access
- Makes the use of Strings, which retain Unicode correctness, easier and quicker
- Adds extended support of archival and serialization
- There is no need to modify code in order to use a new compiler version
- Allows type-safety for serialization to formats like plist and JSON
With the emergence of a Swift 4 update, the migration to Swift 4 programming language becomes the issue of the highest concern for iOS app developers. In this post, we’ll speak about migrating projects to Swift 4. Let’s start with some useful tips.
Migrating to Swift 4
- First, ensure that the project you’re going to migrate to Swift 4, builds successfully in Swift 3.2. You should also remember about significant differences between Swift 3.1 and Swift 3.2, so your project may have some errors (for example, if it’s built in Swift 3.1) that need to be solved before migrating.
- Take into account that by making an iOS project managed under source control you will be able to easier review the changes that were implemented through a migration assistant as well as to discard them and restart the migration process if necessary.
- Since the Migrator is embedded directly into the compiler, it can simultaneously understand and compile the codes of both Swift 3.2 and Swift 4 versions, that is there is no need in modifying the code in order to use a new compiler version and Swift 3.2 and Swift 4 languages can “work” together. So, keep in mind that you can use a Swift 4 compiler and migrate your project piece by piece.
- When you’re about starting the project migration from Swift 3.2 to Swift 4, Xcode 9 provides you with a migration tool facilitating the process. When opening the project in Xcode, use the Issue Navigator ensuring the ability to navigate to Edit -> Convert -> To Current Swift Syntax… to launch a conversion tool.
- When starting the migration process, there will be a list of targets to migrate. After taking which targets you’d like to convert, Xcode will request a preference on Objective-C inferencing. Choose the recommended option to reduce a binary size by reducing inferencing.
- A migration assistant does a migrator build to collect changes, using the scheme you’ve chosen, so the targets that will be processed are the targets in the scheme. To review and modify what the scheme contains, invoke the Edit Scheme…sheet and choose a Build tab. Ensure that all the targets and unit tests are also included.
- You can select between two types of @objc Inference. Minimize Inference: you should add a @objc attribute to the code only where it’s required based on static inference. After that, you need to follow manual stages detailed in Completing a Swift 4 reduce inference migration to finish the conversion. Match Swift 3 Behavior: add a @objc attribute anywhere it would be inferred by the compiler. Since this option adds explicit @objc attributes everywhere they were implicitly added by Swift 3, it doesn’t change a binary size.
- By clicking “Next” you’ll move to a Generate Preview sheet and a migration assistant will initiate a migration build to receive source changes. Once it’s completed and you click on “Save”, all the changes will be applied.
- If you face some issues and difficulties with targets’ processing (when they negatively affect the migration to Swift 4 programming language), switch to Report Navigator and choose a Convert entry that was added and check a conversion build log for errors. If you come across the errors about not being able to code-sign the target, try to disable code-signing from the target build settings.
- Keep in mind that there may be compiler errors related to fix-its. While the migrator is created to incorporate fix-its enabled by the Swift 4 compiler, some of them may not be applied in case they aren’t applicable 100% of the time.
Working with Carthage/CocoaPods
Also, while migrating iOS projects with external dependencies to Swift 4 and using such package managers as CocoaPods or Carthage, you should take into account the following points:
- Ensure that both your targets and source dependencies build successfully in Swift 3.2 mode.
- Note that since source dependencies build successfully in Swift 3.2, you don’t necessarily have to migrate them.
- As Swift 3.1 modules aren’t compatible with ones of Swift 3.2 and Swift 4, it’s more reasonable to use source dependencies rather than binary Swift modules.
- In case there are setup framework search paths for finding binary Swift modules inside a Carthage’s build folder, you should remove them or clean a build folder.
Hope, the article has been useful for you and these tips will help you easily migrate your projects to Swift 4. As we specialize in custom mobile app development and have large expertise in iOS Swift development, feel free to apply to us with any issues!