9 ms·

The Fallacy of Android-First

138 points by schvenk 13y ago

JohnTHaller 13y ago
This article is comparing a complex SMS/MMS app with custom popup window functionality on Android to a relatively simple standalone IM client on iPhone (no popup windows nor SMS/MMS integration since neither are supported on iOS) and drawing conclusions from the experience. If they built the same standalone IM client with no popup windows on Android, I'd wager their experience would be quite different.
- ericmsimons 13y ago
  I share the same sentiment. I'm also pretty confused why he was surprised regarding the complexity of hijacking the phone's SMS/MMS messages. As a non-android dev, if I were told to do that, I would assume that it would be hell. It's just not a common use case for devs, so therefore Google probably has spent their time polishing up other APIs.
- threeseed 13y ago
  Custom popup windows are fine on iOS. Just need to display your own view. And generally the iOS APIs are an order of polish above what I've experienced developing for Android.
  - mirsadm 13y ago
    iOS doesn't support custom pop up windows outside of your app. Which means for an IM app you need to be running it for a popup to appear (sort of making the whole popup window pretty useless IMO). On Android you can display a custom pop up window even if the user is not in your app.
- gcb0 13y ago
  well, it was from someone who designed the yahoo IM (the client so sucky that not even yahoo employees use) and redesign tech crunch... i dont know why those credentials give him any credibility as a developer. not being troll. really. just see how he had to limit to api 4.0 an app that is basically a list. ...unless it is still dealing with sms on android, which would be silly since now they have the IM backend for the IOS version...
- mncolinlee 13y ago
  I rarely ever see apples-to-apples comparisons in Android-iOS development discussions. It's tempting to say that his TechCrunch credentials bias him, but I actually chalk it up to his wanting to write a dev blog with a link-bait title. I don't think the lesson learned has anything to do with Android first at all.
  - madeofpalk 13y ago
    If you read through the article and ignore all the 'We fucked up by using SMS/MMS' stuff, you'll find the crux of why Android didn't work for him: * APIs are not well-documented, and Google has changed them over time * Carriers modify the OS to support their particular [...] idiosyncrasies. * ...we need to ask the user to go into Settings and send us the details. Since manufacturers and carriers often modify Android’s Settings app, we can’t always tell the user where (or whether) she might find them. * On some Galaxy Nexus phones, when you’re listening to Pandora and get a notification sound from Emu, Pandora’s volume drops. This doesn’t happen with other apps’ notifications, nor does it happen with streaming apps other than Pandora, nor does it happen on any other device. * Several text-layout and view-layout bugs created situations where a seemingly harmless visual change would create significant UI bugs. * Poor, inconsistent and conflicting documentation
    - jobu 13y ago
      The market share bit seems pretty huge too: By building for two years’ worth of Android (as we did originally with 4.0+), you’ll support about 40 percent of the U.S. smartphone install base. Removing 4.0-4.1 support leaves you with one year’s worth of OS compatibility, and that number drops to 12.5 percent. By building for iOS 7 only, you’ll support 32 percent of the U.S. smartphone install base.
      - tonfa 13y ago
        That is if you only care about the us. Just including Europe will give you a different story.
- schvenk 13y ago
  (This is the author of the original post.) My comments about the relative difficulty of building on top of SMS/MMS were somewhat of an aside. That difficulty did take us by surprise, but as you say, wasn't reason enough to leave Android on its own. Once we'd decided to abandon the SMS/MMS approach, we were then building our functionality on top of a more straightforward messaging channel, and had to decide whether to proceed on Android or iOS. At that point we chose iOS for the reasons described.
  - codeka 13y ago
    Apart from the SMS/MMS issue, the rest of the article is about how you shouldn't used inexperienced developers to draw conclusions about a platform. This quote is very telling: "We discarded the iPhone prototype we had been working on for a few weeks, polished our rusty Java skills and had an Android alpha out by February 2013." If you'd said "we abandoned out Android prototype, polished our rusty Objective C skills, and released an alpha on iPhone" I'm certain you'd be saying exactly the same things, just about iOS development instead of Android.
    - archagon 13y ago
      I don't know about that. 2 years ago, when I was first trying my hand at iOS development, I found it remarkably easy to get things working. The documentation, to my eyes, was simply excellent. I still find that to be the case.
      - WWLink 13y ago
        I'm not sure if they've changed this, but I had a hard time finding good documentation for using autolayout constraints in code for a layout that was mostly created in code due to it changing depending on what the situation demanded. But I will agree Google's documentation is usually pretty short sighted and made by people that don't like writing documentation.
        sh1989 13y ago
        I struggled for a long time trying to understand how Relative Layouts work. It just didn't gel with me and I found the documentation lacking. One day it clicked, but I very nearly gave up on the whole platform. That said, the quality of the Android documentation has vastly improved since then. The training guides are excellent and the design section is good (although I much prefer the more practical Android Design in Action Youtube series).
ufmace 13y ago
I don't know how true this is, but I upvoted because I'd be interested in hearing what other people who have worked with both systems think of the issue. I'm a little surprised that they say fragmentation is so bad that they need 2-3x the resources for Android. I wonder if that's only the case because they seemed to be using a lot of more advanced features on their Android app?
- Zigurd 13y ago
  In my consultancy I have dealt with the usual case many times: Android second. IF you build the same app for both platforms, the difference in level of effort can be almost entirely attributed to the relative familiarity of the developers with each platform. That misses the point. You can usually do more in Android, and, while I'm a firm believer in shipping an MVP (or even an interim port based on a Web wrapped), if you don't implement a few key features on Android, like Fragment based UI scaling for different device geometries, the Share operation, and standard Intent-based high-level IPC if applicable, you have a pretty lame Android app. Different expectations regarding some conventionally standard features, plus Java, plus Eclipse, plus grokking the Android component life-cycle, plus design for a continuum of screen geometries, means Android is usually more demanding of development resources.
  - gabemart 13y ago
    > the Share operation I'm extremely new to Android development. Does this have a special contextual meaning? What is the Share operation?
    - Zigurd 13y ago
      Here is a good tutorial: http://developer.android.com/training/sharing/shareaction.html http://developer.android.com/training/sharing/shareaction.ht... It can mean very different things to different apps. In all cases it means "I can do something with that data."
      - gabemart 13y ago
XorNot 13y ago
That Android app will run on hardware that's many years old though, thanks to those extra dev resources. WhatsApp currently can run on J2ME phones, but won't run older iDevices thanks to the way Apple runs the app-store.
- Herald_MJ 13y ago
  WhatsApp do maintain a J2ME version, but it's not the same codebase as their Android app.
- glasshead969 13y ago
  WhatsApp can be installed on older devices, they won't get the latest but last updated version of APP which supports iOS version on the device.
- rsynnott 13y ago
  > That Android app will run on hardware that's many years old though, thanks to those extra dev resources. Huh? They said they started off with 4.0 support, and then dropped it, moving to 4.1 support. Android 4.0 came out in late 2011, and 4.1 came out in mid 2012. By simply supporting iOS 7, on the other hand, they would be able to support everything back to the iPhone 4, which came out in mid 2010, over a year before Android 4.0.
mdwrigh2 13y ago
> Android’s SMS APIs are not well-documented, and Google has changed them over time. There were no SMS APIs prior to 4.4. Yes, the implementation was not protected as system only, but it was an implementation detail not an API guarantee, which is a very different thing. This was even called out in a blog post 4 years ago: http://android-developers.blogspot.com/2010/05/be-careful-with-content-providers.html http://android-developers.blogspot.com/2010/05/be-careful-wi...
- deleted 13y ago
  [deleted]
cromwellian 13y ago
Guaranteed free advertising for a me-too WhatsApp competitor awash in a sea of fellow fast-followers. No doubt, this article will be forwarded around the techo-news-sphere.
tobyjsullivan 13y ago
"Android-First" implies that iOS (or something) will be second. By the author's own admission, they don't have a big enough team to develop for both platforms so they have to choose one or the other. My understanding of Android-first is that you iterate quickly with Android to learn lessons fast while still developing for both platforms. I think it would be foolish, as the article suggests, to only build for Android but that does not mean "Android-first" is a bad option for those building for both platforms.
wzsddtc 13y ago
Aside from the fact that this is not a apples to apples comparison, so much of the problems the OP stated in this article are easily solvable and have pretty standard solutions, e.g. use jackson instead of json.org; cache the rendering google map's view when scrolling; and notification sound with Pandora...sounds more like just dealing with the audio streams.. Edit: the entire SMS/email apps for AOSP are open sourced, yes it does not have all the features that the OP wants, but you can get very far with Android's documentations and just reading the source codes.
shinymark 13y ago
I run a small game development studio and we recently decided to launch Android first. It has proved to be a great decision. There are a number of publishing advantages on Google Play that have helped us iterate and communicate with our players that don't exist on the App Store. For example, build deployment speed, the ability to respond directly and publicly to user reviews, and so on. Obviously our game and their messaging software are very different but I was compelled to comment to offer a counterpoint since the post title is so emphatic.
- arjie 13y ago
  I have a few questions, if you have the time and don't mind. Games are often pointed out as particularly harder on Android because of the multitude of devices with different levels of graphics support. Did you have trouble reaching most of the market? If you did, how did you solve it? I can also imagine some stuff like Samsung's Multi Window tool causing problems. Did anyone report that?
  - schvenk 13y ago
    Yeah, one of my fragmentation examples in the post is the direct result of Samsung's Multi Window.
hawkharris 13y ago
I'm a fan of both iOS and Android — so I'm not in any way saying this out of disdain for Apple — but it seems that the mobile app space is clearly moving toward Android. Comparing the exponential growth rate of Android to that of the iPhone, it's hard to imagine that developers will consider "iOS first" strategies in 3-5 years. [0] The author briefly addressed this point, saying something along the lines of "more installs doesn't translate into more customers," but this argument wasn't really fleshed out. Working for a company that makes mobile apps for a broad range of Fortune 500 firms, I've noticed, anecdotally, a seismic shift in clients' attitudes toward Android. From financial services to biotech to retail, many clients have gravitated toward an "Android first" strategy and boosted customer engagement by doing so. [0] http://venturebeat.com/2013/02/06/800-million-android-smartphones-300-million-iphones-in-active-use-by-december-2013-study-says/ http://venturebeat.com/2013/02/06/800-million-android-smartp...
- pjmlp 13y ago
  In Europe it was already Android first. Only the upper layer of the society in many countries can afford to have iOS devices.
  - Yetanfou 13y ago
    It is not just the fact that the whole iOS experience is more expensive - both hardware and software are more expensive on average - but also the fact that the extreme control exerted by Apple over 'its' products ticks off many. For some reason the myth keeps on being propagated that many users of Android would gladly move to iOS 'if only they could afford it'. While there might be some who would do so, in my experience the majority would not as they prefer the relative freedom of choice which Android provides over the controlled experience which is iOS.
- deleted 13y ago
  [deleted]
- jaegerpicker 13y ago
  Raw growth is a horrible metric. iOS is by far beating Android in revenue and overall usage amount. It's continuing to grow even more. [0] Android devices are shipping more raw phones but that's really not your target market. Apple again is well in the lead for users that pay for the app/buy in app purchases/subscribe to services. [1] [0] http://appleinsider.com/articles/13/11/27/apples-ios-brings-developers-5x-more-revenue-per-download-than-android http://appleinsider.com/articles/13/11/27/apples-ios-brings-... [1] http://www.statisticbrain.com/mobile-phone-app-store-statistics/ http://www.statisticbrain.com/mobile-phone-app-store-statist...
jpatokal 13y ago
Our decision to build on top of SMS/MMS... ...was a really bad idea. SMS dates from 1984 and was originally a hack -- a beautiful hack, yes, but still a hack -- to squeeze basic text into empty 128-byte slots in telco switching protocol SS7. Combining multiple SMSes together requires nasty User Data Header hackery, and transmitting binary data over this joke of a channel is even worse. And don't get me started on MMS, a horribly overcomplicated spec that neither handsets nor operators could ever implement correctly, much less interoperably. I used to work on this stuff for a living, and ran away screaming as soon as I could. The mobile messaging world would be a good ten years ahead of where we are today if we'd copied Japan in the mid-1990s and ditched SMS/MMS entirely for email built on packet-switched data, which would have instantly created the decent infrastructure needed for future apps. (The packet-switched bit, that is, not SMTP itself.) But as always, Japan shot itself in both feet by refusing to adopt the same standards as the rest of the world, meaning that e-mail and decent Internet on phones didn't become a mass-market thing elsewhere until the iPhone came out in 2007.
- sizzle 13y ago
  This is fascinating, got a blog we can read?
  - jpatokal 13y ago
    Thanks! I blog at http://gyrovague.com/ http://gyrovague.com/, although my telco days are long behind me so that's the one topic I haven't covered. Might be time for a retrospective...
    - sizzle 13y ago
      I would certainly read that reflective post, if you ever do write it you should definitely submit it. The discussion would be great I'd imagine.
- aeberbach 13y ago
  If you look just at the handsets available in 2000 or so it would have been very easy for Japanese telcos to look at what the world had to offer and conclude it was not much. Compare turn of the century Japanese devices* next to four-color phones like the Siemens S25 and Motorola's monochrome handsets. If you want to blame anyone for not pushing adoption of GSM GPRS and beyond it shouldn't be Japan. There's one country that could have made it the obvious choice for everyone, but thanks to "competition" it never happened... *i.e. J-Phone Sharp J-SH04 http://en.wikipedia.org/wiki/J-SH04 http://en.wikipedia.org/wiki/J-SH04
bitwize 13y ago
I write mobile apps in my spare time. My policy is simple: Android first and Android only until I don't need a Mac to develop for iOS gear. Of course given that Steve Jobs 2011 internal Apple talk, wherein locking customers into the Apple ecosystem was presented as an important corporate goal, that'll happen like never. Don't get me wrong, I want to like iOS and its UX is quite a bit better than Android's still. But I'm not in a position to drop a thou on a Mac just to develop for it.
- wirelessest 13y ago
  If your issue is just the expense of a Mac and not the principle, find yourself a used Mac mini. I agree that the requirement is a pain though. Our CI, automated builds, etc are all standard across all products except the iPhone client which runs as a cron job on an old Mac in the corner.
  - 72deluxe 13y ago
    I second buying a second hand Mac mini. Even the late Core 2 Duo ones were very respectable performance wise.
- rimantas 13y ago
  Well, you know, there can be more reasons why Mac costs "a thou" besides the ability to develop for iOS and OS X. It did not surprise me to see Android developers using Macbooks Pro, but when I saw Windows Phone developer using it—I admit that was unexpected. But understandable.
- jmnicolas 13y ago
  It would be silly of Apple to drop the MAC requirement for iOS dev : lots of effort to port their tools on other OS with the risk of incompatibilities and they would loose sales too.
  - 72deluxe 13y ago
    And there's no incentive to use Objective-C on any other platform, so with Apple pushing Obj-C on their platforms it makes sense to get a Mac for iOS development, particularly if you spill over to desktop development (which you can do in C++ of course).
muppetman 13y ago
I think the real fallacy here is thinking there's room for another messaging app/service. That's where the real fragmentation problem is.
- nickonline 13y ago
  Downloaded "Hello SMS" this morning on Android. I think it's SMS only, but damn is its interface better and more intuitive than any SMS or messaging app I've used to date. I would think that there's always room for a reimagined intuitive interface in any space.
deleted 13y ago
[deleted]
archagon 13y ago
Yikes, the Facebook comments on that article are toxic. People sure do get uppity when someone says something negative about their Favorite Thing. Just want to say thanks to the author for writing the article. As an iOS dev eyeing other mobile platforms, it's nice to get an insider's view on Android development, whether good or bad.
- varkson 13y ago
  Many Android fans have a persecution complex. See Reddit's Android subreddit for more. I can't stand the place, even when I used Android phones.
aarkay 13y ago
In terms of development time, iOs and Android both take the same amount of time if the developers are familiar with the platform, as mentioned by andymcsherry. We often develop features for both iOs and Android alongside and usually release on the same day. As far as SMS/MMS integration goes it can’t be compared, but I do agree with the article that its non trivial to integrate with. I have had experience dealing with SMS on android and there is no documentation at all. The only way to get things working is by looking at the source code of the Android sms app or finding snippets on the internet. I have developed for both platforms and have written a detailed description comparing UI design, Tools, Documentation etc. for both platforms here: http://qr.ae/v4rT2 http://qr.ae/v4rT2.
sharpneli 13y ago
I can relate to this so well. Especially the part where on older versions apps could block eachother but on new one they couldn't read the settings. I have my own small story to tell. I did some code that used OpenGL ES 3.0. I was able to develop it before it was officially supported in Android devices by using desktop gpu's. The day when first 4.3 devices supporting ES3 came. Got few testing devices. Wait. GDB doesn't work? Whoops. 4.3 had an issue where you had to root the device in order to actually debug your native code in the device. Sure it was fine on the few test devices but you cannot really root all of the myriad devices your users might have just to debug. We had an unresolved crash bug on a device we didn't dare to root. And then there was the lovely day when 4.4 came out. Ok the debugging started to work but it also broke most of the graphics debuggers because the gl libs switched from /system/lib/ into /vendor/lib or whatnot. These kinds of issues is why I prefer desktop development by far.
spbaar 13y ago
I built a markov chain fun app on android for SMS but gave up when I realized it's basically impossible to support all or most devices, like he said. Each manufacturer has different sms columns in the undocumented database. Some sms apps delete and move it so you can't see. You can't see people's hangouts or whatsapp etc conversations. Google went through all the trouble making content providers then doesn't even have one for sms.
- josteink 13y ago
  That's changed since 4.4 though (or was it 4.3)? Anyway, if you find yourself meddling around in undocumented databases, you should probably reconsider what you're doing. In the iStore that alone is reason enough for getting you apps rejected. At least here you had the option to do it anyway, if you really, really wanted to.
NicoJuicy 13y ago
I'm not sure, but the biggest problem was building on top of SMS/MMS? Isn't it partially the fault of insufficient investigating the concequences of the architecture decision? That's the impression after reading your article. None the less, at least you tried...? :-) I'm actually curious about what you do find better on Android then on iOS.
sokrates 13y ago
SMS/MMS are shit and a relic of the past. I don't think it's a good idea to try and build a product based on them, ever. Use the Internet.
cowbell 13y ago
This is silly. Their reasons boil down to: 1)Android is hard 2)Android is hard 3)Android is hard 4)Because android was too hard for us, nobody downloaded our app. Let me add a rebuttal: There are many hungry Android developers out there. Developers who do not whine about how Android is hard. Developers who have actually invested the time and effort to be good at Android development. If you write iOS first, and your app is a big hit, these hungry developers will clone your app within days and soak up 75% of the market that you ignored. Since iOS is so easy, many of them will port to iOS just as quickly. Their Android success will have a network effect. The 75% that loves the clone on Android will tell their iOS friends who will then choose the clone over your app. That results in you writing an article on hacker news about how some guy just cloned your Threes/2048 app and is now doing better than you. I have no sympathy for developers who are unable to compete because Android doesn't make development as nice/easy as iOS.
chewychewymango 13y ago
Judging by the linkedin profiles of Emu's employees, the lead engineer only had iPhone experience. In fact, it's unclear whether anyone had Android experience. The real story here is between the lines.

138 points by schvenk 13y ago

This article is comparing a complex SMS/MMS app with custom popup window functionality on Android to a relatively simple standalone IM client on iPhone (no popup windows nor SMS/MMS integration since neither are supported on iOS) and drawing conclusions from the experience. If they built the same standalone IM client with no popup windows on Android, I'd wager their experience would be quite different.

ericmsimons 13y ago
I share the same sentiment. I'm also pretty confused why he was surprised regarding the complexity of hijacking the phone's SMS/MMS messages. As a non-android dev, if I were told to do that, I would assume that it would be hell. It's just not a common use case for devs, so therefore Google probably has spent their time polishing up other APIs.
threeseed 13y ago
Custom popup windows are fine on iOS. Just need to display your own view. And generally the iOS APIs are an order of polish above what I've experienced developing for Android.
- mirsadm 13y ago
  iOS doesn't support custom pop up windows outside of your app. Which means for an IM app you need to be running it for a popup to appear (sort of making the whole popup window pretty useless IMO). On Android you can display a custom pop up window even if the user is not in your app.
gcb0 13y ago
well, it was from someone who designed the yahoo IM (the client so sucky that not even yahoo employees use) and redesign tech crunch... i dont know why those credentials give him any credibility as a developer. not being troll. really. just see how he had to limit to api 4.0 an app that is basically a list. ...unless it is still dealing with sms on android, which would be silly since now they have the IM backend for the IOS version...
mncolinlee 13y ago
I rarely ever see apples-to-apples comparisons in Android-iOS development discussions. It's tempting to say that his TechCrunch credentials bias him, but I actually chalk it up to his wanting to write a dev blog with a link-bait title. I don't think the lesson learned has anything to do with Android first at all.
- madeofpalk 13y ago
  If you read through the article and ignore all the 'We fucked up by using SMS/MMS' stuff, you'll find the crux of why Android didn't work for him: * APIs are not well-documented, and Google has changed them over time * Carriers modify the OS to support their particular [...] idiosyncrasies. * ...we need to ask the user to go into Settings and send us the details. Since manufacturers and carriers often modify Android’s Settings app, we can’t always tell the user where (or whether) she might find them. * On some Galaxy Nexus phones, when you’re listening to Pandora and get a notification sound from Emu, Pandora’s volume drops. This doesn’t happen with other apps’ notifications, nor does it happen with streaming apps other than Pandora, nor does it happen on any other device. * Several text-layout and view-layout bugs created situations where a seemingly harmless visual change would create significant UI bugs. * Poor, inconsistent and conflicting documentation
  - jobu 13y ago
    The market share bit seems pretty huge too: By building for two years’ worth of Android (as we did originally with 4.0+), you’ll support about 40 percent of the U.S. smartphone install base. Removing 4.0-4.1 support leaves you with one year’s worth of OS compatibility, and that number drops to 12.5 percent. By building for iOS 7 only, you’ll support 32 percent of the U.S. smartphone install base.
    - tonfa 13y ago
      That is if you only care about the us. Just including Europe will give you a different story.
schvenk 13y ago
(This is the author of the original post.) My comments about the relative difficulty of building on top of SMS/MMS were somewhat of an aside. That difficulty did take us by surprise, but as you say, wasn't reason enough to leave Android on its own. Once we'd decided to abandon the SMS/MMS approach, we were then building our functionality on top of a more straightforward messaging channel, and had to decide whether to proceed on Android or iOS. At that point we chose iOS for the reasons described.
- codeka 13y ago
  Apart from the SMS/MMS issue, the rest of the article is about how you shouldn't used inexperienced developers to draw conclusions about a platform. This quote is very telling: "We discarded the iPhone prototype we had been working on for a few weeks, polished our rusty Java skills and had an Android alpha out by February 2013." If you'd said "we abandoned out Android prototype, polished our rusty Objective C skills, and released an alpha on iPhone" I'm certain you'd be saying exactly the same things, just about iOS development instead of Android.
  - archagon 13y ago
    I don't know about that. 2 years ago, when I was first trying my hand at iOS development, I found it remarkably easy to get things working. The documentation, to my eyes, was simply excellent. I still find that to be the case.
    - WWLink 13y ago
      I'm not sure if they've changed this, but I had a hard time finding good documentation for using autolayout constraints in code for a layout that was mostly created in code due to it changing depending on what the situation demanded. But I will agree Google's documentation is usually pretty short sighted and made by people that don't like writing documentation.
      - sh1989 13y ago
        I struggled for a long time trying to understand how Relative Layouts work. It just didn't gel with me and I found the documentation lacking. One day it clicked, but I very nearly gave up on the whole platform. That said, the quality of the Android documentation has vastly improved since then. The training guides are excellent and the design section is good (although I much prefer the more practical Android Design in Action Youtube series).

ufmace 13y ago

I don't know how true this is, but I upvoted because I'd be interested in hearing what other people who have worked with both systems think of the issue. I'm a little surprised that they say fragmentation is so bad that they need 2-3x the resources for Android. I wonder if that's only the case because they seemed to be using a lot of more advanced features on their Android app?

Zigurd 13y ago
In my consultancy I have dealt with the usual case many times: Android second. IF you build the same app for both platforms, the difference in level of effort can be almost entirely attributed to the relative familiarity of the developers with each platform. That misses the point. You can usually do more in Android, and, while I'm a firm believer in shipping an MVP (or even an interim port based on a Web wrapped), if you don't implement a few key features on Android, like Fragment based UI scaling for different device geometries, the Share operation, and standard Intent-based high-level IPC if applicable, you have a pretty lame Android app. Different expectations regarding some conventionally standard features, plus Java, plus Eclipse, plus grokking the Android component life-cycle, plus design for a continuum of screen geometries, means Android is usually more demanding of development resources.
- gabemart 13y ago
  > the Share operation I'm extremely new to Android development. Does this have a special contextual meaning? What is the Share operation?
  - Zigurd 13y ago
    Here is a good tutorial: http://developer.android.com/training/sharing/shareaction.html http://developer.android.com/training/sharing/shareaction.ht... It can mean very different things to different apps. In all cases it means "I can do something with that data."
    - gabemart 13y ago

XorNot 13y ago

That Android app will run on hardware that's many years old though, thanks to those extra dev resources. WhatsApp currently can run on J2ME phones, but won't run older iDevices thanks to the way Apple runs the app-store.

Herald_MJ 13y ago
WhatsApp do maintain a J2ME version, but it's not the same codebase as their Android app.
glasshead969 13y ago
WhatsApp can be installed on older devices, they won't get the latest but last updated version of APP which supports iOS version on the device.
rsynnott 13y ago
> That Android app will run on hardware that's many years old though, thanks to those extra dev resources. Huh? They said they started off with 4.0 support, and then dropped it, moving to 4.1 support. Android 4.0 came out in late 2011, and 4.1 came out in mid 2012. By simply supporting iOS 7, on the other hand, they would be able to support everything back to the iPhone 4, which came out in mid 2010, over a year before Android 4.0.

mdwrigh2 13y ago

> Android’s SMS APIs are not well-documented, and Google has changed them over time. There were no SMS APIs prior to 4.4. Yes, the implementation was not protected as system only, but it was an implementation detail not an API guarantee, which is a very different thing. This was even called out in a blog post 4 years ago: http://android-developers.blogspot.com/2010/05/be-careful-with-content-providers.html http://android-developers.blogspot.com/2010/05/be-careful-wi...

deleted 13y ago
[deleted]

cromwellian 13y ago

Guaranteed free advertising for a me-too WhatsApp competitor awash in a sea of fellow fast-followers. No doubt, this article will be forwarded around the techo-news-sphere.

tobyjsullivan 13y ago

"Android-First" implies that iOS (or something) will be second. By the author's own admission, they don't have a big enough team to develop for both platforms so they have to choose one or the other. My understanding of Android-first is that you iterate quickly with Android to learn lessons fast while still developing for both platforms. I think it would be foolish, as the article suggests, to only build for Android but that does not mean "Android-first" is a bad option for those building for both platforms.

wzsddtc 13y ago

Aside from the fact that this is not a apples to apples comparison, so much of the problems the OP stated in this article are easily solvable and have pretty standard solutions, e.g. use jackson instead of json.org; cache the rendering google map's view when scrolling; and notification sound with Pandora...sounds more like just dealing with the audio streams.. Edit: the entire SMS/email apps for AOSP are open sourced, yes it does not have all the features that the OP wants, but you can get very far with Android's documentations and just reading the source codes.

shinymark 13y ago

I run a small game development studio and we recently decided to launch Android first. It has proved to be a great decision. There are a number of publishing advantages on Google Play that have helped us iterate and communicate with our players that don't exist on the App Store. For example, build deployment speed, the ability to respond directly and publicly to user reviews, and so on. Obviously our game and their messaging software are very different but I was compelled to comment to offer a counterpoint since the post title is so emphatic.

arjie 13y ago
I have a few questions, if you have the time and don't mind. Games are often pointed out as particularly harder on Android because of the multitude of devices with different levels of graphics support. Did you have trouble reaching most of the market? If you did, how did you solve it? I can also imagine some stuff like Samsung's Multi Window tool causing problems. Did anyone report that?
- schvenk 13y ago
  Yeah, one of my fragmentation examples in the post is the direct result of Samsung's Multi Window.

hawkharris 13y ago

I'm a fan of both iOS and Android — so I'm not in any way saying this out of disdain for Apple — but it seems that the mobile app space is clearly moving toward Android. Comparing the exponential growth rate of Android to that of the iPhone, it's hard to imagine that developers will consider "iOS first" strategies in 3-5 years. [0] The author briefly addressed this point, saying something along the lines of "more installs doesn't translate into more customers," but this argument wasn't really fleshed out. Working for a company that makes mobile apps for a broad range of Fortune 500 firms, I've noticed, anecdotally, a seismic shift in clients' attitudes toward Android. From financial services to biotech to retail, many clients have gravitated toward an "Android first" strategy and boosted customer engagement by doing so. [0] http://venturebeat.com/2013/02/06/800-million-android-smartphones-300-million-iphones-in-active-use-by-december-2013-study-says/ http://venturebeat.com/2013/02/06/800-million-android-smartp...

pjmlp 13y ago
In Europe it was already Android first. Only the upper layer of the society in many countries can afford to have iOS devices.
- Yetanfou 13y ago
  It is not just the fact that the whole iOS experience is more expensive - both hardware and software are more expensive on average - but also the fact that the extreme control exerted by Apple over 'its' products ticks off many. For some reason the myth keeps on being propagated that many users of Android would gladly move to iOS 'if only they could afford it'. While there might be some who would do so, in my experience the majority would not as they prefer the relative freedom of choice which Android provides over the controlled experience which is iOS.
deleted 13y ago
[deleted]
jaegerpicker 13y ago
Raw growth is a horrible metric. iOS is by far beating Android in revenue and overall usage amount. It's continuing to grow even more. [0] Android devices are shipping more raw phones but that's really not your target market. Apple again is well in the lead for users that pay for the app/buy in app purchases/subscribe to services. [1] [0] http://appleinsider.com/articles/13/11/27/apples-ios-brings-developers-5x-more-revenue-per-download-than-android http://appleinsider.com/articles/13/11/27/apples-ios-brings-... [1] http://www.statisticbrain.com/mobile-phone-app-store-statistics/ http://www.statisticbrain.com/mobile-phone-app-store-statist...

jpatokal 13y ago

Our decision to build on top of SMS/MMS... ...was a really bad idea. SMS dates from 1984 and was originally a hack -- a beautiful hack, yes, but still a hack -- to squeeze basic text into empty 128-byte slots in telco switching protocol SS7. Combining multiple SMSes together requires nasty User Data Header hackery, and transmitting binary data over this joke of a channel is even worse. And don't get me started on MMS, a horribly overcomplicated spec that neither handsets nor operators could ever implement correctly, much less interoperably. I used to work on this stuff for a living, and ran away screaming as soon as I could. The mobile messaging world would be a good ten years ahead of where we are today if we'd copied Japan in the mid-1990s and ditched SMS/MMS entirely for email built on packet-switched data, which would have instantly created the decent infrastructure needed for future apps. (The packet-switched bit, that is, not SMTP itself.) But as always, Japan shot itself in both feet by refusing to adopt the same standards as the rest of the world, meaning that e-mail and decent Internet on phones didn't become a mass-market thing elsewhere until the iPhone came out in 2007.

sizzle 13y ago
This is fascinating, got a blog we can read?
- jpatokal 13y ago
  Thanks! I blog at http://gyrovague.com/ http://gyrovague.com/, although my telco days are long behind me so that's the one topic I haven't covered. Might be time for a retrospective...
  - sizzle 13y ago
    I would certainly read that reflective post, if you ever do write it you should definitely submit it. The discussion would be great I'd imagine.
aeberbach 13y ago
If you look just at the handsets available in 2000 or so it would have been very easy for Japanese telcos to look at what the world had to offer and conclude it was not much. Compare turn of the century Japanese devices* next to four-color phones like the Siemens S25 and Motorola's monochrome handsets. If you want to blame anyone for not pushing adoption of GSM GPRS and beyond it shouldn't be Japan. There's one country that could have made it the obvious choice for everyone, but thanks to "competition" it never happened... *i.e. J-Phone Sharp J-SH04 http://en.wikipedia.org/wiki/J-SH04 http://en.wikipedia.org/wiki/J-SH04

bitwize 13y ago

I write mobile apps in my spare time. My policy is simple: Android first and Android only until I don't need a Mac to develop for iOS gear. Of course given that Steve Jobs 2011 internal Apple talk, wherein locking customers into the Apple ecosystem was presented as an important corporate goal, that'll happen like never. Don't get me wrong, I want to like iOS and its UX is quite a bit better than Android's still. But I'm not in a position to drop a thou on a Mac just to develop for it.

wirelessest 13y ago
If your issue is just the expense of a Mac and not the principle, find yourself a used Mac mini. I agree that the requirement is a pain though. Our CI, automated builds, etc are all standard across all products except the iPhone client which runs as a cron job on an old Mac in the corner.
- 72deluxe 13y ago
  I second buying a second hand Mac mini. Even the late Core 2 Duo ones were very respectable performance wise.
rimantas 13y ago
Well, you know, there can be more reasons why Mac costs "a thou" besides the ability to develop for iOS and OS X. It did not surprise me to see Android developers using Macbooks Pro, but when I saw Windows Phone developer using it—I admit that was unexpected. But understandable.
jmnicolas 13y ago
It would be silly of Apple to drop the MAC requirement for iOS dev : lots of effort to port their tools on other OS with the risk of incompatibilities and they would loose sales too.
- 72deluxe 13y ago
  And there's no incentive to use Objective-C on any other platform, so with Apple pushing Obj-C on their platforms it makes sense to get a Mac for iOS development, particularly if you spill over to desktop development (which you can do in C++ of course).

muppetman 13y ago

I think the real fallacy here is thinking there's room for another messaging app/service. That's where the real fragmentation problem is.

nickonline 13y ago
Downloaded "Hello SMS" this morning on Android. I think it's SMS only, but damn is its interface better and more intuitive than any SMS or messaging app I've used to date. I would think that there's always room for a reimagined intuitive interface in any space.

deleted 13y ago

[deleted]

archagon 13y ago

Yikes, the Facebook comments on that article are toxic. People sure do get uppity when someone says something negative about their Favorite Thing. Just want to say thanks to the author for writing the article. As an iOS dev eyeing other mobile platforms, it's nice to get an insider's view on Android development, whether good or bad.

varkson 13y ago
Many Android fans have a persecution complex. See Reddit's Android subreddit for more. I can't stand the place, even when I used Android phones.

aarkay 13y ago

In terms of development time, iOs and Android both take the same amount of time if the developers are familiar with the platform, as mentioned by andymcsherry. We often develop features for both iOs and Android alongside and usually release on the same day. As far as SMS/MMS integration goes it can’t be compared, but I do agree with the article that its non trivial to integrate with. I have had experience dealing with SMS on android and there is no documentation at all. The only way to get things working is by looking at the source code of the Android sms app or finding snippets on the internet. I have developed for both platforms and have written a detailed description comparing UI design, Tools, Documentation etc. for both platforms here: http://qr.ae/v4rT2 http://qr.ae/v4rT2.

sharpneli 13y ago

I can relate to this so well. Especially the part where on older versions apps could block eachother but on new one they couldn't read the settings. I have my own small story to tell. I did some code that used OpenGL ES 3.0. I was able to develop it before it was officially supported in Android devices by using desktop gpu's. The day when first 4.3 devices supporting ES3 came. Got few testing devices. Wait. GDB doesn't work? Whoops. 4.3 had an issue where you had to root the device in order to actually debug your native code in the device. Sure it was fine on the few test devices but you cannot really root all of the myriad devices your users might have just to debug. We had an unresolved crash bug on a device we didn't dare to root. And then there was the lovely day when 4.4 came out. Ok the debugging started to work but it also broke most of the graphics debuggers because the gl libs switched from /system/lib/ into /vendor/lib or whatnot. These kinds of issues is why I prefer desktop development by far.

spbaar 13y ago

I built a markov chain fun app on android for SMS but gave up when I realized it's basically impossible to support all or most devices, like he said. Each manufacturer has different sms columns in the undocumented database. Some sms apps delete and move it so you can't see. You can't see people's hangouts or whatsapp etc conversations. Google went through all the trouble making content providers then doesn't even have one for sms.

josteink 13y ago
That's changed since 4.4 though (or was it 4.3)? Anyway, if you find yourself meddling around in undocumented databases, you should probably reconsider what you're doing. In the iStore that alone is reason enough for getting you apps rejected. At least here you had the option to do it anyway, if you really, really wanted to.

NicoJuicy 13y ago

I'm not sure, but the biggest problem was building on top of SMS/MMS? Isn't it partially the fault of insufficient investigating the concequences of the architecture decision? That's the impression after reading your article. None the less, at least you tried...? :-) I'm actually curious about what you do find better on Android then on iOS.

sokrates 13y ago

SMS/MMS are shit and a relic of the past. I don't think it's a good idea to try and build a product based on them, ever. Use the Internet.

cowbell 13y ago

This is silly. Their reasons boil down to: 1)Android is hard 2)Android is hard 3)Android is hard 4)Because android was too hard for us, nobody downloaded our app. Let me add a rebuttal: There are many hungry Android developers out there. Developers who do not whine about how Android is hard. Developers who have actually invested the time and effort to be good at Android development. If you write iOS first, and your app is a big hit, these hungry developers will clone your app within days and soak up 75% of the market that you ignored. Since iOS is so easy, many of them will port to iOS just as quickly. Their Android success will have a network effect. The 75% that loves the clone on Android will tell their iOS friends who will then choose the clone over your app. That results in you writing an article on hacker news about how some guy just cloned your Threes/2048 app and is now doing better than you. I have no sympathy for developers who are unable to compete because Android doesn't make development as nice/easy as iOS.

chewychewymango 13y ago

Judging by the linkedin profiles of Emu's employees, the lead engineer only had iPhone experience. In fact, it's unclear whether anyone had Android experience. The real story here is between the lines.