We are all beginners again (sort of)
WWDC has ended and it will be missed. For iOS developers the world over, the beginning of end of WWDC marks the start of Beta season. Beta season is where iOS devs get to spend every few weeks downloading a new version of Xcode and a new set of API changes and hope that those changes didn’t undo our previous two weeks of work. It is an exhilarating dash to get apps out and ready before the new phones drop in September and iOS(current++) is released.
I don’t mean to sound harsh, I say all of this out of love. Developing for iOS has allowed me to do the best work of my career and to have the most fun doing it. Apple’s summer crush of new features is a very marked contrast to the system that Rails and JS developers have to deal with where a new frameworks are released daily. One framework (call it Toad) will be quietly released. Soon it will gain adherents and github followers, and hacker news articles which will trumpet it as the second coming because it allows you to write your code using IOUs instead of promises. There is much rejoicing followed by a backlash of developers who find themselves unable to switch to Toad because their current project was started using the old hotness, Ode. Toad v. Ode will spawn Twitter fights, meme smack-downs, and ten thousand new meetups. Java script message boards will be full and Twitter will scream and no work will actually get done. Not that it would have gotten done anyway because npm is down again.
The end of WWDC also marks the conversion of technical debt into actual problem as a years worth of cut corners and deferred maintenance begins to break wildly against a new SDK. Mobile departments and consultants try to get budget for refactoring or rewriting parts of code are suddenly unmaintainable. It is usually a hard conversation because no one want to hear the word “re-write” after spending copious money on a project that was perfect two weeks ago. However this year, Tim Cook did all the heavy lifting during these painful conversations by announcing Swift, the new Apple Programming Language. The question now becomes not if we get to rewrite, but when.
Since Swift’s announcement, I have been telling people that it is a great time to be an iOS developer because we all get to be new again. Patterns of thought and code snippets that we have been honing for the past six years all get to be examined and re-engineered. The conventions that have grown up around the language will be shattered and begun anew. It is a grand opportunity to see our apps and our work in a new light and for us to become better developers.
Unfortunately this is not actually true.
After spending a week with the language and porting a few existing classes to it, it turns out that Swift is not actually that big a deal.
Objective-C as a language is probably the smallest fraction of the total knowledge that one needs to create an app. The syntax is creaky and weird and it is charmingly verbose, but knowledge of the language itself has never really defined the quality of the developer who wields it. True skill as an iOS developer has always been and always should be defined as a mastery of the frameworks that Apple publishes and how they create utility and joy for the user. It is the difference between a developer who can hit the ground running on a project and one that is going to be copying and pasting code from tutorials all day long. It is also the difference between a developer who can talk to design and product about ways to improve the quality of the app and save hours of wrong thinking. At Monsoon we pride ourselves on hiring people who are able to look at the whole product and bring it to life from end to end, which is a lot different than being able to memorize all of the gotcha’s of a language that has been around for decades. Swift changes that not one jot.
In hindsight, some of the changes that Apple has made to Objective-C over the past years have made Objective-C a whole lot more like Swift-like than it seems at first glance. ARC (compiler based memory management) is the biggest example of this, but the profusion of blocks in the API over the past three releases have already shaped developer minds around the idea of using closures. Ty Enums have become a lot more strict (so that they can be more useful) and the ability to add associated objects to private objects looks a lot like Swift’s extensions. A lot of the other big name features of the language (namespaces, extensions, generics) are really just ways for developers to get things done quicker without having to resort to black magic like method swizzling. Given a few weeks of writing Swift I am sure that developers will start to wonder why it was never thus before. Swift will make developers’ lives easier, but users will not notice.
Pixel Perfect No More
The bigger change at WWDC is the focus on adaptive UI. Apple did not actually announce devices with different screen sizes but they are no doubt coming. The Apple rumor complex debates about the exact size and shape of these new screens and if Apple will supply the same magic that made the transition to retina devices so seamless. The introduction of Adaptive UI informs us that the there will be no magic and that they will create several different screen sizes and shapes. It will be up to the developers to make it work for their apps. I am not looking forward to the iPhone six announcement at all.
At Monsoon we have begun testing iOS devs on their ability to deliver “pixel perfect” renditions of mocks from designers. That is no longer a thing. It is now auto-layout or nothing.
The great Un-bundling continues
More than the introduction of app backgrounding in iOS 4.0 or even ‘true’ multitasking extensions change the way we think about apps. Instead of just having the ability to run two apps at the same time (thus making it easy to cut and paste data from one to the other), extensions give developers the ability to send the functionality the user wants into another app.
Extensions allow us to spread the thing that makes our apps special, its secret sauce, across the entire Apple Ecosystem. It allows all a chance to become a platform.
It also means we can now write more focused apps and release them as suites. This will allow us to keep each app focused on doing one thing well and release them to the app store more often.
Several high profile apps have already split themselves into smaller components this year (Foursquare into Swarm, Foursquare and Foursquare for Business and Facebook into Facebook, Paper, and Messenger). The introduction of Extensions is going to speed this trend.
Cloud kit is where Parse was 4 years ago. The nice thing it has going for it is the integration with your appleID so a user could download an app and sign in without signing in at all. However since it is not cross platform I don’t see may clients passing up a true cross platform back-end solution in order to get Single Sign On.
Both may actually be useful now that we can run pre and post build scripts and the Testflight acquisition may have fixed Testflight.
XCTests is now worth our while to roll out on every project. The ability to test Asynchronous code means that we can usefully test systems integrations rather and unit based minutia (which I am beginning to believe does not really belong on the client side at all).
WWDC 2014 dropped a lot of new things on developers and radically changed our tool set, but it did not changes what we do. It changed how design apps, how we think about how they interact with others and how we interact with our servers, but it does not change the thing that we have to do everyday. We are still just trying to get ideas into the hand of people who will be enriched by them.