Wak Oentoenk

Summary: The business of making native apps for mobile devices is dying, crushed by a fragmented market and restrictive business practices. The problems are so bad that the mobile web, despite its many technical drawbacks, is now a better way to deliver new functionality to mobiles. I think this will drive a rapid rise in mobile web development, largely replacing the mobile app business. This has huge implications for mobile operators, handset companies, developers, and users.


The decline of the mobile software industry

Mobile computing is different from PC computing.

For the last decade, that has been the fundamental rule of the mobile data industry. It was the central insight of Palm Computing's "Zen of Palm" philosophy. Psion came up with similar ideas, and you can hear echoes of them from every other successful mobile computing firm: Mobile computers are used differently from PCs, and therefore must be designed differently.

We all assumed this also meant mobile devices needed a whole mobile-specific software stack, including an operating system and APIs designed specifically for mobility, and native third-party applications created from the ground up for mobile usage.

That's what we all believe, but I'm starting to think we got it wrong.

Back in 1999 when I joined Palm, it seemed we had the whole mobile ecosystem nailed. The market was literally exploding, with the installed base of devices doubling every year, and an incredible range of creative and useful software popping up all over. In a 22-month period, the number of registered Palm developers increased from 3,000 to over 130,000. The PalmSource conference was swamped, with people spilling out into the halls, and David Pogue took center stage at the close of the conference to tell us how brilliant we all were.

It felt like we were at the leading edge of a revolution, but in hindsight it was more like the high water mark of a flash flood. In the years that followed, the energy and momentum gradually drained out of the mobile applications market.

The problem wasn't just limited to Palm; the level of developer activity and creativity that we saw in the glory days of Palm OS hasn't reappeared on any mobile platform since. In fact, as the market shifted from handhelds to smartphones, the situation for mobile app developers has become substantially worse.

That came home to me very forcefully a few days ago, when I got a call from Elia Freedman. Elia is CEO of Infinity Softworks, which makes vertical market software for mobile devices (tasks like real estate valuation and financial services). He was one of the leaders of the Palm software market, with a ten year history in mobile applications.

I eventually moved on from Palm, and Elia branched out into other platforms such as Blackberry. But we've kept in touch, and so he called recently to tell me that he had given up on his mobile applications business.

Elia gave me a long explanation of why. I can't reproduce it word for word (I couldn't write that fast), but I've summarized it with his permission here:

Two problems have caused a decline the mobile apps business over the last few years. First, the business has become tougher technologically. Second, marketing and sales have also become harder.

From the technical perspective, there are a couple of big issues. One is the proliferation of operating systems. Back in the late 1990s there were two platforms we had to worry about, Pocket PC and Palm OS. Symbian was there too, but it was in Europe and few people here were paying attention. Now there are at least ten platforms. Microsoft alone has several -- two versions of Windows Mobile, Tablet PC, and so on. [Elia didn't mention it, but the fragmentation of Java makes this situation even worse.]

I call it three million platforms with a hundred users each (link).

The second technical issue is certification. The walls are being formed around devices in ways they never were before. Now I have to certify with both the OS and with each carrier, and it costs me thousands of dollars. So my costs are through the roof. On top of that, the adoption rate of mobile applications has gone down. So I have to pay more to sell less.

Then there's marketing. Here too there are two issues. The first is vertical marketing. Few mobile devices align with verticals, which makes it hard for a vertical application developer like us to partner with any particular device. For example, Palm even at its height had no more than 20% of real estate agents. To cover our development costs on 20% of target customer base, I had to charge more than the customers could pay. So I was forced to make my application work on more platforms, which pushed me back into the million platforms problem.

The other marketing problem is the disappearance of horizontal distribution. You used to have some resellers and free software sites on the web that promoted mobile shareware and commercial products at low or no charge. You could also work through the hardware vendors to get to customers. We were masters of this; at one point we were bundled on 85% of mobile computing devices. We had retail distribution too.

None of those avenues are available any more. Retail has gone away. The online resellers have gone from taking 20% of our revenue to taking 50-70%. The other day I went looking for the freeware sites where we used to promote, and they have disappeared. Hardware bundling has ended because carriers took that over and made it impossible for us to get on the device. Palm used to have a bonus CD and a flyer that they put in the box, where we could get promoted. The carriers shut down both of those. They do not care about vertical apps. It feels like they don't want any apps at all.

You can read more of Elia's commentary on his weblog (link).

Add it all up, and Elia can't make money in mobile applications any more. As he told me, "Mike, it's time for you to write the obituary for mobile apps." More on that later.

Although it's a very sad situation, if Elia's experience were an isolated story I'd probably just chalk it up to bad luck on the part of a single developer. But it mirrors what I've been hearing from a lot of mobile app developers on a lot of different operating systems for some time now. The combination of splintering platforms, shrinking distribution channels, and rising costs is making it harder and harder for a mobile application developer to succeed. Rather than getting better, the situation is getting worse.

I've always had faith that eventually we would solve these problems. We'd get the right OS vendor paired with a handset maker who understood the situation and an operator who was willing to give up some control, and a mobile platform would take off again. Maybe not Palm OS, but on somebody's platform we'd get it all right.

I don't believe that any more. I think it's too late.


The mistake we made

We told ourselves that the fundamental rule of our business was: Mobile is different. But we lost sight of an even more fundamental law that applies to any computing platform:

A platform that is technically flawed but has a good business model will always beat a platform that is elegant but has a poor business model.

Windows is the best example of inelegant tech paired with the right business model, but it has happened over and over again in the history of the tech world.

In the mobile world, what have we done? We created a series of elegant technology platforms optimized just for mobile computing. We figured out how to extend battery life, start up the system instantly, conserve precious wireless bandwidth, synchronize to computers all over the planet, and optimize the display of data on a tiny screen.

But we never figured out how to help developers make money. In fact, we paired our elegant platforms with a developer business model so deeply broken that it would take many years, and enormous political battles throughout the industry, to fix it -- if it can ever be fixed at all.

Meanwhile, there is now an alternative platform for mobile developers. It's horribly flawed technically, not at all optimized for mobile usage, and in fact was designed for a completely different form of computing. It would be hard to create a computing architecture more inappropriate for use over a cellular data network. But it has a business model that sweeps away all of the barriers in the mobile market. Mobile developers are starting to switch to it, a trickle that is soon going to grow. And this time I think the flash flood will last.

If you haven't figured it out yet, I'm talking about the Web. I think Web applications are going to destroy most native app development for mobiles. Not because the Web is a better technology for mobile, but because it has a better business model.

Think about it: If you're creating a website, you don't have to get permission from a carrier. You don't have to get anything certified by anyone. You don't have to beg for placement on the deck, and you don't have to pay half your revenue to a reseller. In fact, the operator, handset vendor, and OS vendor probably won't even be aware that you exist. It'll just be you and the user, communicating directly.

Until recently, a couple of barriers prevented this from working. The first was the absence of flat-rate data plans. They have been around for a while in the US, but in Europe they are only now appearing. Before flat-rate, users were very fearful of exploring the mobile web because they risked ending up with a thousand-Euro mobile bill. That fear is now receding. The second barrier was the extremely bad quality of mobile browsers. Many of them still stink, but the high quality of Apple's iPhone browser, coupled with Nokia's licensing of WebKit, points to a future in which most mobile browsers will be reasonably feature-complete. The market will force this -- mobile companies how have to ship a full browser in order to keep up with Apple, and operators have to give full access to it.

There are still huge problems with web apps on mobile, of course. Mobile web apps don't work when you're out of coverage, they're slow due to network latency, and they do not make efficient use of the wireless network. But I believe it will be easier to resolve or live with these technical drawbacks in the next few years than it will be to fix the fundamental structural and business problems in the native mobile app market.

In other words, app development on the mobile web sucks less than the alternative.

Here's a chart to help explain the situation. Imagine that we're giving a numerical score to a platform, rating its attractiveness to developers. Attractiveness is defined as the technical elegance of the platform multiplied by how easy it is for developers to make money from it. The attractiveness score for native mobile app development looks like this over time:



This is why mobile app developers are in trouble. Even though the base of smartphones has been growing, and the platforms themselves have become more powerful, the market barriers have been growing even faster. So attractiveness has been dropping.

Now add in mobile web development:



Based on what I'm hearing from mobile developers, the lines just crossed. The business advantages of mobile web development outweigh its technical limitations. More importantly, if you look at where the lines are going, the advantage of mobile web is going to grow rapidly in the future.

I'm not saying all native mobile development is dead. In fact, we're about to see the release of Apple's native development tools for the iPhone, and as Chris Dunphy just pointed out to me, they are sure to result in a surge of native development for that platform. But I think even a rapidly-growing base of iPhones can't compare to the weight of the whole mobile phone market getting onto a consistent base of browsers.


What it all means

If you're a mobile developer, you should consider stopping native app development and shifting to a mobile-optimized website. That's what Elia did, and he said it's amazing how much easier it is to get things done. Even mobile game developers, who you'd think would be the last to abandon native development, are looking at web distribution (link; thanks to Mike Rowehl for pointing it out).

See if you can create a dumbed-down version of your application that will run over the mobile web. If the answer is yes, do it. If the answer is no, try to figure out what technology changes would let you move to the web, and watch for those changes to happen.

There are exceptions to any rule, and I think it makes sense to keep doing native development if your app can't work effectively over the web, and it's a vertical application so popular that you can get about $50 or more in revenue per copy. In that situation, you probably have enough resources to stay native for the time being. But even you should be monitoring the situation to see when you can switch to the web, because it will cut your expenses.

If you're a mobile customer, make sure your next smartphone has a fully functional browser that can display standard web pages. And get the best deal you can on a flat-rate data plan; you'll need it.

If you're an operator or a handset vendor, get used to life as a dumb pipe. By trying to control your customers and make sure you extract most of the revenue from mobile data, all you've done is drive developers to the Web, which is even harder to control. You could have had a middle ground in which you and mobile developers worked together to share the profits, but instead you've handed the game to the Google crowd.

Congratulations.


Oh, about that obituary...

In loving memory of the mobile applications business. Adoring child of Java, Psion, Palm OS and Windows Mobile; doting parent of Symbian, Access Linux Platform, and S60; constant companion of Handango and Motricity. Scared the crap out of Microsoft in 2000. Passed away from strangulation at the hands of the mobile industry in 2008. Awaiting resurrection as a web service in 2009. In lieu of flowers, the family asks that you make a donation to the Yahoo takeover defense fund.

I've been invited to moderate a panel on mobile operating systems at the CTIA conference this April. No doubt this will be the highlight of the entire conference ;-) , so make your travel reservations early.

Participants tentatively will include Symbian, Microsoft, Access, RIM, and several others.

Here's the session description:

Operating Systems, User Interfaces and Browsers: Where is the Technology Going?

Mobile phones are plagued with interoperability issues, making it difficult for applications to run properly on all handsets, hurting both consumers—who find their handset incapable of running the desired application—and applications developers—who have to develop multiple versions of the same application. What are the pros and cons of open versus closed handheld operating systems? This panel will address the likely outcome of the openness rage should it move to the handset, including the long-term effects of this possible technology shift.

Should be a fun conversation.

The panel will consist of brief presentations followed by Q&A, so I wanted to give you an opportunity to participate. If you'll be at CTIA, please come by the panel on April 2 at 2:30. If you won't be there, let me know what questions you'd like to see asked. Just post a comment below, and I'll see what I can do. I'll also post a report after the session.

(By the way, if you'll be at CTIA and want to chat, drop me a note at the address here.)

Could Yahoo be fixed and thrive as an independent company? I think it could, but now we'll probably never know, because Microsoft wants to buy it. There are reports that private equity firms, and possibly News Corp, also want to bid (link). Even Google has supposedly offered to help (link). But by declaring its desire for Yahoo, Microsoft has basically acknowledged that its own Internet business is failing. Now that Microsoft has said that in public, it has no choice but to outbid everyone else.

Which is a shame, because I think the combined companies are likely to fail. To explain why, I have to talk about the right and wrong ways to compete with an industry leader...


How to fight a leader

In my opinion, the best way to fight a dominant company at the top of their game is not to go head to head with them. You don't launch a competing line of mainframes against IBM in the 1960s, and you don't launch a consumer operating system against Microsoft in the mid-1990s. What you want to do is challenge them in a business they don't understand, or better yet an area where their own strengths make them weak. That's what Google did -- while Microsoft was focused on beating Netscape, AOL and the other first-generation Internet companies, Google quietly established a franchise in search advertising. It's now using this secure base to subsidize free online applications (and a mobile operating system) that compete with Microsoft.

Although Google's direct impact on Microsoft's applications business to date has been miniscule, Google's tactics will eventually present Microsoft with a Catch-22 situation: If it tries to hold the line on prices, its customers will gradually migrate away. If it matches Google on price, it destroys its own revenues.

Microsoft's response has been to try to get a piece of Google's advertising revenue. First it tried to build its own search and advertising business. Now that's failing, so it wants to buy Yahoo's to get critical mass.

The problem is that even with Yahoo, Microsoft will still be far behind Google in search advertising. Google has a huge lead, and is willing and able to spend lavishly to defend it if it has to. I think what Microsoft is doing is equivalent to leading an infantry charge uphill against an infinite number of machine guns.

If Microsoft really wants to spend $45 billion, I think it would be far better served by investing it to attack someplace where Google is weak.


Google's weaknesses

A dominant company's strengths are also usually its weaknesses. (For example, IBM was so deeply embedded in corporate big iron that it couldn't understand the PC business. Microsoft was so caught up in monetizing a computer platform that it couldn't picture someone giving away the whole thing.) Google's weakness is its beautifully managed and consistent corporate culture. Google hires only the best and brightest software engineers. It hires them young, so they can be molded, and it brags about screening them all for "Googliness." That consistent culture means it acts far more predictably than many technology companies, and it has very consistent blind spots.

One of Google's blind spots it that it can't tell the difference between usability and utility. Usability is the process of making software easy to learn without a manual or extensive training. Google is extremely good at designing for usability. Its interfaces are clear, uncluttered, and generally self-explanatory. Utility is the ability of a product to solve a major problem for a user. That requires the designer to get inside the head of the target customer, understanding not only his or her rational needs but also the emotional landscape. Google is terrible at designing for utility. It tends to attack problems that engineers care about, rather than normal people; and it often produces elegant technologies that don't engage people emotionally and fail to deliver the full solution they need. (If you want a great example of the difference between usability and utility, compare the old Google Video to YouTube. Google Video was cleaner and easier to use, but it was launched without sufficient content, and was about as emotionally engaging as a slab of concrete.)

One of the best ways to compete with Google, then, is to focus on utility -- to create online products and services that solve real problems for customers, and address both emotional and rational needs. That's what Amazon is doing with Amazon Web Services (although in this case the customers are developers rather than consumers.)

There are many, many more opportunities to create high-utility Internet applications. What you need is a critical mass of bright engineers, a product management culture that understands how to design for utility, and senior management that focuses the company on its best opportunities. Designing for utility takes more resources than just tossing a product out there, so management must restrict the number of projects the company undertakes.

Yahoo has plenty of bright engineers, and I think it understands utility better than Google. Ironically, Yahoo's attempt to make itself into a media company probably helped here, because it forced the company to learn about engaging people emotionally.

What Yahoo has lacked, in my opinion, is the awareness that it's actually a products company, not a media company; and the management discipline to focus on a small number of initiatives.

Will a buyout by Microsoft fix those problems? I don't think so. Microsoft itself isn't great at designing for utility. Mostly, it focuses on copying and adapting things that have been developed by others. One of the most depressing documents I've seen on the Web recently was the alleged plan for Windows Mobile 7 (link). Assuming that the plan is genuine, it shows that rather than trying to do something new in mobiles, Microsoft is slavishly trying to copy and "improve" on the interface of the iPhone (so, for example, rather than just using finger touches you can also shake the phone to make it do things). This comes after Microsoft spent the last couple of years trying to copy RIM, and before that Palm.

Even the bid for Yahoo is driven by Microsoft's desperate desire to copy and co-opt another company's business model. That's exactly what Yahoo doesn't need. Rather than focused management that can pick out the most disruptive embers in Yahoo's portfolio and fan them into bonfires, Yahoo is likely to get layers of well-meaning ROI analysis, a distracting flood of resources, political integration hassles, cultural conflicts, and a mandate to "concentrate on the core."

The process will probably strangle Yahoo and distract Microsoft. I really hope I'm wrong, but I think there's a very good chance that the merger will be the beginning of the end for both companies.

A. Microsoft.

(Yeah, I know, it's an old joke. But it probably applies. More later.)