They Call Me Mr. Upgrade

I’m not a very old person, but I feel like development used to be a little different 6 or 7 years ago. I’d write a program (say in Java), the syntax / libraries would be good for around 1–2 years, and when things started to deprecate, i’d have another 1–2 years to make a change.

Today, things tend to be a little different. Now we get major iOS revisions every year and with the introduction of Swift back in 2014, the annual upgrade has become complicated. To be clear, i’m actually okay with all of this happening, as it’s actually very good to see so much development effort being put into Swift, but as the person doing the upgrade, the details can be highly frustrating.

At Liquid, I’ve been tasked with upgrading all of our iOS applications to iOS 10, along with LPK. If you’ve been following my blog entires with working on LPK, i’m happy to announce i’ve upgraded all of our tutorials to support the latest XCode and iOS. A friendly reminder that you can find all of them here:

The Dependency Game

LPK has a bunch of dependencies, all of them managed with Pods. If all your libraries are in Objective-C, you probably haven’t noticed a huge impact when upgrading to iOS10 (at least I haven’t). But if any of them have Swift, then it can be a little frustrating.

First, Xcode 8 requires all your Swift Code to be at least Swift 2.3 compatible (preferably Swift 3.0). To be fair, the Swift team has been deprecating plenty of code for the past few months. If you’re code requires some upgrading, you’ll be notified when you try to open up your project in the latest XCode. The convertor isn’t perfect, but it’ll do most of the work for you when converting Swift syntax. Converting your own code isn’t that bad, but using incompatible libraries can be a pain.

In a perfect world, the dream would be to pray and hope that at the time you’re upgrading your own code, the developers for your libraries are doing the same. Unfortunately, this is not the case. Even at the time of writing this post, one of the dependencies for LPK just made a push to support Swift 3.

If your libraries are really old, there’s really not much you can do other than try to fix some of the errors yourself. If the pod / library is recent enough, you can still rely on the “Use Legacy Swift Language Version” flag, found under build settings.

UI Funniness

Other than the massive Swift upgrade, typically there the annual upgrade (for some reason i think of the annual purge or something…) means something in your UI is going to change. Last year I believe it was the way tableview and popover internals worked, and this year it’s toolbars. Perhaps it was just the way we coded toolbars at Liquid, but almost all the toolbars we used ended up having a white background to it. We had to manually fix each one and add a translucent property.

XCode was also much stricter about autolayout, and some things in our app that worked in iOS9 didn’t work in iOS10. But this i’m actually much more okay with, because it is a clear issue with the way we did autolayout, and forcing the developer to fix their mistakes is always good for everyone.

Another year has passed and another chunk of time has gone to upgrading to iOS10. It wasn’t the worst of all the years I feel like, but it was definitely a little bothersome. Hopefully next year, it will be a bit smoother.