CloudKit's Advantage

Greg Pierce responded to my earlier post with a great explanation of why he chose CloudKit for the next version of Drafts:

Why am I willing to make these trade-offs for CloudKit, despite it’s limitations? Because, ultimately, developer perspectives aside, I felt it was the right choice for my customers.

They will not need to setup another account with yet another set of credentials to manage. More importantly, their data will be stored with Apple, a vendor they have already choosen to trust. It will be stored in siloed, private data stores that not even the developer can access. That cannot be said for apps using Azure, Parse or other backend services.

This is one of the biggest reasons I want CloudKit to succeed. As a user, it's easy to get started with a CloudKit-based app because you (presumably) already have an iCloud account. That means more time exploring the interesting and unique things the app can do, rather than messing with accounts and credentials. And the privacy aspect is significant. I'd argue that Apple takes user privacy more seriously than any of its competitors. (Whether you agree with that or not, Greg is certainly right that users have chosen to trust Apple with at least some of their data by virtue of creating an iCloud account.)

However, these advantages may also limit some of CloudKit's possibilities. As I describedin my earlier post, the inability to move data off of CloudKit is one of my key concerns. While it's conceivable that Apple could add data export to CloudKit in the future, it's hard to imagine how they'd do so without compromising privacy. It's possible export could be limited to public data, but that might limit the utility of the feature in the first place. (For example, suppose Vesper used CloudKit at launch, but then decided to move to another service. It wouldn't do them much good if they couldn't migrate everyone's notes, which would presumably be stored as private data.)

As Greg pointed out, CloudKit holds a lot of potential benefit for users as well as developers. On the other hand, users won't see much of that benefit if few developers adopt it. Hopefully Apple has (or will) strike the right balance so that we all reap the rewards.

Web Services, Dependencies, and CloudKit

Brent Simmons blogged a response to my question about dependencies for apps, and he outlined a number of questions developers should consider when choosing a web service:

How long will this service be around? How difficult would it be to move? How much of this service’s unique features do I use? How much benefit do I get from those?

This extends to software, too. What is a given package’s reputation for security? Is it likely to be maintained in the future? Will upgrading to get a security fix also mean revising some of my code?

You have to plan for scale. Will this service and and those software packages allow room for growth? (Sharding, running multiple instances, etc.)

That got me thinking about how CloudKit fits into this picture. As an iOS developer, CloudKit is immensely appealing at first glance. The API is low-level enough that you have a good deal of control over how your app interacts with the server. At the same time, you get a lot of server-side functionality for free, which leaves you with more time to focus on building a great app. But I still have a lot of misgivings about it. I'm going to go through some of Brent's questions with regard to CloudKit, changing the order a bit here and there when it makes sense.

How long will it be around? Is it likely to be maintained in the future?
I have to say this is an area where I don't have a lot of confidence in CloudKit. Although Apple's cloud services have improved somewhat over time, they've also gone through a lot of incarnations. Moreover, Apple has a tendency to lose focus on products that aren't a huge success, and encourages developers to move to the latest and greatest tech. If CloudKit isn't a big success, I'm not confident that Apple will continue to pour resources into improving it. Past experience leads me to worry that they'd spend more time building a replacement system and promoting it to developers.

What is a given package’s reputation for security?
This is a strong point for Apple. Although CloudKit is a new product, both security and privacy are clearly important to the company. No system is completely secure, but I don't have any more concerns about security in CloudKit than I would with Azure or any other competing service.

Will this service and and those software packages allow room for growth?
This is a tough question to answer. CloudKit is a fairly opaque box in terms of implementation, so it's difficult to say how well it would scale. Apple clearly has vast resources at its disposal if it chooses to use them, but the fact remains that developers probably won't get a whole lot of information about how CloudKit scales. It'll either scale without us having to do anything, or it won't. Even the storage and data transfer limits are unclear beyond the free tier. The documentation lists the usage you get for free with each app and additional user, but then simply says, "If you need more capacity than the limits listed above, contact us." That's hard to plan for.

How difficult would it be to move?
For me, this is the killer. As it stands now, it seems that it would be incredibly hard to move a CloudKit-based app to another platform. There is simply no obvious way to move data en mass from CloudKit to any other service. Maybe this is possible and Apple just hasn't discussed it publicly, but as a developer, I need more certainty than that. Maybe CloudKit will work wonderfully for many years to come. But maybe it won't, or maybe I'll eventually want to do something that CloudKit doesn't support. For those and a host of other reasons, I can't imagine building critical aspects of my app around a service that doesn't let me have a backup plan.

Brent talks a bit in his post about choosing Azure for Vesper. Of course, CloudKit wasn't available when they were adding sync to Vesper, but I imagine the decision would have been the same regardless. CloudKit sounds like a great option for some kind of incidental feature, but not for anything central to the app experience.

Tunnels DC Retrospective

A few weeks ago, I decided to pull my Metro app, Tunnels DC, from the App Store. After almost four years in the store, I thought it might be interesting to do a bit of a retrospectve on the app, what worked, what didn't, and why I eventually removed it from sale.

Tunnels DC debuted on the App Store on November 9, 2010. I'd recently left a job, which gave me the extra hours I needed to finish the project after tinkering with it in my spare time. Back then I was commuting daily on the Metro, and although there were other apps that purported to show train arrival times, few were using Metro's then-new API. Many of the other apps in the category also lacked much design polish. I felt that there was an opportunity for success with a well-designed app backed by official API data from WMATA itself.

Unfortunately, Tunnels DC was never the commercial success I hoped it would be. Although I certainly didn't expect to be making a full-time living off the app, I hoped that it would generate better sales than it did. Below are some charts showing the app's revenue over time.

As you can see, the app's best year was by far its first. After that, sales tailed off significantly. Even in the first year, the best sales days totaled less than $30. Most days were closer to $1-2. By the end of the app's life, most days had no sales at all.

I attribute the app's poor sales to two main factors:

Competition

This is probably the biggest reason the app wasn't a success. In an increasingly crowded category, there just wasn't much to set Tunnels DC apart. It wasn't long before most apps were using the official API. Some supplemented that with additional data that wasn't publicly available. Others clearly had very strong design teams working on them. Finally, a few apps were backed by large companies that could afford to promote their apps heavily. For example, DC Rider is published by the Washington Post, which is conveniently able to promote the app in their newspapers.

Tunnels DC also faced strong pressure on prices. Many of its competitors were free apps. Some of these had ads, while others were published by companies with other revenue streams. I considered making Tunnels DC free, but decided against it for three reasons:

  1. I wanted the app to pull its own weight. Although Tunnels DC never made a ton of money, it at least covered the annual cost of an iOS Developer Program membership that allowed it to be in the App Store. If the app were free, I'd be paying out of my own pocket to get it out into the world.
  2. I didn't want to put ads in the app. I hate using apps with ads and would much rather pay a buck or two to get an app without them. Moreover, I wasn't confident that ads would generate much revenue, even if app downloads increased somewhat.
  3. I guessed that a free app would come with increased support demands. I've heard a lot of developers talk about how free apps generate more negative reviews on the App Store, and more email from people demanding new or different features. I figured I'd rather stick to a low-priced paid app, even if it meant fewer downloads.

Limited Market

By its nature, Tunnels DC is only useful if you're in the Washington, DC metro area. There's no real reason for someone who lives elsewhere to buy the app. As such, the pool of people who might even consider buying the app is relatively small.

Limited Investment

Given the app's modest download numbers, I hesitated to put a lot of time into adding features. Realistically, it's unlikely I would have gotten a very good return on my time investment. If I'm being honest, I also didn't have a ton of ideas for ways to expand on the concept. In such a highly competitve app market, I needed to come up with a good way to differentiate my app from others. Since I failed to come up with strong new feature ideas, I decided to spend my time elsewhere.

Ultimately, my decision to pull the app from the App store was a result of poor sales numbers. By this summer, downloads had decreased so much that the app didn't seem worth even the minimal level of support it required. I was also given a push by the start of service on Metro's new Silver Line. As the Silver Line launch date approached, it was unclear that the API would support it. A tip from someone familiar with the situation confirmed my suspicion that the API is not high on WMATA's list of priorities. Although the API did eventually gain support for Silver Live trains, the uncertainty surrounding it was enough to tip the scales in favor of removing Tunnels DC from sale. Although I'd almost certainly have done so sooner or later in any event, the issue with data reliability served as a prompt to pull the trigger.

Tunnels DC was never a project designed to pay the bills. Nonetheless, it does offer some lessons for next time. Foremost among these are:

  • Pick a good market. Make sure it's big enough to support sustained app sales.
  • Have strong features that set your app apart. This seems obvious in retrospect, but I think it's an easy trap to fall into. The more crowded the category, the more the app needs to differentiate itself from the competition.

I have a couple of app ideas in the works, so there should be an opportunity to put these lessons into practice sooner rather than later. Stay tuned.

Using Third-Party Code in iOS Development

Last weekend at CocoaConf DC, there was one refrain that really caught my attention: be wary third-party code. Avoid CocoaPods. Do things yourself. Speakers said it. Conference attendees said it. It seemed to be everywhere.

I don’t buy it.

Developers on other platforms thrive by making good use of third party, open source code. The Ruby community is a great example. You can find a gem for just about anything. Some are great, some are terrible, and a lot lie somewhere in between. But the existence of all these gems means you don’t have to re-invent the wheel for every new application. You can spend your time focusing on the things that are unique to your app.

Unfortunately, there seems to be a fairly deep cultural difference in the Objective-C community that rejects third-party code.

There are some key differences between writing a web app in Ruby and an iOS app in Objective-C that may account for the do-it-yourself sentiment. Most prominently, web developers have control over the system their app will run on. Servers can be configured with the exact OS and language versions that the app was designed and tested on. If developers keep the OS, language, and gem versions constant, the gems should continue to work correctly. (That said, web developers certainly use things like jQuery that rely on the browser, which changes under them all the time.)

On iOS (or the Mac), developers have much less control over the OS version that their apps run on. Sure, you can set a minimum requirement, but that doesn’t stop things from changing in the future. If Apple makes major changes in iOS 8, it could break third-party code. That lack of control over the complete environment does make third-party code a little more prone to headaches in Objective-C.

So should that dissuade iOS and Mac developers from using third party code? I don’t think so. Changes in the OS could just as easily break code that you wrote yourself, and when that happens, you’re on the hook to fix it yourself. Moreover, good third-party code shouldn’t break in catastrophic ways. Well-designed, well-maintained code should keep up with major OS releases. Apple gives ample time for beta testing before major updates, and rarely removes functionality without warning.

Just as on other platforms, the key to taking advantage of third-party code is to use it carefully and judiciously. Look first to widely-used, actively-maintained libraries. Plan how you use third-party libraries so you could replace them if necessary. Of course, don’t rely on them for everything. There’s always a time to do your own work. The power of sharing code is that you can spend more time on what makes your app unique, and less time reimplementing work others have already done.

The Age of Tim Cook

After all the product announcements and updates in yesterday's WWDC keynote, Tim Cook closed by showing a new Apple ad titled "Designed By Apple." Just as in the recent iPhone ads, we see images of people going about their lives. They might be holding an iPhone or sitting near a MacBook, but the gadgets are just barely there, almost a whisper of themselves. The focus is unquestionably on people. The voice-over in Designed by Apple reads as follows:

This is it. This is what matters. The experience of a product. How it will make someone feel. Will it make life better? Does it deserve to exist? We spend a lot of time on a few great things, until every idea we touch enhances each life it touches. You may rarely look at it, but you’ll always feel it. This is our signature, and it means everything.

After more than a year at the helm, it's clear that Tim Cook is putting his stamp on Apple, and this is it. In these commercials, the technology gets out of the way. Products aren't a goal on their own, they're a means to an end, a way to make people's lives better. You can hear that philosophy shine through when Cook talks about things like iOS's accessibility features that let a blind man to go for a walk in the woods. The focus isn't on gee whiz technology, it's on what people are able to do with it. The point of the iPhone camera commercial isn't the number of megapixels or colors – it's the photos people take of their friends and loved ones, their parents and their children.

You can also see that theme emerging in iOS 7's new design. We can quibble over aesthetics, but the goal of getting design out of the way and letting content take over is admirable. Again, the focus isn't on the technology, but what you do with it. It's not on how your email client looks and works, but on the messages you get from people in your life.

Of course, Apple is a product company, and its goal is to sell us gizmos and gadgets. But the remarkable focus, and one that's quickly becoming Cook's signature, is on doing that by making products that really enrich people's lives. It's not about being flashy, or having the most features, or checking off the most boxes. Some will dismiss that as mushy gobbledygook, but it's not the worst way a company could answer the question, "Should we build this?"

This isn't about leaving Steve Jobs behind. Far from it. Under Steve, Apple's goal was always to make great products regardless of what others were doing. But make no mistake, Tim Cook is putting his own stamp on Apple. It's a little more human, a little more personal, even down to the funnier, more casual tone of the WWDC keynote. Cook has chosen to surround himself with people and a philosophy that focus on the humanity in technology even more directly than Steve did. Sounds like a pretty good sign for the months and years ahead.