Mobile Apps: What Every Business Needs to Know
A decision framework for whether to build a mobile app in early 2008, when distribution meant fragmented carrier decks and Apple's SDK was still just a promise.
In February 2008, “building a mobile app” meant something far messier than it does once an app store exists to browse and install from. There was no App Store yet. Apple had said back in October 2007 that it would release an SDK allowing outside developers to build native iPhone applications, and had pointed to sometime around February, but nothing had shipped by the time this was written. For every other phone, the picture was already fragmented: Java-based apps (J2ME) for a wide range of handsets, BREW apps for Verizon’s network, native BlackBerry apps aimed squarely at business users and Windows Mobile applications for the smartphones built around Microsoft’s platform. A business weighing whether to build something needs to understand what it was signing up for.
What building an app meant in early 2008. Without a unified store, distribution ran through carrier decks (the menu of downloadable content a wireless carrier put in front of its own subscribers), direct downloads from a company’s own site or install links emailed to customers. Each path required its own approval process, its own technical format and, in the case of carrier decks, often a revenue split and a listing fee just to get placed at all. Testing across handsets was its own burden, since screen sizes, processors and input methods varied enormously between manufacturers.
Who this made sense for. Businesses with a customer base already carrying BlackBerry devices for work, banks, logistics companies, sales-driven businesses with a mobile workforce, had a much clearer case for a native app in early 2008, since BlackBerry’s app ecosystem was mature and its business-focused user base was a known quantity. A consumer retailer trying to reach the general public faced a much harder calculation given how scattered that audience’s devices were.
Why waiting had a real case too. Apple’s iPhone had shown, in under a year on the market, how much of an audience a well-designed device could pull toward itself, and the company’s own signals suggested a native app platform for it was coming soon. A business betting heavily on J2ME or BREW development in February 2008 risked building for a landscape that could shift meaningfully within the year if Apple’s promised SDK opened a large, concentrated audience that hadn’t existed as a target before.
Questions worth asking before committing. Does a meaningful share of your customers carry smartphones today, since feature phones with no real app capability still made up the majority of handsets in early 2008. Is the problem you’re solving suited to an installed app, something needing offline access or hardware features, or would a well-built mobile website solve it just as well without any of the distribution headaches. And can your business afford to build for one platform at a time, rather than trying to cover BlackBerry, Windows Mobile and J2ME simultaneously with a small team.
The pragmatic middle ground. For most businesses without an obvious BlackBerry-carrying customer base, the more defensible move in February 2008 was investing in a solid mobile website rather than a native app, while keeping an eye on what Apple’s promised developer tools would look like once they shipped. A business could always build a native app later; a badly timed one, built for a platform that fragmented further or lost relevance, was much harder to walk back.
The honest state of mobile apps in February 2008 was a landscape in transition, useful for a narrow set of business use cases already, and worth watching closely for anyone whose customers were starting to carry smarter phones.
Keep exploring: browse more Marketing Strategy guides, see everything we published in 2008 or check out the Digital Business Marketing Awards.
