This year I experienced my first iOSDevUK conference — a conference that takes place by the sea in Aberystwyth in Wales. I really enjoyed myself and the team who put the conference on do a great job. As someone with tricky food needs I particularly appreciated the attention they paid to this!
This week I was lucky enough to be interviewed by Scotty on his and John’s excellent iDeveloper podcast. This means I also made the flint.tools website live!
I’ll be honest, at first I felt there were not many exciting things at this WWDC. Personally I am very happy to see the new notifications improvements and Siri shortcuts, and I can verify after running iOS 12 beta on an iPhone 6 that the performance improvements are very real.
However, on deeper investigation in terms of Flint framework there were some definite points of interest that affect us and some new things we can do in the future when these final OS releases come out, so that we get even more out of our code. If you don’t know what it is, Flint is a small Swift framework that helps you modularise your code around Features and Actions, removing huge amounts of boilerplate and complexity for you when dealing with many common tasks on Apple platforms such as permission checking, publishing NSUserActivity instances, URL mapping, feature flagging and in-app purchases.
Making mistakes is how we learn. But not all mistakes are equal, and making the same one over and over is not learning.
Often I run two or more different Xcode builds on the same machine, either because a client project can’t yet build on the latest Xcode release, or because we’re in a new Xcode beta period. Of course I forget which one I am running, especially if switching between projects multiple times in the same day. Xcode 9.4 is here today, and Xcode 10 beta is around the corner at next week’s WWDC 2018! It’s arguably the worst time of year for this problem.
Flint is our open source framework for tackling a lot of Apple platform boilerplate code. One of the many powerful things it gives you is support for Conditional Features in your apps. You define how your feature is toggled on or off, and your code is not allowed to even run the actions associated with the feature unless all those toggles are on. This post is about some great improvements to this mechanism and how we tackled them.