Comparing the iPhone and Android Development Environments
I’ve spent the last few weeks working on an Android project at work and, I have to say, I am having a familiar feeling of shock at how bad the Android development environment is.
Here are some comparisons.
Objective-C vs. Android
First and foremost, using Java is much better than Objective-C. While I consider Java to be a verbose language, it looks like Python next to the antiquated C offshoot. Private methods, inner classes, anonymous classes, generics, better function syntax, and a much wider plethora of 3rd-party code are just a small smattering of the advantages of Java.
It’s no contest.
XCode vs. Eclipse
I used to love Eclipse. I could do my PHP, Ruby, Java, and Flex coding in one place. I could master one IDE and get benefits for whatever work I do. It’s been over a year since I had to use Eclipse in a daily basis (for Flex 3 programming), and coming back has been…
…a horrible experience…
I don’t know how it happened. Eclipse is bloated, slow, and the simple act of changing editor contexts (XML vs. Java vs. Android Manifest, etc.) is mind-numbing. It takes seconds. And before you offer, I’ve upped Eclipse’s memory and turned off auto-compile. Maybe my laptop is too old to handle it (about 3 years old), but it’s making for a *miserable* experience doing Android work.
Contrast this with XCode, XCode is a delight to work with. It’s sleek, lightning-fast, and I never see any slowdown when typing in code. I took XCode for granted for sure.
XCode in a landslide.
iPhone Simulator vs. Android Emulator
I’ve done both Java ME and BlackBerry mobile work, and I always liked the java ME emulator. It did what it had to do. So, when I met the iPhone Simulator, I was disappointed to see how little you can do with it. No GPS? No accelerometer? How hard could it be to add those emulations?
However, the Simulator does something better than I’ve ever seen. For one thing, it’s super accurate. I hardly ever see a problem in a device that I don’t see in simulation. It runs fast, I can shut it down whenever, I can reset it easily, I can change languages, and so on.
Android’s Emulator, on the other hand, is the worst emulator I’ve ever seen. It’s worse than BlackBerry’s — which is saying something. In both cases, they take a couple minutes to load up. With Android’s, you can keep it running and future runs start quicker, so that’s better. However, it feels flaky to me. Sometimes I run an app and it just doesn’t run anymore on the emulator and I have to restart the thing. The screen locking feature is awful…I don’t see why I have to unlock the screen on an emulator. At least give me an option to turn that off.
(UPDATE: It appears there is an option to turn that off, thanks to reader dootzky)
It’s also horribly slow. I once times an activity as taking 8 seconds to display. This may be related to my Eclipse issues as well, but it must be noted because I have *none* of these problems with iPhone development. Every Android developer I run into says they don’t even use the emulator anymore, opting to run the app on the device directly. It’s that bad. But, for god knows what reason, when you run on the device you get this obnoxious dialog asking what device to use.
What?
iPhone Documentation vs. Android Documentation
Both documentation systems are about equal in power. Each has their strong suite. I tend to favor XCode’s search, but Android has some better explanations for some things and shows inherited fields and such. It’s really a wash, though.
Call it a draw.
Overall
The Android platform does a lot of things you simply can’t do with iPhone. You have more control and the power of Java allows you to write stricter code that accomplishes these tasks with better software methodologies.
However, working with each one day in and day out, I’ll take the iPhone environment over Android — hands down. The sheer speed of XCode and your development cycle runs rings around Android’s more frustrating environment. That can still change in the future as tools are more maleable than platforms, but that’s the reality right now. And while there are options to use the NetBeans or IntelliJ environments instead, that’s only possible when not working with a team of people using the standard Eclipse environment already.
Would love to hear of your experiences.
I Miss Gaming Consoles.
I was lucky enough to grow up during the classic age of home game consoles. You go to the store, buy an Atari 2600, and for the most part it’s all you ever need. Sure, they had those wheel controllers which were great for Pong and Wizard of Wor, but the system was all-in-one. Original Nintendo? Loved it! The accessories were never required, the NES MAX was for sub-par gamers who needed help. I miss those days!
You know what pissed me off about the PS3? That for all it’s grandiose technology, it has completely fucked up the most basic and simple tasks. Look at this:
When I’m ejecting a disc or booting the system, I cannot turn it off! I’ve perfected the double press to get around this, literally hit eject and then a fraction of a second after hit power. If you wait just half a second, it’s too late. Why can’t I just turn off the damn system whenever I want? I have to sit there like a shmuck until it lets me.
When I merely (and most often accidentally) touch any button on the remote, the system turns on. This is mind numbing! I have to keep the remote out of the remote caddy because the buttons are too sensitive and, because the system runs at 1,400 degrees fahrenheit, if it turns on I must turn it off. BUT NO! I am not allowed to turn it off until it finishes booting! WTF?! (see above)
Why won’t the controllers recharge when the system is off? Are you kidding me? You expect me to keep the system on while I recharge? I’m certainly not going to play with the controller plugged in, the cable is too short. I find myself always recharging my controllers on my laptop because my laptop is smart enough to charge them while it’s shut!
Why is there no option to just boot right into the game that’s in the system? There’s an option to start a video or game automatically when it’s inserted while the system is running, but if you have a game in there already and boot the system, you have to go through the menu to start it. Stop wasting my time!
Why does the option to start a video or game force me to hit left 4 times and down twice and then Enter?? Starting a video or game should be one button! It’s what I intend to do 98% of the time. Why do you make it even less accessible that the pointless mailbox?
Now, contrast this with something like the original Nintendo Entertainment System. Let’s say I wanted to play a game. Oh, look, the cartridge is still in there from earlier today. I hit power. Game has started! DONE!
Perhaps I have to put it in first. Take cartridge, open door (whether system is on or not), slide in, press down. Hit power. Game on! DONE!
It’s very hard for me to look at (A) disc loading times that are getting longer with every generation of systems, (B) menuing systems on my gaming console with no ability to bypass quickly, and (C) game prices increasing to $60 and wondering if we’re really advancing. We should be going in the opposite direction.
My theory is validated by the fact that gamers are progressively more interested in $5 downloadable games on the PS3 and $0.99 games on their iPhones! BRING BACK THE CARTRIDGE SYSTEMS!
A Checklist for your Mobile Functional Spec
When constructing a spec for your client, starting from scratch can be a little painful as it’s very easy to forget the “boilerplate” functionality you need to know about. Here’s a little bootstrap to get you started on what you need to ask:
- Target Devices – What devices does the app need to run on? Does it require the hardware advancements of iPhone 4 (retina display or gyroscope)? Should it run on iPad? Must 1st gen iPhones and iPod Touches be able to run the app? Many of these answers logically lead to answers for the next question…
- Target OS – What minimum iOS should be supported? If 1gen hardware must be supported, you need minimum support for v3.1.3. If you don’t need to support that hardware, you can safely require v4.0. The iPad currently requires 3.2, but you can’t make an iPhone/iPad universal build unless you support v3.1.3. (This will soon change when iPad upgrades to v4.1.) The later the better. It’s not just about new API’s, but a lot of basic ones have been extended with useful stuff as well, including blocks.
- Orientation – Should the app support portrait or landscape? Do any individual screens have different requirements? This question helps determine how specific you can be with your UI design.
- Multi-Tasking Support – Does the app need to be able to run anything in the background? If the user leaves the app, do you expect them to continue from where they left off when they re-run it or should the app state reset?
- Local and Push Notification – Will the app need to support push notification from Apple? This necessitates how you create your provisioning profile. How about local notifications?
- App Size – Is there a concern about breaking the 20MB barrier for 3G download ability? A user may want to download an app while on 3G but be refused, possibly leading to them not bothering later. How large an app is a user willing to install or update? (Size is usually not an issue, but users may remove an app rather than update a 500MB app again.)
- App Iconography – How many icons and default screens need to be done? Do you need custom sizes for iPad, Spotlight, and iPhone 4? In what orientations are the default screens needed?
- Data Persistence – Will data need to be persisted? Should this data be SQLite or plists or NSUserDefaults or Core Data? Are there any other systems (or ports) that use SQLite already? What possible future functionality might be required? Use the simplest possible, but keep the future in mind.
And finally — what does the app do? Now you’re ready to rock! Investigate every last piece of functionality required for this app and leave no stone unturned. Everything you miss now will cause you delay later and possibly leaving you in a position where you never know when the app will be considered complete. Protect your contract and your sanity and take the time now to spec your app!
Is it Profitable? Ask Gorilla Mart.
I’ve been pondering lately — just how profitable is the iPhone?
We all know the stories, there are developers out there that had huge hits and pulled down millions in their success. Angry Birds, Doodle Jump, and we all love these stories because it inspires us to keep crafting. It actually reminds me of the American phenomenon where voters will actually back the interests of the very wealthy over themselves. It’s natural that we hope to be there one day. Only a tiny, tiny percentage of us will, however.
Rapture In Venice has been successul, especially lately. I’m now at a point where the work finds me, rather than me finding it. It’s nice not to have to sell myself…my own work does that for me. The question is, who else is profiting off iPhone development?
A little while ago I wrote a story about Gorilla Mart and, well, one whale of a project disaster. :-) It’s in the App Store now, and I got a chance to check on its sales figures today. Here are some jarring statistics:
- Gorilla Mart’s app downloads get in a week what my little Task List app gets in a day.
- Gorilla Mart’s app cost nearly $150,000 to create.
That’s a LOT of money! US dollars here. That went into UX designers, artists, software development (in many phases), project management, bug fix cycles, feature increments, and so on. And the downloads are pretty darn low for it.
So what happened? What happened, I believe, is that the urgency for the app eclipsed the desire for the app. There was no brilliant idea or driving force to make the app, the idea was retrofitted behind a business goal of merely having one. I think in these cases the user detects that. It’s not authentic, it’s forced. The work behind it isn’t passionate, it’s paid. It breaks no boundaries, its existence is merely for it to exist.
Task List, on the other hand, was a labor of love. I made it because I’m a very task list-centric human being. I write down *everything* I need to get done and that list motivated me to do it. None of the apps on the market satisfied me, so I sat down and merely made the app that *I* wanted. Not a single feature was for the benefit of anybody else. In the end, I created an app that has generated hundreds of downloads a day. I feel like my user base detects that labor of love.
Now, this isn’t about Task List. That’s merely a free, ad-based app I really expect no return on. What I’m referring to are the real successful apps out there backed by an indie developer who wanted to make their tower defense game reality because they believed in it, or the kids’ app maker who produced their Old MacDonald app because they knew their kids would love it!
Ultimately, the best-selling apps for iPhone are games. I believe that’s the case not just because the market loves to play games, but because you cannot possible force a game. The idea comes, it’s deemed a good one, and the team goes about making that vision happen. Writing a game is a lot of work, so you have to believe in it to do it. Nobody makes a game to satisfy a market “niche,” they just set about making a freakin’ cool game! There are no Gorilla Marts producing games, only game developers who know what’s cool.
Apps will fail and succeed. The ones born from a desire to make something great, regardless if it gets a single download, will ultimately shine. The user must feel the passion; the pursuit of excellence. And, in the end, those are the ones that become the most successful.
The best advice I can give is not to create an app just because you want to create one for the sake of it. Make an app because you WANT the app or NEED the app. If you need it, most likely a lot of other people out there do, too. This guarantees you’re not just competing with a competitor for a space. If you needed the app, and a competitor satisfies that need, then it’s not going to work out for you.
If you ever find yourself saying, “Hey, I have an idea, how about an app that lets you design bathrooms,” it’s going to fail. You don’t want it. You don’t need it. You likely have no domain knowledge to even make a decent one, let alone a good one. Just stop.
Create what you desire. Build what you want to see built, not what you *think* may sell. Only then can you make something great.
John Blanco
I've been writing mobile apps professionally for 10 years: Blackberry, Java, ME, iPhone, Android. I've gotten dozens of apps into the various App Stores for dozens of clients, big and small.
My current specialty is in iOS and Xamarin development. If you need an app written at a fixed price or just need a hourly developer to give a boost to your current team, I might be your guy.
Let's make an app!