Slashdot Mirror
Why Developers Still Prefer iOS To Android
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."
Here's one article that shows most expensive categories http://techcrunch.com/2011/07/18/most-expensive-google-adwords-keywords/
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.
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.
/* Dang, I can't type that well. */
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.
I think we can keep recursing like this until someone returns 1
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. 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).
Wait. The front web page of Flurry says "FLURRY: Introducing a game-changing marketing approach to build your iOS audience more effectively." So, they target Flurry for iOS and then find that most of their developers use iOS. And this is worthy of any notice?
There are 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+.
[alk]
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.
Got Code?
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.