As noted by Craig Hockenberry, it has been a full decade since Apple shipped the first version of the iPhone SDK to developers.

It’s hard to remember today that, in the beginning, the iPhone didn’t have third-party apps. It came with a handful of built-in apps written by Apple for things like checking stocks and the weather, jotting down quick notes, making calendar events and reviewing contact information.

These apps were, for the most part, self-contained. The rich environment we enjoy on iOS today where apps can share lots of data with each other just wasn’t present in 2007.

The outlier in this paradigm was Safari, which put the Internet — or at least the parts that didn’t require Flash — in the palm of our hands.

This made Safari the iPhone’s only real opening to the outside world, and I believe it was the most important app on that original iPhone.

At WWDC 2007, just a few weeks before the iPhone went on sale, Apple told a room full of Mac developers that the way to write apps for the upcoming device was via Safari. Here’s John Gruber on the topic:

Perhaps it’s playing well in the mainstream press, but here at WWDC, Apple’s “you can write great apps for the iPhone: they’re called ‘web sites’” — message went over like a lead balloon.

He continues:

Telling developers that web apps are iPhone apps just doesn’t fly. Think about it this way: If web apps — which are only accessible over a network; which don’t get app icons in the iPhone home screen; which don’t have any local data storage — are such a great way to write software for iPhone, then why isn’t Apple using this technique for any of their own iPhone apps?

Or, take Apple’s argument regarding iPhone development and apply it to the Mac. If web apps running in Safari are a great way to write iPhone apps, why aren’t web apps running in Safari a great way to write Mac apps?

If all you have to offer is a shit sandwich, just say it. Don’t tell us how lucky we are and that it’s going to taste delicious.

Ouch.

Thankfully, this wasn’t the case for long. As soon as iPhones were in the wild, developers — including Hockenberry — were hard at work figuring out what made it tick, and what it would take to run software on the device. After all, the iPhone’s operating system¹ was based on Mac OS X, meaning it was a familiar environment to Cocoa developers.

That’s not to say that there weren’t some impressive web apps built for the iPhone. Web developers did some really clever things in those days, but web apps could never be as rich or as powerful or as nice as honest-to-goodness native apps. Apple may have called web apps a “sweet solution,” but it just wasn’t meant to be.

In October 2007, Steve Jobs published an open letter on the subject:

Let me just say it: We want native third party applications on the iPhone, and we plan to have an SDK in developers’ hands in February. We are excited about creating a vibrant third party developer community around the iPhone and enabling hundreds of new applications for our users. With our revolutionary multi-touch interface, powerful hardware and advanced software architecture, we believe we have created the best mobile platform ever for developers.

It’s come out in the years since that Jobs wasn’t in favor of this plan, but was persuaded that it was the right call. His letter goes on:

It will take until February to release an SDK because we’re trying to do two diametrically opposed things at once—provide an advanced and open platform to developers while at the same time protect iPhone users from viruses, malware, privacy attacks, etc. This is no easy task. Some claim that viruses and malware are not a problem on mobile phones—this is simply not true. There have been serious viruses on other mobile phones already, including some that silently spread from phone to phone over the cell network. As our phones become more powerful, these malicious programs will become more dangerous. And since the iPhone is the most advanced phone ever, it will be a highly visible target.

On March 6, 2008, Apple took to the stage to unveil the SDK.² Here’s a bit from Jason Snell’s live blog, quoting Scott Forstall:

“Starting today we’re opening up the same APIs and tools that we use to develop our own applications today. Now, there are a lot of pieces that make up an SDK. But the most important are the APIs and the platform. And we have a great one, Mac OS X.”

He went on to outline the layers that made up Mac OS X: Core OS, Core Services, Media, and Cocoa.

“To build the iPhone OS, we took the bottom three layers and moved them across. Now Cocoa is interesting… it’s the best application framework out there, but it’s based on a keyboard and mouse.”

Cocoa Touch was the name given to the new framework, and it enabled developers to work with familiar tools for an all-new platform. They could use numerous core services to use things like the Contacts database or Photos library on the device, and tap into Apple’s rich media stack to make their apps flexible and powerful.

Development was done in Xcode, just as it was for Mac apps, for both regular and apps and games. Apps could be run directly on an iPhone, or on the host Mac via the new iPhone emulator.

To say that people were excited to get their hands on the SDK is an understatement. Anyone could download it and start writing an iPhone app, no matter their background or level of experience.

I spoke to David Smith, developer of Workouts++, Pedometer++ and other fine iOS and watchOS apps:

“The funny thing about the original SDK is that I had no idea at all about Apple development. So I just dived in and tried to hack things together. It wasn’t until much later that I knew enough to see where it was limited or basic,” he said.

While a lot has changed in the last decade, Smith praised UITableView for aging well. “That was the crux of most of my early development and it still is a lot of it to this day,” he said.

Russell Ivanovic, developer at Shifty Jelly, the home of Pocket Casts and Pocket Weather, was new to developing on Apple’s platforms as well.

“I’d never done any Mac development or even seen Objective-C. Interface Builder felt more primitive than what Microsoft had at the time, but some of the components like UIScrollView and UITableView felt like they came from the future. They were so fast and easy to use it was incredible,” he said.

There were, of course, some pretty severe limitations in the initial version of the iPhone SDK.

The first release lacked some of the tools Apple had previewed, as Marco Arment, developer of Overcast, reminded me.

“The first version of the SDK lacked Interface Builder and Core Data. I got started on Instapaper’s app immediately, and since those tools weren’t there, I just taught myself to do interfaces and data persistence manually. They were both added to the SDK within a month or two, but I never went back to re-learn them because I’d moved on to other parts of the app,” he said. “To this day, I do almost all of my interfaces in code, and I don’t use Core Data.”

Developers who were new to the Apple way of doing things found it difficult to discuss their development with others.

For the first several months it existed, the iPhone SDK was protected by a strict NDA, as Chris Foresman wrote about in July 2008:

The NDA made a degree of sense during the SDK’s beta period, since the API and documentation were in flux and nondisclosure could keep inaccurate information from being published. One of Ars’ own staff members noted, however, that the potential for bugs and mismatches between documentation and the actual API means that more developers are facing the same stumbling blocks during the beta period. Those developers are used to solving such problems by taking advantage of online forums, blogs, IRC channels, and mailing lists to get help with problems; the NDA prevents any of that.

In fact, there were no books, seminars, or conferences on how to build iPhone apps until after the NDA lifted.

Apple relaxed the NDA in the fall of 2008, but it took some time for developers to become comfortable with talking about the SDK and related technologies.

The tools were primitive in places, and there were limitations when it came to apps that wanted to do phone-like things over EDGE. For example, VOIP apps would be permitted, but were restricted to working just over Wi-Fi. It was implied this as a bandwidth problem, but many raised their eyebrows at AT&T and other carriers over this.

Perhaps the primary complaint was the utter lack of multitasking for third-party apps. A handful of Apple’s own apps, including Phone, Mail, Safari and iPod, could run in the background, but that was it. Any other app had to be in the foreground, active on the screen, to be running. Tapping the Home button would exit the app as it faded from view.

This was before the era of push notifications, so there was no way for an app to wake up or receive new information. This meant some apps, like instant messaging clients, were a bit frustrating to use.

John Gruber explained why this was the case:

Why has Apple imposed this limitation? Easy: the iPhone is severely resource constrained. Battery, RAM, and CPU cycles are all severely limited. If third-party apps could run in the background, all three could suffer. RAM would suffer for sure; all running apps consume memory. The iPhone has just 128 MB of RAM, and no swap space. CPU performance and battery life would suffer when background apps do something — and if they’re not doing anything, what’s the point of keeping them running? I noticed a significant increase in battery life after I switched the Mail app’s auto-checking interval from 15 minutes to 60 minutes. That’s just one app.

This would get better over time, but is perhaps the thing that struck me as feeling the oldest while revisiting these materials.

It’s been a long ten years since the first iPhone SDK, but there’s no doubt that it ushered in the age of apps we now enjoy. We often think about Apple products as being able to change the world, but in the iPhone’s case, that was made possible thanks to a set of development tools.