Developing iPhone Apps is risky business

This week, the New York Times reported that Apple rejected Sony’s e-book app from the iTunes Store. This basically blocks the Sony e-book reader from the iPhone, iPad and other iOS devices since the iTunes Store is the only way to put software on a device without hacking its operating system.

Few consumers care since the Sony e-book system has very little market share. But as a software developer, this is a sobering reminder that it is very risky to develop software for the iOS platform.

If you manufacture a traditional product like a shirt or a toothbrush, you have a variety of retailers that can sell your product. If Wal-Mart refuses to sell your product, you can still sell it at Target or at a department store. But for the iPhone, iPad and other iOS devices, the only place to sell your software application is through the Apple iTunes Store. If Apple rejects your application, you have nowhere else to go. You can modify the software and try again, but ultimately you have no choice besides Apple.

Apple apologists argue that it’s Apple’s product and they can control the marketplace. Some may claim that Apple might want to block a Sony application because it competes directly with Apple’s own iBookstore. This argument is absurd: in fact, Apple tolerates other forms of channel conflict. For instance, Apple retail stores sell Microsoft Office for Mac even though it competes directly with Apple’s own iWork. And Apple really needs Microsoft Office for Mac – there’s no way I could make the Mac my primary computer without Microsoft Office for Mac.

A more interesting issue is the question of revenue: Apple supposedly rejects any application that has an embedded store. This is logical, since Apple gets commissions both on the sale of applications through the iTunes Store as well as “in-app purchases”: add-on functionality that can be purchased for an existing application. Amazon’s Kindle application sidesteps this issue by making book purchases from a web browser, but the New York Times article suggests that Apple plans to forbid this as well.

If you take this idea to the extreme, then Apple’s policy is to reject any application that accesses external content that was not purchased through Apple. For instance, suppose you have a subscription to a service like Netflix – that would be blocked because Netflix doesn’t sell subscriptions through Apple’s iTunes Store.

Of course I’m taking this to a ridiculous extreme, but I’m trying to illustrate that this policy is absurd. And the situation is exacerbated by the Apple’s notorious policy of secrecy. For example, the public doesn’t know exactly why the Sony application was banned; in researching this topic, I found that the primary source for this story was the New York Times article, which quotes Sony but not Apple. Although this story inspired many different reports, the New York Times article appears to be the one and only primary source.

Trying to see things from Apple’s perspective, there is a valid reason to ban applications that have an alternate store: if you purchase content from another store, then Apple gets no revenue from the transaction. Imagine the following scenario: a software developer creates an application and publishes it via iTunes as a free application. In its default mode, this application has limited features – it functions as a free trial. However, the developer sells the ability to upgrade the application by buying an unlock code from his own website – not from the iTunes Store or the in-app purchasing system. In this case, the application developer would be utilizing the infrastructure of Apple and its huge customer base, while circumventing commissions to Apple on purchases of the upgraded software application.

On the other hand, it’s not reasonable for Apple to expect commissions on sales of e-books purchased via Amazon or Sony.

There’s a simple policy that would fix this for everyone: Apple should allow applications to use paid content that is device-independent, while blocking the use of paid content that is solely for the iOS application. This would allow someone to use a Netflix account or a Kindle or Sony book, while preventing someone from cheating the system through a custom unlock feature.

In fact, this is exactly how music works with iTunes: you have the option to purchase music from the iTunes Store, but you can also sync music from CDs or even digital downloads purchased from other sources such as Amazon or eMusic. And I hear no outcry that Apple is losing revenues to CD sales.

But more importantly, this is an example where the App Store process is broken, and Apple’s policy of secrecy means that you don’t know exactly how or when it will be addressed. Although I don’t work on iOS applications, I have worked for software companies for most of my career. And this situation makes me very nervous: trying to develop for a platform where I cannot be sure that my software will ever be sold. In the case of Sony, they invested time and money in developing the e-book reader. Who knows if they will ever be able to recover these costs. Frankly, the risks are just too high.

There’s far less risk for a web application. So long as it conforms to standards, a web application should work on iOS devices as well as many other systems. Unfortunately, many applications like games are impractical or impossible as web applications since they need direct access to hardware. In the case of e-book readers, they need to function well offline so that you can read books on an airplane or while traveling off-network. New web technologies like HTML5 and CSS3 are very helpful, but they still cannot replace many native applications.

While a web application has lower risk for the developer, it is a worse situation for Apple. Clearly, Apple has no opportunity for commissions on the sale of web applications. And one of the advantages for Apple of native applications is that they create vendor lock. Once someone amasses a large library of paid iPhone applications, it’s more likely that that person will buy another iPhone when it’s time to upgrade. But if that person is using web applications, then there’s much less reason to stick with Apple for the next smartphone.

Until Apple opens up with its developer community, I believe there will be some backlash: some developers will decide to write web applications instead. And that can’t be good for Apple.

Advertisements
Explore posts in the same categories: Tech

4 Comments on “Developing iPhone Apps is risky business”


  1. […] basically blocks the Sony e-book reader from the iPhone, iPad and other iOS devices since … develop iphone apps – Google Blog Search This entry was posted in How To Make Iphone Apps and tagged apps, Business, Developing, […]

  2. frank Says:

    Know any lawyers you could ask if this is an anti-trust case? Apple has sole control on what can be installed on an iPad, with the result that they can limit competition from rivals like Sony.

    The only reason I bought iPads for us is because I wanted to be able to read e-books from Amazon and Barnes & Noble. The only books I have in iBooks are the free ones I downloaded from the Guttenberg Project sit.

    I held my nose a bit when I made the purchase because I knew how much Apple liked to control what you but on your machine, but this really disturbs me. I didn’t plan on buying anything from Sony, but I don’t want Jobs & Co to take the option away from me.

  3. Greg Says:

    It’s a fine line. Apple developed the platform, and they can run it as they please. I think a more interesting question is whether Sony has a right to sue under breach of contract for the SDK.

    In any event, we know little about this situation besides the NYT article, so it’s hard to tell what was really going on with the Sony app.


  4. I have developed the app called “Florist Now” for iphone, which you can send flowers from your iphone. Although Apple is not getting any commission from sales, the application is approved. I hope that Apple will not change its mind in the future.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: