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.
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.
(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.
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.
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...
> 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-wi...
...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.
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 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.
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?
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.
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]
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?
I've been switching back and forth between Android and iPhone development for 4 years now, and I'd say development time is roughly equal between the platforms. A developer that understands Android well should instinctively know how handle different device sizes and fragmentation. The platform is equipped to handle these things well, and the only complaints I ever hear are from iOS developers that simple aren't used to and aren't willing to understand the platform.
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.
I've been building mobile apps for about 2-3 years. The company I consult for builds iOS first... not because of any design/coding difficulty though. Not to beat this very dead horse anymore but iOS users pay more frequently... so we go iOS first to determine if it's even worth it to build for Android.
> I'm a little surprised that they say fragmentation is so bad that they need 2-3x the resources for Android.
It's highly dependent on what you're doing. For instance, if you're using OpenGL ES, you'll likely have a lot of testing overhead. Ditto if you're doing anything interesting with the camera API (OEMs like breaking this). If you avoid OpenGL ES, the camera, any of the new UI stuff, and the network, then testing becomes less scary.
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.
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.
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.
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.
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.
> 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.
"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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
[+] [-] JohnTHaller|12 years ago|reply
[+] [-] mncolinlee|12 years ago|reply
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.
[+] [-] schvenk|12 years ago|reply
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.
[+] [-] ericmsimons|12 years ago|reply
[+] [-] gcb0|12 years ago|reply
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...
[+] [-] threeseed|12 years ago|reply
And generally the iOS APIs are an order of polish above what I've experienced developing for Android.
[+] [-] mdwrigh2|12 years ago|reply
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-wi...
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] jpatokal|12 years ago|reply
...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.
[+] [-] aeberbach|12 years ago|reply
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
[+] [-] sizzle|12 years ago|reply
[+] [-] shinymark|12 years ago|reply
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|12 years ago|reply
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?
[+] [-] hawkharris|12 years ago|reply
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-smartp...
[+] [-] pjmlp|12 years ago|reply
[+] [-] jaegerpicker|12 years ago|reply
[0] http://appleinsider.com/articles/13/11/27/apples-ios-brings-... [1] http://www.statisticbrain.com/mobile-phone-app-store-statist...
[+] [-] unknown|12 years ago|reply
[deleted]
[+] [-] ufmace|12 years ago|reply
[+] [-] andymcsherry|12 years ago|reply
[+] [-] Zigurd|12 years ago|reply
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.
[+] [-] Consultant32452|12 years ago|reply
[+] [-] rsynnott|12 years ago|reply
It's highly dependent on what you're doing. For instance, if you're using OpenGL ES, you'll likely have a lot of testing overhead. Ditto if you're doing anything interesting with the camera API (OEMs like breaking this). If you avoid OpenGL ES, the camera, any of the new UI stuff, and the network, then testing becomes less scary.
[+] [-] bitwize|12 years ago|reply
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.
[+] [-] rimantas|12 years ago|reply
[+] [-] jmnicolas|12 years ago|reply
[+] [-] wirelessest|12 years ago|reply
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.
[+] [-] wzsddtc|12 years ago|reply
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.
[+] [-] XorNot|12 years ago|reply
WhatsApp currently can run on J2ME phones, but won't run older iDevices thanks to the way Apple runs the app-store.
[+] [-] Herald_MJ|12 years ago|reply
[+] [-] rsynnott|12 years ago|reply
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.
[+] [-] glasshead969|12 years ago|reply
[+] [-] tobyjsullivan|12 years ago|reply
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.
[+] [-] muppetman|12 years ago|reply
[+] [-] nickonline|12 years ago|reply
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.
[+] [-] sharpneli|12 years ago|reply
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.
[+] [-] cowbell|12 years ago|reply
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.
[+] [-] aarkay|12 years ago|reply
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.
[+] [-] chewychewymango|12 years ago|reply
The real story here is between the lines.
[+] [-] spbaar|12 years ago|reply
Google went through all the trouble making content providers then doesn't even have one for sms.
[+] [-] josteink|12 years ago|reply
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|12 years ago|reply
None the less, at least you tried...? :-) I'm actually curious about what you do find better on Android then on iOS.
[+] [-] cromwellian|12 years ago|reply
[+] [-] sokrates|12 years ago|reply
[+] [-] archagon|12 years ago|reply
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|12 years ago|reply