Apple dropped two big surprises at WWDC 2014 directly at developers. Here’s a quick look at what they might mean for your app development.
Swift Programming Language
This week, Apple announced Swift, a whole new language, developed in-house, which aims to be the successor to Objective-C for all Apple development work.
- Compiles to native code sharing the mature LLVM compiler with ObjC
- Uses ARC for memory management, not a runtime garbage collector
- Tuned for performance and code safety, like a good modern language
All indications are that Apple is not holding back with Swift, and I fully expect that within 2 years, the vast majority of new iOS applications will be built using Swift.
I recommend that all iOS developers start familiarizing themselves with Swift right away. Apple has a big-ass manual available for free on iBooks that gives the full language specification. And more learning-friendly books will no doubt be announced by the end of the month.
But don’t turn your existing development plans on their head just yet. There will be plenty of early-adopters building meaningful apps with Swift. Let them be the guinea pigs for now. Apple isn’t killing support for Objective-C anytime soon (in fact, the way Swift is built, Objective-C continues to share improvements in the underlying compiler and runtime.)
There was very little said about Apple’s CloudKit announcement. But I think it’s a very bold move, and not one that’s clear to pay off for Apple.
CloudKit appears to be a direct competitor to Parse, which was recently acquired by Facebook, and has been undergoing an identity crisis as it figures out what developers it’s actually going after. I know a number of developers who are fleeing Parse based on lack of customer support, scalability challenges, and distrust of Facebook as a shepherd for the platform’s future.
Apple is providing extremely generous limits for a free platform provider, presumably to be more aggressive in luring the first crucial customers to their cloud.
If I had to guess right now, I don’t believe that CloudKit will be wildly popular for the “serious” backend developer. It has three major limitations:
- iOS only — the promise of building a backend API that will work with iOS/Android/Web is busted right from the start.
- Unproven platform performance and support — Apple doesn’t have a great track record with cloud services themselves, so developers will be wary of trusting their backend to Apple
- Proprietary technology — almost all mobile backends are built with open-source tech, which makes it easier to port them across cloud providers, and easier to hire developers with the skills to maintain/grow them
Could be great for you!
If you are building an iOS-only application that has modest cloud-data needs, or if you can’t find/afford a separate backend developer, but need your iOS team to prototype out the end-to-end app, a CloudKit deployment could be a great option.
Brent Simmons writes about this exact issue for iOS developers:
Design is what it does, how it works, and what it looks like. Implementation is what you do in Xcode. The back-end is — well, it’s, hrrmmm, something other people do? Or something we just ship without?
CloudKit is Apple’s proposal to solve backends for iOS developers.
If you are in this camp, a solo iOS-only developer who needs data syncing, or cloud backup, or server-side business logic, I recommend you seriously look at CloudKit. You’ll be on the bleeding edge for now, as I expect much slower adoption of CloudKit than of Swift. But the potential time-savings for a Platform as a Service offering that couples tightly to your native app development is a promise worth exploring.
perhaps with lingering Objective-C scattered about, much as we used a lot more raw-C in the early days of XCode work. ↩