Something interesting happens when you ignore hype and prejudice and start paying attention to results: reality manifests itself, sometimes with surprising results.
So let me give you some results: A bit over a year ago I became 1/4 of our new mobile team (2 android guys, 2 iOS guys) at work. We set out to write our apps, which have the same design, use the same visual elements, the same API, and have the same features etc. A year later, with thousands of lines of code and man hours behind them, both apps are still at the same level as each other, with neither being ahead of the other.
In short, anyone that tells you Android development is harder than iOS is lying, incompetent or has an agenda. Or simply mistakes his opinion for reality.
We can agree to disagree. I have done both iOS development and Android development on a fair number of high-profile projects.
To clarify, I am saying Android development is harder in the big picture (not just coding, but styling/graphic design/layout). Part of the reason why I believe this (my opinion) is harder is because the tools (Xcode, IB) are so much better for working in a team. Especially, when you have an on-site designer. You can give the designer a XIB file to style and modify to pixel precision. Android's layout editor still has a long way to catch up.
> same design... same visual elements
If you are using the same UX for both apps, you're doing your Android users a disservice. Android is different enough to command its own tweaks.
What does pixel precision mean in an environment meant for different screen sizes, resolutions and even ratios? Good design means things like alignment, relationships between elements, ratios between sizes etc. It doesn't mean 7px or 10px. What I'm saying is that you can design things very well without pixel-perfect precision and while Android's tools may be more manual (essentially a saner HTML without cross-browser crap), they are not out of reach of any HTML developer.
And yes, our apps are not identical: Android has a drawer, dilaogs, spinners, toasts, uses the back button etc. But at the end of the day, you'll find the same functional screens, presenting the same information and offering the same functionality.
Pixel precision means that we can send a standard PSD to a client and they can style it and send it back so that we can slice it up and deliver the finished app.
Android's layout is definitely more powerful but you cannot set every property in code that you can set in XML.
We've started using separate layout files for every screen resolution tranche (e.g. layout-land) but I am still hoping for a way to preview multiple resolutions simultaneously.
Thank you for respecting the Android consumer and not doing something like a "Back" navigation button on-screen.
Pixel precision means that we can send a standard PSD to a client and they can style it and send it back so that we can slice it up and deliver the finished app.
This is meaningless when you have variable screen sizes to deal with (or at least a large enough number of fixed screen sizes to make this impractical). You can get away with essentially making a UI out of images on iOS, but not on Android.
Android's layout containers are far more flexible than iOS's springs and struts system. I've found this to be true of MacOS desktop programming as well, in the face of something like Gtk or Qt. Maybe my brain is just wired to prefer fluid, auto-adjusting layouts, but I find the Apple way of UI layout to be very primitive and limiting.
Do you guys just ignore color fidelity on the devices in this process? I found the earlier iPhones and iPod Touches had pretty different color profiles to the iPhone 4 (and iPad).
I guess layout is, strictly speaking, more important to UX than pitch-perfect color. Still, it's one of the things that bugged me when working on my (aborted) iOS project.
We better fire our designer :)
He did not know about this.
He does have one of those colour matching doohickeys to calibrate his monitor.
In general, I think as long as it is not a CMYK print ad, a little deterioration in colour is ok.
I am surprised he didn't. The contrast of the displays is noticeably worse on older models. And that pretends that older models are not well... old.
I was just hoping you had some sweet solution because I think you could make a business out of layout, resolution, and color testing for mobile all on its own.
Pixel-perfect layouts in Android are harder, but declarative layout makes a lot of things easier. For example, if I need to add one button to a row of buttons in iOS, I have a lot of fiddly tweaking in IB to do. In Android I add one more line to an XML file and I'm done. Need to change the background color and text of all the buttons in your app in iOS? I hope you created them all programmatically. In Android I change a few lines in my style file and I'm done.
iOS's UI stack is clearly pre-web. Android is post-web.
Oh yes, we have a hand-maintained (pre-iOS5) very complicated UINib manager that loads Nibs and lets us "style" based on a system of plists and resource bundles.
Xibs are hideously verbose and clearly not designed to be edited by hand. They also don't offer anything like the auto-layout and declarative styling Android gives you.
Apple's recent introduction of autolayouts shows that they see this as a deficiency.
From my experience, when you start using Scala[1] or Ruboto[2] (which deals away with the XML and replace with friendly DSLs, at the cost of heavy load time), Android development can actually become a joy.
Often their agenda is a salary, so they go for, and recommend, the platform most likely to make money (even per fixed number of possible customers it seems). If iOS makes more money, that's a valid reason to pick it.
Your claims are easily proven false. Any platform where you're targeting multiple hardware devices needs more architecture, design and testing work.
The fact that the implementation phase takes about the same time is not very relevant, especially when considering that you're cutting corners and using the same UX on all platforms.
With all due respect to the developer who wrote this post, standalone apps are relatively easy - you start jumping into the rabbit hole when you start getting into server API integration and doing processing off the main thread (AsyncTask, IntentService, Service, unit tests lions tigers oh my), layouts that don't suck, and custom animations... Making an Android app look sexy/good is an art in itself that I am still trying to learn.
At a certain point of app complexity, writing an Android app becomes less about writing an Android app and more about writing a well-structured, async/decoupled and performant app in Java.
Why is iPhone development relatively easy? Well, for one thing, the territory is well trodden. And it is based on the beautiful foundational framework of Cocoa, which has its roots in NeXTSTEP. Cocoa masters have been able to switch to iOS and tell people/show people how to code properly. Cocoa has been around for a while; the Android SDK is a WIP (but it has come a long, long way since Cupcake). Also, Java lacks compiler-level support for/doesn't have blocks and categories (two of the things that make Objective-C a joy). And, love it or hate it, you will start to miss CoreData when you don't have anything near equivalent on Android.
Some of my favorite resources for learning Android:
The best book for the money (frequently updated, author has huge SO reputation)
The Google source (note, not all code is pretty but it shows one way of getting things done).
Android is known for its flexibility, power, and customization. There are many ways to setup/do things, some good, some bad. That just doesn't apply to the end user's experience but to developing apps for it.
> you start jumping into the rabbit hole when you start getting into server API integration and doing processing off the main thread (AsyncTask, IntentService, Service, unit tests lions tigers oh my)
Yes, the first thing to learn is concurrent programming in Java, and Android's classes that simplify it.
Then learn about components - everything that implements the ComponentCallbacks interface - and how lifecycles work. If you skip over this you are doomed.
Then learn how to keep your data model in a ContentProvider.
After that, you are through most of what is different and that might be strange.
(OP here.) I agree with you on most points, but I don't know how you'd write a graphical game without dealing with asynchronous operations. For example, this app uses an extended SurfaceView (uses its own thread to draw), timers to handle move animation, and AsyncTasks to perform computer AI turns and implement a hack that makes Toasts last longer. Otherwise the UI would be clunky and give a "not responding" message whenever it wasn't your turn.
I would say that graphical games are a step above the simple "standalone app" you mention.
I apologize. I may have rushed to judgement. I didn't get a chance to check out your game, will do. Games are definitely not a simple standalone app.
I stand by my assertion that non-trivial app development on Android can be harder than on iOS. For example, take a look at the Google Music app source (an example of a complex app) and see if you can understand how it was designed and why it was implemented in such a way. I can't claim to fully understand it.
I certainly could've done that. I liked Toasts, found that you couldn't extend their duration beyond 3.5 seconds, Google'd the problem and found a hack to extend them. Either approach would've worked fine.
Maybe eight months of experience isn't enough to judge it fairly, but I think Cocoa's almost mystical reputation is somewhat inflated. If you compare Cocoa Touch to Cocoa on the Mac you can see that Cocoa Touch is a much cleaner, simpler and more consistent version of Cocoa. There is still room for improvement.
It's a testament to the skills of the original authors of Objective-C that a 1989 technology is still competitive in 2011, but we've learned a lot about language and UI framework design since then.
Why is _Android_ development relatively easy? Well, for one thing, the territory is well trodden. ... _Java_ masters have been able to switch to _Android_ and tell people/show people how to code properly. ... _Java_ has been around for a while.
Goes both ways, no? Not that your comment is without merit but this bit just struck me as really odd.
Java isn't the most flexible language. Java is notorious for having over-engineered frameworks and APIs (J2EE). There is lots of unavoidable copy and paste. The newer things that make Java look more modern, lithe and Ruby-like like Spring/Hibernate - don't work well within the power/memory limitations of a mobile device.
And, more importantly, the market isn't just there for Android apps. Not as many people want to code Android. I hate to say it but some of the projects I've been involved on - Android was a "checklist" item - as on 'We're on Android now, too'. I only know a handful of full-time Android developers, but I know many, many people who have quit their jobs and have gone full-time iPhone (contract/product).
It's important to distinguish Java the language from Java the framework-encrusted "enterprise" tool. Java as a language isn't so bad. Objective-C and Java each have their own strengths and weaknesses. For example, my Java code dealing with collections is much cleaner than comparable code in Obj-C because I don't have manually box & unbox primitives with incredibly verbose messages.
The JVM also gives you alternatives. Currently none of the non-Java JVM languages is great for Android but Jetbrains' Kotlin project is looking very promising:
http://blog.jetbrains.com/kotlin/
> Java is notorious for having over-engineered frameworks
You've got to separate Java the language from all the other stuff. You aren't going to use J2EE for Android so how does that affect you? Java may not be the most elegant language but neither is Objective-C without warts.
> And, more importantly, the market isn't just there for Android apps.
Now you are just moving the discussion.. this is not what the OP was talking about nor was it the point of this discussion.
The OP's thesis was about how Android development is easy. I countered that with the strong personal opinion that once you get into more complicated apps that it gets harder. I believe it gets harder because there are less resources (for example, if you compare the Apple developer docs with Google's Android docs - you would be hard pressed to say that the quality and quantity of Google's docs are more).
Apple clearly had the lead on developer mindshare because of the success of the App Store. Google is catching up but the reality is you can make a living off iOS easier than Android. You could do both but going from CoreData to ContentProviders in one day might make your head queasy.
Speaking of J2EE, I would love to have Spring or Hibernate ORM. I've tested the various Android ORMs and they do not yet seem to be 1.0.
> AsyncTask, IntentService, Service, unit tests...
Maybe I'm off-base here, but I think that if you understand the abstract concepts behind these on another platform (say GNU/Linux development with Qt or GTK) then it's simply a matter of translating your understanding of the concepts into the new platform's way of doing it. This is what a CS degree is meant to teach you (i.e. in my degree program, they never taught any programming languages -- only concepts in the abstract). Learning Services, ContentProviders, AsyncTask, etc. was really not bad at all and as you said, the SDK has gotten drastically better over the years.
The challenge is two parts: 1) creating an app that does what you want and does not ANR 2) creating an app that looks good and responds well. I stress that the 2nd part is what the users notice the most - they don't care about your well-designed network processor logic if it takes too long or lacks the shine and polish of an iOS equivalent app.
I'm not saying it is easy to polish an app on iOS. We've spent months polishing an iOS app to client satisfaction. The thing about Android is that clients are willing to accept less polish.
In my experience, the difference between Android and iOS for me is "How?" for the former versus "Is this even possible?" for the later.
Yes, iOS is friendlier to newbies, but Android is more flexible and allows pretty much anything you can think of. More complexity is the drawback of having more flexibility, but after learning the platform it isn't really that bad (as the article says, with which I agree).
As a note I've been developing in Cocoa since 2005, and Android on and off since it come out. Also taught both iOS and Android at the local university. I still prefer iOS and it's tools a whole lot better. Developing for Android isn't bad, it's the development tools.
* installing Xcode is simple, minus the large download. For android I've got to get an IDE, android sdk, plugin for my ide, download platforms needed, create virtual machines (making sure to enable snapshot mode or wait forever on each reboot).
* the iOS simulator is nice and quick, though it gives you false hopes of how fast your app runs sometimes. The Android emulator is slow, almost unbearable at times. I've also gotta make sure I'm on power or my battery drains quick.
* programming for either is about the same in terms of ease or difficulty. Concepts are easy to get. Sometimes I think android is a little bit more straight forward.
* setting up a device to accept a dev build is a few clicks on iOS. On android I've got to enable the device for non market apps, etc on the device itself.
* I still have no clue which market is the best to put Android apps, the fact there is a choice makes everything even more confusing.
* fragmentation, though I've never had any major issues.
I really don't have much against Android as a platform, it's the development tools that drive me away. Apple has everything so it just works.
Which market is the best to put Android apps? How about all of them? I love the fact that you have choices. There's only one iOS app store, so you're putting all your eggs in that basket.
Yes, but everyone knows that one app store. It's too much of a pain to manage multiple markets on Android. Especially when some do reviews and others do not.
I've spent over a year maintaining a BlackBerry app, and while I've only been dabbling in Android, what I find in the docs and tools from Google is several steps above the BlackBerry equivalent. Anyone complaining about how Android development is painful should spend a month or two working on BlackBerry apps.
Have fun fighting a terrible, custom Swing IDE that RIM wrote, because debugging via their buggy Eclipse plugin (which is downloadable as an entire Eclipse install, so you have to reinstall all your customizations and other plugins) doesn't always work (forget the actual step debugger, which doesn't work at all, I'm talking about getting the output from System.out.println). Cross-platform development is pretty weak: there's no official support for Linux, and there are no simulators and no support for older devices on OS X (50% or more of the BB subscriber base).
Enjoy the need for a round-trip to a RIM server which has a habit of being down (it's been better recently, I admit) just to put your app on a device during development. Users can change the permissions on a per-application basis, and can install and run apps without the required permissions enabled, so you need to manually check the permissions you need every time the app starts. API calls that need this care aren't documented, so you have to do basic science on the device to figure it out.
Want to make an HTTP connection? Great, here's a giant ball of accumulated wisdom on how to tiptoe around APNs and other transport-level bullshit. Or you can pay $2000/yr for access to an undocumented BIS string that might work a bit better.
Programming is hard. Some tools are shitty, but there's often someone on the other side of the fence who has it worse or better. There are a few senior devs here who have horrifying war stories about J2ME and Brew. It seems that even Blackberry development is a bit smoother than other mobile platforms. And I'm sure embedded programmers have even scarier tales of low-level Heisenbugs.
Edited to add: Oh yeah, BB is also all based on J2ME, which means Java 1.3. No collections, no generics, no auto-boxing, no for-each loop, no reflection. Yes, even on the new BlackBerry 7 devices, Java 1.3.
I have spent a short period of time dealing with Blackberry, and I can do nothing but echo your sentiments. Would you mind sending me an email (in profile), so I could pick your brain about Blackberry?
> I ran into problems putting up a free and paid version of the same app on the Android market
This is one of the most aggravating issues I have with the Android market at the moment. Every app that has a free version handles it differently: Some you buy a key and enter it (which means purchasing out of band), some use the Android Market micropayment system (so it often isn't clear you have to pay for the app at all), some use a free version and full version of the app (so if I play the first 15 levels in the demo, I have to play them all through again when I buy the game). C'mon, Google. Pretty common use-case here.
I've been writing iOS apps for about 8 months now and recently started writing some simple Android apps to get a feel for it. Maybe things get worse with more complicated apps, but I'm actually finding so far that Android makes the easier things easier than iOS.
I think the question for most indie iPhone developers is not necessarily: is android hard? But: is android worth the time investment. For indie developers, time = money.
The range of sales for android paid apps are publicly available on the android market. Based on my own sales figures (I've been as high as #66 overall on the Top Paid iphone list) as well as knowing the sales figures of other highly ranked apps like Angry Birds and Doodle Jump, it is apparent that paid apps on android do an order of magnitude less in sales than their iOS counterparts of the same rank.
That said, I'm release my best performing iPhone app (currently makes about 1K/day) on android in a few days. So we'll see how it goes.
Time Required and Difficulty (or Ease) of developing on one platform vs another ...
... without factoring in the amount of money you can make (or if you don't want to make money, the amount of people you can reach).
It's also very, very strange to not talk about the huge number of devices that run on Android and the complexity of supporting some/a few/most of them.
*
What's the point of - It took exactly just as much effort and time and pain to make a great app on Android as on iPhone
without elaborating on
- how much profit there was
- how many people it reached
- various other factors like how much of the Android time was spent on supporting various devices
- what the level of quality on each platform was.
Finally, don't mean to be a dick about this but -
Who cares if someone makes an app in 4-5 days worth of work and releases it.
Where are the people who have made amazingly good Android Apps?
What's their story?
Do we really want to focus on how easy it is to make an app that takes just 5 days and is nothing out of the ordinary?
I can corroborate. Developing Android apps is easy.
I got "hello world" to work in about 15 minutes, and was doing asynchronous HTTP Posts of images from the gallery to a remote server the next day, with hooks into the Android sharing system and progress bars and the whole thing. All this while riding in a truck, without Internet, from Salt Lake City to San Francisco to demo to some investors (Android app was a small part of a larger demo).
I hadn't touched java in 8 years. Never done Android development previously. It was brain-dead simple.
Your post is missing the main gripe of many developers so far. Which is that there's far more money in iOS land than there is in Android. It's hard for an average game to make more than $100 a week.
With the amount of competition in the iOS app store, how easy is it to make more than $100 a week from an iOS game anymore? There may be more people doing it there but there are probably also more apps languishing in obscurity. Android is gaining in popularity and it seems like the situation for developers is improving. I think the main challenge is creating a unique, engaging game for any platform.
There's no doubt that iOS apps are bringing in more money now. However, the Android market shows you actual sales stats for apps and its clear that some people are making money on Android too. I also find it hard to believe that Android's current hardware sales volumes aren't going to eventually pull up market sales too. They may always lag behind Apple's but I'd be very surprised if the ratios stay as skewed as they are now.
If you're already established and successful in the iOS store then it makes sense to stay there. If you're starting from scratch then it's not quite so clear-cut, I think.
I take some issue with this argument. Not necessarily to say that it's false, just to say that it's not a strong argument or at the very least holds little foresight.
As an example I recently downloaded Words With Friends on the Android, became immediately annoyed with the ads and was at a loss when I tried to find a pay version. I emailed them and although they replied within hours (fantastic!) they said they don't have a paid version at the moment (it's in the works).
I'm reminded of John Carmack's ad-hock survey of iOS and Android users to find how many people would have spent at least $20 for apps[1], and then he explains in more detail why we won't be working with Android at that time. His reasoning is solid, but that survey puts an exclamation on the same point you're making, which is unfortunate.
It's easy to claim nobody pays for things on Android if there's nothing there worth paying for. It seems to me this would make Android a prime market rather than a poor one.
I've personally spent at least $40 on Android apps in the last year or so (mostly games) and will spend plenty more as developers come and give me reason (or at least a chance) to give them money.
For instance I wanted an app that would block calls and SMSs and do a better job than the built-in functionality.
I found an ad-supported app that did the job, but the UI was awful.
So I tried to buy a non-free app that had good reviews -- problem was that the developer wouldn't allow purchases from my country, so I couldn't purchase it.
Also, as a developer Android is a poor choice for me, not because there's anything wrong with the platform, but because Google doesn't allow me to be a merchant that receives money from them (I'm not in one of the approved countries).
So the only option available to me as a developer is to release ad-supported apps. And with ads the UI experience suffers, so this automatically puts me in a don-t-give-a-shit state of mind where I don't care about experience as much as I care about volume.
This goes round and round, but on the whole I think that the quality of Android's marketplace represents an opportunity precisely because the competition is doing a poor job.
Well, that might be true or not. It is just another topic. Just because there is Android in the header doesn't mean all Android topics are equally important in this discussion.
So let me give you some results: A bit over a year ago I became 1/4 of our new mobile team (2 android guys, 2 iOS guys) at work. We set out to write our apps, which have the same design, use the same visual elements, the same API, and have the same features etc. A year later, with thousands of lines of code and man hours behind them, both apps are still at the same level as each other, with neither being ahead of the other.
In short, anyone that tells you Android development is harder than iOS is lying, incompetent or has an agenda. Or simply mistakes his opinion for reality.