Hacker News Reader

Comment by cromwellian | Hacker News Reader

Somewhat deceptive, because a lot of stuff in Android is now unbundled and separately updated, whereas with iOS you have to upgrade to a new OS version to get a new version of the app.

iOS needs a whole OS update to update things like Mail, Maps, Safari, Siri, Notes, Reminders, Camera, Photos, etc

On Android, many of the core equivalents are available as Play store updates with the exception of stuff like Chrome and WebView which had deeper OS dependencies.

Is someone stuck on say, Android 4.2 (two releases ago) in a worse situation than someone stuck on iOS 5? The Android user in many cases could still get the latest Google Now cards, Chrome, Gmail, Maps, etc

Yes, it was bad in the Gingerbread era. But if you've got Jellybean or equivalent, in many cases, you don't need to be on KitKat to get the majority of the latest features.

View on HN

It's bad for developers though. You have to stick with older API's when developing Android apps if you want to target the largest audience possible. As we speak already ~75% of iOS users are on iOS 7[0] and I'm quite sure it'll be close to ~90% in the next 2-3 months.

For me as mobile developer, this is one of the reasons why I'll keep developing iOS apps first and target Android second.

Android adoption rates can be seen here[1].

[0]: https://mixpanel.com/trends/#report/ios_7

[1]: https://mixpanel.com/trends/#report/android_frag

"You have to stick with older API's when developing Android apps if you want to target the largest audience possible."

what? surely you just use the new features as and when they become available and always use the oldest API as a 'base level'? this is the same for all platforms... including iOS - if you approach backward compatibility as something you seriously want this is not even a problem. even given the quick uptake on updates in the iOS world, supporting just iOS 7 seems a bit nuts to me.... maybe i get the wrong end of your stick though.

i'm kind of mystified how you are doing things to make this the case... the only significant headache i have ever had with backward compatibility is when apple stop me from being able to do it by force.

> "what? surely you just use the new features as and when they become available and always use the oldest API as a 'base level'? this is the same for all platforms... including iOS - if you approach backward compatibility as something you seriously want this is not even a problem. even given the quick uptake on updates in the iOS world, supporting just iOS 7 seems a bit nuts to me.... maybe i get the wrong end of your stick though."

In iOS often newer versions of the operating system make certain functionality much easier to develop due to the new API's that are added or existing API's that are extended or improved. I personally don't find backwards compatibility hugely important, I just want to provide enough backwards compatibility to serve 85+% of the market. I think in the coming months we'll reach that stage for iOS 7, so for the current app I'm working on will target iOS 7+, that is if I can convince our client this is a good idea.

Sadly, for Android I'm likely required to target versions 3.2+, which means some functionality might not work as well or look as great compared to what's possible in the newest versions of Android, especially if I find myself using the lowest common denominator of API's. I don't like to do extra work just for a small part of the audience, so that is something I'll try to avoid (perhaps some people will hate me for this?).

that makes sense. ditching backwards compatibility does make life a lot easier - as long as you are aware of the compromise (or that it doesn't exist if you are targeting some enterprise environment perhaps) then it does make sense.

In general though I think as an approach it is customer unfriendly and programmer (or other ulterior motive) friendly /only if the programmer is lazy or starting from scratch/. Eventually you do have to decide a cutoff point based on the time you spend vs. the reward - however if you reuse your code properly these become one time costs that are rapidly amortised - and following the practice of backwards compatibility helps in a cross platform environment to ensure that your /architecture/ is actually future proof and platform agnostic.

As a one man band I enjoy supporting all of the platforms and with a large amount of backwards and forwards compatibility. It might be easier as a team of one, but it makes me feel (that bad kind of) pride when I look at 10+ man dev teams failing to do the same...

Why would you target android 3.x? 3.x was a very short-lived, tablet-only release that never had a significant install base.

I understand wanting to support 2.3 for older/low-end phones, but I've never seen any statistics, including those you posted, that suggest 3.x has enough market share to be worth supporting.

I might have been mistaken with 2.3 yeah :)

> Sadly, for Android I'm likely required to target versions 3.2+, which means some functionality might not work as well or look as great compared to what's possible in the newest versions of Android, especially if I find myself using the lowest common denominator of API's. I don't like to do extra work just for a small part of the audience, so that is something I'll try to avoid (perhaps some people will hate me for this?).

This is a bunch of nonsense, support apps back to 2.2 or 2.1 is not difficult and you can easily target higher level APIs even if you use an older OS version as a base API level.

With iOS, 75%-80% of people are already on iOS7, far higher than that if you look at people who install new apps

I think the point he is trying to make is that the technically newest APIs (19/Kitkat) aren't all that different from any of the 3 Jelly Bean APIs in a significant enough way that the SDK can't mitigate the differences in an acceptable way.

http://developer.android.com/about/versions/android-4.4.html

All pretty reasonable for an API upgrade, and I don't think it's going to break legacy.

The stats at your second link are based on apps that use mixpanel. I suspect that Google's statistics [1] are going to be more accurate because they are based on play store purchases and periodic update checks.

[1] http://developer.android.com/about/dashboards/index.html

The support libraries solve most of the API problems though.

This was mostly true for Gingerbread and even Froyo and Eclair too (that's as far as my personal experience goes). YouTube, maps, play store etc. got several major updates on their own schedule and many new Google apps were released for them.

Android and iOS have different development models, if that isn't taken into account then comparisons are meaningless. Google often gives people the chance to opt into beta or dev releases, by this standard nearly every desktop Chrome user is two versions behind the latest release.

BTW, Chrome is available from the store, though webvew isn't (yet).

> Yes, it was bad in the Gingerbread era.

We're still in the Gingerbread era. Yes, it was released three years ago, but almost a quarter of Android users are still stuck on Android 2.3:

http://developer.android.com/about/dashboards/

> We're still in the Gingerbread era.

Indeed, phones with it installed are still widely available for sale.

http://www.amazon.com/HTC-A510e-Unlocked-Android-Bluetooth/d...

5 available phones from a third party Amazon seller is stretching the term "widely available" a bit.

Chrome is updated through the Play Store every ~6 weeks. You're right about WebView, though.

It's also deceptive to say "iOS needs a whole OS update to update things like [...]", it needs an incremental update, which it gets, so how is that an issue at all? That you can't update them individually?

If an iPhone can no longer get a major version upgrade (e.g. a N.x upgrade not an N.0x upgrade), it also can't get any of its apps updated.

Some of my relatives who took my iPad 1s when I bought new Ipads for my kids are stuck on iOS 5.1.1. Those iPads are from September 2010, but stopped receiving any updates for system apps as of May 2012.

So yes, granular, loosely coupled updates are better than "rebuild the whole tightly coupled world and ship a firmware-diff" updates.

In particular, if an app is not tied to specific kernel features on Android, changes are it can have along life, because Android OS level services like Google Play Services can be independently updated as well.

Even when an iOS device can run the latest version, it doesn't mean it runs it smoothly…

My iPad 2 (just over two years old) is a real pain with iOS7, virtually every time I switch apps the app has to restart from scratch

And you can still buy an iPad 2 brand-new, likely for the same price you paid...

Yes, this is true, especially in the past (up to the iPhone 4/ iPad era). Obviously hardware dependent features aren't there (eg siri when new, iOS7 camera, M7, etc) either.

Still, I have zero issues with iOS 7 on my iPad 2 and my parents are happy on their 4S.

That sounds like you have a bigger problem, iOS 7 runs just fine on my iPad 2.

Yes, I believe that's the issue. I recall with the Maps debacle, you had to wait for a minor update of the OS to update the app itself. Obviously the "iOS needs a whole OS update" can be seen in two ways, we know that going from say 7.0.1 to 7.0.2 means that a few things on the source changed and they recompiled, but for the end user, they don't receive a patch of say 15MB with what has changed. So in that respect iOS needs a whole OS update to update things like Maps (not the data obviously, but the source of the app).

The issue there is that for someone living in a country where data is expensive, a 10MB download is better than an ~800MB one every time there's some bugfixes/app updates. Plus from my knowledge, Play Store can deliver a patch of the app, instead of downloading the whole 10MB.

> but for the end user, they don't receive a patch of say 15MB with what has changed.

Yes they do: http://cdn.macrumors.com/article-new/2013/09/ios_7_0_2.jpg (since iOS 5).

Thanks for that, I didn't know.

Right but there were many other good mapping apps at the time Apple introduced their maps app, and since then there has also been the Google-developed Google Maps app — all these are updated individually.

Aside from Maps (for which there were alternatives) the other apps haven't really had any urgent patches bundled into minor OS upgrades that I can recall.

I was cherry-picking Maps, but I remember that not all iOS apps were updated to the iOS7 look and feel when it came out, it was only at point releases that the few that weren't updated received the update. If Apple has a new shiny Safari browser ready, they have to bundle it with the whole OS update instead of pushing an update on the App Store.

One could even say that the advantage of Google being able to system app updates on the Play Store is that Android apps competing with iOS ones (not a great comparison, but Google Now and Siri) have an advantage in that Google keeps on pushing updates regularly as and when they are ready, whereas Apple would update Siri during a major OS update or the incremental ones. [I am aware that back-end services/responses are updated regularly by both, but I'm referring to code which would change an app's behaviour].

> I was cherry-picking Maps, but I remember that not all iOS apps were updated to the iOS7 look and feel when it came out

This is not true for apps that come with the OS. Some Apple apps were updated later, but only those that come from the App Store like any other regular 3rd party app.

The advantage Google has to be able to update core apps from the store instead of through OS updates is specific to Android's nature, because it allows them to work around OS updates not being available to customers (because of carriers, OEMs, whatever). Apple doesn't have that problem because they update the OS themselves. Also, Google likes to update its software more often than Apple does.

Also, every app developer on IOS is a jerk that deliberately add some fake requirement (such as front facing camera) so appstore will refuse to install the app on 3gs or older models. just because they fear they might get one bad review for the app being slow there... well, not that there are a single app that isn't just a useless native version of some site anyway.

actually is a shame that apple don't let you restrict which devices you can run on.

also apple should (but don't) reject apps that ask for a front facing camera and yet don't use it. its in the app store submission requirements...

I'm an App Developer who has never done this. Every app developer I know has never done this. I really don't understand why you are so bitter for absolutely no reason, except maybe you have a 3GS and won't upgrade.

I've been forced to do this by a publisher and did not feel good about it at all. To be fair, though, it was a quick port of a flash game that was completely unplayable on the 3gs and not fun on the 4.

A quick search will bring up tables of which device requirements will disallow which devices, so it's not an unheard of practice. But nobody is excluding potential customers out of spite, it's because the older harware genuinely can't handle the apps.

you are the minority. congratulations.

I have a 3Gs so i can also be exception, like you, and keep upgrading my apps/sites and not having to add "front facing camera" just so i can be a slob and not test for the phone poor people uses.

screw upgrading phone every year. my gaming desktop is not upgraded that often.

3GS is now not allowed because the modern version of Xcode can't compile for it

Maybe you should think through what you are saying. If someone is stuck on iOS 5, which phone would they be using? A phone that's 4 years old (i.e. pre Gingerbread era)? Apple has done a pretty good job of allowing phones/tablets to be updated, with the iPad 1 being a big exception.

What Google is doing is helping but the ideal solution would be to have people be able to upgrade their mobile devices for at least 3 years. As much as I dislike Microsoft, if they provide a better upgrade path, they could become a much bigger player by making upgrades trivial for the 99.9%.

Linux distributions versus FreeBSD.

apt-get upgrade versus make buildworld :)

freebsd-update pkg update

...

I was kidding. Yes, FreeBSD has a very good package manager, but as far as overall philosophies and maybe popular perception, Linux is the million-tiny-independently-updateable-bits-that-may-or-may-not-fit-together and FreeBSD is the huge-giant-blob-we-update-together-and-it-all-works!

Base system, of course.

Also, the iPhone 4 phones don't upgrade to the latest, iOS7 on an iPhone 4 is barely usable, AND WORSE you can't downgrade. I've known people who "bricked" their phones, where it was usable but very slow and painful to even make phone calls. So is it truly a fair comparison?

Now those on Android 3.x are definitely screwed. At least the 4.x phones are getting the new apps, and new APIs.

From the developer's perspective, this is just a shit. Now you have to deal with something like DLL hell in API versions instead of a few of fixed major versions.

Reply on news.ycombinator.com