App Development Before the iPhone

What it was like developing and selling phone apps before the iPhone.

For most people in North America the start of the app era begins in 2008 with the launch of the Apple App Store. However, the rest of the world was installing apps on tiny Nokia phones long before that.

So what was it like to write an app back then? Well the phones themselves had barely more CPU power than a CD player and the screens were really bad. Downloading apps was done over SMS via a random collection of third party stores. Despite all this, it was kind of a chance to relive the 8-bit era, and the limitations of the platform seemed to level the playing field between indies and big companies. So back in 2004 we ordered a Nokia 3100 for $65 from eBay and decided to give it a shot.

The J2ME Era

Back before Android and iOS, the dominant platform for phone apps was J2ME. It was basically a stripped down Java runtime and an attempt to standardize the capabilities of phones across manufacturers. That standardization didn't really work though, so you ended up testing your app on hundreds of phones, each with slightly different problems. Processing power and memory were also severely limited. We were working with a screen size of 128x128 pixels, a total available memory of 212K, and the entire app needed to fit in a 64K download. It was a lot like being back in the 8-bit days and programming for the Commodore 64, and we kind of loved it.

We decided to embrace the 8-bit aesthetic and write a classic Ultima-style RPG. Our goal was to make the biggest game that could fit inside the memory and storage limitations. Ultimately we managed to fit almost 20 hours of gameplay into a total download size of 63.8K - 200 bytes to spare! Here are some of the tricks we used to fit everything in such a small package:

  • Don't store dungeon map data, instead include the map generator algorithm and store a bunch of good random seeds. Then each map only uses a couple bytes in the app bundle (plus the size of the generator code, divided over all maps).

  • It turns out that each Java class costs a few hundred bytes in header data. We ended up cramming everything into a couple classes to save that overhead.

  • Java methods have a similar overhead, so we made every variable that needed external access public.

  • We also packed all the icons for the game onto a single tile sheet and reduced the colors down to 32 colors total.

Behold, the tileset and finished game of "Gurk" in their original sizes:

(We ended up porting the game to Android if you want to try it out. It's still only 96K, maybe the smallest game on the Play Store? We could have kept it at 64K if Android didn't make us include an icon. It's available for free on the Play Store.)

We were really happy how the game turned out. It was a huge world that you could explore on your tiny phone whenever you had a spare minute. Here's the PDF we made describing all the features. However, we found out the reality of actually selling the game to players was another thing entirely. Back then you needed to do deals with all the different stores and many of them required you to pay a large up front fee. For example, Motorola wanted a $5,000 "developer registration fee" just to get started. No thanks!

The Sidekick

While trying to find a place to sell our game we met the people at Danger, makers of the T-Mobile Sidekick (officially called the Hiptop, but mainly known as the Sidekick in North America). They had created what seemed to be a fully modern App Store and the phone itself was really advanced too. Apps for the device could be an "enormous" 200K in size, and we had access to megabytes of memory. It definitely felt like a next level platform.

The only problem being that the app store team was totally uninterested in our RPG. They wanted us to write something specifically for the Sidekick, and not just port over our little J2ME game. We were reluctant to throw away all the work we had put into the game, but after some experimentation we found that the Sidekick had some impressive audio capabilities. Because of that, we threw out the RPG and wrote a drum machine which became our first successful release for Sidekick. We went on to write many more music apps, some screenshots of which are below:

As we got more experience with the platform we started making some pretty advanced stuff. For example, here's an entire song written in our multi-track midi music workstation, Kick Synth:

So what was it like developing apps in 2005 for the Sidekick? Overall it was pretty awesome. The SDK felt modern and really got the tradeoff right between simple APIs and powerful low level access. We eventually met the audio engineers at Danger and they said we were the first (and possibly only) apps to use the low level audio APIs, but they had included them hoping someone like us would come along.

That kind of developer empathy was visible throughout the SDK. The UI system was both powerful and very quick to work with, the low level drawing APIs were great and the build system was simple and effective. Somehow this roughly hundred person company had designed phone hardware, built an operating system, an optimizing compiler, a JVM, and a full app SDK. Then they took that SDK and built a whole suite of full featured apps for the phone including a web browser, email client, app store, AIM client and so on. It was pretty incredible. A number of these people went on to start Android and create the most widely used software in the world, but the building blocks and the evidence of talent was already very visible in the Sidekick.

Some things that were included in those early Sidekick SDKs are just now being added to modern mobile operating systems:

  • A fully disconnect-resistant networking stack that made it easy to handle connection problems.

  • Automatic user data backup for apps to "the cloud" (it was just called "the backing store" back then)

  • Built in device-to-device messaging for apps. You could easily send a message with a payload from one user to another with your app. It was possible back then to write an entire messaging app without having a server.

The main downside to the Sidekick App Store was that both the team at Danger and someone at T-Mobile had to approve every app in the store. This frustrated some developers so much they stopped working on apps entirely. The solution we ended up with was to submit so many ideas that if even half of them got approved we would have a ton of apps to write. That system led to us writing over 40 apps for the Sidekick, many of them shown in the screenshots above (more details available over here). It was the reason we incorporated Larva Labs as a company and it was the thing that ultimately let us quit our jobs and go independent.

This month (October 2017) happens to be the 15 year anniversary of the first T-Mobile Sidekick. It's pretty safe to say we wouldn't be where we are now if we hadn't discovered the Sidekick. Thank you to everyone who made that possible at Danger and happy anniversary!