Swift 4.0 Migration — ERROR..!! ERROR..!!

Worried..? Not Today..😎

Now that Swift 4 is here, sooner or later we’ll have to migrate our code.

Earlier, when Swift 3 arrived, migration seemed to be a tedious task ⚔️. Swift 3 contained some very major API changes. Of course, Apple provided us with the migrator tool to reduce manual overhead, but as we say there is always some loophole left no matter how hard we try. Even after the swift migrator tool did most of it, but still there was a lot of work left to be done by the developer himself 😰.

Now again we have to deal with one more such migration 🤢. But don’t worry, this time its not that difficult like before. There are not many major changes in the already existing APIs. Although, some new APIs are definitely added to the frameworks, but that’s not our concern right now. Our only focus at this moment is what changes we need to make in our code that uses the changed APIs.

Let’s Begin..!!! 🚀

Let’s have a look on the major errors and warnings that might appear while migrating your code to Swift 4.0.

1. @objc inference

Before Swift 4, the compiler made some Swift declarations automatically available to Objective-C. For example, if one subclassed from NSObject, the compiler created Objective-C entry points for all methods in such classes. The mechanism is called @objc inference.

In Swift 4, such automatic @objc inference is deprecated because it is costly to generate all those Objective-C entry points. When “Swift 3 @objc Inference” setting is set to “On”, it allows the old code to work. However, it will show deprecation warnings that need to be addressed. It is recommended to “fix” these warnings and switch the setting to “Default”, which is the default for new Swift projects.

The issue that I faced was with the _Selectors._😐

A selector expression lets you access the selector used to refer to a method or to a property’s getter or setter in Objective-C.

The method name and property name must be a reference to a method or a property that is available in the Objective-C runtime.

In short, selectors in Swift interact with Objective-C APIs and hence require an @objc inference. Earlier it was automatically handled by the compiler. But in Swift 4, you need to define it explicitly.

In Swift 3.2

In Swift 4.0 — use the Fix suggested by Swift compiler 😬 and it will add @objc inference to the selector method.

2. Declarations from/in extensions cannot be overridden yet

In Swift 3, there was no restriction on method overriding from or in a class extension. But in Swift 4, you just cannot yet (it might be available in near future).

Extensions add new functionality to an existing class, structure, enumeration, or protocol type. This includes the ability to extend types for which you do not have access to the original source code

Extensions can add new functionality to a type, but they cannot override existing functionality.

While migrating to Swift 4, you’ll get compile-time errors 🙈 if you have used extensions to override methods.

In Swift 3.2

isValid() is defined in BaseCell’s extension

isBlank() is defined in BaseCell original source code and overridden in SampleCell’s extension

In Swift 4.0 — just move the overridden methods’ definition to original class source code 🎯

3. NSAttributedString attributes’ key names

A very straight forward change is introduced in NSAttributedString API — the key names corresponding to the attributes of an attributed string will now be referred using an enum NSAttributedStringKey.

Example:

NSFontAttributeName will now be referred as NSAttributedStringKey.font
NSForegroundColorAttributeName will now be referred as NSAttributedStringKey.foregroundColor etc_._

In Swift 3.2

In Swift 4.0 — simply use the Fix suggested by Swift compiler and it will do all the work for you 😅

Promotions

Don’t forget to read my other articles:

I will update the article as I proceed further with the migration. Watch this space for more on Swift 4 migration.

Feel free to leave comments in case you have any doubts. 🙂🙃