A lot of work goes into making an app. First, you have to come up with an idea. And not just any idea, your idea should be unique and fun if you want to make it big. Then, you have to put days, weeks, and months of work into development. Unless, of course, you were thinking about paying someone else to do it. In this case, your wallet would be feeling the pain instead of your brain. Finally, after you have chosen a price and done some competition research, you still have to pick an app market.
To give us some background and experience on the topic, we have invited Dave Howell, Founder and CEO of Avatron Software, to an interview on the topic of app development. Although the discussion is one-sided due to the fact that he is an iOS and Mac app developer, his company develops apps for Android, iOS, Mac, Windows, and Samsung Bada.
I have been a Mac app developer since 1987, when I got my first job out of college writing MIDI software. Since then, I’ve done software engineering at a number of software companies, and did contract engineering for 8 years. My last contract client was Prismo Graphics, which was acquired by Apple in 2002.
I followed Prismo Graphics to Apple to turn that last project into an Apple app called LiveType. I also contributed to the iWork team on Numbers, Keynote, and Pages, and managed a visual-effects SDK called FxPlug. While at Apple I earned an MBA from Cornell, and in 2008 left to launch a startup called Avatron. I hired some other engineers and we built our first app, Air Sharing.
I had planned to seek funding for Avatron. But Air Sharing was a hit from the start, with over a million downloads in the first week. So four years later, we’re still self-funded, profitable, and growing.
Air Sharing is a document viewer app that lets you view, manipulate, and print many kinds of documents. It also lets you connect to file servers like Dropbox, iDisk, Box.net, FTP, SSH, and many others.
Print Sharing is a spin-off of Air Sharing, taking just the printing feature of Air Sharing and presenting it in a very simple workflow for printing documents from almost any app.
Our most popular app is Air Display, which turns an iPad, Android tablet, or Mac screen into an extra monitor for another computer. We also have a Windows version of Air Display coming soon.
Personally, I’ve developed for Mac, Windows, Sony Playstation, and iOS. At Avatron, we’ve produced apps for Android, iOS, Mac, Windows, and Samsung Bada.
These are all very visual platforms. And they’re all popular.
iOS is both the most mature and most successful platform we develop for. Our sales on iOS are about 40x more than on Android, for example. I believe that people just don’t buy Android apps. They pirate them or download the free stuff.
There are no open mobile platforms. iOS is built on BSD Unix and the open-source Darwin, but there are proprietary layers on top of that. Android is built on Linux but lacks transparency and community. Unless you jailbreak your iPhone or root-hack your Android phone, it’s not open. And all of the mobile platforms are hampered by the closed carrier networks.
But that said, we don’t really care whether iOS or Android are open, except for the sheer blood-sport of arguing about it. We’re in business to create great apps, not to participate in a community. We care about delighting our users and about product quality. Everything else either is a means to those ends or a hobby.
The many form factors of Android devices isn’t so bad for us. This is something we’re used to from Mac and Windows. It does prevent us from designing pixel-perfect user interfaces for Android. We can’t hand-draw UI treatments for every possible permutation of physical device parameters. So we hand-tune our iOS interfaces and adapt to dynamic runtime conditions on Android, Mac, and Windows.
Developing for Android will be worth it when people start purchasing apps on it. Until that time, Android will always be a platform that we port to, but not a platform on which we’ll develop new apps.
I started out on a PDP 11/40 minicomputer at a local university when I was 13. The Radio Shack TRS-80 was coming out then. The Commodore 64 was a few years away. But the Apple II was the prominent machine at the time. Microsoft was incorporated four years later, so they weren’t a player. Google’s co-founders were four years old then, so I didn’t see Android coming.
Developers follow the money. At the moment, we can’t build a business writing Android apps. If that changes, we’ll be more likely to start with Android, or develop concurrently for iOS and Android. But for now, it takes us roughly as much work to write Android apps as to write for iOS, but Android yields a tiny fraction of the sales volume.
I actually expect Microsoft to be a contender eventually. The only two big companies around with any significant experience developing platform-wide SDKs and maintaining them over decades are Apple and Microsoft. Google’s inexperience here will bite them as they thrash their SDKs, deprecating and introducing rapid changes that would have made sense on the web for their own internal development teams but are @#!*% on app developers.
The TRS-80 and Apple II both used BASIC, just like the PDP-11, so it was pretty easy to make the transition. And you could fully specify the SDKs in a few pages.
I still haven’t done this. It’s a target, not a destination. You can’t master it.
Think grand and ambitious. Have some big wonderful system that you’d like to deploy in a few years. But for v1.0, spend some time defining a piece that you can bite off. Make sure that single piece solves some problem completely. Make it beautiful and polish all of the edges. Don’t ship until it’s beautiful.
Make sure users are rarely disappointed by finding limitations, but are often delighted by finding unexpected refinements and stumbling upon unnecessary elegance. Encourage them to explore, to think, “I wonder what would happen if I tap this or drag this?” You want them to feel safe in the knowledge that they can’t break your app by doing things you didn’t think of.
The only way to do this is to define a problem scope that fits your schedule and the capacity of your engineering team. If you are too ambitious in 1.0, you will have some of the features only 80% done. It’s always better to have three features 100% done then a hundred features 90% done.
And good luck!