Devs Bet Big On Android Over Apple's iOS 328
CWmike writes "A majority of mobile app developers see Android as the smart bet over the long run even as they vote for Apple's iOS in the short term, according to a survey conducted jointly by Appcelerator and IDC. The survey polled more than 2,300 developers who use Appcelerator's Titanium cross-platform compiler to produce iOS and Android native apps. Of the 2,300 polled, 59% said that Android had the 'best long-term outlook,' compared with just 35% who pegged Apple's iOS with that label. But three out of four said that iOS offers the best 'near-term' outlook, with 76% tagging Apple's operating system as the best revenue opportunity."
Re:woowoo (Score:5, Informative)
You do realize that Apple has paid out over a billion dollars to developers? I always enjoy these off the cuff statemetns about how poorly Apple Developers are treated when the simple fact is, that it is a lucrative market, which is why 3 of 4 still plan to develop for it in the immediate future. (ref: http://news.cnet.com/8301-31021_3-20007010-260.html [cnet.com])
Assuming they create a good product, they are treated very well, getting an instant distribution model that functions at break even. Not a bad deal at all.
The simple fact is that a huge majority of apps are approved within 2 weeks. Of those that are rejected, almost unilaterally they violated the developer agreement, and then complain about it after the fact. Google Voice was a good example. At the time it was developed, it offered unlimited texting, which duplicated core functionality, which of course is listed in black in white the agreement.
I know it's popular to love to hate Apple lately, but the simple fact is that the majority of apps are rejected because the developer took a chance and ignored the agreement. I will grant that some of these rejections seem a bit stupid.
Given that 95% percent are accepted without any issue at all, leaving only 5% of questionable apps, the argument that Apple is rejecting apps willy nilly is not exactly a good reflection of reality.
Re:That sounds about right.... (Score:3, Informative)
Android app store is 2% of Apple's:
http://larvalabs.com/blog/android/android-market-payouts-total-2-of-app-stores-1b/ [larvalabs.com]
Half of iPhone users buy at least one app per month. Only 21% of Android users
http://www.fiercemobilecontent.com/story/admob-half-iphone-users-buy-paid-apps-every-month/2010-02-25 [fiercemobilecontent.com]
Re:woowoo (Score:4, Informative)
It is clear that the $1B is referring to the money users paid for the apps. Apple says that they paid it b/c it is given to Apple and then immediately forwarded to the developers.
Re:That sounds about right.... (Score:3, Informative)
I see you've never worked in the financial services industry, where I've seen people make entire careers out of endlessly tweaking the same piece of legacy software.
Look at hackel's proposal, and his outrage that somebody wants to "make money from their code." Apparently, we should all be working as wage slaves, where no matter HOW GOOD the code is that we write, we get paid for the amount of hours we sat at a desk writing it.
Imagine if you told your contractor that you would pay them $100 an hour, regardless of the quality of their work? Think you'd see some overruns and slow work? I do. Oh sure, you can fire them if they take too long, and go through all the expense and hassle and frustration of finding someone new to take over the job, with untold hours of your own wasted, as well as significant cost overruns because the new guy has to redo half the shitty stuff that was done by the guy who got fired.
When you set that up as an economic model, you put people in the position where, to quote from Office Space, "my only real motivation is not to be hassled, that and the fear of losing my job. But you know, Bob, that will only make someone work just hard enough not to get fired."
Re:woowoo (Score:3, Informative)
You might've missed the recent repeal of section 3.3.1. Apple now no longer requires applications to be written in Objective-C.
http://www.apple.com/pr/library/2010/09/09statement.html [apple.com]
Re:woowoo (Score:3, Informative)
In other words, your rant is based entirely on imagination. Please learn some facts before ranting again.
Re:Sampling bias? (Score:3, Informative)
Your basic widgets are pretty straightforward to implement on multiple systems, but what eats up time and effort is indeed things like getting layout to feel like it fits in the system, and to integrate with native widget styles, dialogs, or UI conventions that are different. (Use a system icon there, a menu here; a nav bar at top here, submit/cancel buttons at the bottom there.)
For StatusNet Mobile [status.net] which we built with Titanium we've had to do a lot of special-casing to get various parts of the UI looking and feeing a little more native on each system, and we've still got a number of dialogs that need more work. The majority of our UI though is in a webview, which is nicely universal. ;)
Tying into low-level platform integration can be a bit more difficult too; being able to 'share' messages out to other apps that accept the Action.SEND intent or text/plain for instance required tossing in a low-level module to hook into the Android system code directly, which was more awkward than I'd prefer.
Re:Shared libraries are a big key (Score:3, Informative)
b)There really isn't a clean way to talk between applications. You can send files, but it's really a drop box, I can COPY(not link!) something into another apps area, but after that the file is no longer mine. So if I want to send something to another app to process and then get it back to do some processing by my application I have to hope the app tells me about the changes, and considering the app may not even know I exist(nor should it, thats the beauty of decoupling), thats a lot to ask.
Indeed, there's not a great way to share data between apps on iOS; the 'file sharing' in iOS 3.2/4 seems pretty dreadful and awkward to use. You can push some data around via URLs, but I've not been able to find a system for discovering URL handlers, or having a way to declare support for particular types of data instead of manually listing some application-specific URL schemes.
Android's system for "Intents" is a bit nicer; you can combine some typed or structured data (say text/plain) and an action ('send') and just shove that off to whatever apps will take it. That's how the 'share' buttons in Gallery, Twitter, etc are implemented, and how you launch email dialogs, etc. Much more flexible, though still tends to be UI-driven rather than behind the scenes.
I can *sort* of understand 1 from a performance standpoint, if you allow user created dynamic libraries every time the application is swapped out of memory you have to find which dynamic libraries it uses, make sure nobody else is using them, then unload them. However as memory increases the rationale behind needing to constantly load/unload them starts to disappear.....
Dynamic libraries don't really work that way; when your program is loaded, the linker pops over to your libraries and pokes a few bits in memory that make the function & data references work correctly. The untouched parts of the library can be shared between processes because the executable code is memory-mapped from the file into address space directly; the kernel's memory manager deals with knowing what's using it, so at the system level there's no special need to go looking for what process is using what library.
There can be performance issues with dynamic libraries because the dynamic linker has to, well, link more things when your program is loaded. :) But the biggest issue here is probably simply that of filesystem management. The preferred application model on Apple's systems (both Mac OS X and iOS) is for most individual apps to be self-contained: any libraries that aren't bundled with the system should be bundled into your application, so they don't have to be separately installed or uninstalled.
On iOS you're even more restricted because user-installable apps are kinda funkily sandboxed from each other, and the app distribution/installation infrastructure is totally geared towards individual, standalone app bundles. If you've got no place to put shared libraries that will share them, there's not much point to using dynamic linking (unless you're going so far as to manually load/unload the libraries and link symbols yourself to keep from having to load them, which is probably not very beneficial these days; it might be better to just link statically and avoid fixups. :)
Re:Not a surprise (Score:3, Informative)
> Meego will take a while to catch on
Maybe - time will tell - but as a Meego developer, I can say that there is quite some interest in hiring people with such skills - more so than Maemo ever was anyway (IMO). I think some entities actually get that Android isn't quite what they want - good enough for now perhaps and better than iOS and Microsoft, but not much better than peeing in their pants to stay warm ;)