Apple's upcoming challenge

Up to now, Apple's business has been simple: sell hardware. Software such as macOS, GarageBand, and even iTunes was made to sell hardware.

Up to now. Or some time in the recent past.

Apple now has two major lines of business: hardware and services. At some point, conflicts between the two will arise. How will Apple navigate those conflicts?

Here is how this affects consumers and developers -- and Apple.

In the past, developers were reluctant to build certain types of apps. The fear was that Apple could build their own version of an app and include it in iOS or macOS, and that such an inclusion would reduce sales of the independent app to near zero. (Apple includes lots of apps for its phones and for its laptops. macOS includes a word processor, a spreadsheet, an e-mail client, and sound editing software, among other things.)

But now, with income from the sale of apps (or subscriptions to online apps) Apple faces a choice: Do they build an app or let someone else build it?

If Apple builds the app, their hardware/software offering is more complete, which makes it more appealing to customers. On the other hand, Apple must invest in the app and maintain the app over time.

Suppose Apple doesn't build the app. Odds are high that someone else will build the app, and submit it to Apple for inclusion in the Apple App Store.

And charge for it. Either a one-time charge or a subscription fee. Both of which provide income to Apple.

Notice what has happened. The app, when developed by Apple, is an expense. When developed by a third party, it is revenue. But the differences are more than financial.

Removing the financial aspect, the big difference of the two modes is control. When Apple builds the app it has complete control over the appearance, functionality, performance, and reliability. Apple can ensure that data is stored only on Apple devices or Apple-approved cloud servers. When Apple lets third parties build the app, it cedes some control to those third parties.

I can see two trends in the future.

One is that Apple will cease adding apps to its macOS and iOS operating systems. (It will add utilities that control and configure hardware, like the AirPort utility for AirPort devices. But it will add few games or office tools.)

Another is that Apple will increase (or attempt to increase) its control over apps that run on macOS and iOS. Apple will issue stronger and more detailed guidelines for user interfaces, security, privacy, and reliability. In this case, Apple is trying to have its cake (maintain control) and eat it too (farm out development to third parties and gain revenue).

I think this strategy just might work for Apple. They sell lots of hardware, and third-party developers want access to that market. Apple customers are loyal, replacing their old Apple laptops and phones with new Apple laptops and phones.

There are some risks.

Such a strategy will mean a difficult time for third-party developers, who will have to jump through more and more hoops to get their apps published in Apple's App Store. Some developers may give up on the Apple market, and this is the risk that Apple must manage. If too many developers abandon the Apple ecosystem, then Apple loses apps and income, and could lose customers for hardware.

Another risk is that Apple loses its ability to develop apps. If it relies on third parties to create apps for iPhones and Macbooks, will it shift its internal resources from app development to something else? Will it lose the ability to create regular, non-system apps? If it does, then returning to a strategy in which Apple creates apps (user apps, not just system apps) will require the re-development of that development experience.

But if Apple avoids those problems, they can succeed and reap the rewards.

Apple is stuck in its own revenue trap

The "Hey" e-mail app got a bit of attention this week. Made by BaseCamp, and published on iOS (and therefore subject to the terms and conditions of the iOS App Store), Apple rejected version 1.0.1, claiming that the app did not meet its guidelines. Two aspects made this rejection notable: version 1.0 was approved (and version 1.0.1 is minimally different), and Apple decided to "clarify" its terms and conditions after many people complained that the app was, in fact, in compliance with the published terms and conditions. (Apple's clarification was that certain rules apply to "business apps" and different rules apply to "consumer apps", and that the "Hey" e-mail app was out of compliance because it did not provide Apple with 30% of its revenue.)

Lost in the noise about the "Apple tax" and clarity of terms and conditions and consistency of rulings on said terms and conditions is an aspect of Apple that we may want to ponder.

Apple justifies its 30% cut of in-app revenue by offering the platform and services.

iOS is a capable platform. It does a lot. One can argue that the 30% rate is too high (or too low). One can argue that Apple holds a monopoly on apps for iOS.

I want to think about something else: Apple's model of computing, which allows it to justify the "tax".

Those services assume a specific model of computing. Not cloud computing, not web services, not distributed computing. A model of computing that was dominant in the 1970s (when Apple was founded) and the early 1980s. The model of local computing, of personal computing.

In this model, apps run on phones and applications run on laptops and desktops (and the Mac Pro tower). Apps and applications communicate with the user through the user interface. Everything happens on the local device. For Apple iPhones and MacBooks, computing occurs on those devices.

Compare that model to the model used by Google's Chromebook. In that model, the Chromebook is a simple device that sends requests to servers (the cloud) and simply presents the results. (IT professionals of a certain age will recognize this model as a variant of the 1960s timesharing, or IBM's terminals to mainframes. Both used simple terminals to invoke actions on the remote system.)

Back to Apple.

Apple must keep this model of local computing, to justify their take of revenue. They cannot move to a Chromebook model. If they did, they would lose their reason for the 30% tax. Developers are angry enough now at Apple, and while some decline to write for the iOS platform, many others "pay the tax" albeit grudgingly.

But what happens when computing moves to the cloud? A cloud-based app does little on the phone. The computing is on the servers. The app, at best, presents a UI and sends requests to the servers. Is the UI and an HTTP stack enough to justify the 30% "tax"? It's my opinion that such a simple system does not, and therefore Apple must keep apps in the older model of local computing, in which an app uses many services.

Apple has built a nice operating system and platform with its iOS, and it has built a trap with its App Store and 30% revenue cut. Apple is loath to give up that revenue. To keep that revenue, it needs to provide the services that it proudly hawks.

So, as I see it, Apple is stuck. Stuck with local computing, and stuck with a relatively complex platform. I expect Apple, for at least the short to middle term, to stay with this model. That means that apps on iPhone and iPad will stay in the local computing model, when means that they will be complex -- and difficult to support.

In the long run, I think Apple will move to a cloud-based model of computing, but only after everyone else, and only when Apple starts losing business. It will be a difficult transition, and one that may require new management of Apple. Look for a run of quarters with disappointing earnings, and a change in leadership, before Apple changes its App Store policies.