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.

Developers for open source

Infoworld makes the case that open source is constrained not by money but by developers -- people.

This seems a good time to recall some wisdom from the late 1990s. Christine Comaford, a technology pundit of the times, listed four things that techies want:

Lavish, genuine praise
Fun projects to work on and fun tools to work with
Free beer and pizza
Some money
(And look where money is in this list.)

I've taken the liberty of expanding Ms. Comaford's first item with the adjective "genuine".

Open source can learn from this list, and use it to attract and retain developers.

The money is ready. Infoworld admits that funding is available.

Fun projects and fun tools are also available. Open source has plenty of projects. Today's tools are much better than those of 1997.

Keep in mind, in 1997, open source didn't exist like it does today. It was a tiny corner of the IT realm, obscure and unknown to many. The vast majority of development was in corporations or government agencies, with development tied to employment and tools specified by corporate committees.

If open source projects want to attract developers, the two remaining aspects are the place. Free beer and pizza -- substitute soda, juice, fruit, and sandwiches if you want -- and lavish praise.

Praise. Recognition. Credit (as in movie-style credit).

These are mechanisms to entice developers.

Apple and cloud computing

 Apple's tussle with Epic (the creators of Fortnite) shows a deeper problem for Apple. That problem is cloud computing.

Apple has avoided cloud computing, at least from its customers' perspectives. Apple is the last company to use the "run locally" model for its application. Apps for iPhones and iPads run on those devices, applications for Macbooks run on them. (Apple does use servers and possible cloud computing for iCloud storage and Siri, but those are accessories to macOS, not a front-and-center service.)

In contrast, Google's cloud-based Documents and Sheets apps let one build documents and spreadsheets in the cloud, with data stored on Google's servers and available from any device. I can create a document on a Chromebook, then open it on my Android phone, and later update it on a desktop PC with a Chrome browser. This works because the data is stored on Google's servers, and each device pulls the latest version when it is needed.

Microsoft is moving in this direction with its online version of Office tools. Even Oracle is moving to cloud-based computing.

Apple is staying with the old "local data, local execution" model, in which computing and data is on the local device. Bur Apple does let one move from one device to another (such as from an iPad to a Macbook) by synchronizing the data onto Apple's servers.

The difference is the location of processing. In Google's model (and in Microsoft's new model), processing occurs on the server. Apple keeps processing on the local device.

For simple tasks such as word processing and spreadsheets, the difference is negligible. One might even claim that local processing is better as it offers more options for documents and spreadsheets. (More fonts, more chart options, more functions in spreadsheets.) The counter-argument is that the simpler cloud-based apps are better because they are simpler and easier to use.

Regardless of your preference for simple or complex word processors, cloud computing is also used by games, and games are a significant market. More and more games are shifting from a model of "local processing with come communication to other users" to a model of "some local processing to communications with servers for more processing". In other words, games are using a hybrid model of local processing and cloud processing.

This shift is a problem for Apple, because it breaks from the "all processing is local" model that Apple uses.

What is Apple to do? They have two choices. They can stay with the "all processing is local" model (and ignore cloud computing) or they can adopt cloud computing (most likely as a hybrid form, with some processing in the cloud and some processing remaining on the local computer).

Ignoring cloud computing seems risky. Everyone is moving to cloud computing, and Apple would be left out of a lot of innovations (and markets). So let's assume that Apple adopts some form of cloud computing, and enables developers of applications for Apple devices to run some functions in the cloud.

How will Apple host their cloud platform? Here again there are two choices. Apple can build their own cloud platform, or they can use someone else's.

Building their own cloud infrastructure is not easy. Apple comes late to cloud computing, and will have a lot of work to build their infrastructure. Apple probably has the time to do it, and most definitely has the cash to build data centers and hire the engineers and system administrators.

But the alternative -- using someone else's cloud -- is also not easy. Apple is not friends with the major cloud providers (Amazon.com, Microsoft, Google) but it may form alliances with one of the smaller providers (Oracle, Dell, IBM) or it might purchase a small cloud provider (Linode, Digital Ocean, OVH). Apple has the cash to make such a purchase. While possible, a purchase may not be what Apple wants.

My guess is that Apple will build their own cloud platform, and will make it different from the existing cloud platforms. Apple will need some way to distinguish their cloud platform and make it appealing to app developers.

Perhaps Apple will focus on security, and build a self-contained cloud platform, one that offers services to Apple devices but not others, and one that is isolated from other cloud platforms and services. An "Apple only" cloud platform with no connection to the outside world would allow Apple to ensure the security of customer data -- with no connection to the outside world, data would have no way to escape or be extracted.

Apple may go so far as to mandate the use of their cloud platform, prohibiting apps from communicating with other cloud platforms. iPhone apps and Macbook applications could use Apple's cloud, but not AWS or Azure. This would be a significant restriction, but would guarantee revenue to Apple.

(Assuming that Apple charges for cloud services, which seems a reasonable assumption. Exactly how to charge for cloud services is a challenge, and may be the only thing preventing Apple from offering cloud services today.)

The outcome of the dispute between Apple and Epic may foreshadow such a strategy. If Apple prevails, they may go on to create a locked cloud platform, one that does not allow competition but does ensure security of data. (Or perhaps a milder strategy of offering the Apple cloud, but only on the condition that the Apple cloud is the only cloud used by an app. Classic apps that use other clouds may continue to run, but they could use Apple cloud. Moving any services to the Apple cloud would mean moving all services to the Apple cloud.)

I don't know how things will play out. I don't know what discussions are being held in Apple's headquarters. These ideas seem reasonable to me, so they may come to pass. Of course, Apple has surprised us in the past, and they may surprise us again!

Apple and Fortnite

Events in the Apple vs. Fortnite dispute are unfolding rapidly. In less than a week, Fortnite modified their web page to allow payments outside of Apple's payments API (which meant that Apple could not extract a 30% toll), Apple removed Fortnite's app from the Apple App Store (which meant that customers can no longer install it on Apple devices), and Fortnite ran an advertisement video that parodies Apple's "1984" ad for the original Macintosh computer. Fortnite has also filed a lawsuit against Apple.

A few thoughts on this dispute:

First, Apple will probably win the lawsuit. It seems to be a contract dispute, and I think Apple's terms and conditions are strong enough to defend its actions. (Although I am not a lawyer and I am not offering legal advice.)

Second, Apple is probably surprised at the tactics used by Fortnite. I'm sure Apple is frequently involved in lawsuits, ranging from patent disputes to wrongful termination by employees. Most of these are handled quietly. Fortnite is running a very public campaign, and wants to make as much noise as possible. I'm not sure that Apple is prepared for a public dispute.

Third, Fortnite is prepared for this fight. The parody of Apple's "1984" advertisement shows that -- such a parody was not assembled in an afternoon hack session.

Fourth, Apple is the larger of the companies, and is therefore "punching down" against the smaller Fortnite. Apple faces the risk of looking bad, and must tread carefully. Carelessly worded statements by Apple will be received poorly.

Fifth, it seems that Fortnite is ready to walk away from the Apple platform. A public spat such as this one leaves little room for reconciliation.

Sixth, Apple is most likely ready for Fortnite to walk away. Apple recognizes that the revenue from Fortnite is a small portion of its overall income. Apple probably assumes that it can get other companies to provide games for Apple devices.

Finally, while Fortnite will probably lose in a court of law, they may win in the court of public opinion. This may be damaging to Apple. Apple has fans and followers, but I don't know that Apple has many friends. The fans and followers will stay with Apple, but partners and suppliers may become more cautious in their dealings with Apple. Small developers may delay releases for Apple devices, or may defer them indefinitely. For Apple to win, it needs more than lawyers -- it needs a good public relations campaign.

Add Functional Programming to Object-oriented Programming, not the other way round

The programming world has multiple paradigms, or styles of programming. The reigning champion is Object-oriented Programming, embodied in C++, Java, and C# and oriented around, well, objects. The prior champion was Structured Programming (or Procedural Programming) represented by C and Pascal and oriented around control structures (and avoiding GOTOs). The challenger is Functional Programming oriented around functions, and in the languages Haskell and F#, among others. An older paradigm is Unstructured Programming (USP), which does use GOTOs and lacks the modern IF/THEN/ELSE and DO/WHILE constructs of Structured Programming.

SP and USP operate in the same space: small and medium-side programs. Since they operate in the same space, one often picks one of them, but does not use both. (One can use both, but it is not easy.)

Object-oriented programming (OOP) operates in "the large" and helps us organize large systems. Structured Programming (SP) and Functional Programming (FP) operate in "the small" and help us build short blocks of code that are reliable and readable. In this view, SP complements OOP and they work well together. SP and FP, on the other hand, compete in the same space. We can build large systems with OOP and SP, or with OOP and FP. (We can build small programs with SP alone, or with FP alone. OOP is not useful with small programs.)

Structured Programming is demonstrably better than Unstructured Programming. Functional programming is arguably better then the older Structured Programming. One would think that we would use the best paradigm, and that we would use Functional Programming. But we don't. It takes time to learn a programming paradigm, and most programmers know the Structured Programming paradigm. Structured Programming is what we have, buried inside many modern systems.

The mix of Object-oriented Programming and Structured Programming makes sense. To use a programming paradigm, or a mix of paradigms, one must have a language that supports the paradigms. C++, Java, and C# all support OOP and SP. Pascal supports only SP; Object Pascal and Delphi support both. Haskell supports FP.

The advocates of Functional Programming have noticed that their preferred languages have achieved modest acceptance, but none have become as popular as the most popular languages C++, Java, and C#, or even Python. That lack of acceptance makes some sense, as a Functional Programming language does not have the Object-oriented Programming concepts that help us organize large systems. (Conversations with practitioners have probably ended with project managers and OOP programmers saying something along the lines of "Functional Programming is nice, but we have a large code base in an Object-oriented Programming language, and we cannot give up that organization." 

I think these conversations have spurred the advocates of Functional Programming to merge OOP into FP languages, the hope that project managers and programmers will accept the new combination. The combination of object-oriented programming and functional programming is a nice trick, and it works.

But this approach is, in my view, the wrong approach.

When programmers and managers say that they want a programming language that supports OOP and FP, they don't really mean that they want an FP programming language that supports OOP.

What they want is a programming language that supports their current code base and allows them to add Functional Programming in small doses.

They want a compromise, much like C++ was a compromise for OOP. C++ offered classes to C programmers -- and was originally called "C with classes". It didn't mandate a pure OOP approach. Instead, it let programmers add OOP to an existing code base, and add OOP in a gradual manner.

The "FP plus OOP" approach fails because the existing code base is not OOP, but OOP with SP. A "FP plus OOP" language requires that all of the SP code blocks be re-written in FP. That can work for tiny programs and classroom exercises, but it doesn't work in the industry with large sets of code.

Yes, some companies have large, million-lines-of-code systems written in FP. But those systems were built in FP from the beginning.

Companies that have large, million-lines-of-code systems written in OOP (with procedural code too) don't want to stop everything and re-write that code. They want to add FP in small doses. They want the benefit of FP in a few key locations. Over time, they can expand FP to other parts of the system.

They don't want an FP language with OOP extensions. They want an "OOP and SP" language with FP extensions.

There is a language that may provide a path forward. Microsoft has its F# language, which is a Functional Programming language, but it also lives in .NET, which means one can combine F# modules with C# modules. If one has a system in C# and wants the advantages of Functional Programming, F# is worth investigating.

But beyond F#, I see no languages that offer a compromise between paradigms, and a way forward for managers and programmers. The current set of FP languages are too "pure" and don't allow the mixing of OOP, FP, and SP paradigms.

Perhaps we will see some new languages that bridge the worlds of Structured Programming, Object-oriented Programming, and Functional Programming.

Apple's risky game

Apple's recent spat with Hey has shown a possible problem with Apple's strategy.

If I may oversimplify events: Hey.com built an app for e-mail, and submitted it to Apple for distribution in the Apple App Store. Apple approved it. Hey then submitted an upgrade, which Apple rejected, claiming that the Hey.com e-mail app did not conform to Apple's rules. Hey.com charges users $99 per year for the e-mail service, and Apple wanted 30% of it. Hey fought back, saying that the terms for apps were 30% of in-app purchases, and people could buy a subscription on the hey.com web site. Apple said that such an arrangement was not satisfactory, and stood firm on its rejection of the upgraded app.

Hey's complaint is mostly one of fairness: the terms and conditions said "in-app purchases". Hey thought that they conformed to that clause. Apple then explained that an app must allow for in-app purchases when a subscription is required. (And apparently when a customer subscribes on the web site, Apple still wanted 30%.)

To further muddy the waters, Apple allows "read only" apps such as Netflix to avoid the 30% fee. 

One can see the advantage of Apple's strategy: by forcing an app maker to pay the 30% fee, it increases income (for Apple).

But a side effect of this strategy is that it converts a partner in one's ecosystem into a customer. Were hey.com to accept the proposed terms, they would be paying Apple. (Which, last time I checked, makes them a customer.)

So is hey.com a partner, a competitor, or a customer?

They are a partner in that they provide an app for the Apple App Store.

They are a competitor in that their app (an e-mail app) competes with Apple's built-in e-mail app.

They are a customer in that they pay money to Apple.

It is one thing to irritate your competitors; it is another to irritate your customers. Competitors expect that you will compete. Customers expect that you deliver value. And the folks at Hey consider the services provided by Apple in exchange for the 30% fee to be insufficient.

For Apple, this is probably a business decision, governed by finances and not by emotions. Even if they lose some app providers (customers), they make more money overall.

Further muddying occurred with a recent announcement (true or otherwise) that Amazon paid less than 30% for its app. This will not sit well with developers, especially after Tim Cook (CEO of Apple) claimed that all app developers have the same arrangement.

"Ah," think the small developers, "I see how this works. The big companies have a nice little club with discounts, but I have to pay full price."

Apple must tread carefully here. Apple has its market, and its walled garden, and its App Store. Partners or partners-turned-customers may grumble and pay the 30% "Apple tax" -- for now.

Apple runs the risk of becoming the next Microsoft -- or more specifically, the next big company that people love to hate. Developers may play by Apple's rules, grudgingly, as captives in the market. But when an alternative appears on the horizon, they will remember Apple's behavior and many will flock to that new opportunity. Apple may gain in the short term and lose in the long.