I presented last night at Seattle Xcoders, first time in a number of years – last time was when I was still working for Disney. The presentation was a rehash of the talk I did at the Swift Cloud Workshop a couple of months ago, and sharing a bit of what I’ve learned from my bug fixing and “getting into swift” learning by working on the Swift Package Manager.
I have a few more fixes and bugs I want to tackle, but for the past two weeks I focused on getting back into the cocoa frameworks; relearning and catching up. I was last using these libraries about 7 years ago. My oh my, the world there as seriously changed! There are some nice things, and some not so nice things – great technical advances and a couple of head-slappers.
First thing that’s obvious is the API surface area has grown enormously. All the pieces I worked with previously are there, and nearly double that as well with new libraries and frameworks. The frameworks are akin to tree rings too – you can see the generational aspects of when the API’s were first developed in the method signatures – some using NSError callbacks, some using blocks, and less consistency than you’d expect from a decade of evolution. Or perhaps exactly what you’d expect from a 15+ years of organic growth and language evolution.
Alas the documentation hasn’t kept up with the API surface area – even from external publishers. Where I used to be able to know 90% of the key API structures from something like the Big Nerd Ranch’s IOS Programming guide, it only covers an introduction today – and misses entirely some of the things like Storyboards and anything in depth with Autolayout. Apple’s documentation has even less structural organization around it, still embedded and (mostly) technically correct, but extremely limited. Without the sample code and WWDC videos they publish to tease it apart, I would be lost – as most of the documentation is written with the expectation that you already have the knowledge you’re seeking on how to use the frameworks.
I also find it immensely frustrating that you can’t download the various guides they publish to something like iBooks and read them offline or on the side with an iPad. There is contextual help in Xcode, but the screen real-estate is so cramped on my laptop that I’m often keeping an iPad on the side with some documentation (or that big nerd ranch book propped open) while I’m digging and learning.
When Apple enabled their forums, I thought that might help with some of the gaps, but in reality it’s StackOverflow that’s made the difference. The Q&A site often includes sample code in detailed questions and answers from a community helping itself, and it isn’t uncomon for the answers there include references back to the formal documentation. That linkage provides the “explanation” for that otherwise arcane but technically accurate wording in the Apple provided documentation.
And finally there’s Xcode – I still see the fragments of the separate interface builder in references, but it’s all a single app now. The debugging and diagnostic tools provided by Apple are absolutely amazing, especially some of the recent advances visually displaying view and memory debugging, and the whole “Instruments” tool chain that have been my gold standard for understanding how a process is operating since I started working on other platforms those 5-7 years ago. I keep trying to recreate those capabilities using whatever native tools I can find on the other platforms just to see what’s happening.
I am not as much a fan of the design tooling. The storyboards views and complex inspector setup, as well as the “fiddly magic” of knowing what to click, where to click, and how to link things together isn’t well coordinated or even consistent. I think it represents the steepest learning curve to developing IOS apps, which is frustrating, because you can tell it’s trying to make it easier.
Also frustratingly, it’s not internally consistent from a composition point of view – so there’s times when you just need to wipe out a whole view controller and recreate it rather than starting with something small and building up to what you want.
When IOS first came out, I built and taught some workshops with O’Reilly to get started on it – with the complexity of the APIs, development setup, and learning the technologies you need to use to get started today I think it would take weeks for a person completely new to the Apple ecosystem. I’m not even sure a week-long bootcamp style setup would do more than introduce you to the barest minimum needed to get up and running.
I’m not at all surprised at the focus on technologies like React Native for leveraging web development knowledge into mobile development, although that’s got to make debugging a comparative nightmare. Not my interest, to be honest, because I wanted to see what was possible (and new) with the native capabilities. But I can see the appeal in leveraging knowledge you already have elsewhere.
Rhonabwy 