1ft Startup

There are two major real-world reasons that the shoestring development world for mobiles is rather more difficult than traditional startup software development:

1. Broad phone support is nigh-impossible on a low budget.
   
   First of all, any BREW phones are right out the window: Qualcomm’s BREW platform is prohibitive to small fries, because they have a strict, expensive testing process for any app to be ‘approved’ for a particular handset/carrier, and customers with BREW phones can only install apps that their carrier makes available. This means you’ll need to recoup thousands of dollars in testing costs, as well as hire someone to manage carrier relationships (or do it yourself, you poor bugger). This model effectively cuts out everyone who’s working from a garage, or anyone who wants to give their app away for free.
   
   So that leaves us with Java ME as the other major platform. Java ME is, of course, sweetly intended to be a “Write Once, Run Anywhere” platform, but the KVM authors are all have their own eccentric disloyalty to the spec. This is the kind of thing that an outside observer wouldn’t believe to actually be a hindrance these days, I mean, it’s the year 2000 and hey, we’ve got flying cars! Alas, it’s truly amazing how cracked out some implementations can be. Coding errors aside, there are intrinsic differences in the handsets’ actual, physical capabilities anyhow: Screen dimensions, resource constraints, whether the phone has a Clear key, etc. These attributes must be addressed across thousands of devices regardless.
2. People buy new phones more often than they buy new underwear. This is really an amendment to the first statement, because it causes two sub-problems:
   1. Your app may not work on their new device, and therefore:
   2. You must test new devices eternally.

   You can still install a good chunk of shareware from the Windows 95 days on a new Vista install without much trouble. Even if you couldn’t, it seems that the replacement rate of phones far outstrips that of computers (though I don’t have numbers for that one… lazyweb?), so people are likely to be making better use of their older apps and older OSs on their computer than on the phone.
   

In this environment, it’s extremely unlikely that we’ll see something similar to the runaway successes that we’ve seen in shareware, selling apps and games that scarcely need updating in a decade to keep doing well for themselves. While the shareware makers on the desktop are kicking back on their porch sipping lemonade and responding to fanmail, all us mobile indies have got the Sisyphusean task of sneaking into the Cingular store to test our apps on the hottest new Nokia.

I hate to leave off here on a down note, but I will be back soon with the more interesting upsides, and how to get rid of at least some of the pain that plagues us.

I just gave a J2ME Game API workshop to Michael Sharon’s excellent Mobile Application Design class over at NYU’s ITP program. We walked through the best practices behind creating an old-skool side-scroller game. Talk notes and source from the game we put together can be found here.

There are two major things that make mobile software development vastly different and more frustrating than development in other industries. These hindrances are holding the whole sector back, and really, it’s in everyone’s best interest to smooth the development path for mobile software, both for WAP and downloadable applications.

Carriers need to learn how to let go.

Remember Prodigy, and the good old days of AOL? The carriers do, and they’re totally in love with the “walled garden” style of trapping a user in their own universe. Carriers still want to control all of the mobile content that the user sees, buys, and uses. This goes both for the mobile web and for downloadble applications. This has a couple effects:

• Users are given limited choices. Obviously. But this means that it’s very hard for the industry to grow organically. You’ll hear over and over again that “nobody knows what works yet” in mobile, and this is largely due to the fact that it’s extremely difficult to get the audience to try new things. What the user sees and gets is dictated from the top down.
• Mobile software companies depend hugely on carrier relationships. The success of your game/application depends a lot less on free market capitalism and how good your product actually is, and much more on how strong your relationships with the big carriers are.

Handsets need to obey standards.

There’s a terrible tension between the need for software and browser compatibility across multiple handsets, and the need for handsets to distinguish themselves from others in the market with wacky features. That’s not to say that Nokia or Motorola should stop making phones with peculiar geometry or features nobody else has, but they need to do so without requiring developers to bend their code to fit into yet another sub-model. A single phone represents a fraction of a percent of a developer’s user base, so maintaining so many SKUs quickly becomes unmaintainable.

Java ME needs to stabilize. Porting games and apps — that is, making a mobile app work across multiple handsets — is an awesomely frustrating chore. There’s a special room in hell where you have to port Java ME apps to support handsets full of undocumented bugs. From this torture has risen a thriving cluster of small startups that specialize in porting, who have knowlege of the handsets’ different capabilities and bugs and retool code that works well for one phone to work against three dozen other phones. Those shops often rely on a third-party database of undocumented phone capabilities, another mini-industry built on the inefficiencies of the mobile space. A big part of the promise of Java is supposed to be that “write once, run anywhere” feel-good feeling, and maybe with the exception of varying graphics sizes for different screen sizes, it should. Full-time porting jobs should not exist! But they do, and they probably will continue to for a few years. It must be said that BREW is much better in this respect; it doesn’t hurt that Qualcomm is the tightly-controlled central source for the firmware.

All of this is sort of a crying shame for a technology that should be so much farther along than it is, but it also presents a neat, obvious opportunity to people willing to move it forward. The silver lining for the United States is that our backwardness and slowness has given us two crystal balls into the future of mobile: The internet, and the rest of the world’s mobile industry. You can guess some things about the future: Walled gardens will give way to third party portals, and as more site come online and cross-connect to each other, search engines will become more useful and the portals will become less so. The greater the connectivity capabilities, the better the apps — and we can watch the huge successes half a world away that will likely be repeated here in two more years. The industry is moving, fast, and everyone (even the carriers, in their own weird way) seem to recognize this situation and are working to move everyone out of the darkness, and soon, this mini-rant will be obsolete.