#WanariBuzz – TeamWanari Business Blog

The great Swift migration

Introduction

Tamás Keller

Tamás Keller

I like my coffee like I like my code. Without bugs in it.


LATEST POSTS

Mobile Apps

The great Swift migration

Posted on .

The conundrum

As you may or may not have heard already, Apple announced some rather important new rules to AppStore acceptance policy, taking effect this month. These affect all new submissions to the store, whether it’s a new app, or just an update. There has been no word about currently live applications being removed, but honestly, every app should be updated regularly, which means there’s no escape for anyone.

That is, if your goal is NOT to gradually downgrade the quality of your product. But hey, whatever floats your boat.

In this article I’m going to explain the major ramifications of this change, and our experience in tackling some obstacles that came along.

I am an iOS developer with over 4 years of experience, however since this topic doesn’t exclusively affect developers, but also product owners and managers, I will try and clarify technical terms as best as I can.

Sorry, devs 🙂

 swift migration app store compatibility

The rules

iPhone X support

This one came as no surprise: All applications must support the new Super Retina display introduced by iPhone X, meaning that they must respect the so-called Safe Area which spans the phone’s unobstructed surface (i.e. “the middle”).

It’s actually not such a great deal, since the increased phone resolution provides enough space to adjust our layouts. But here’s the cake.

iOS 11 SDK becoming a requirement for App Store

Some clarification for non-developers:

To those of you who don’t know what an SDK is, it’s basically the core kit that allows us to turn source code into working software. It’s a lot more complicated than that, of course, but you get the gist.

The main issue is that projects written in the Swift development language will only compile with the SDK version corresponding to the language’s version, and they are not (or just barely) compatible backwards.

Now that the iOS 11 SDK will be mandatory for commercial uploads, all said projects require Swift 4.

On with the technicalities:

If you or your team maintains a project that was originally written in Swift 2 (~2 years ago) which hasn’t been upgraded yet, you might be wondering: “How badly does this change affect me?”

In short: Quite a lot.

You will no longer be able to distribute these old apps through the App Store, unless you upgrade your source code to be compatible with the latest SDK.

The underlying challenge varies depending on the complexity, code quality and size of your application, along with the number of 3rd party dependencies used.

As you’ve probably guessed already, we too maintain/support a few of these older apps, and here’s what we did (and here is what you will likely have to do too).

The process

For the sake of simplicity I’ll only discuss one of the projects, since the process is usually, more or less, the same.

After the initial analysis, we’ve determined that the following steps were needed to completely migrate the source code.

Investigate dependencies, i.e 3rd party libraries and frameworks

Since the changes revolve around the Swift language, I’m only going to mention libraries (“libs” for short) that were written in Swift. Objective-C source code is still functional.

The main issue presented itself when we noticed that some of the these Swift libraries were “abandoned,” having no updated versions that support current Swift syntax. There are multiple ways of fixing this problem, which I will discuss later in this article.

Fortunately, most of the dependencies are regularly updated at least once a year (let’s call these the “progressive” ones), all you need to do is update your desired version numbers. We use CocoaPods to manage our dependencies, so it wasn’t really tough at first. However…

Code auto-conversion

Xcode (the development environment) has a built-in converter that automatically offers a Swift upgrade (pun intended) for your project upon detecting out-of-date source code being opened. Unfortunately, it has some imperfections:

  • If the code is flawed (at some point everybody writes stuff they’re not proud of), the results will stay flawed. It’s not a magic wand.
  • Parts of the language underwent such a big change that the converter simply cannot transform it.
  • There are also some more complicated coding techniques that are just impossible to convert, so there’s almost always some polishing needed afterwards.
  • And finally, it can only do Swift 2 → 3 conversions, THEN 3 → 4.

Yes, it means that we have to split the conversion process and library updates into 2 phases mentioned just above.

The good news is that going from Swift 3 to 4 is a cakewalk compared to the “horrors” of 2 → 3 as there weren’t as many changes in Swift 4 than before, it was more like an upgrade instead of reinventing the wheel.

My colleague, Robi has already published a post about the auto-conversion from Swift 2 to 3, check it out, it has some really useful tips:

http://leaks.wanari.com/2016/09/26/converting-project-swift-3-0/

Back to libraries for a bit

If a discontinued lib is not too large and finding a replacement proves to be too problematic, I suggest forking the repository and upgrading it yourselves, the auto-converter can help a lot here. Forking means making a copy of the repo, this will be entirely yours to manipulate. You can even make a Pull Request to the original repo to make your contribution.

One thing to mention about progressive libraries: Keep in mind that you shouldn’t upgrade to the latest version right away in phase one, as they often won’t compile yet. The versions you’re looking for are often stashed away on side branches.

swift migration ios mobile app

At this point, the code should compile and build successfully, we can finally start testing and modifying! But first…

Some cleaning

The automatic converter sometimes writes some new utilities directly into your project to help it compile right away.

Look for “FIXME” comments in the source code and eliminate them. These are all workarounds, you don’t want to keep these for various reasons.

  • The language offers way better solutions in their stead.
  • If not, then you might want to consider some refactoring, errors like these usually indicate bad coding practices.

iPhone X-ifying

Now that our code is up-to-date and the project isn’t filled with a myriad of errors, it’s time to go through the UI and make sure that everything looks fine on an iPhone X.

The parts to look out for are the topmost and bottommost section of the screen, make sure that your designs follow the  User Interface Guidelines set up by Apple. This will be either really easy or horrible, it depends on the UI in question.

Testing, testing, and more testing

Here we are, at the cornerstone of every nutritious breakfast. Make sure to subject your application to proper QA and UAT testing. Just because the code compiles successfully, there might still be runtime errors lurking ahead, syntax is NOT the only thing that changed over different Swift versions. Several bad practices were looked over and basically allowed by the core OS in the past, they actually cause crashes now.

Final thoughts

Overall, it could be worse. I’m not sure how many people are directly affected by this event, but I certainly hope this short post was useful to you.

Our projects were estimated to be ~10 days to fully migrate, they are still in progress, so I cannot give definitive times at this point, but I’ll update this post as soon as I have the final results.

I hope your upgrade process goes smoothly! Please leave your thoughts or corrections in the comments for the greater good, so we can all imporove!

Have a nice day, everyone!


We value your privacy and won’t give your info out. Ever.
Tamás Keller

Tamás Keller

I like my coffee like I like my code. Without bugs in it.

Navigation