Android’s Growth Rate and How It Actually Hurts The App Market(blog.appboy.com)
blog.appboy.com
Android’s Growth Rate and How It Actually Hurts The App Market
http://blog.appboy.com/2010/06/androids-growth-rate-and-how-it-actually-hurts-the-app-market/
I feel everywhere I look people are having the old iPhone Vs. Android debate. Granted I am mostly looking in very geeky places, but still, this is a pretty common discussion in my circles. Before the announcement of iPhone 4, many thought Android was going to take the lead soon and some believed it already had when it came to technology and specs.
11 comments
Here is my comment I posted:
I hate to be so harsh but this reeks of FUD. Now part of me understands why, but I can’t pretend to agree with it.
First of all, the biggest glaring issue with your analysis is that with the inclusion of iOS 4 and the iPhone 4, iDevices will have a similar fragmentation problem (if you will) that developers will have to contend with. As it was mentioned in a comment by Greg Dunn, games and 3D apps are going to be one that really polarizes the App Store. But there are other things, like the iPhone 2G won’t be getting iOS 4 and subsequently adds a rift in what apps can work on it if they focus on iOS 4 features. This is even a problem for the iPhone 3G that is getting the upgrade to iOS 4 but wont have features like ‘multitasking’ which is again just another thing to account for in different versions.
Now admittedly, there are less to deal with on the iDevices side, it is just as much of a problem, and probably more sore because there are more older iDevices than there are Android at this point. Then you have to count the iPad which throws a loop into it. Apple is handling the SDK stuff pretty well, but its going to be an issue just like it is for Android devices.
The other issue with your article is that you ignore all the efforts Google has done and continues to do to make developers jobs easier when accounting for the multiple devices. Newer versions of the Android SDK have code in place to handle variations in screen resolution/size. You can easily make an app in the newest SDK for the oldest version of Android (1.5) and it will work, although a lot of features may be missing. Google is working hard to make sure this problem isn’t as much of a problem in the future, and as the time between major releases slows down, this will mean the amount of versions out there are less over time.
Another thing to keep in mind, the amount of Android handsets is very little, especially the older <2.0 versions. Most if not all newer handsets have been upgraded to 2.1 or are getting 2.2. Even some older phones like the T-Mobile MyTouch 3G and the new MyTouch 3G Slide are getting 2.2. So the majority of phones out there, like the Evo 4G will be on the bleeding edge and keep up with the pack for years to come. So the pool of different Android versions overwhelmingly is filled with handsets of 2.1 or better. Ultimately, this is a non-issue, or at most, as much of an issue as it is for iOS developers.
I hate to be so harsh but this reeks of FUD. Now part of me understands why, but I can’t pretend to agree with it.
First of all, the biggest glaring issue with your analysis is that with the inclusion of iOS 4 and the iPhone 4, iDevices will have a similar fragmentation problem (if you will) that developers will have to contend with. As it was mentioned in a comment by Greg Dunn, games and 3D apps are going to be one that really polarizes the App Store. But there are other things, like the iPhone 2G won’t be getting iOS 4 and subsequently adds a rift in what apps can work on it if they focus on iOS 4 features. This is even a problem for the iPhone 3G that is getting the upgrade to iOS 4 but wont have features like ‘multitasking’ which is again just another thing to account for in different versions.
Now admittedly, there are less to deal with on the iDevices side, it is just as much of a problem, and probably more sore because there are more older iDevices than there are Android at this point. Then you have to count the iPad which throws a loop into it. Apple is handling the SDK stuff pretty well, but its going to be an issue just like it is for Android devices.
The other issue with your article is that you ignore all the efforts Google has done and continues to do to make developers jobs easier when accounting for the multiple devices. Newer versions of the Android SDK have code in place to handle variations in screen resolution/size. You can easily make an app in the newest SDK for the oldest version of Android (1.5) and it will work, although a lot of features may be missing. Google is working hard to make sure this problem isn’t as much of a problem in the future, and as the time between major releases slows down, this will mean the amount of versions out there are less over time.
Another thing to keep in mind, the amount of Android handsets is very little, especially the older <2.0 versions. Most if not all newer handsets have been upgraded to 2.1 or are getting 2.2. Even some older phones like the T-Mobile MyTouch 3G and the new MyTouch 3G Slide are getting 2.2. So the majority of phones out there, like the Evo 4G will be on the bleeding edge and keep up with the pack for years to come. So the pool of different Android versions overwhelmingly is filled with handsets of 2.1 or better. Ultimately, this is a non-issue, or at most, as much of an issue as it is for iOS developers.
* Have you ever tried Android 1.6 on a Samsung Galaxy then spent two minutes playing with a Nexus*
If the author tries another HTC devise I'm sure he'll make this point more stronger. He seems to forget that although all these devices may run different versions of the same operating system, most manufacturers (except the Google-branded phone) customize the user experience. HTC has HTC Sense, Motorola has MOTOBLUR and Sony I guess has Mediascape and Timescape (Not sure about Sony tho).
So as mentioned in the article instead of spending 3min just "spending 2min playing with a Nexus One", he might want to try out apps on it and dig out more than just staring at the home screens or the menus. It's all like the same necklace you see at different shops at different prices with a different gem color. And the Android market sorts out apps based on the minsdk setting specified by the app developer. So a developer can target devices easily. Also the Android SDK provides a way to use different images for different screen type (there's a drawable dir in the app's resources dir that does takes csre of this).
The Android SDK and Market's architecture is well thought of.
A lot of people actually curse the 24hr return policy of the market too. But it's very right. There's no need to provide a separate lite version if you don't feel so. Users can just buy the app, try out the full version, and return it if they aren't satisfied. Which is a safer bet than letting users think a thousand times if the app is worth the money, buy it and end up with a real crap app. Thus leaving the process of reviewing the app to the user.
If the author tries another HTC devise I'm sure he'll make this point more stronger. He seems to forget that although all these devices may run different versions of the same operating system, most manufacturers (except the Google-branded phone) customize the user experience. HTC has HTC Sense, Motorola has MOTOBLUR and Sony I guess has Mediascape and Timescape (Not sure about Sony tho).
So as mentioned in the article instead of spending 3min just "spending 2min playing with a Nexus One", he might want to try out apps on it and dig out more than just staring at the home screens or the menus. It's all like the same necklace you see at different shops at different prices with a different gem color. And the Android market sorts out apps based on the minsdk setting specified by the app developer. So a developer can target devices easily. Also the Android SDK provides a way to use different images for different screen type (there's a drawable dir in the app's resources dir that does takes csre of this).
The Android SDK and Market's architecture is well thought of.
A lot of people actually curse the 24hr return policy of the market too. But it's very right. There's no need to provide a separate lite version if you don't feel so. Users can just buy the app, try out the full version, and return it if they aren't satisfied. Which is a safer bet than letting users think a thousand times if the app is worth the money, buy it and end up with a real crap app. Thus leaving the process of reviewing the app to the user.
Users can just buy the app, try out the full version, and return it if they aren't satisfied. Which is a safer bet than letting users think a thousand times if the app is worth the money, buy it and end up with a real crap app. Thus leaving the process of reviewing the app to the user.
A safer bet for who? If you have no return option you will be happier about your purchase...
http://blog.ted.com/2006/09/happiness_exper.php
A safer bet for who? If you have no return option you will be happier about your purchase...
http://blog.ted.com/2006/09/happiness_exper.php
This guy doesn't know what he's talking about. As a mobile developer (on - surprise! - Android) I can say for sure that unless you're writing native code through JNI, Google has taken great pains to make sure that an Android phone is an Android phone is an Android phone. "Fragmentation" is just not the big deal everyone is making it out to be. In fact, our Android application has required less than 1% of the effort to "port" it across all phones than our equivalent J2ME app required. You want to talk about fragmentation, go look at feature phones!
And he seems unaware that iDevices have 3 different screen sizes and variable amounts of cameras. Then acts as if screen size and resolution are somehow dependent.
I'm a developer on a fairly high profile Android app. We target Android 1.5 (the oldest version with significant market share), and we've had very few problems with fragmentation. Our app works just as well on a G1 as it does on a Nexus or EVO with Sense. If you use the SDK right it's fairly effortless. With a little runtime checking, you can even add support for new features in new OS versions while remaining compatible with 1.5 (unit tests help a lot for this).
If it works on the G1, it'll work pretty well on other devices if you're careful about the assumptions you make. Honestly, the hardest part has been producing separate assets of all our images for different resolutions.
Granted, we're not doing anything with OpenGL, my understanding is that gets much more complicated.
If it works on the G1, it'll work pretty well on other devices if you're careful about the assumptions you make. Honestly, the hardest part has been producing separate assets of all our images for different resolutions.
Granted, we're not doing anything with OpenGL, my understanding is that gets much more complicated.
Wasn't this essentially the reason why IBM's PC and it's open architecture would never work?
You seem to have forgotten that the PC evolved to run one particular closed-source operating system. That is the major reason why PCs ended up all looking alike and working alike.
Microsoft enforces a lot of that conformity by creating official hardware standards and certifications:
http://en.wikipedia.org/wiki/WHQL_Testing
... but even in the absence of that, the requirement to run Windows in a seamless fashion constitutes a de facto standard embodied in code that the vendor cannot change.
Android, by contrast, is open source. Vendors can and do take Android, make fundamental changes in how (e.g.) the interface works, and release quirky versions of Android on their own quirky hardware. So there are far fewer constraints on how divergent the boxes can be and still carry the "Android" label.
Microsoft enforces a lot of that conformity by creating official hardware standards and certifications:
http://en.wikipedia.org/wiki/WHQL_Testing
... but even in the absence of that, the requirement to run Windows in a seamless fashion constitutes a de facto standard embodied in code that the vendor cannot change.
Android, by contrast, is open source. Vendors can and do take Android, make fundamental changes in how (e.g.) the interface works, and release quirky versions of Android on their own quirky hardware. So there are far fewer constraints on how divergent the boxes can be and still carry the "Android" label.
In point of fact, Google has something almost identical in the form of the Compatibility Definition Document, which gives fairly strict and detailed specifications for what an Android device is. There's also a set of tens of thousands of automated tests that an Android implementation has to be able to pass to be considered "Android." And to date, no one has really made "fundamental" changes in how the interface works - the only major mover out there is sense UI, and it still uses the same widgets and framework.
Although Android is open source and could just be hacked around with most of the modifications seem to be modular components i.e. here is a new HTC keyboard, if you don't like it you can switch it to the standard Android keyboard or buy a 3rd party keyboard like Swype.
To be fair, it didn't work out too well for IBM (hence the much more closed PS/2 range). The real winner was Microsoft.
I think it's fairly obvious at this point that the 2 hurdles in mobile are the heterogeneous android ecosystem and the iPhone AT&T straight jacket ecosystem.
For the most part, an iphone is an iphone is an iphone, but the android experience is all over the place. Only die hard developers care about openness all other consumers care about cost and value in relation to the experience provided compared to existing alternatives. Android needs to be setting benchmarks with cutoff dates so people know what they're getting, for how long, and the carrier/phone manufactures need to support it.
Feature lists are 1990s.
For the most part, an iphone is an iphone is an iphone, but the android experience is all over the place. Only die hard developers care about openness all other consumers care about cost and value in relation to the experience provided compared to existing alternatives. Android needs to be setting benchmarks with cutoff dates so people know what they're getting, for how long, and the carrier/phone manufactures need to support it.
Feature lists are 1990s.
What is the timetable to use a new api on iOS and what is it on Android(assuming you want to target the majority of the market)?
How does it help the ecosystem to have 4-5 different shells running on top of Android? It makes the word Android mean less to people. So I can probably run the same apps but my interaction with the phone is different and upgrades take much longer to be verified.
These aren't dire problems but I think a lot of people would like to see them addressed in some way.
How does it help the ecosystem to have 4-5 different shells running on top of Android? It makes the word Android mean less to people. So I can probably run the same apps but my interaction with the phone is different and upgrades take much longer to be verified.
These aren't dire problems but I think a lot of people would like to see them addressed in some way.
Could anyone enlighten me on how Android developers handle the problem at the moment? Lowest common denominator, optimizing for popular resolutions or releasing versions for different resolutions seem to be pathways one could take, but they all seem inadequate.
By using the well designed and thought out frameworks that Google provides exactly for this particular reason. Honestly this whole "fragmentation" thing is a red herring. You create your app, you create different sets of resources (images and layouts) for different classes of device (broadly speaking there are three groups of Android phones) and that's about it - you're done. Developing for Android has entailed way less worry about specific devices than, say, Blackberry or feature phones.
I totally agree. Since when did developers need exactly the same specs on every device to develop a good app? It doesn't seem to be an issue for Web / Facebook / PC / Mac / Linux apps.
Main thing is there is stuff you can do with minsdk set to 2.0 that customers using HTC Heros, Sony X10s, and other popular but not updated devices won't be able to access.
Another point the author misses is that most users - and for that matter developers - aren't chasing the latest features in Android. Look at Froyo for instance - it's awesome, but I can guarantee you that right now, probably less than 1% of apps in the market actually use Froyo specific features. And as nailer points out, if you really must use them, then you can make sure no one with a phone earlier than that can even see your app in the market.
Yeah ... I have the same question for ...
* different desktop browsers
* different mobile browsers
* different Windows versions
* different desktop hardware
* different JVM versions / vendors
* different gaming consoles ... you have to be stupid to choose just one
Another guy who evaluates the Android ecosystem as a pseudo-iPhone. It isn't.
http://www.yafla.com/dforbes/If_Android_was_HTML5_then_the_i...
Read it. Absorb. Learn.
http://www.yafla.com/dforbes/If_Android_was_HTML5_then_the_i...
Read it. Absorb. Learn.
[deleted]
Oh look. Another article that skimps on the details more than any of the previous ones crying about fragmentation and how it will destroy Android.
We get it. We're tired of these articles. When the development cycle slows and when the custom layers either die or turn into a simple custom skin alongside Android, this will all be a thing of the past.
We get it. We're tired of these articles. When the development cycle slows and when the custom layers either die or turn into a simple custom skin alongside Android, this will all be a thing of the past.
Androids growth rate = giving away crappy phones