The Negative Impact Of iOS On Android

[Sazar]

http://blog.iangclifton.com/2013/03/...os-on-android/

I’m a big proponent of competition among corporations because I believe the consumer ultimately benefits. That means that, although I’m a major fan of Android, I want to see iOS really innovate and I want to see another mobile OS gain traction. Early on, iOS did a lot to push mobile devices forward and helped set bars in a lot of areas for other platforms to meet. Unfortunately, iOS has not changed much lately and in some ways hurts Android when used as the “golden standard” due to its limitations. A lot of the harm isn’t realized by consumers, but Android developers encounter it constantly when something has to be done “the iOS way” or an Android feature is not even considered because iOS cannot do the same.

A good read with a number of examples explaining what's going on.

Devs go where the money is, obviously, but consumers are negatively impacted as a result

[wc326]

things cellphone are pushing at this point..
not software to be honest.

it will be camera, cpu, gpu, and display.

some still consider into buying the iphone on the software(games), but many are only considering their phone with best camera, best display etc...

[Sazar]

Originally Posted by wc326

things cellphone are pushing at this point..
not software to be honest.

it will be camera, cpu, gpu, and display.

Those things are pointless without the software, it's a symbiotic relationship. If you hold one thing back, it holds everything back.

This article gives a little more context to the repeated accusations that other devices have inferior quality to iOS apps. That is typically true, but now we see why some of those design decisions are made.

[Chuck]

I can swear I read an article about Chinese government stating the same thing not too long ago.

[shrike126]

Strangely enough, Friday I had a meeting with a software engineer from Apple and we talked about this exact specific thing. On one of the software products/platforms I work on, we were looking for certain specific APIs that iOS just doesn't offer us. The response I got was something along the lines of "a lot of app developers found innovative ways to deliver great products an apps using their ecosystem and functionality, that we just needed to find a workaround for any self imposed or perceived limitation."

I couldn't help but respond that we had, our work around was to just develop for Android. There were other things we tried to discuss but the answer we kept coming back to was that, at Apple, their success is built on foundation of thinking differently.

[Sazar]

Originally Posted by shrike126

Strangely enough, Friday I had a meeting with a software engineer from Apple and we talked about this exact specific thing. On one of the software products/platforms I work on, we were looking for certain specific APIs that iOS just doesn't offer us. The response I got was something along the lines of "a lot of app developers found innovative ways to deliver great products an apps using their ecosystem and functionality, that we just needed to find a workaround for any self imposed or perceived limitation."

I couldn't help but respond that we had, our work around was to just develop for Android. There were other things we tried to discuss but the answer we kept coming back to was that, at Apple, their success is built on foundation of thinking differently.

From a project management perspective, thinking differently is an asset. But it can also be an anchor when it comes to flexibility. Thinking different for the sake of thinking differently eventually leads to a myopic perspective with its own inherent limitations.

Apple derives it's success due to simplicity and, what used to be, a relatively elegant OS.

Now, that same, stale, feature-less OS has become the anchor that is tying down innovation at Apple and, unfortunately, other platforms.

Native Android applications by Google show what can be done with the platform. Likewise, tier 1 apps on WP (and those developed by Microsoft and Nokia) show what can be done on that platform.

Kudo's to Apple for what they have done, but it is time to stop limiting themselves, and everyone else.

[Zero]

I don't see how Apple is doing anything to impact Android development. It's devs idiotically trying to copy iOS apps that's the problem.

Why not just develop apps that make use of Android specific strengths? Multiplatform development doesn't *need* to create a uniform experience across all platforms (in reality, it isn't anyways).

[shrike126]

Originally Posted by Zero

I don't see how Apple is doing anything to impact Android development. It's devs idiotically trying to copy iOS apps that's the problem.

Why not just develop apps that make use of Android specific strengths? Multiplatform development doesn't *need* to create a uniform experience across all platforms (in reality, it isn't anyways).

I don't think that's the point. I think the point is that businesses, when developing apps, look at the lowest common denominator and develop & deploy with that in mind. Businesses see a drop off in return on investment for developing features that meet 50% of the target audience after they run out of ability with iOS and now their efforts won't reach "everyone" anymore.

[Zero]

Then that's business' problem, nothing to do with iOS limitations. Also a problem with where the money lies.

[shrike126]

Originally Posted by Zero

Then that's business' problem, nothing to do with iOS limitations. Also a problem with where the money lies.

Except... it's the limitations in iOS that's starting to hamstring app development. Which is the point of the article.

[Zero]

Originally Posted by shrike126

Except... it's the limitations in iOS that's starting to hamstring app development. Which is the point of the article.

You're repeating yourself so let me repeat myself... Only insofar as trying to make multiplatform apps the same. Like you said, you can choose to make Android-only apps to completely avoid this issue.

[t0adp1p3]

Originally Posted by shrike126

I don't think that's the point. I think the point is that businesses, when developing apps, look at the lowest common denominator and develop & deploy with that in mind. Businesses see a drop off in return on investment for developing features that meet 50% of the target audience after they run out of ability with iOS and now their efforts won't reach "everyone" anymore.

In your own words even if you take ios out of the equation, you'd be left with essentially android only right? Whats the lowest common denominator on android? You don't think fragmentation and a large portion of users using older versions of android is more significant then anything ios is doing? Honest answer, would be appreciated. Keep in mind less than 2% of apple users are still on ios 4.

[shrike126]

Originally Posted by Zero

You're repeating yourself so let me repeat myself... Only insofar as trying to make multiplatform apps the same. Like you said, you can choose to make Android-only apps to completely avoid this issue.

I think we're gonna go in circles on this. I don't think it's a huge problem, but I see the author's point. Apple hasn't done much to extend the platform lately, if anything they've made efforts to remove functionality from it (see UDID as a recent example). When half of your install base cannot easily be identified through OS APIs like you could on Android, then you have to find a hack/work around to support. This means you stop relying on the on-device APIs like you would for Android because you want your identifiers to be consistent. Sure this won't work over WiFi or for non-telephony devices, but if I'm looking at network oriented "stuff" then that's fine.

So for example, for Android I can query the device MDN/MEID/NAI and as a carrier, I can do a lookup to retrieve subscriber records for that unit. But with iOS I cannot query a device and retrieve a subscriber ID that's meaningful and has context. So instead I find a work around. Which means my work around now affects my Android platform because I want the device ID to be consistent.

I'm not saying Apple MUST fix this, in fact I understand the approach they're taking. I expect removing things like this is a step towards keeping Apple in control of device/user identification. They don't want iOS apps to do anything that could potentially reduce Apple's control over what's being implemented.

Originally Posted by t0adp1p3

In your own words even if you take ios out of the equation, you'd be left with essentially android only right? Whats the lowest common denominator on android? You don't think fragmentation and a large portion of users using older versions of android is more significant then anything ios is doing? Honest answer, would be appreciated. Keep in mind less than 2% of apple users are still on ios 4.

You can't really take iOS out of the relevant target platforms for an application but assuming you did. If you've got Android only, you target an API level and go from there. So far I've yet to see a lot of inconsistency in Google Android API implementations. So, for example if I'm targeting API level 10, I'm reliably reaching 90% or so of the Android install base. Likely my use cases didn't really rely on that other 10% anyways.

[Sazar]

Thanks for the explanation Shrike, I was about to start typing out but you are a dev and a consumer, so you see it from both perspectives

[Zero]

Originally Posted by shrike126

Which means my work around now affects my Android platform because I want the device ID to be consistent.

There's your problem right there.

[AdelphiaX]

Originally Posted by shrike126

I think we're gonna go in circles on this. I don't think it's a huge problem, but I see the author's point. Apple hasn't done much to extend the platform lately, if anything they've made efforts to remove functionality from it (see UDID as a recent example). When half of your install base cannot easily be identified through OS APIs like you could on Android, then you have to find a hack/work around to support. This means you stop relying on the on-device APIs like you would for Android because you want your identifiers to be consistent. Sure this won't work over WiFi or for non-telephony devices, but if I'm looking at network oriented "stuff" then that's fine.

So for example, for Android I can query the device MDN/MEID/NAI and as a carrier, I can do a lookup to retrieve subscriber records for that unit. But with iOS I cannot query a device and retrieve a subscriber ID that's meaningful and has context. So instead I find a work around. Which means my work around now affects my Android platform because I want the device ID to be consistent.

I'm not saying Apple MUST fix this, in fact I understand the approach they're taking. I expect removing things like this is a step towards keeping Apple in control of device/user identification. They don't want iOS apps to do anything that could potentially reduce Apple's control over what's being implemented.


You can't really take iOS out of the relevant target platforms for an application but assuming you did. If you've got Android only, you target an API level and go from there. So far I've yet to see a lot of inconsistency in Google Android API implementations. So, for example if I'm targeting API level 10, I'm reliably reaching 90% or so of the Android install base. Likely my use cases didn't really rely on that other 10% anyways.

Heard this reiterated on a podcast last night. I don't do programming for either but they mentioned the iOS platform as being restricted. That it's becoming more labor intensive to support the Apple platform because it's not as streamlined as the Android API's. Dev's are having to spend more time to "bandaid" iOS apps so they appear the same and have less end user support issues.

Originally Posted by Zero

There's your problem right there.

What are you arguing in 'pro' for?

[Omega53]

This is basically the whole consoles vs pc debate

[shrike126]

Originally Posted by AdelphiaX

Heard this reiterated on a podcast last night. I don't do programming for either but they mentioned the iOS platform as being restricted. That it's becoming more labor intensive to support the Apple platform because it's not as streamlined as the Android API's. Dev's are having to spend more time to "bandaid" iOS apps so they appear the same and have less end user support issues.

That's pretty much the case for everything I've come across on the platform. The most galling part though is they don't even recognize that this is a "thing" at all. Talking to their software engineers about it, at least the one I spoke with last week, just earns a "think different" response. The theme on their end is that there isn't a problem, we just need to understand that Apple Knows Best.

Interestingly enough, I don't think their software engineers and their app review / policy enforcement team are on the same page. When we were talking about what's available in our APIs, we mentioned a specific piece of functionality that was available that we made use of in our app. Our app got rejected by the Apple store review team (after 5 weeks of waiting). The rejection was based on a function that existed in other apps and continues to exist in these other apps. When we talked to the engineer about it, he literally said "Well why don't you use this specific function in this way?"

Our response? "Uh... we did. Your app review process rejected our app and told us to take it out."

"Oh, well I can't speak for the app review team's policy enforcement."

API restrictions are only part of the problem, some seemingly sporadic enforcement of specific policies can also be a challenge, especially when you've already burned developer cycles.

Oh well. Sorry I can't give specifics regarding the API and functionality in this example.

[ViN86]

Originally Posted by shrike126

That's pretty much the case for everything I've come across on the platform. The most galling part though is they don't even recognize that this is a "thing" at all. Talking to their software engineers about it, at least the one I spoke with last week, just earns a "think different" response. The theme on their end is that there isn't a problem, we just need to understand that Apple Knows Best.

It's not surprising. It's a machine of arrogance fed by consumers. Devs have to play by their rules because the market is so damn big.

[Razeus]

Originally Posted by Zero

I don't see how Apple is doing anything to impact Android development. It's devs idiotically trying to copy iOS apps that's the problem.

Why not just develop apps that make use of Android specific strengths? Multiplatform development doesn't *need* to create a uniform experience across all platforms (in reality, it isn't anyways).

Exactly. Yes, iOS are superior in the looks department, but that shouldn't hold back devs for developing on Android if they can something that iOS can't do. Google needs to make a big push for this. The idea of apps being the same no matter the platform is good, but the apps should play to the platforms strengths.

I see the same thing in PS3/Xbox 360/PC development. Make everything the same across the platform. Devs should be rewarding people for their platform choices.

Some of his gripes are silly. App icons? Really? That's holding back development. I can't help it if everyone chooses blue for their icon. I prefer the uniform look. Android icons drive me crazy because they are all different sizes visually. OCD. Plus, I've never seen by battery level "jump around" just because I app switched. This article is just another "why Android is better than iOS". Pure propaganda.

Anyways, there are murmurings that iOS 7 is behind schedule due the visual (ie. Jony Ive) changes that are coming.

[Zero]

Originally Posted by AdelphiaX

What are you arguing in 'pro' for?

That it's absurd to blame iOS for businesses making the choice to dumb down apps. omega's trollish comment is kinda right. You can "dumb down" your PC game because the market is bigger for consoles. But PC-specific games still exist and thrive, and others have expanded functionality over their console versions.

In this case, Android and iOS hold almost equal market share so there's even less reason design apps for one platform to conform to the other. And what about BB or WP? If you want to talk about limitations for true multiplatform development, they factor in too.

One platform being weaker than the other is only a problem IFF you try to make the user experience or backend work exactly the same way across all platforms (in reality, almost no one does that). Platform-specific workaround is always an overhead cost and technical challenge when you develop on multiple platforms.

[Zero]

In shrike's example, device unique identifier was kind of a hot topic last year when Apple changed some of the API functionality around that. Beyond just allowing Apple control, it's also a safeguard against malicious requests for information. Few apps are made by carriers so the need for that functionality is outweighed by the potential security/privacy risk it presents, The fact that it's readily available on Android should be of concern to users, especially those that root.

[AdelphiaX]

Gotcha, I see your PoV now.

[HAL10000]

Originally Posted by Sazar

Kudo's to Apple for what they have done, but it is time to stop limiting themselves, and everyone else.

How on earth is this Apple's fault?

There also isn't a big push on the part of the consumer for Apple to change, is there? They're still selling units as fast as they can make them. It's just the technogeek community who have nothing else to talk about and Apple's competition is unable to "unlimit" themselves.

Innovation as defined by the technogeek/FOSS communities have largely come at the expense of actual usability, which Apple has steered clear of. And doors have had a square interface for too long. It's boring. It's not innovating. All doors from now one have to be triangles.

[shrike126]

Originally Posted by Zero

In shrike's example, device unique identifier was kind of a hot topic last year when Apple changed some of the API functionality around that. Beyond just allowing Apple control, it's also a safeguard against malicious requests for information. Few apps are made by carriers so the need for that functionality is outweighed by the potential security/privacy risk it presents, The fact that it's readily available on Android should be of concern to users, especially those that root.

Except... that's not the reason Apple did that. That's the claimed reason, but the reason they did that was because they did not want external user identification contexts beyond the silo'ed approach they would have control over.

For example, let's say you have a free service you're offering. It's a streaming service or something. If you can identify the user's participation in other things through a mechanism such as capturing MAC IDs or something, or in the case of Android the MDN or NAI, you can capture that information and build a reference table that gives you identification context. Then later, let's say the same user is on a non-carrier radio and connecting over WiFi. I can still, on Android, query the MDN or NAI and retrieve user identifying context information, so now their NASCAR app will authenticate and work over WiFi despite not being on the carrier radio. Great. User doesn't have to fill anything out and I'm offering them a service, conveniently, through an authentication mechanism that's unobtrusive. Assuming some level of server or network based validation of authorization (i.e. is their account still paid up) I get to offer all this without creating a new credential service that needs to be managed by the user.

But Apple doesn't want to give anyone identifier context anymore. Why? Because now you have to go through Apple for authorization to subscription based services OR create prompts for user identification info they may or may not know. With this new user identification barrier in the way, I get to either create a second mechanism to capture and handle the identification and authentication of users on iOS specifically, or I create a user authentication mechanism that requires user interaction.

Again, not talking about any specifics but yes this is an example of how iOS is affecting Android too. Which was the point of the article.

[Sazar]

Originally Posted by shrike126

Except... that's not the reason Apple did that. That's the claimed reason, but the reason they did that was because they did not want external user identification contexts beyond the silo'ed approach they would have control over.

For example, let's say you have a free service you're offering. It's a streaming service or something. If you can identify the user's participation in other things through a mechanism such as capturing MAC IDs or something, or in the case of Android the MDN or NAI, you can capture that information and build a reference table that gives you identification context. Then later, let's say the same user is on a non-carrier radio and connecting over WiFi. I can still, on Android, query the MDN or NAI and retrieve user identifying context information, so now their NASCAR app will authenticate and work over WiFi despite not being on the carrier radio. Great. User doesn't have to fill anything out and I'm offering them a service, conveniently, through an authentication mechanism that's unobtrusive. Assuming some level of server or network based validation of authorization (i.e. is their account still paid up) I get to offer all this without creating a new credential service that needs to be managed by the user.

But Apple doesn't want to give anyone identifier context anymore. Why? Because now you have to go through Apple for authorization to subscription based services OR create prompts for user identification info they may or may not know. With this new user identification barrier in the way, I get to either create a second mechanism to capture and handle the identification and authentication of users on iOS specifically, or I create a user authentication mechanism that requires user interaction.

Again, not talking about any specifics but yes this is an example of how iOS is affecting Android too. Which was the point of the article.

It seems you are one of the few who got the gist of the article.

Everyone else seems to have gone into full defensive mode

[Zero]

Originally Posted by shrike126

Except... that's not the reason Apple did that. That's the claimed reason, but the reason they did that was because they did not want external user identification contexts beyond the silo'ed approach they would have control over.

And yet, there's plenty of ways to id users that still work.

It always comes down to choice. You can CHOOSE to be inflexible with how you expect the app to behave across all platforms (or how it talks to the backend). Or you could CHOOSE to make it better on one platform, or even disregard the other. I know my carrier (Rogers) doesn't offer the same account support app for all smartphones.

It's a completely stupid argument (the article, not you shrike). And no sazar, just because people don't agree with everything that's pro-Android, doesn't mean they're necessarily "defending" the other platform. x eleventy billion

[t0adp1p3]

Hey shrike, thanks fr answering my question, pretty nice Of ya to reply

[Sazar]

Originally Posted by Zero

It always comes down to choice. You can CHOOSE to be inflexible with how you expect the app to behave across all platforms (or how it talks to the backend). Or you could CHOOSE to make it better on one platform, or even disregard the other.

This is exactly what the article talks about though. Sure there is choice, but it is a choice driven directly by iOS in the case of many devs who may not have the time and money to have to make the necessary adjustments from platform to platform.

It's a completely stupid argument (the article, not you shrike). And no sazar, just because people don't agree with everything that's pro-Android, doesn't mean they're necessarily "defending" the other platform.

Ironically, the above is directly applicable to your own comments in this thread and others.

[Zero]

Originally Posted by Sazar

This is exactly what the article talks about though. Sure there is choice, but it is a choice driven directly by iOS in the case of many devs who may not have the time and money to have to make the necessary adjustments from platform to platform.

That's an absurd claim, developing on different platforms will always require overhead. If you don't have time and money, then you've done something wrong getting to that point.

I feel like this is devolving into a "because I said so" argument. Feel free to believe whatever feeds into your agenda.

Ironically, the above is directly applicable to your own comments in this thread and others.

What exactly are you trying to say?