Hacker News Reader

Comment by JohnTHaller | Hacker News Reader

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.

View on HN

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

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.

That is if you only care about the us. Just including Europe will give you a different story.

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

The next time somebody on this site says 'x is true because everybody I know is/uses/does y', I'm going to blow a gasket.

(Not that anyone cares probably)

For me it is exactly the other way around, apart from the cheap bit.

One of my favourite sayings: The plural of anecdote is not evidence.

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.

Quite, and those undocumented APIs are used to do something that they wouldn't be allowed to do at all on iPhone.

* "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.

See: http://android-developers.blogspot.co.at/2013/10/getting-you...

Interesting. So the SMS API was a private API all along? On iOS you get rejected for using private APIs for that very reason.

iOS 4 has an API for sending text messages, doing the same prior to Android 4.4 required using hidden API's. That's the real issue.

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.

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.

that is no longer and issue as the SMS/MMS api was just made public several months ago

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?

Initially our target audience was US-centric, and cost isn't nearly as much of an issue for SMS/MMS in the US as it is elsewhere.

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...

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.

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.

Reply on news.ycombinator.com