Musings from The Software Underground

There's been a ton of speculation and opinion floating around about the forth-coming SDK for the iPhone, what development will entail and how iPhone apps will be distributed.

Development

I personally can't wait to write code for the iPhone. I actually wrote code for the Newton before I had ever written a single line of code for the Mac, so my handheld roots go back pretty far. One thing that has to be remembered when writing code for a handheld is that, in all cases up to this point, writing for a handheld is not the same as writing for a desktop. There is not going to be as much available to you, as a developer: there is less memory, less processing power, less screen space, and usually less functionality (to keep things simple).

Craig Hockenberry's excellent recent post (So you’re going to write an iPhone app…) on writing a native iPhone twitter app (using a "jailbroken" phone), MobileTwitterrific, bears this out. What Craig describes doesn't surprise me at all, and I think his account is probably pretty close to what we'll see from the SDK. The gist of his findings is:

• Don’t expect to reuse much of your existing code.
• You’re given approximately 64 MB of space to work with (about half of what’s available.) If you go beyond that, Springboard shuts you down unceremoniously.
• There are no NIBs. None.
• Don’t think that your desktop and mobile application will share any look and feel.

From what he's discovered already, we won't have Interface Builder, nibs, etc., but I think that's fine. User interfaces, if the existing iPhone applications are any indication, are pretty simple and are pretty limited in their layout anyway. Granted, not having a way to easily lay out a form, and having to do it in code won't be as simple as what you might do when making a Mac application, but that will also have a way of forcing you to keep things "light" and simple. iPhone applications are not going to have a lot to work with. They will be limited in how much memory they will have access to. You will also not want iPhone applications loading lots of user interface elements unnecessarily. I learned lessons like this when I developed applications for the Newton, and the iPhone won't be any different I'm assuming.

Distribution

So, once you've written that killer iPhone application, how will you distribute it? Most speculation falls into the "iTunes store" realm.

From Wired:

It will also turn iTunes into a software store, because Apple will probably use iTunes as the primary distribution vehicle for what's likely to be a massive community of iPhone software developers. In so doing, it could usher in a new way of buying low-cost software that's both easier and faster than downloading shareware or purchasing shrink-wrapped boxes.

I, for one, expect that, and welcome it. I don't think that some of the concerns people have voiced are "stoppers" for anyone who wants to develop iPhone apps. Pricing will probably be low, which should be fine. iPhone applications in general will probably not be the "behemoth" applications that a typical desktop application is in general, and will be priced accordingly. iPhone apps SHOULDN'T be like their desktop counterparts and SHOULD be simpler, so the speculated pricing isn't off putting to me, because think of the potential volume. Not everyone agrees:

From Infinite Loop:

This presents two problems. If Apple dictates the price at which applications can be sold, then Apple dictates the percentage of the sales that the developer takes in addition whether their application is featured, or even listed. Developers might be motivated to only make their apps worth $4.99. Those truly robust, worthwhile applications might never be made, or only be available to jail-broken iTouches or iPhones.

I don't think this is a valid fear. Honestly, it think this comment shows a fundamental misunderstanding of how we as developers work. We don't create things based on their "worth" but on fulfilling what we perceive as a need, and fulfilling it in the best possible way.

Another bit of speculation is on what Apple's cut of each sale will be. We don't have any idea what that would be yet, in an "iTunes store" distribution scenario, but whatever it is, you have to figure it will be reasonable. You also have to understand that Apple will be providing to you a high-quality buying and distribution experience. As a developer, you won't have to set up your own storefront, distribution etc. What's that worth to me, as a developer? A LOT. The way I figure it, whatever their cut, I'll more than make up for it in sales because they'll provide more exposure and a better means of distribution than just about any indie developer could get on their own. That's highly valuable. The less work I have to spend on things like this, and the more time I get to spend writing application code, the better, at least as far as I'm concerned.

What about speculation that Apple will have to "approve" applications for the platform? I fully expect this, how could they not? I'm not sure if "certification" will include code "reviews" or submissions (I kind of doubt it). More likely is a suite of tests all applications will have to pass to prove that they will "play nice." Apple is all about a "quality" experience for the end user. Unlike a desktop Mac, a handheld can be much more of a "closed" system and I expect that Apple will keep things that way. Does this limit who can and will develop for the iPhone? Yes, but I'm not sure that in this case, that this is a bad thing.

One big question is "how will we provide demos?" Will be even be able to? Will buying iPhone apps be like buying shrink-wrapped software? It's possible that "demos" will actually be an easy return policy. Buy the app, but if you don't like it, just ask for a refund.

Vs. Developing for Google's Android

Finally, some people may ask, "Why even develop for the iPhone at all, when there's Android?" Well a lot of us, as developers for Apple products, develop for Apple products because we believe that Apple makes the best platforms to develop for. The existence of Android doesn't really change anything. I see Android as being more of a replacement for Windows CE/Mobile/whateveritiscallednow than a competitor for the iPhone SDK. As we've seen before, it's about developing for one, focused platform, or many, diverse platforms, and any iPhone SDK vs. Android battle doesn't change this at all. By many indications, developing for Android is not exactly a picnic, and think about the application design process: you could have no idea what platform you are really developing for. It could be a compact Nokia with a small screen and limited resources, or a smart phone with a larger screen and more resources, but you might not have any idea. The alternative is to pick only certain targets, but then how is that better than developing for the iPhone instead? I'll put my money on the iPhone thanks.

All this being said, I can't wait to see what is unveiled by Apple, supposedly by the end of this month. I'm hopeful that we'll be allowed to write 1st-class iPhone applications using Objective C, with all the goodness inherent, and a slimmed down version of the frameworks we're used to using to build applications now for Mac OS X. Time will soon tell.