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!
Aside from listening to Scotty complain in typical British fashion as we British do about the trains all the way to and from Wales, I met many nice and interesting new people from all over Europe and saw several interesting talks. I met at least half a dozen people I’ve only ever interacted with online. I can strongly recommend this conference as something really quite different, it had a great friendly feel and it is in such a beautiful place.
Talks of particular note include Paul Hudson’s Swift and Star Wars mashup, Dave Verwer’s talk on app marketing and “Jobs to Be Done”, Ellen Shapiro’s session on choosing which “Fucks to give” and Luca Bartoletti’s talk on his work at Citymapper. Did you know they experimented with their own bus service in the UK?
In terms of my ongoing work on Flint framework it was certainly very interesting. I was giving out stickers and shirts to anyone who would take them, which is excellent practice for trying to distil the message about what Flint and feature oriented development is about and what goals it serves. It takes time to iterate and get these things right.
In fact by the third day I was inspired to spend 2-3 hours after midnight in the conference accommodation putting together slides for a future lightning talk on Flint, which I’ll also draw from to make video screencasts soon.
What did surprise me was that most of the sessions I attended had overlap with what Flint is trying to do. Indeed in the very first workshop there were questions from the audience about the possibility of hooking up analytics tracking into UI coordinators. Given my Flint perspective I would say that is the wrong place to do it, unless you are tracking something specific about coordinator behaviour. Flint’s action-based analytics support tracks activity at the point of execution, not at the point of UI navigation which is usually a better fit.
Several sessions had to spend a lot of time talking about requesting system permissions for e.g. HomeKit and Speech Recognition and access to Calendar Events which each have similar but discrete APIs for requesting permissions. There’s a lot to think about with these APIs even if you only need one kind of permission, let alone complex apps that require multiple permissions. There’s always the advice to carefully onboard users and prepare them for the permission you are about to ask for — something that is nuanced and hard to get right. Flint’s authorisation controller deals with all of the plumbing for you in these scenarios, and you just have to show the appropriate UI at each step or tell it to skip if the user wants out.
Luca’s Citymapper talk mentioned how they have lots of ugly feature flag #ifdefs everywhere and how they’d like to move away from this, which is one of the main reasons I created Flint — the horror of not knowing if your code was correct or would even compile without toggling all the different #ifdef permutations and building (and testing) with each, and that this usually requires checking the feature flag in many places throughout your view controllers, and if you miss some places things can go bad in obscure ways. Conditional features make it impossible to invoke actions related to a feature that is flagged, without first checking you can perform them.
Many talks involved talk of decoupling your logic from UIs using coordinators or flow controllers, and the relative merits or not of MVVM. The fact that there will never be agreement on how best to wire up logic and model to your UI is why I designed Flint to not mandate any particular model for this — that is beyond the scope of the framework and too limiting. By taking just a single input type and a presenter type that, thanks to the power of Swift, can be absolutely anything you want (View Controller, Coordinator, Flow Controller, or even just a function) we have largely avoided the entire issue while supporting pretty much all possible approaches you might use in an app.
Chris Winstanley presented about iOS 12 Siri Shortcuts in apps which was very timely as I had just that day started work on finding the right way to express this support in Flint. Work on that is progressing nicely and we should have something to share in a 1.0-ea4 release soon. This is turning out far more nuanced than it would at first seem. We’ll have support for automatic donation of shortcuts via NSUserActivity if you want that, as well as automatic donation of INIntent based shortcuts too. Support for invoking actions from a given INIntentHandler implementation and support for continuing the activities that come back to the app if the user taps the Siri result panel of a shortcut it has executed (that’s a fun little element right there). These APIs are just bedding down at the time of writing.
Interestingly, on the second to last day I met a Rails developer who is learning iOS development. It was really interesting to talk to someone who has seen conventions over configuration and “smart” wrapper APIs in an app framework before and can understand what something like Flint is trying to achieve. You often get the feeling in Apple development circles that these things are not something you need or want in native apps. To be fair, people in server development initially felt the same about Rails et al. I recall first hand the resistance to Grails in the Java, J2EE and Spring community.
Nevertheless, it’s going to be fun helping people learn what is possible if you embrace these kinds of tools! If you think this sounds like an interesting project please join the Flint newsletter mailing list and check out the project.
