Why Developers Shouldn’t Use iCloud Syncing, Even If It Worked

Brent Simmons has a number of reasons not to use iCloud, including one that lines up with my recent post on the topic:

We’ve been living in a social world for years. But iCloud syncing is not social: it’s per-user syncing.

If you write your own server, you can write the social bits, so your users can share recipes, weather forecasts (look, Mom, it’s going to be sunny on Thursday!), favorite articles, or whatever-it-is your app does.

He offers another great reason, which is iCloud’s inability to interact with server-side services:

iCloud can’t poll Twitter to see if your follower count has gone up or down. iCloud can’t generate weather forecasts. iCloud can’t track ships.

There are all kinds of services that make sense on the server side. You could do some of them on a client, but at the expense of timeliness and battery life. If it’s a good idea, and you don’t do it on a server, your competition just has to write a server that does it, and your app is finished.

Even if you wanted to write your own server and then integrate with iCloud for syncing, it’s impossible. There’s no API that would allow a server to connect to iCloud.

At this point, implementation problems are by far the biggest obstacle to iCloud adoption. But once those are solved, the limitations designed into the platform will still be a big barrier.

Flying iPads

The New York Times reported yesterday that the FAA is getting closer to allowing people to use electronic devices on planes during takeoff and landing. From the Bits blog:

According to people who work with an industry working group that the Federal Aviation Administration set up last year to study the use of portable electronics on planes, the agency hopes to announce by the end of this year that it will relax the rules for reading devices during takeoff and landing. The change would not include cellphones.

Marco Arment is concerned about the term “reading devices.”

Is the Kindle Fire a reading device since it’s named “Kindle”, even though it can do a lot more? Are iPads reading devices? How about an iPad Mini with an LTE radio? I assume iPhones would be prohibited as “cellphones”, but what about iPod Touches?

I agree that “reading devices” is a silly and probably self-defeating standard to use, but I think Marco may be taking the Times article a little too literally. I doubt that the FAA would use the term “reading devices” in an actual regulation, because they’d have to device on a definition for a reading device. As Marco points out, that’s a tall order. If the FAA released a statement talking about reading devices, I’d be very worried. But in this case, I think we’re looking at a case of a reporter being a little loose with his words.

The most likely scenario is that the FAA will use similar rules during takeoff and landing as it does during the cruise section of the flight. That is, radios that send and receive signals must be turned off. During flight, WiFi is OK; during takeoff and landing, it’s not. I imagine the rules will look something like this:

  • All electronic devices must be set so they do not send or receive a signal.
  • After takeoff and before landing, you may use WiFi but not cellular communications.

The second rule is basically the status quo. The updated version simply replaces “please turn off all electronic devices” with “please set all electronic devices so that they do not send or receive a signal.” (I wouldn’t be surprised to see an additional rule banning headphone use during takeoff and landing, so that you can hear crew announcements. Right now you can use headphones for TV on airlines like JetBlue, but crew announcements preempt the TV audio.)

Will some people get it wrong and leave radios enabled on their phones? Sure, but some people forget (or “forget”) to turn off electronics now, and it doesn’t seem to be a problem. Will flight crews have trouble determining whether people are really complying with the rules? Yes, but again, that’s pretty much the status quo. Will different devices do different things in “airplane mode,” leading to inadvertent violations of the rules? Probably, but having a standard set of rules about use of electronics use during flight will gradually help standardize airplane modes.

The Price of Free

Michael Jurewitz, a.k.a. Jury:

There is no doubt that free can lead to huge user bases and massive adoption. In the face of venture capital or existing cash stores, the siren call of free often sounds like a low-risk bet on future profits. In practice, free is a costly mistake that businesses and small developers should avoid, and users should run away from like the plague.

I’m going to assume for a moment that if you are reading this blog you care about making great product. Selling to lots of users is at least as important to you as being proud of what you build. Most folks in this camp aren’t looking for a quick sale or to flip their business to a big buyer. If you care about the long term success of your business, you want users handing you money for what you build. You want the acquisition of money closely aligned with what makes your users happy.

This is a big part of why I’ve never made my iOS apps free, even when sales have been relatively slow.

The Sunday-Only Newspaper Problem

A strange pricing trend has emerged as a number of high-profile newspapers have started charging for access to their web sites. Specifically, newspapers are charging less for Sunday paper delivery and unlimited web access than they charge for web access on its own. For example, the Boston Globe charges $3.50/week for Sunday-only delivery and web access, but $3.98/week for web access alone. The New York Times has a similar model, and the Washington Post is apparently considering it as well. This pricing is the opposite of what you’d normally expect: you pay more to get more. Why are newspapers essentially paying people to take their Sunday editions?

The bread and butter of a newspaper is print advertising. A Pew Research Center report on the state of the news media calculated that newspapers brought in $19.1 billion in print advertising revenue, and only $3.3 billion in online ad revenue. Moreover, online ad sales aren’t growing fast enough to offset the loss in print ads:

Print advertising losses continue to far exceed digital ad gains. For 2012, the ratio was about 16 print dollars lost for every digital dollar gained—even worse than the 10 to 1 ratio in 2011.

Notably, the Pew report also documents an increase in Sunday, subcriptions:

Sunday circulation has risen thanks to more new rules for counting audience that includes more digital products and the industry’s emphasis on growing sales of Sunday issues, which are the best-read and most profitable papers of the week.

It seems that efforts by newspapers to increase their Sunday paper circulation are succeeding. In order to prop up print circulation numbers, newspapers are subsidizing Sunday-only subscriptions. By including web access with a Sunday-only delivery, papers can encourage people to buy a print subscription, even if all they really want to do is read online.

What should we think of all this? Well, firstly, that newspapers are going to have to deal with the death of their print editions sooner or later. These subsidies will last a while, but it’s pretty easy to see the writing on the wall.

As a consumer, I have just one request: Don’t make me pay more to avoid getting something I don’t want. I don’t want a print edition of the Sunday paper. Honestly, I’ll never look at it. The best-case scenario would be to charge less for web-only access than for a Sunday edition, but based on the data I’m pretty sure that’s not in the cards. But there’s another option that should help everyone out: Give readers the option to buy that Sunday-only subscription, use the online access, and donate the actual printed Sunday paper to a school, library, or charity. People like me wouldn’t have their houses cluttered by unwanted paper, needy people get access to quality news coverage, and the newsapaper gets to keep its print subscriptions up. Newspapers, make it happen and I’ll gladly subscribe!

Justifying a Larger iPhone

After years of shipping only one size of iPhone, why would Apple suddenly add a second, larger “iPhone Plus” like the one that’s been rumored? Andy Ihnatko’s recent post about giving up his iPhone in favor of a Samsung Galaxy S III points the way:

The Galaxy S III’s screen has roughly the same pixel density as the iPhone 5 (they’re both greater than 300 ppi). When I’m reading a book, I can see more of the page, and the wider content margins are more comfortable. I get to see more of a map without having to zoom or scroll. I can see more of the email message, and more of the article in my newsreader. A movie or video is large enough that I feel as though I’m seeing all of the rich HD detail I was meant to see. When I’m reading comics, I don’t need to keep twisting the screen to read panels that have different orientations.

The screen of the iPhone 5 sometimes makes me feel like I’m reading a grocery receipt, not a book. And I never used to read from my phone in bed. Now, if my (still quite beloved) iPad is downstairs and the Galaxy S III is on the nightstand, I’ll spend an hour reading from the Samsung rather than risk cold feet.

Ihnatko’s point isn’t that there’s anything wrong with the iPhone. Rather, he’d simply prefer a larger size, and Apple doesn’t provide one. The taller iPhone 5 gets part of the way there, but it seems that there are a significant number of people who’d prefer an even bigger device. It’s remarkably similar to people who liked the iPad but found the Kindle Fire to be a more appealing form factor. With the iPad Mini, Apple addressed that segment of the market quite successfully. Now would be an opportune time to do the same with the iPhone.

Clean My Mac

I stumbled on Clean My Mac 2 the other day and was immediately impressed. Since switching to an SSD instead of spinning hard drive on my main Mac, space has been at a premium. Clean My Mac does some pretty slick scanning to find unneeded files. For example, it scans your iPhoto library and locates all the photos that have been rotated but otherwise left untouched. It then offers to delete the original file, since it’s not really needed. It can also get rid of unnecessary language files or old universal binaries. I thought I had my hard drive cleaned out pretty well, but Clean My Mac found about 11GB of stuff I didn’t need. Recommended!

A Sharing API for iCloud

Apple’s iCloud service has generated its share of criticism. Some (rightly) centers on lingering bugs, particularly involving Core Data. Other critics focus on missing features, notably the inability to share documents between users and apps. Many developers frustrated by iCloud’s limitations have turned to third party services like Dropbox, or developed their own app-specific back ends. But these other services do more than allow users to communicate between users or apps on one device. They allow developers to make use of the power of the web to grow and promote their app. What iCloud needs most is the ability to share content on the web.

Over the past few months, a number of high-profile iOS apps have introduced web sharing. Loren Brichter’s hit game Letterpress can share “replays” of games to the web. Marco Arment’s The Magazine just launched a web version. Even Instagram, which made its way to a billion-dollar buyout by Facebook on the strength of its iOS app, has launched a web-based photo sharing. Clearly, even strongly iOS-focused developers feel the need to enable at least minimal web sharing. Notably, all of these apps remain iOS-centric. The developers aren’t abandoning iOS or moving their focus to Android. Rather, web sharing is a great way to introduce apps to a wider audience. Posting a Letterpress replay on Twitter or Facebook is a more compelling advertisement for the game than simply saying “Hey, download this app!”

iCloud’s lack of an external API inhibits this kind of sharing. Reliability issues aside, I think this is a key reason that Dropbox remains appealing to a lot of iOS developers. To fill the void, Apple should devise a non-iOS API for iCloud to allow developers to extend their services onto the web and draw users into the app.

At the outset, the API could even be read-only, or mostly read-only. Photo Streams are a great example of this concept in action. An iOS user can create a shared photo stream to send to other friends on iOS devices, or share a public URL that’s viewable on the web. Nobody expects to be able to create full new photo streams on the web, but its great to allow Grandma to view and comment on pictures, even if she doesn’t own an iPad. (Maybe she’ll like the web experience so much that she’ll consider buying an one, but that’s a topic for another time.)

It would be exceedingly difficult for a third party iOS developer to create an experience like Photo Stream web sharing using iCloud. There’s simply no way to access iCloud data from the web. Most likely, a developer interested in such a feature would bypass iCloud and develop their own API or use a service like Dropbox. There’s nothing wrong with those as options, if Apple is serious about driving iCloud adoption, they need to address web sharing as a key requirement. Doing so would also make developers’ and users’ lives easier. Using Dropbox requires that users have or sign up for accounts. Building a new API requires developing and maintaining a whole server-side infrastructure. Both add new dependencies to an app, and create additional layers between users and a great product. Apple can and should make things simpler.

An external API could do for iCloud what iTunes for Windows did for the iPod and iTunes Store. By allowing iOS developers a simple way to share content from their iCloud-enabled apps on the web, it would help those apps (and iOS by extension) gain exposure to a much wider audience. Because iCloud is still tied back to iOS or Mac device sales, a sharing API simply helps extend the reach of Apple’s platforms.

What is there to lose for Apple? Developers are already creating web-sharing features; they’re just doing it by bypassing iCloud in favor of other services. The iCloud API would only be accessible to members of the iOS or Mac developer programs, whose yearly membership fee should offset costs involved in running the service. Killer apps using iCloud can only help sales of iOS devices. If people use iCloud more, Apple even make a few extra bucks selling extra cloud storage capacity.

Apple’s first priority with iCloud needs to be fixing implementation issues with the current product. After that, a public-facing, sharing-oriented API should be high on the feature list.