Why Developers Still Prefer iOS To Android 614
An anonymous reader writes "Google Chariman Eric Schmidt recently addressed an Android user lamenting the fact that that mobile apps are often released on Apple's iOS platform well before they finally reach Android. Schmidt cooly and curiously explained that this dynamic will change in just 6 months. Here's why he's wrong. Though Google brags about the total number of Android users, developers care about certain kinds of users (those that pay for apps). A similar dynamic can be found in television advertising, where advertisers will more money for ad spots on less popular shows in order to reach desirable demographics, even though other programs may have many millions of more viewers."
Re:Android has many problems (Score:5, Informative)
I also remember that some years ago there was lawyers paying really high clicks for some really specific cases. I think it was targeting some people who got major health problems as result of some company. They paid for those clicks really much because the amount of money they got from settlements etc was so good.
Android is not a viable proposition (Score:3, Informative)
For developers, that is. Android is a one size fits all approach, but not all Android phones can run all games, some are too weak. This causes developers headaches, bad reviews on their games, etc. And Android Market is not secure like iTunes, the apps don't go through a vetting process before they are put on the market, like iTunes does for their apps. So malicious apps are out there. Unlike iOS. Android is the new Windows... Sure it'll sell well, but Apple can give assurances on security, and the corporate sector will never adopt Android so it will remain the poor man's iPhone and the domain of geeks who can't face the fact that iOS is actually very good.
Now... flame away :)
Re:Mod topic as flamebait? (Score:2, Informative)
It's not flamebait. It's based on a study by Flurry Analytics [flurry.com] showing that Android developer share has declined by more than one-third in the last year. Apparently, refuting the Eric Schmidt with hard numbers is now "flamebait" because happens to be negative news about Android.
Re:Android has many problems (Score:4, Informative)
Re:Really Has Nothing to Do with Development (Score:5, Informative)
Most of the iOS APIs are derivatives of the very well tested, designed, and readable NS (NextStep) APIs that have been in production for over twenty years. Apple adds new APIs with every release, yet they still follow the design patterns and methodologies of the older application interfaces, making learning new ones quite easy.
With Objective C finally receiving easier memory management (yes, it was never terribly hard but it was at times frustrating), new developers, especially Java developers, can start rolling out code relatively quickly. As a point of history, Java's developers apparently did look at Objective-C as one of their primary influences. Personally, I find Objective-C much easier to code in then Java, and the clear nature of Apple's APIs combined with very, very strong development tools makes me much prefer iOS development over Android
There's an added benefit of iOS development which isn't commonly mentioned - it's relatively easy to port iOS code over to Mac OS X, allowing you to reach a broad and lucrative environment, leveraging your previous work.
one word: consistency (Score:5, Informative)
I'm developing on both Android and IPhone; started out on Android and now have extended my repetoire to IPhone.
The advantage but also disadvantage with Android is that it's very open-ended. Often you want to get a specific thing done and you end up alot of time bending the API to your will. (Oh tabview, why art though so...) Or bump into the limitations of your architecture and need to rework some things to get it running.(why does it crash on device x when I have two nested frameviews to have this design? Why doesn't it scale well on device y?)
The IPhone API takes more knowledge (how does that delegate call again and what object is stored where and how do I get a refernce to this?) but it's consistent. And the look is consistent. (which shaves up alot of time thinking about the GUI when trying to implement it.)
I'm an avid Android lover but I can appreciate the IPhone API as well.
Re:Android has many problems (Score:4, Informative)
The short reason is that Android was first conceived as a Blackberry competitor, with most input coming from a keyboard. High-priority interface responsiveness wasn't as much a concern in that environment. The Android simulator used to look like this [imgur.com]. The iPhone came out and blew everyone away, made touchscreens all the rage, and Android changed to compete. The fact 2011 Android interface responsiveness is not competitive with the 2007 iPhone is something of an embarrassment, in my opinion, but the technical foundation was just not designed to deliver that kind of experience, while iOS was designed from the ground up to support it (every interface element is backed by a GPU-accelerated Core Animation layer).
Re:Mod topic as flamebait? (Score:5, Informative)
Re:Mod topic as flamebait? (Score:4, Informative)
I think you might have just explained the results without even realizing it.
Is Flurry Analytics not a thing that competes with Google Analytics? Because I could kind of see how Google would be better able to promote Google Analytics to Android developers more easily than to iOS developers, which would take them disproportionally out of Flurry's numbers.
Re:Android has many problems (Score:5, Informative)
There [google.com] are [google.com] a couple of insightful posts by a Google engineer addressing this specific myth. The original reddit comment, where your comment originally came from, generated a very interesting discussion on the subject over at G+.
Money (Score:5, Informative)
The reason is simple, I use a cross platform tool kit to create my apps. The apple versions out sell the android versions by at least 100-1 ratio. I quit even bothering to compile a android version. If I spend more than a hour testing and compiling a android version I am wasting my time. Once there is a few bucks to be made I will likely return to the android market, until then I am completely IOS / Apple Store focused.
I could care less what a android fan boy says.
1. Apple Store has better monetization.
2. IOS applications perform better (native execution)
3. The platform is standardized I am not trying to build for 300 different devices.
Re:Hey hold on there... (Score:4, Informative)
The Galaxy S II was the best selling device last round - even outselling the iPhone 4S.
The iPhone 4S has only been out 2 months. Too early for stats. The Galaxy S II certainly didn't outsell the iPhone (4). You're confused with the sales of the entire range of Samsung, which did outsell the iPhone. But that includes around 50 different Samsung phones, including many free with a contract ones.
I'm afraid your appraisal of Android as being a generation ahead of iPhone is as deluded as your misunderstanding of sales figures.
We're making an Android port now. (Score:3, Informative)
For a client. We built their very successful, very nice, iOS app.
It's hell making the Android port.
The iOS version of the App has these beautiful sliding table views that overlap each other with nice drop shadows. Simple gestures move them on and off the screen. As you scroll one of them, the other table view scrolls and highlights to match up to the corresponding section. When you tap products they animate and fade into an expanded information view. It's a really nice app and users love it.
Then they asked for the Android version, we're working on it. But we had to throw out the overlapping tables with drop shadows. We had to implement a stupid paging system for tables because they wouldn't scroll smoothly with ~2,000 products (each product has downloadable images that start to fetch when they are scrolled on screen). The table cells can't animate as they expand like on iOS. Putting a ScrollView inside a ScrollView doesn't "just work" like it does on iOS, where touches are correctly, and importantly, delayed slightly before being passed to inner-content views.
This app manages a lot of data and it works smoothly on iOS all the way back to an iPod Touch 2G, which has completely anemic hardware compared to the Galaxy S2. Yet the Galaxy S2 struggles with the sorts of interactions, UIs and data we ask it to render.
Another annoyance is that different Android phones seem to behave differently. On the HTC device we test with, our WebViews allow user scaling even though we disallow it in the meta-tag. Our loading indicators look different. We have to account for the user possibly using a different system font and thus can't rely on getting a pixel-perfect design to the. It truly sucks.
The final annoyance is that different Android phones have different color calibration. The colors are designed to match the company's printed books. Their printing spot colors work beautifully on iOS screens. Yet look at the Android app on a Galaxy S2 and HTC device (using the same RGB values) and the resulting colors are completely different.
I'm also trying to do things the "Android way." Yet I am rapidly discovering there is no consistent way to design apps for Android. Editable table views? Every app seems to do it differently. Google+ and Google Reader both handle them differently! How the hell do they let this happen?
Re:Android has many problems (Score:5, Informative)
There were two, actually - the first one (VS2002 and VS2003) was "C++ with managed extensions" - that was pretty nasty in more ways than one could imagine, and was hastily scrapped. The new one that's still alive (VS2005+) is C++/CLI.
However, it's important to understand what "compiles to .NET" actually means. VC++ compiler can compile pretty much any random C++ code to IL bytecode, but to do that it needs to use bytecodes which are not memory-safe ("not verifiable", in .NET parlance) - think pointer arithmetics and other such things. IL itself is expressive enough to allow for such things, and the resulting code is architecture-independent, and is JIT-compiled and runs under the VM just the same. So, yes, you can take a C++ library as is, and run it in .NET. The catch is that it cannot be sandboxed. Therefore, it does not run on Windows Phone (or Silverlight), because those only allow for verifiable IL, such that it can be sandboxed.
Then there's C++/CLI, which is a set of language extensions to C++ that lets you access .NET APIs, and define your own - keywords like "ref class" and "gcnew". If you write code using only those language extensions, you can use /clr:pure compiler switch to request the compiler to produce verifiable, sandboxable IL. That runs on WP7 just fine, but in that mode, you can't use most features of regular C++ - no arrays, no pointers, no regular classes etc. Basically, what you end up with is a subset of C# with more C++-like syntax. Obviously, this is completely useless from portability perspective - you can't run any existing C++ code with this.
There is a way to use this mode to write code that's portable between WP7 and other platforms if you do it from the get go. I briefly described it in one of my old Slashdot post; basically, the idea is to define a bunch of macros such that they expand, alternatively, to C++/CLI constructs when compiling for WP7, or to regular C++ constructs with identical meaning when compiling for everything else (with a support library for smart pointers, strings and such that matches C++/CLI semantics). You still end up with a rather limited subset of C++ - about as expressive as C# or Java with C++-style templates - but it's actually possible to write something useful in it, and have it run on all platforms. However, this is only applicable to any code that you would be writing yourself there and then - i.e. it doesn't solve the problem with numerous existing C/C++ libraries, and it doesn't solve the problem with porting existing iOS or Android apps. Besides, given the current market penetration of WP7, it is likely still too much effort for too little gain.