Should I Be Using Swift or CloudKit for My iOS App?

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

Since the beginning of iOS and Mac OS X, developers have been building apps using Objective-C, with a smattering of C/C++, and a brief flirtation with Java Cocoa.

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
  • Modern language by design, feels like an alien hybrid of Python and Javascript
  • Uses ARC for memory management, not a runtime garbage collector
  • Tuned for performance and code safety, like a good modern language
  • Despite being compiled, has an interactive debugger that acts a lot like a modern script console that Python, Ruby, or Javascript developers will be familiar with

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[1].

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.)

CloudKit

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.


  1. perhaps with lingering Objective-C scattered about, much as we used a lot more raw-C in the early days of XCode work.  ↩

What WWDC 2014 Means for Your App

In addition to introducing lots of interesting consumer software features, Apple’s Worldwide Developer Conference 2014 was jammed packed with important announcements for teams building mobile applications. Here’s an early look at what these announcements mean to teams building iOS applications.

Design

Good news for battle-weary developers after last year’s major iOS 7 overhaul — the fundamental design language of iOS 8 remains the same. But we’re now two generations out from iOS 6, and if your app hasn’t yet adopted a new design, it’s officially feeling antiquated, and it’s time to invest that effort.

It’s also safer now to adopt some of the more obscure iOS 7 gestures, like swiping to take action on items in a list, and the back-swipe as a universal back button. Apple’s continued use of these gestures will make them both less opaque to users, and more expected in 3rd party apps.

Swipe UI
Swipe UI

Device Support

While no new hardware was announced at this WWDC, the writing is on the wall for continued resolution independence. All indications are that a larger iPhone is coming this year. And in the new XCode 6, the simulator has options for a mysterious “Resizable iPhone”, which tells me that developers should start making their UIs more fluid now, in preparation for more diversity in device aspect ratios.

XCode6 Simulator Options
XCode6 Simulator Options

As far as we know, all iOS 8 devices will be retina, which eases the burden of shipping too many different assets in your application. But it’s not impossible that new resolutions (e.g. @3x) will be introduced with upcoming devices, so be ready with high-quality vector art, while continuing to push more design elements into code.

App Store Changes

There are lots of changes to the AppStore coming

  • Video “screenshot” previews
  • App Bundles, to sell multiple apps at a special bundle price
  • Related searches
  • Explore Tab
  • Editors Choice badges
  • Trending searches
App Bundles
App Bundles

I’m a bit concerned that these changes will add up to make the AppStore an even bigger popularity contest, especially those last three features. It makes discovery

Also worth noting is that a search in Spotlight will now return AppStore results, which could make a nice shortcut for prospective users to find your app in the store. I expect to see more apps advertising “search for us on your phone” if this feature works smoothly.

Custom Keyboards and Predictive Typing

Most of us are probably not going to build a custom keyboard. But app developers should be prepared to start testing their apps with 3rd party keyboards. Especially if you’ve been extending the top of the keyboard with custom buttons. Time will tell how well-behaved custom keyboards are, but no doubt some subtle bugs and usability issues will be lurking here.

Custom Keyboards
Custom Keyboards

If you have a text-entry-heavy application, spend some time with the new predictive typing as well. It’s still unclear how much control developers will have over the suggestions in their application (Apple says it’ll “learn each user and app”), but it’ll have an impact on your user experience for sure, and takes up even more space above an already bulky keyboard[1].

iCloud Drive

If your application deals with documents, or can open other document types, you’ll touch iCloud Drive somewhere.

In my opinion, this announcement is a lot bigger than the press it’s been getting. For the first time on iOS, we have something closer to a true filesystem. Users will begin to expect an experience more like they have on desktop, where your app can import, export, and support more filetypes stored in their iCloud Drive[2]. All file management in your app should be done using the new floating panel Apple provides.

TestFlight

Apple’s acquisition last February of the TestFlight service is starting to bear fruit. App developers can now run beta tests with 1000 users (and each may have multiple devices!) That’s a game changer for any large-scale beta testing effort. And it’s free.

The major downside is for cross-platform devs who would prefer a service that works with both iOS and Android, and who will probably turn to the fortunately-timed new beta distribution offering from Crashlytics/Twitter.

Extensibility

This is probably the biggest tectonic shift for iOS app developers since the launch of the AppStore itself. For the first time, the core operating system will support inter-app communication and services.

To date, most apps have been hacking around inter-app communications using custom URL-handlers, so other apps could trigger your app to launch with parameters. It’s worked surprisingly well, but is severely limited.

With Exensibility, your application can publish and consumer functionality that includes

  • Register your app in share sheets
  • Offer data and services to other apps
  • Create UI that can be embedded in other aware applications, like 3rd party photo manipulation tools that all camera apps can use

Remember to play nice with other apps in your ecosystem. Very few apps can afford to wall themselves off, and user expectations for interoperability are going to keep growing. Get out ahead of it with application extensions.

Widgets

Related to Extensibility, and even more immediately apparent to users, are Widgets for iOS. An ancient feature on Android, iOS is exposing widgets in Notification center, for things like weather and sports scores.

Along with Extensibility, this is a tool in the development arsenal that you shouldn’t ignore! The opportunity to have your app present on the lock screen and notification center, visibly in the daily workflow of your users, is a privilege. Time spent crafting a beautiful and useful experience in your widgets will pay off in spades with user engagement.

Widgets
Widgets

TouchID

If you have secure data in your app, start using the TouchID API now to unlock it. Basically, anywhere you were already prompting for a password should optionally use TouchID.

For other personalized devices, this is great too. Like I should have to confirm my TouchID before a remote control app will open my garage doors, or show me my medical history.

Continuity

Apple is making big moves in the area of placeshifting, most noticeably with their new Continuity feature. But this is only relevant for Mac OS X machines right now.

If you are building productivity, creative, or developer tools, you likely have a disproportionate Mac user base. We will start to expect integration between iOS and desktop, and I suspect that at least basic support for this will become table-stakes for high-end multi-device apps.

You can get away with ignoring Continuity in a new app for now, but expect users to bug you about it.

Location Aware Apps

Not specifically mentioned in the keynote, but reported by AppleInsider, app developers who also have a brick-and-mortar presence, can use iBeacon technology to put shortcuts on user homescreens when the iPhone is in the proximity of a store.

Location-Aware Apps
Location-Aware Apps

This won’t be used very often, but it’s an important trojan horse to what I expect will be a future holistic iOS payments system.

Metal, SpriteKit, SceneKit

For game developers, Apple continues to lead the pack. With improvements across the board, there’s no question that iOS will remain the most popular mobile gaming platform for developers.

Even if you are a pretty serious 3D gaming developer, chances are you won’t use the new Metal framework directly. You are probably building your app with a toolkit like Unity, and when they release a version that supports Metal, you’ll automatically get the advantages in your app.

For casual game developers, SpriteKit and SceneKit are likely to substantially speed up your graphics and physics engine development.

Swift and CloudKit

These topics were worthy of their own post. See Should I Be Using Swift and CloudKit for my iOS App? for the low-down here.

What about HealthKit and HomeKit?

Obviously, if you are squarely in the health/wearables applications or home automation space, you are paying very careful attention to those elements of the WWDC announcements.

My guess is that for at least the next year, these features are going to suffer the same fate as PassKit, announced last year. There was a flurry of initial experimental support, but very few users integrated it into their daily workflows, and it has languished. Even power-users I know make very little weekly use of PassBook.

My recommendation is to watch curiously from the sidelines unless your core business relies on health or home features.

Resources

Follow the whole announcement with great photos and commentary at The Verge


  1. Particularly concerning for iPhone 4S, the last remaining “short” form-factor phone that will run iOS 8  ↩

  2. or Dropbox, Box, etc., via the new Extensibility features  ↩

Email in 2014 is Mostly Mobile

Email testing and tracking company Litmus published a great look at email client traffic in 2013. The upshot is that more than half of all emails are being read on mobile devices, and the trend will continue. Litmus finds a whopping 38% on iOS alone.

In response, you’d better be testing how your emails look on those devices, and doing responsive email design up front to make the best impression with all your email communications.

Email Client Market Share
Email Client Market Share

iOS First, and Three Reasons You Might Not

For practical early-stage startup purposes, there are really just two mobile platforms.[1] Apple’s iOS and Google’s Android.

Start with iOS Only

If you are launching a new mobile application, build and launch it on iOS out of the gate, and forget about Android for a while.

I say this because I’m an incurable fanboi who has been brainwashed by the Church of Apple.[2] And also because I’ve run mobile development teams for apps with more than a million downloads on each platform. Please learn from my experience, or send me a postcard from the special corner of hell reserved for early-stage executives who attempt parallel mobile development strategies.

There are three main reasons you should stick with iOS for the first phase of your mobile buildout.

Single platform focus.

You already know this one. Trying to do too much at once is the classic blunder of the early-stage tech company. The task of building a great product on one platform alone is daunting. More than one is guaranteed to distract you. You’ll be burdened with two parallel design processes (if you think it’s okay to have an app look/act identically on the two platforms, please tell me in the comments, so I can write another article smacking you around). You’ll likely find bugs that have to be fixed in both places. You’ll have much higher support costs fielding questions from multiple sides of the fence. Not to mention at least double the testing time in-house.

Building for two mobile platforms is like having two children. It turns out to be a lot more than twice the work of one child.

iOS is easier to build for

This is a real “live-wire” issue in some circles. But even in the most optimistic case, the two platforms are equal in difficulty when it comes to building a solid app. But the consistency and maturity of the iOS SDK really starts to shine when you have to get fancy, like using the camera, the microphone, capturing video, doing animations for games or 3D applications, etc. When it comes to more complicated apps, you can read all over the web about the challenges of developing for Android.

Someday those challenges will be worth it for your business, and you’ll be prepared to hire two Android devs for every one iOS dev. But not right now.

iOS is more lucrative

This trend may be slowly changing, but for now, iOS is still a more lucrative platform than Android. iOS users are less price sensitive, apps are on average three-times more expensive. And this has a major bearing on the relative revenue per platform, with Android still well behind iOS, despite equal (or by some measures far greater) market share.

Consider Android If…

So under what circumstances would I ignore my own advice? Here are a few (but proceed with caution):

  1. Network Effect / Communications Tools – If the success of your product is dependent upon a network effect, and in particular if it’s a communication tool, you may have no choice but to have a ubiquitous platform presence. For example, a mobile app for coordinating schedules for little league sports teams will not succeed unless all the parents in the league can use it. Adoption by 50% of the parents provides no real value. Just don’t underestimate the complexity parallel development tracks will add to your product roadmap.
  2. Particular Target Demographics – Certain countries have higher Android saturation (I’m lookin’ at you Spain). Android skews lower-income. Notwithstanding the argument above that iOS is a demonstrably more lucrative platform, you may identify that your market skews heavily Android. If you are in this situation, develop for Android-only out of the gate, and ignore iOS. The focus you’ll gain by sticking with one platform is still critical.
  3. “Freedom” Required – It’s possible that your app relies on behaviors not available in iOS. You are building a mobile browser and need users to set it as the default on their devices. You need to be able to communicate directly with other apps on the phone, or share data between applications natively. iOS has guidelines for accomplishing 95% of what you want to, but if that remaining 5% is a deal-breaker for your business, then you probably already know that you are an Android-first/only product.

iOS Challenges

While iOS is the best launch platform available, it’s not all ponies and roses. iOS comes with its own set of development challenges, including restrictions on how data is managed and shared, sometimes lengthy approval (or soul-crushing rejection!) cycles for the App Store, plus brutal competition for app discovery. Dealing with these challenges is a topic for a future article

Additional Resources


  1. If you want to argue about why Blackberry or Windows Phone are also viable, my comments section is always open to you, be my guest.  ↩

  2. While true, I unfortunately have no incentive to give you bad information on this topic.  ↩