Just a quick note to let you know about a couple of informational resources for mobile developers.
--Motorola is starting the online publicity for its upcoming Android-based smartphones. They did a brief interview with me, asking how mobile app developers can distribute their software (link).
--Elia Freedman of Infinity Softworks did a great presentation on his experiences selling through the iPhone App Store, and the lessons he has learned. It’s well worth watching the video here.
It's best to watch both of these, and think about them, before you develop your mobile app.
Showing posts with label developers. Show all posts
Showing posts with label developers. Show all posts
Tuesday, 23 June 2009
Wednesday, 10 September 2008
App stores and APIs: It's the ecosystem, stupid
If you make a web application or mobile platform, one of the trendiest things you can do is add APIs and a software marketplace to it so developers will extend your product. Google is previewing its application market for Android (link), T-Mobile USA has promised a new applications store for its phones (link), and many people I've spoken with believe Microsoft bought Danger in order to get its software store technology.
The idea of encouraging third party developers dates back at least to the early days of MS-DOS, but it was associated mostly with operating systems until Web 2.0 applications took off a few years ago. Google played a big role in that change, by exposing APIs to Google Maps that made it possible to embed maps in other web applications. That helped Google Maps quickly blow past established mapping services like Mapquest, while the installed base of Google Maps extensions made it hard for Microsoft's web mapping product to gain traction.
The drive for web APIs got another big boost when Facebook enabled developers to extend its functionality, driving an explosion of widgets for Facebook that helped it grow past MySpace to become the #1 social network in the US (at least according to Alexa).
The web app people all noticed Google's and Facebook's success and furiously started adding APIs to their products. Today it's unusual to hear about a new web app that doesn't have some sort of API story or future plan to add them.
In mobile, applications have an interesting history. Lately some new mobile players have generated huge attention for their application marketplaces. The chart below shows the one year growth in the developer base for a certain well-known mobile platform:
If you're like most people in Silicon Valley, you probably think that's an Apple iPhone developer chart. But actually it's Palm OS ten years ago, from 1998 to 1999.
Disturbing, isn't it? The idea that a platform could take off like that and then crash and burn...makes you wonder if the same thing could happen to the platforms that are popular today.
And in fact, if you look at the history of APIs on both mobiles and web apps, the failures are more numerous than the successes. If you're a developer trying to pick the right platform to create your apps on, that choice is very dangerous -- you're betting the success of your company on something that has a better than 50-50 chance of failing.
If you work at a web or mobile company creating APIs or an app store, the news is equally disturbing: The odds are that you won't succeed.
So it's very important to look at the history of those failed platforms, to figure out what goes wrong and how to avoid it. When you do that, the answer is pretty clear:
It's the ecosystem, stupid
The success of a developer program is not driven just by the beauty of the APIs or the store, but by how the overall ecosystem works to enable developers to prosper. The two parts of the ecosystem that are most important to developers are the ability to create something cool, and the ability to make money. Coolness gets developers to try your platform in the first place. Most developers, especially the innovative new ones, gravitate to a platform that lets them easily create something cool that will impress their friends. But as those developers get older and more responsible, they eventually get tired of drinking lemon drops with Mark Cuban (link). They need to pay rent, buy food, and do other things that require money. If they can't make money from a platform, they will move away to the next one. So the financials are what makes developers stick around over time.
If the ecosystem breaks down anywhere in the chain, the developer community will eventually collapse. You can see this in process driving the history of some prominent web and mobile platforms:
Facebook. Earlier I said Facebook apps were a success because they helped the company grow. That's definitely true from Facebook's short-term perspective, but if you talk to Facebook developers the story is much more mixed. Some people online say there are lots of ways to monetize Facebook apps (link), but other reports say it's difficult to actually make the revenue come in (link). The online attitude toward this when Facebook's platform launched in 2007 was pretty dismissive. One commentator wrote (link):
That's the right attitude for a developer to take: Control your own destiny. But monetization becomes a Facebook problem if nobody can make money. Developers poured into the Facebook platform like the tide in the Bay of Fundy, but a lot of them couldn't make money and promptly poured back out. I can tell you from personal experience that some are pretty bitter and unlikely to do anything with Facebook again.
Mobile Java's problem was that it's not a real platform. Handset vendors and operators were allowed to break compatibility between their implementations of Java, forcing developers to tweak their java apps almost endlessly, dramatically raising their costs and making it hard to scale their companies. The selling model for Java apps was also seriously broken -- to get prominent placement on a phone, developers often had to cut special deals with carriers. Some of the most successful mobile Java game developers have survived because they're great deal-makers; they figure out how to develop for a big brand that wants to create a mobile presence, or they hook into the promotion of a movie. This business model favors a few companies with the skill and contacts to cut the deals; the current mobile Java world is not an ecosystem that can support huge numbers of developers.
Palm and Windows Mobile both succeeded at first in enabling developers to create a lot of interesting applications. Although both operating systems had technical flaws, they were reasonably open to any developer, and the "write once run anywhere" idea mostly worked. Unfortunately, the marketing and sales model for those applications started out mediocre and got worse over time. There was no software store on device, so users had to go out on the web to find apps. This cut the number of people looking for applications. Those who did look online usually landed in the mobile application stores, which over time took a larger and larger share of the developer's revenue. Eventually, the stores' cut grew to more than 50% of revenue, making development uneconomical for many companies. When sales of Palm OS and Windows Mobile devices failed to grow rapidly, the financial model for many developers fell apart, and the ecosystems faded.
What to look for in an ecosystem
If you're a developer looking to find a viable ecosystem, or a platform vendor looking to build one, here are the things to look for.
How easy is it for developers to create something cool? How powerful are the APIs? Can the platform be programmed using standard development tools? Eclipse seems to be the preferred platform among much of the web app crowd, and it's free.
Is the platform programmed in a language that's obscure or difficult to use? This has long been one of the big barriers to Symbian native app development.
How do applications get visibility? Is the store displayed at the first level of the smartphone? How easy is it for users to navigate the store? Online stores like Handango are notoriously hard to navigate; the user experience is about like walking through a flea market.
Can good apps rise to the top? In some software stores, the developer has to pay for prominent placement on the store. This is incredibly corrosive to the ecosystem. The big software companies with money to pay for placement are often the least innovative. So users see an app prominently featured, try it, are disappointed, and never try another one. If web search worked this way, there's a good chance that the web as we know it would never have developed. The practice of pay for placement is a self-defeating, regressive tax -- it penalizes most the small developers who are most likely to create compelling new apps that make a platform more successful.
Ideally, placement on the store should be based on independent user reviews, so the best new apps can rise to the top naturally.
What are the terms of business? Can a developer bill for an app through the user's phone bill? Forcing people to input their credit cards separately slows adoption of software. Can the developer choose different forms of payment? Developers should be enabled to experiment with freeware and subscription payment systems, just as they do on the web. How much of the developer's revenue does the store keep? The ideal cut is no more than 20%.
Are there restrictions on the application's functionality? This is a sore point for iPhone developers. Apple won't allow intermediate platforms that run other applications. So no Java, no Flash, and no emulators like StyleTap's Palm OS emulator (link). This also inhibits other developers who want to expose APIs within their applications.
What is the overhead for security? Some platforms require applications to pay for a new security certificate every time the app is revised. The cost is typically a few hundred dollars, which doesn't sound like much to a big operator or OS company, but is a huge burden to a small company with several apps. They're basically punished every time they fix a bug, which is very unwise -- you want developers to fix bugs instantly, because that increases user satisfaction and reduces support calls. Basic security certificates can and should be issued automatically by the software store, at no charge.
How big is the user base? This will be a more and more important issue over time. For a developer, the ideal platform would let them sell to the whole base of mobile phone users, not just one brand or model.
Room for improvement
Based on those tests, no mobile platform offers an ideal ecosystem today. Apple probably comes closest at the moment. Here's how I'd grade it:
--Power: A-. The iPhone APIs give developers a huge amount of power, and there was a lot of delighted commentary on the web when the APIs were first revealed. But there is a learning curve for iPhone development; Apple has its own tools and its own variant version of C. And support for some typical OS features (such as cut and paste) is missing.
--Store: A-. The store is built into the device prominently, so apps are easier to discover. And there is a user-driven rating system. Developers can bill through Apple's iTunes system; not as convenient as billing through the carrier, but not bad. Apple takes 30% of revenue, which is not ideal, but is better than the 50% or more cut that burdens mobile app developers elsewhere.
--Terms: C+. There are significant, ambiguous restrictions on what a developer can do on the iPhone. The most onerous terms restrict the ability of developers to add functionality to applications and create software that run other applications. The terms cause a lot of confusion among developers; I'm on a mailing list for iPhone developers where they have been trying to figure out whether they can download content to an iPhone app. The answer: it's unclear as to whether content is a form of functionality, and you should ask Apple's lawyers. That is an incredibly intimidating message to app developers. It feels far too much like doing business with the operators.
--User base: Incomplete. It's relatively straightforward to make money from iPhone apps today because the number of developers is still relatively low. But over time, I think it's unlikely that Apple will be able to grow its user base at the same rate as the developer base is growing. If that happens, life will get much less pleasant for iPhone developers.
The ideal mobile app ecosystem would have the API power of the iPhone and the discovery experience of the iPhone store, coupled with business terms that allow add-on APIs like Flash, Java and Google Gears, all working across a much larger base of devices.
What it all means
If you're a software developer and some platform vendor or web company comes around evangelizing their software store or their APIs, you should evaluate the overall ecosystem they're providing, not just the store or APIs alone. If they haven't thought through issues like billing and discovery, it's a big warning sign.
If you work for a platform or web app company that wants to create a developer community, you need to plan the whole ecosystem and make sure it'll all work. This is especially important for a mobile company that wants to compete with the iPhone store. The way to fight iPhone for developers is to create a superior ecosystem. Apple's weak point is the business and technical restrictions on its developers, and the limited reach of the iPhone APIs. If another vendor -- say, Nokia or Google or Microsoft -- can pair a great store and powerful development with more openness and broader reach, they might be able to give Apple some serious competition. Elia Freedman had some good suggestions on ways to start (link).
____________
PS: Thanks to MobHappy for including my post on smartphone share in the Carnival of the Mobilists (link).
The idea of encouraging third party developers dates back at least to the early days of MS-DOS, but it was associated mostly with operating systems until Web 2.0 applications took off a few years ago. Google played a big role in that change, by exposing APIs to Google Maps that made it possible to embed maps in other web applications. That helped Google Maps quickly blow past established mapping services like Mapquest, while the installed base of Google Maps extensions made it hard for Microsoft's web mapping product to gain traction.
The drive for web APIs got another big boost when Facebook enabled developers to extend its functionality, driving an explosion of widgets for Facebook that helped it grow past MySpace to become the #1 social network in the US (at least according to Alexa).
The web app people all noticed Google's and Facebook's success and furiously started adding APIs to their products. Today it's unusual to hear about a new web app that doesn't have some sort of API story or future plan to add them.
In mobile, applications have an interesting history. Lately some new mobile players have generated huge attention for their application marketplaces. The chart below shows the one year growth in the developer base for a certain well-known mobile platform:
If you're like most people in Silicon Valley, you probably think that's an Apple iPhone developer chart. But actually it's Palm OS ten years ago, from 1998 to 1999.
Disturbing, isn't it? The idea that a platform could take off like that and then crash and burn...makes you wonder if the same thing could happen to the platforms that are popular today.
And in fact, if you look at the history of APIs on both mobiles and web apps, the failures are more numerous than the successes. If you're a developer trying to pick the right platform to create your apps on, that choice is very dangerous -- you're betting the success of your company on something that has a better than 50-50 chance of failing.
If you work at a web or mobile company creating APIs or an app store, the news is equally disturbing: The odds are that you won't succeed.
So it's very important to look at the history of those failed platforms, to figure out what goes wrong and how to avoid it. When you do that, the answer is pretty clear:
It's the ecosystem, stupid
The success of a developer program is not driven just by the beauty of the APIs or the store, but by how the overall ecosystem works to enable developers to prosper. The two parts of the ecosystem that are most important to developers are the ability to create something cool, and the ability to make money. Coolness gets developers to try your platform in the first place. Most developers, especially the innovative new ones, gravitate to a platform that lets them easily create something cool that will impress their friends. But as those developers get older and more responsible, they eventually get tired of drinking lemon drops with Mark Cuban (link). They need to pay rent, buy food, and do other things that require money. If they can't make money from a platform, they will move away to the next one. So the financials are what makes developers stick around over time.
If the ecosystem breaks down anywhere in the chain, the developer community will eventually collapse. You can see this in process driving the history of some prominent web and mobile platforms:
Facebook. Earlier I said Facebook apps were a success because they helped the company grow. That's definitely true from Facebook's short-term perspective, but if you talk to Facebook developers the story is much more mixed. Some people online say there are lots of ways to monetize Facebook apps (link), but other reports say it's difficult to actually make the revenue come in (link). The online attitude toward this when Facebook's platform launched in 2007 was pretty dismissive. One commentator wrote (link):
The problem of not making money with your app is not a Facebook problem. It's your problem!
That's the right attitude for a developer to take: Control your own destiny. But monetization becomes a Facebook problem if nobody can make money. Developers poured into the Facebook platform like the tide in the Bay of Fundy, but a lot of them couldn't make money and promptly poured back out. I can tell you from personal experience that some are pretty bitter and unlikely to do anything with Facebook again.
Mobile Java's problem was that it's not a real platform. Handset vendors and operators were allowed to break compatibility between their implementations of Java, forcing developers to tweak their java apps almost endlessly, dramatically raising their costs and making it hard to scale their companies. The selling model for Java apps was also seriously broken -- to get prominent placement on a phone, developers often had to cut special deals with carriers. Some of the most successful mobile Java game developers have survived because they're great deal-makers; they figure out how to develop for a big brand that wants to create a mobile presence, or they hook into the promotion of a movie. This business model favors a few companies with the skill and contacts to cut the deals; the current mobile Java world is not an ecosystem that can support huge numbers of developers.
Palm and Windows Mobile both succeeded at first in enabling developers to create a lot of interesting applications. Although both operating systems had technical flaws, they were reasonably open to any developer, and the "write once run anywhere" idea mostly worked. Unfortunately, the marketing and sales model for those applications started out mediocre and got worse over time. There was no software store on device, so users had to go out on the web to find apps. This cut the number of people looking for applications. Those who did look online usually landed in the mobile application stores, which over time took a larger and larger share of the developer's revenue. Eventually, the stores' cut grew to more than 50% of revenue, making development uneconomical for many companies. When sales of Palm OS and Windows Mobile devices failed to grow rapidly, the financial model for many developers fell apart, and the ecosystems faded.
What to look for in an ecosystem
If you're a developer looking to find a viable ecosystem, or a platform vendor looking to build one, here are the things to look for.
How easy is it for developers to create something cool? How powerful are the APIs? Can the platform be programmed using standard development tools? Eclipse seems to be the preferred platform among much of the web app crowd, and it's free.
Is the platform programmed in a language that's obscure or difficult to use? This has long been one of the big barriers to Symbian native app development.
How do applications get visibility? Is the store displayed at the first level of the smartphone? How easy is it for users to navigate the store? Online stores like Handango are notoriously hard to navigate; the user experience is about like walking through a flea market.
Can good apps rise to the top? In some software stores, the developer has to pay for prominent placement on the store. This is incredibly corrosive to the ecosystem. The big software companies with money to pay for placement are often the least innovative. So users see an app prominently featured, try it, are disappointed, and never try another one. If web search worked this way, there's a good chance that the web as we know it would never have developed. The practice of pay for placement is a self-defeating, regressive tax -- it penalizes most the small developers who are most likely to create compelling new apps that make a platform more successful.
Ideally, placement on the store should be based on independent user reviews, so the best new apps can rise to the top naturally.
What are the terms of business? Can a developer bill for an app through the user's phone bill? Forcing people to input their credit cards separately slows adoption of software. Can the developer choose different forms of payment? Developers should be enabled to experiment with freeware and subscription payment systems, just as they do on the web. How much of the developer's revenue does the store keep? The ideal cut is no more than 20%.
Are there restrictions on the application's functionality? This is a sore point for iPhone developers. Apple won't allow intermediate platforms that run other applications. So no Java, no Flash, and no emulators like StyleTap's Palm OS emulator (link). This also inhibits other developers who want to expose APIs within their applications.
What is the overhead for security? Some platforms require applications to pay for a new security certificate every time the app is revised. The cost is typically a few hundred dollars, which doesn't sound like much to a big operator or OS company, but is a huge burden to a small company with several apps. They're basically punished every time they fix a bug, which is very unwise -- you want developers to fix bugs instantly, because that increases user satisfaction and reduces support calls. Basic security certificates can and should be issued automatically by the software store, at no charge.
How big is the user base? This will be a more and more important issue over time. For a developer, the ideal platform would let them sell to the whole base of mobile phone users, not just one brand or model.
Room for improvement
Based on those tests, no mobile platform offers an ideal ecosystem today. Apple probably comes closest at the moment. Here's how I'd grade it:
--Power: A-. The iPhone APIs give developers a huge amount of power, and there was a lot of delighted commentary on the web when the APIs were first revealed. But there is a learning curve for iPhone development; Apple has its own tools and its own variant version of C. And support for some typical OS features (such as cut and paste) is missing.
--Store: A-. The store is built into the device prominently, so apps are easier to discover. And there is a user-driven rating system. Developers can bill through Apple's iTunes system; not as convenient as billing through the carrier, but not bad. Apple takes 30% of revenue, which is not ideal, but is better than the 50% or more cut that burdens mobile app developers elsewhere.
--Terms: C+. There are significant, ambiguous restrictions on what a developer can do on the iPhone. The most onerous terms restrict the ability of developers to add functionality to applications and create software that run other applications. The terms cause a lot of confusion among developers; I'm on a mailing list for iPhone developers where they have been trying to figure out whether they can download content to an iPhone app. The answer: it's unclear as to whether content is a form of functionality, and you should ask Apple's lawyers. That is an incredibly intimidating message to app developers. It feels far too much like doing business with the operators.
--User base: Incomplete. It's relatively straightforward to make money from iPhone apps today because the number of developers is still relatively low. But over time, I think it's unlikely that Apple will be able to grow its user base at the same rate as the developer base is growing. If that happens, life will get much less pleasant for iPhone developers.
The ideal mobile app ecosystem would have the API power of the iPhone and the discovery experience of the iPhone store, coupled with business terms that allow add-on APIs like Flash, Java and Google Gears, all working across a much larger base of devices.
What it all means
If you're a software developer and some platform vendor or web company comes around evangelizing their software store or their APIs, you should evaluate the overall ecosystem they're providing, not just the store or APIs alone. If they haven't thought through issues like billing and discovery, it's a big warning sign.
If you work for a platform or web app company that wants to create a developer community, you need to plan the whole ecosystem and make sure it'll all work. This is especially important for a mobile company that wants to compete with the iPhone store. The way to fight iPhone for developers is to create a superior ecosystem. Apple's weak point is the business and technical restrictions on its developers, and the limited reach of the iPhone APIs. If another vendor -- say, Nokia or Google or Microsoft -- can pair a great store and powerful development with more openness and broader reach, they might be able to give Apple some serious competition. Elia Freedman had some good suggestions on ways to start (link).
____________
PS: Thanks to MobHappy for including my post on smartphone share in the Carnival of the Mobilists (link).
Thursday, 1 May 2008
Adobe frees mobile flash: It's about time
Today Adobe announced a series of changes to its emerging web applications platform. The changes include:
--The next version of the mobile Flash runtime will be free of license fees. Adobe also confirmed that the mobile version of the Air runtime will be free.
--Adobe changed its licensing terms and released additional technical information that will make it easier for companies to create their own Flash-compatible products.
--The company announced a new consortium called Open Screen supporting the more open versions of Flash and Air. Members of the new group include the five leading handset companies, three mobile operators (including NTT DoCoMo and Verizon), technology vendors (including Intel, Cisco, and Qualcomm), and content companies (BBC, MTV, and NBC Universal). Google, Apple, and Microsoft are not members. It's not clear to me what the consortium members have actually agreed to do. My guess is it's mostly a political group.
Adobe said that the idea behind the announcements is to create a single consistent platform that lets developers create an application or piece of content once and run it across various types of devices and operating systems. That idea is very appealing to developers and content companies today. It was equally appealing two years ago, when then-CEO of Adobe Bruce Chizen made the exact same promise (link):
If Adobe had made the Open Screen announcement two years ago, I think it could have caught Microsoft completely flat-footed, and Adobe might have been in a very powerful position by now. But by waiting two years, Adobe gave Microsoft advance warning and plenty of runway room to react -- so much so that ArsTechnica today called Adobe's announcement a reaction to Microsoft Silverlight (link).
Also, the most important changes appear to apply to the next version of mobile Flash and the upcoming mobile version of Air -- meaning this was in part a vaporware announcement. Even when the new runtime software ships, it will take a long time to get it integrated into mobile phones. So once again, Microsoft has a long runway to maneuver on.
Still, the changes Adobe made are very useful. There's no way Flash could have become ubiquitous in the mobile world while Adobe was still charging fees for it. The changes to the Flash license terms remove one of the biggest objections I've seen to Flash from open source advocates (link). The Flash community seems excited (link, link). And the list of supporters is impressive. Looking through the obligatory quotes attached to the Adobe release, two things stand out:
--Adobe got direct mentions of Air from ARM, Intel, SonyEricsson, Verizon, and Nokia (although Nokia promised only to explore Air, while it's on the record promising to bundle Silverlight mobile).
--The inclusion of NBC Universal in the announcement will have Adobe people chuckling because Microsoft signed up NBC to stream the Olympics online using Silverlight. So NBC is warning Microsoft not to take it for granted, and Adobe gets to stick its tongue out.
What does it all mean?
Nothing much in the short term. As I mentioned earlier, this is mostly a vaporware announcement (other than the license changes). Some people are speculating that this will put pressure on Apple to make Flash available on the iPhone (link). That's possible, if Apple's real concern was that they didn't like Flash Lite. Now they can port full Flash, or someone else can do it. But if Apple is in reality unwilling to let anyone else's platform run on the iPhone then we'll see other objections to Flash emerge.
The marketing competition to control the future of web apps is continuing to heat up. Microsoft is trying to take the whole thing proprietary by creating a comprehensive architecture, Adobe is trying to drive its own platform, Sun is trying to re-energize Java, Google is making its own moves, and so on (link). Plus, of course, most web app developers today are happy with what they're using now and have little interest in switching to any of the new architectures (check out the dandy commentary by Joel Spolsky here).
It's an enormously complex situation, and it's going to take months, if not years, before we can start to see who's winning and who is losing. Rubicon is working on a white paper that will try to clarify the situation a bit. I'll let you know when it's published.
In the meantime, enjoy the marketing fireworks. The intense competition is forcing companies to innovate faster and open up their products, as Adobe did today. I think that process is good for just about everyone in the industry.
--The next version of the mobile Flash runtime will be free of license fees. Adobe also confirmed that the mobile version of the Air runtime will be free.
--Adobe changed its licensing terms and released additional technical information that will make it easier for companies to create their own Flash-compatible products.
--The company announced a new consortium called Open Screen supporting the more open versions of Flash and Air. Members of the new group include the five leading handset companies, three mobile operators (including NTT DoCoMo and Verizon), technology vendors (including Intel, Cisco, and Qualcomm), and content companies (BBC, MTV, and NBC Universal). Google, Apple, and Microsoft are not members. It's not clear to me what the consortium members have actually agreed to do. My guess is it's mostly a political group.
Adobe said that the idea behind the announcements is to create a single consistent platform that lets developers create an application or piece of content once and run it across various types of devices and operating systems. That idea is very appealing to developers and content companies today. It was equally appealing two years ago, when then-CEO of Adobe Bruce Chizen made the exact same promise (link):
If we execute appropriately we will be the engagement platform, or the layer, on top of anything that has an LCD display, any computing device -- everything from a refrigerator to an automobile to a video game to a computer to a mobile phone.
If Adobe had made the Open Screen announcement two years ago, I think it could have caught Microsoft completely flat-footed, and Adobe might have been in a very powerful position by now. But by waiting two years, Adobe gave Microsoft advance warning and plenty of runway room to react -- so much so that ArsTechnica today called Adobe's announcement a reaction to Microsoft Silverlight (link).
Also, the most important changes appear to apply to the next version of mobile Flash and the upcoming mobile version of Air -- meaning this was in part a vaporware announcement. Even when the new runtime software ships, it will take a long time to get it integrated into mobile phones. So once again, Microsoft has a long runway to maneuver on.
Still, the changes Adobe made are very useful. There's no way Flash could have become ubiquitous in the mobile world while Adobe was still charging fees for it. The changes to the Flash license terms remove one of the biggest objections I've seen to Flash from open source advocates (link). The Flash community seems excited (link, link). And the list of supporters is impressive. Looking through the obligatory quotes attached to the Adobe release, two things stand out:
--Adobe got direct mentions of Air from ARM, Intel, SonyEricsson, Verizon, and Nokia (although Nokia promised only to explore Air, while it's on the record promising to bundle Silverlight mobile).
--The inclusion of NBC Universal in the announcement will have Adobe people chuckling because Microsoft signed up NBC to stream the Olympics online using Silverlight. So NBC is warning Microsoft not to take it for granted, and Adobe gets to stick its tongue out.
What does it all mean?
Nothing much in the short term. As I mentioned earlier, this is mostly a vaporware announcement (other than the license changes). Some people are speculating that this will put pressure on Apple to make Flash available on the iPhone (link). That's possible, if Apple's real concern was that they didn't like Flash Lite. Now they can port full Flash, or someone else can do it. But if Apple is in reality unwilling to let anyone else's platform run on the iPhone then we'll see other objections to Flash emerge.
The marketing competition to control the future of web apps is continuing to heat up. Microsoft is trying to take the whole thing proprietary by creating a comprehensive architecture, Adobe is trying to drive its own platform, Sun is trying to re-energize Java, Google is making its own moves, and so on (link). Plus, of course, most web app developers today are happy with what they're using now and have little interest in switching to any of the new architectures (check out the dandy commentary by Joel Spolsky here).
It's an enormously complex situation, and it's going to take months, if not years, before we can start to see who's winning and who is losing. Rubicon is working on a white paper that will try to clarify the situation a bit. I'll let you know when it's published.
In the meantime, enjoy the marketing fireworks. The intense competition is forcing companies to innovate faster and open up their products, as Adobe did today. I think that process is good for just about everyone in the industry.
Thursday, 6 March 2008
The iPhone SDK: Apple gets it right
I have time tonight for only a quick note on Apple's iPhone software developer kit announcement. Overall, it is deeply impressive how many things Apple got right. We still need to see more details on terms and conditions, and a lot will depend on Apple's execution, but here are the problems they appear to have solved:
--Mobile applications are hard for users to find and install, so Apple is building the applications store into every device. Apps are installed automatically when you buy them, and you can also be notified of upgrades when they're available.
--Third party applications stores take far too much of a developer's revenue -- 60% or more. So the Apple store takes 30%. That's a bit high (20% would be better), but everyone else has been so greedy that Apple looks like a charity.
--Getting applications certified for use on mobiles is expensive and time-consuming, so Apple has streamlined the process dramatically. Developers pay $99 a year, and apparently get automatic certification of all their apps. We need to learn more about how the app approval process will work, but if it's not burdensome this service alone justifies Apple's 30% cut of revenue. Apple takes responsibility for ensuring that iPhones remain secure and do not abuse the network, something that no one else has been willing to do.
--Developers want to get access to the features of the phone, so Apple has exposed a very rich API set including access to the accelerometer and other special features of the iPhone. This is not a sandbox; it looks like it's access to pretty much the whole OS.
--And oh by the way, Kleiner Perkins is creating a $100 venture million fund for iPhone developers. Makes Google's $10m contest for Android developers look like a popgun.
It has been obvious for at least six years that all of these changes were needed in the mobile market, but until now no one in the US and Europe has had the courage / political muscle / intelligence to carry them all out. The other mobile platforms now look pretty pathetic by comparison -- not so much because their technologies are bad, but because their business infrastructure is so primitive.
At the announcement today, John Doerr called this Apple's third platform, which has a very specific meaning in Silicon Valley. It means they're planning to drive rapid growth in apps, which will make the iPhone more attractive to customers, which will in turn attract more developers, bringing in even more users, and so on in a virtuous circle.
I don't know how far Apple can drive that, just because their sales are so small compared to the total number of phones out there. I still think it's likely that web apps will eventually displace most native mobile apps, because the addressable market will be so much larger. But eventually can take a long time, and if anyone can buck the trend it'll be Apple. They have created by far the best overall proposition for mobile developers on any platform in the US or Europe, and I hope they'll do very well for a long time.
Apple is challenging the rest of the mobile industry to compete on its terms. It will be very interesting to see how the other mobile vendors react, Nokia and Microsoft in particular. Nokia seems to be focused on a strategic positioning activity around seeing who can collect the most runtimes, while Apple is solving real developer and user problems. It's a striking contrast.
The rest of the industry is still trying to figure out how to respond to the system design of the iPhone, and now they need to also figure out how to run an ecosystem as well. Right now Apple is changing the terms of the competition faster than the other guys can react, which is exactly the right way to beat a group of larger competitors.
--Mobile applications are hard for users to find and install, so Apple is building the applications store into every device. Apps are installed automatically when you buy them, and you can also be notified of upgrades when they're available.
--Third party applications stores take far too much of a developer's revenue -- 60% or more. So the Apple store takes 30%. That's a bit high (20% would be better), but everyone else has been so greedy that Apple looks like a charity.
--Getting applications certified for use on mobiles is expensive and time-consuming, so Apple has streamlined the process dramatically. Developers pay $99 a year, and apparently get automatic certification of all their apps. We need to learn more about how the app approval process will work, but if it's not burdensome this service alone justifies Apple's 30% cut of revenue. Apple takes responsibility for ensuring that iPhones remain secure and do not abuse the network, something that no one else has been willing to do.
--Developers want to get access to the features of the phone, so Apple has exposed a very rich API set including access to the accelerometer and other special features of the iPhone. This is not a sandbox; it looks like it's access to pretty much the whole OS.
--And oh by the way, Kleiner Perkins is creating a $100 venture million fund for iPhone developers. Makes Google's $10m contest for Android developers look like a popgun.
It has been obvious for at least six years that all of these changes were needed in the mobile market, but until now no one in the US and Europe has had the courage / political muscle / intelligence to carry them all out. The other mobile platforms now look pretty pathetic by comparison -- not so much because their technologies are bad, but because their business infrastructure is so primitive.
At the announcement today, John Doerr called this Apple's third platform, which has a very specific meaning in Silicon Valley. It means they're planning to drive rapid growth in apps, which will make the iPhone more attractive to customers, which will in turn attract more developers, bringing in even more users, and so on in a virtuous circle.
I don't know how far Apple can drive that, just because their sales are so small compared to the total number of phones out there. I still think it's likely that web apps will eventually displace most native mobile apps, because the addressable market will be so much larger. But eventually can take a long time, and if anyone can buck the trend it'll be Apple. They have created by far the best overall proposition for mobile developers on any platform in the US or Europe, and I hope they'll do very well for a long time.
Apple is challenging the rest of the mobile industry to compete on its terms. It will be very interesting to see how the other mobile vendors react, Nokia and Microsoft in particular. Nokia seems to be focused on a strategic positioning activity around seeing who can collect the most runtimes, while Apple is solving real developer and user problems. It's a striking contrast.
The rest of the industry is still trying to figure out how to respond to the system design of the iPhone, and now they need to also figure out how to run an ecosystem as well. Right now Apple is changing the terms of the competition faster than the other guys can react, which is exactly the right way to beat a group of larger competitors.
Tuesday, 4 March 2008
Nokia and Microsoft, sittin' in a tree...
There's so much hype in the mobile industry that I'm always reluctant to use a word like "shocking," but nothing else fits Nokia's announcement today that it will support Microsoft Silverlight.
If you missed the press release (link), Nokia said that it's going to make Microsoft Silverlight available for all of its mobile platforms -- Series 40 (the low-end phone OS), S60 (the high-end OS), and its Maemo Internet tablet. (It's not clear if Silverlight will be bundled or just offered as a download.) Silverlight is a web app graphics and interface layer, intended to displace Adobe Flash.
The announcement was shocking for several reasons:
--Up until now, Nokia and Adobe had worked together closely. Nokia is one of the few companies paying to bundle Flash on its phones, and Nokia had featured Adobe prominently at some of its developer events in Silicon Valley. So the announcement I was expecting was that Nokia would bundle Air, the next evolution of Flash, rather than its competitor.
--Nokia has generally treated Microsoft as the spawn of the devil. The whole Symbian OS consortium was designed primarily as a way to prevent Microsoft from getting a controlling role in mobile software. Now Nokia gives Microsoft's software layer a huge boost?
--Although Microsoft had hinted vaguely about taking Silverlight mobile, it had given no definite plans at all. So this is a huge step forward for Silverlight.
--Just a few weeks ago, Nokia bought TrollTech and announced that its software was going to unify development across Series 40 and S60. Now Nokia endorses Silverlight, which will also run across Series 40 and S60. Which one are developers supposed to focus on?
What in the world is going on?
I don't know. Nobody from Nokia has explained it to me, so I have to read between the lines. Nokia says in the press release: "Nokia aims to support market leading and content rich internet application environments and to embrace and encourage open innovation. By working with Microsoft, we are creating terrific opportunities and additional choices for the development community." Okay, so I guess what they're saying is that they want to support every platform and development option out there. Presumably the benefit to them is that they can claim their phones support more software than anyone else.
I doubt that's the only motivation, though. By supporting numerous platforms, Nokia reduces the possibility that any one of them can dominate the market and push around Nokia. It also lets Nokia play the sides off against one another. I'm sure the threat of embracing Air made Microsoft give Nokia a very good deal on Silverlight, and no doubt Nokia will now use its Microsoft relationship to get business concessions from Adobe (assuming that Nokia still plans to work with Adobe at all; that's not entirely clear).
Anyway, I can sort of see how this all works for Nokia strategically, although it feels like Nokia is trying too hard to be clever. I'm not as clear on the benefits of all this for mobile developers and users. As was covered in last week's post on mobile apps (link), many developers view the proliferation of platforms as a problem, not a benefit. Microsoft itself said in the Nokia press release:
That's a pretty danged funny quote coming from a company that now offers at least four mobile platforms (two versions of Windows Mobile, Silverlight, Tablet PC, and does .Net CF count as a fifth?), in a press release from a company that apparently wants to support every platform available. If you really think platform confusion is a problem, guys, look in a mirror.
For users, the benefit of all this deal-making is unclear. We're stumbling into a world where you'll need to know details of which platforms are loaded on a particular phone in order to know which apps it can run. I can't think of a better way to discourage use of mobile applications.
If you missed the press release (link), Nokia said that it's going to make Microsoft Silverlight available for all of its mobile platforms -- Series 40 (the low-end phone OS), S60 (the high-end OS), and its Maemo Internet tablet. (It's not clear if Silverlight will be bundled or just offered as a download.) Silverlight is a web app graphics and interface layer, intended to displace Adobe Flash.
The announcement was shocking for several reasons:
--Up until now, Nokia and Adobe had worked together closely. Nokia is one of the few companies paying to bundle Flash on its phones, and Nokia had featured Adobe prominently at some of its developer events in Silicon Valley. So the announcement I was expecting was that Nokia would bundle Air, the next evolution of Flash, rather than its competitor.
--Nokia has generally treated Microsoft as the spawn of the devil. The whole Symbian OS consortium was designed primarily as a way to prevent Microsoft from getting a controlling role in mobile software. Now Nokia gives Microsoft's software layer a huge boost?
--Although Microsoft had hinted vaguely about taking Silverlight mobile, it had given no definite plans at all. So this is a huge step forward for Silverlight.
--Just a few weeks ago, Nokia bought TrollTech and announced that its software was going to unify development across Series 40 and S60. Now Nokia endorses Silverlight, which will also run across Series 40 and S60. Which one are developers supposed to focus on?
What in the world is going on?
I don't know. Nobody from Nokia has explained it to me, so I have to read between the lines. Nokia says in the press release: "Nokia aims to support market leading and content rich internet application environments and to embrace and encourage open innovation. By working with Microsoft, we are creating terrific opportunities and additional choices for the development community." Okay, so I guess what they're saying is that they want to support every platform and development option out there. Presumably the benefit to them is that they can claim their phones support more software than anyone else.
I doubt that's the only motivation, though. By supporting numerous platforms, Nokia reduces the possibility that any one of them can dominate the market and push around Nokia. It also lets Nokia play the sides off against one another. I'm sure the threat of embracing Air made Microsoft give Nokia a very good deal on Silverlight, and no doubt Nokia will now use its Microsoft relationship to get business concessions from Adobe (assuming that Nokia still plans to work with Adobe at all; that's not entirely clear).
Anyway, I can sort of see how this all works for Nokia strategically, although it feels like Nokia is trying too hard to be clever. I'm not as clear on the benefits of all this for mobile developers and users. As was covered in last week's post on mobile apps (link), many developers view the proliferation of platforms as a problem, not a benefit. Microsoft itself said in the Nokia press release:
"We want to make sure developers and designers don't have to constantly recreate the wheel and build different versions of applications and services for multiple operating systems, browsers and platforms."
That's a pretty danged funny quote coming from a company that now offers at least four mobile platforms (two versions of Windows Mobile, Silverlight, Tablet PC, and does .Net CF count as a fifth?), in a press release from a company that apparently wants to support every platform available. If you really think platform confusion is a problem, guys, look in a mirror.
For users, the benefit of all this deal-making is unclear. We're stumbling into a world where you'll need to know details of which platforms are loaded on a particular phone in order to know which apps it can run. I can't think of a better way to discourage use of mobile applications.
Sunday, 24 February 2008
Mobile applications, RIP
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:
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.
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.
Subscribe to:
Posts (Atom)
-
Today, everyone relies on Internet for their day-to-day work and needs, and there are millions of websites registered there on the Internet... -
Images are the backbone of your well-nourished articles. Every business success factor rate depends on how well was its content marketing, a... -
I was very surprised by the volume of responses to last week's post on the decline of the mobile applications business. Many of the com...