iOS, Android, and the mobile web

As Keepskor approaches its first release, I’ve spend a considerable amount of time thinking about the mobile market and mobile development. Last week, I looked at the size of the market opportunity; This week, let’s cover more technical issues.

Many Questions

The mobile market is basically broken out in a 2 + 2 configuration: Android and iOS are the two contenders you can’t do without, while RIM and Microsoft are the two you might want to keep an eye on. Looking at this through the lens of limited resources, it makes for tough choices. If you only have resources for one platform, which should it be? If you have resources for more than 2, should you also try to reach a third platform (and if yes, which one) or should you pour more investments in the first two?

In order to better make those calls, one must assess the market position of each of the players and place some bets as to where those players will be in 12 months. While interesting from an intellectual challenge, it can be emotionally wrenching from a company standpoint as some of the bets you make today could help turn your company into a winner or loser.

App or web?

Mobile apps seem to be the largest trend here. While many new apps have come up over the last few years, there doesn’t seem to be much discussion of mobile web offerings. Curiously, the internet seems to be splintering into javascript-heavy apps running on users’ computers and mobile applications of the same apps running natively on mobile devices.

With HTML5, a lot of the benefits that mobile apps could offer seem to disappear: whether it is access to geo-location capabilities, local caching so the app can run when there is no signal, or even access to hardware capabilities like a camera (something Google is trying to bake into future versions of HTML), there appears to be an increasing array of possibilities that would ensure some parity between web-based offerings and apps-based ones.

However, the web has a few challenges to overcome. For starters, local notification, or the ability to throw some type of alert flag when the application is not running, is not available in web apps. One-click billing is not built-in by default. Access to local hardware devices is also limited. But ultimately, the problem web apps are going to encounter when compare to local apps have nothing to do with technology.

The main value of an iOS or Android app over a web app is largely a marketing issue. To a lot of thought leaders, the web is seen as yesterday’s invention and apps are seen as the current hot trend. To launch a web app in 2011 is seen as similar to trying to launch a CD-based offering in 1995: maybe interesting but probably not, and more likely outdated than up to the latest trend (or to put it in more brutal terms, it would be seen as “dead,” as per the criteria highlighted in Om Malik’s excellent post on the subject.)

Furthermore, the presence of an app in the respective app stores by Apple, Google (and now Amazon) represents marketing channels which cannot be matched in the open web. As restrictive as they are, those channels can represent a substantial advantage for new product offerings. The presence of your apps’ icon on a user’s phone is also another marketing marker that is hard to be matched by web application: yes, it true that bookmarks can be presented alongside applications but few users know how to do that and even fewer actually do make those links.

If an app is launched on a platform like iOS and Android, it gets more publicity than if it launches as a mobile web-based offering. This, by the way, is something I see as a reason for concerns in the long terms as it means that most of the debate is now centering not on a more open world but on one as to which walled garden is better: Apple’s or Google’s?

As a strong supporter for a more open web, I find myself conflicted: on the one hand, I see that getting into those walled gardens is bad for the web as a whole; on the other hand, in order to run a successful business, I have to be in those walled gardens. Almost a year ago, I covered this as Apple is the new China and things have gotten worse since, as Google is following a path similar to Apple. But in the end, one has to be realistic: the only way to influence this debate is to become successful enough that your voice gets amplified: so playing in the walled gardens is imperative for any new mobile company that wants to succeed.

iOS or Android first?

With apps as an obvious first step towards development, the next question in the decision tree is Android vs. iOS. Here, there are confusing signals in the marketplace: on the one hand, one can talk about market size and see that Android is becoming the most used operating system in the mobile world. On the other hand, one can see the fragmentation of the Android market as a developer’s nightmare.

Assuming the fact that most startups have limited resources, one could safely make the bet that a less fragmented market is easier to launch a successful product on and thus developing for iOS first would make the most sense. That is generally the rule that most developers follow and I want to challenge that rule.

According to Apple, there are over 350,000 apps in the app store. By comparison, the Android market has over 100,000 apps. So one can safely say that there are roughly 3 to 4 apps on iOS devices for every app on Android devices. Today, the path of most applications is to establish themselves on the iPhone, get the adulation of the Apple crowd and then move to migrate to Android devices.

This generally means that apps which were successful on the iPhone benefit from a lift when they finally make it to the Android marketplace as Android users are curious to see what all the hubbub was about. This situation has led to a situation whereas both top 10 lists are dominated by apps that first saw the light of day as iOS ones.

But what if one were to apply the amount of effort that goes into crafting a well-received app for iOS into developing a similar app for Android first? What if a company were to decide to prioritize its efforts on developing the best app for Android devices? All things being equal, a great app developed for iOS would have to be better than over 350,000 apps while a similar app being developed for Android would have to be better than 100,000 apps.

When looking at those numbers, combined with the fact that the Android marketplace is exploding, it seems that Android development makes more sense when first getting out the door but there is yet another catch.

Free or Paid?

Paid apps seem to fair better in the Apple world than in the Android world. I don’t know if it is due to the demographic profile of Apple users vs Android users (remember that Apple tends to market itself as a premium brand, probably creating a user community that is more affluent and more free-wheeling with its spending) but the fact of the matter is that if you are marketing a paid app, this is something you have to consider.

So if your monetization model is purely centered o selling apps, you may be better off using Apple’s offering (as long as you can figure out how to build a successful business 99 cents a time.)

On the other hand, few apps with hybrid strategies (social, web, mobile) are offered as paid ones. A few examples like Facebook, Twitter or LinkedIn all seem to show that app that also work as web-based platforms are generally free (as platforms though, they have created opportunities for others to market paid apps on top of their services). If your app is a social web app, the Android market seems to be a better place in the short run.

The key to this positioning will have to be around your company’s ability to present itself as breaking the mold. By going against the grain, you are likely to suffer the ire of Apple fan-boys but the ensuing controversy may get you marketing views you would not have gotten otherwise.

Danger to Android

Today, Android is indeed a fragmented market. So development for that platform is more complicated than development for iOS, where one only has to worry about 2 phones (iPhone 3GS and 4).

The challenge Google now has is balancing its openness while making it easier for developers to deal with the multitude of changes. Its recent efforts in trying to tighten up regulation of the platform can cut both ways. Developers on the Android platform should keep an eye on the impact of those efforts on carriers and device manufacturers support. If Google tightens the screws too much, it could lose some of the momentum it has built and give companies like Apple and Microsoft a chance to establish leadership in the space.

The second tier

Today, developers have to develop an offering for both the Android and iOS marketplace. Once they’ve done so, the next strategic question is whether to put any effort into RIM, HP (aka. Palm) or Microsoft’s offering.

If I were to follow the points above, logic might dictate that the smaller the platform, the better the way to shine out. However, at the current time, those platform look too small to cater to today. The recent announcement from Nokia may point to Microsoft becoming an emerging platform again but  the actual switch is not due for another couple of years. At that point, the marketplace may look radically different again.

So at the end of day, my recommendation (and what we’re betting on at Keepskor) is Android first, mobile web second, iOS third, and then figure out the next step.

Previous Post
Mobile Internet Market Size
Next Post
5 startup myths

Related Posts

8 Comments. Leave new

April 4, 2011 3:53 pm

The iOS market is twice the size of Android when you include the iPod Touch (iPhone without a phone component). So if you’re going for volume iOS is undoubtable the one. Then you have to consider the iPad market where Android is having trouble with over priced tablets.

Android has a long way to go but its looking like the tablet market is going to be like the iPod market – Apple dominated.

Apple’s Mac line, let alone the Windows world, have more hardware and software diversity in one minute than Android has all year. Yet no one seriously suggests that “fragmentation” somehow hurt the desktop PC market.

I believe “fragmentation” is a FUD bullet point created somewhere inside Apple’s marketing department. It presumes an ideal world that could only be a fantasy of an Apple executive; one in which a single manufacturer produces perfect, standard devices in a graceful schedule.

Ironically, Android has the most comprehensive, well-engineered mechanisms for handling hardware and software diversity ever widely deployed. All to manage an ecosystem with diversity both limited and similar to Apple’s: screen sizes, generational changes in CPU, GPU, RAM, and IO performance, the presence or absence of discrete sensors like a compass, and uniquely to Android, some worthless and universally ignored manufacturer-supplied skins and extensions.

Google’s development environment produces apps that run on everything, or you can choose a higher API version from a pullout menu should you need to. You can simulate virtually any type or version of hardware, and run your apps on it with a single click. The emulator is a proper low-level design, unlike Apple’s simulator.

Bugs are, of course, not uniform across builds. 🙂 But by the logic that this somehow dooms the platform, it’s time to call for i.e. the web browser folks to pick a winning browser and all others to capitulate.

    One counter-argument to this is that the fragmentation means higher amounts of time spent in quality control for app developments as apps have to be tested on a variety of form factors and formats. From that standpoint, it makes developing for Apple easier. On the other hand, if you solve that puzzle, it seems the market will continue to increase at a faster rate: the main reason is that networks (and Android is more of a network, with many suppliers) tend to win over monolithic structures.

      To argue against myself, another counterargument is that closed and perfectly standardized development targets such as XBox, Playstation and Wii won over their open counterpart, the PC, in the video game industry. Some counter-counterarguments are that the vertically integrated platform vendors could subsidize the hardware sales with future licensing revenues, and that relative to game consoles (where a single, largely standard device reigns for 5+ years), iOS already has most of the same types of diversity that Android has (making the compatibility “time spent” argument less of a budget driver than other forms of tool quality, and the word “fragmentation” something of a shibboleth).

      (I’d add the argument that game consoles won because Windows was so poor for its most common uses that it created the competitive opportunity.)

        I would beg to differ as to the amount of diversity within the iOS platform being anywhere near as high as Android. As far as I can see, there are 11 devices with iOS: iPhone, Iphone 3G, iPhone 3GS, iPhone 4 GSM, iPhone 4 CDMA, iPad, and 4 iPod Touch versions. That’s the whole iOS universe to date. HTC alone probably has that many Android devices… and that’s one manufacturer.

        So the diversity isn’t really there on iOS and that makes it easier to do quality control for it.

          There are definitely many more Android device models. But obviously there’s a common API. A single app could run on them all. Let’s define diversity in terms of variations that add time to your development schedule.

          How many screen resolutions must you support? The only relevant answers are basically “One, or more than one.” Is there a standard hardware design with predictable performance characteristics, or do I have to cope with variations? Are things like a camera or compass or near field communications or a 3G/4G radio optional (so you have to check for them with an API and deal if they’re not there)? Both Apple and Google vary screen sizes, performance characteristics and hardware features. Developers on both platforms use layout managers, gracefully degrade via performance tests and API calls, almost without even noticing. What kind of diversity is left that is a big driver of development time?

          You would need a survey to prove this, but I would guess the average “diversity-related work” per project to be roughly equivalent for iOS and Android, and small in both cases. Write your app using an API version of your choice, and it will _generally_ work on all devices that support that version. The difficulty that remains is considerably less than in Windows development (where the architecture is inferior and the diversity vastly greater). It will not keep developers away from the #1 smartphone platform in the US.

        I would beg to differ as to the amount of diversity within the iOS platform being anywhere near as high as Android. As far as I can see, there are 11 devices with iOS: iPhone, Iphone 3G, iPhone 3GS, iPhone 4 GSM, iPhone 4 CDMA, iPad, and 4 iPod Touch versions. That’s the whole iOS universe to date. HTC alone probably has that many Android devices… and that’s one manufacturer.

        So the diversity isn’t really there on iOS and that makes it easier to do quality control for it.

I believe it’s a mistake to merge the tablet and phone markets when doing those analysis: the use patterns and models are radically different (but if you want to merge things, then Microsoft wins the war because it’s got portable PCs and phones running windows. *just kidding*)

Your point about the iPod Touch is a valid one, however. So this a valid counter-argument. However, I have a question regarding usage patterns of the touch: how many people see the WiFi as an always-on type of offering. I wish it were the case but the dearth of WiFi hotspots in a lot of areas still mean that as far as mobile apps, EDGE, 3G and 4G are the only way to go (it is for the same reason, incidentally, that I do not recommend going after a web-based app only approach).