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.
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
* "APIs are not well-documented, and Google has changed them over time"
* "Carriers modify the OS to support their particular [...] idiosyncrasies."
* "Poor, inconsistent and conflicting documentation"
Not true. Google usually documents APIs well, and older versions of Android are forwards compatible to newer versions.
The SMS Api that the author used was a so-called "hidden API". These APIs are not documented on purpose, as they are not supposed to be used by developers. These are experimental APIs that can and mostly will change over time.
Hidden APIs are not part of the Android specification and they are not part of the Android compability test suite. Of course they do not work reliable on different versions of the operating system.
iOS does not have an API for sending text messages. iOS has an API that presents the user with an Apple-controlled screen, from which she can then send a text message...but there's no way to send a message without presenting that extra UI step.
And on android 4.4 you can have 1 and only 1 app can send text messages. There both compromises around the idea that sending SMS messages costs people money. If it's really important to you you can always set up your own SMS server and use that, however for security reasons Apps don't get full control of the SMS system though an API.
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.
Yes but consider that about 95% of the People I knie have Smartphones. Those that really want a smartphone mostly have iPhones. On android it is 80% the phone that was cheap for their desired contract. Most will never use more than web & email
I keep hearing about fragmentation but I'm not having that much problems with my app (more than 1 million users). Especially on 4.0+ because manufacturers have to ship Holo, so you can control the look of your app.
What kind of problems devs are seeing with the various 4.0 devices?
Part of the problem with the APIs being badly documented and them changing is that the entire SMS and MMS stack was an undocumented (deliberately) API until 4.4. Trying to build an app around an undocumented API will always lead to running into bugs and changes in the API.
blekko's "izik" tablet search engine app is basically identical on Android and iOS -- almost all javascript -- and the engineer who wrote it says that 60% of the js is workarounds for Android differences.
(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.
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.
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.
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.
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).
Likewise, I got pretty good at it and love relative positioning (especially if you use it on a list). However, it is definitely a steep learning curve lol.
Any language gets rusty if you don't use it. It's like riding a bike. If I'd written this post two weeks after we started building for Android, that would be another thing.
I have a more off-topic (from Android/iOS) question, why did you decide to go with SMS/MMS, I understand that in theory it meant not having to build an infrastructure, and re-invent the wheel... but for me, as a customer the huge appeal is that other messaging apps free me from SMS and make use of my much cheaper data-plan. SMS is so limited and expensive compared to the amount of data I can send over 3G/Wifi, in fact, frequently sending messages on my phone is now free, but with one tied to SMS/MMS it would always cost me money to use.
Maybe it's hindsight being 20/20, but it just seems like a really strange direction to go in, so is there something other than the infrastructure and theoretical ease of use that drove your decision?
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...
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.
> 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...
Not following you here -- Japan never had GSM, and even their initial attempts at 3G (FOMA, CDMA2000) didn't play ball with the rest of the world.
At the end of the day, the problem in the Western world was that operators were so in love with their massive SMS revenues with nearly 100% profit margins that they had zero incentive (well, negative incentive, really) to push for anything else. Whereas Japan, precisely thanks to not adopting GSM, never had SMS in the first place, so e-mail charged by the byte became the first killer cross-operator messaging app. (There were SMS equivalents in Japanese networks as well, but most all were restricted to one operator and consequently never really took off.)
Sure - what I mean is had Japan been the only place not to have GSM they may well have been forced to adopt it. GSM was around in the USA at that time (Moto Timeport "Worldphone" etc.) but was nothing like a standard, everywhere I looked I saw CDMA.
Thanks! I blog at 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...
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.
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.
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.
One other challenge related to different device sizes is that designers cannot create a pixel-perfect design in Photoshop and send it off to the developer. They have to be aware of how the interface components will resize and shift around as the aspect ratio, resolution, and screen size changes.
Designing for responsive layouts should be second nature for designers dealing with Android. The same issues appear on web in much more dramatic fashion.
You would assume that web desginers and graphic designers in general have been around much longer than iOS though. This is not a "new" problem which haven't already been solved.
Being too iOS-centric in this space will severely limit your capabilities as a developer and designer.
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.
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).
I wouldn't be surprised if Apple someday has a Windows (or whatever) version of Xcode. That is, in a kind of parallel to the OP's essay, Xcode as we know it isn't necessarily "Mac-only" but simply built for Mac first.
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.
