The iPhone SDK and App Store Turn a Closed Device into a Software Platform

The original iPhone shipped in June 2007 with powerful Apple-written applications but no supported way for outside developers to install their own native code. Less than thirteen months later, Apple opened the App Store with more than 500 native applications, a development kit based on the company’s own tools, wireless purchasing, centralized updates, and a revenue-sharing system. That combination transformed the iPhone from a closed product with web extensions into a controlled software platform.

The word controlled is essential. Apple did not simply publish programming interfaces. It joined development tools, cryptographic signing, operating-system isolation, editorial review, payment, discovery, and distribution into one system. Developers gained capabilities and a worldwide route to customers; Apple gained durable power over the conditions under which native software reached its devices.

The 2007 answer was the web

At the iPhone’s introduction, Apple did not promise a public native software development kit. In June 2007 the company instead announced support for third-party “Web 2.0 applications.” Developers could build sites that used Safari’s standards and invoked selected phone services, such as starting a call, composing email, or showing a location in Google Maps. Updates happened on the developer’s server, so users did not install an executable package.

This was not literally an absence of third-party software. A capable web application could provide email, news, productivity, or data services, and it avoided device-level installation risks. But it could not match native access to graphics, storage, sensors, offline execution, or the iPhone’s interface frameworks. Developers also created unofficial native software through jailbreaking, demonstrating demand while bypassing Apple’s supported security model.

Apple’s initial web-only position is sometimes retold as a permanent refusal overturned by surprise. The timeline was faster. In October 2007, Steve Jobs announced that a native SDK would arrive in February 2008, saying the company was trying to protect users from malware while enabling development. The preview ultimately arrived on March 6 rather than in February.

The SDK was more than an API list

The iPhone SDK beta gave developers Xcode for source editing and debugging, Interface Builder for constructing interfaces, Instruments for performance analysis, and a simulator for testing without a device. Cocoa Touch exposed the frameworks Apple used to build native iPhone applications. Developers could work with the multi-touch display, accelerometer, location services, networking, media, and hardware-accelerated graphics under documented rules.

Native access made entirely new classes of mobile software practical. Games could use touch, tilt, sound, and three-dimensional graphics. Business applications could work with locally stored data and enterprise services. Medical, travel, social, and reference tools could integrate location or function offline. The July launch catalog covered all of those categories rather than just reproducing desktop utilities on a small screen.

The simulator was not an emulator of every hardware characteristic, and native access was never unlimited. Frameworks mediated what an application could do. Private interfaces were off limits, background execution was severely constrained in early releases, and sensitive capabilities depended on entitlements. The platform promised substantially more power than the web while reserving system authority to Apple.

App Store distribution was the second half of the product

A toolkit alone would not have produced the same market. The App Store let a customer select software on the phone, charge a paid application to an existing iTunes account, download it over Wi-Fi or cellular service, and receive update notifications. It was also available through iTunes on a Mac or PC. Apple announced more than 500 applications for launch on July 10, 2008, including over 125 offered free of charge; ten million downloads followed during the first weekend.

Apple initially made the store available in 62 countries. Developers set a price or chose free distribution and retained 70 percent of paid sales revenue. Apple kept 30 percent while providing hosting, billing, storefront presentation, and delivery. Free applications did not generate a per-download fee. The model dramatically reduced the work required for a small developer to collect payments and reach international customers.

It also changed discovery. Before centralized stores, mobile software often moved through carrier portals, manufacturer catalogs, download sites, or desktop installation tools. Compatibility, payment, and trust could vary by handset and network operator. The App Store put one searchable catalog directly on every supported iPhone. That convenience concentrated attention: placement, rankings, search results, categories, and approval now affected whether a developer could find a market.

Security came from several layers, not review alone

Every supported third-party native application had to be code-signed, allowing the operating system to verify its origin and integrity. Applications ran in sandboxes that limited access to other apps and system resources. Entitlements represented approved capabilities. The operating system, not a human reviewer, enforced those runtime boundaries.

Store review added a separate layer. Apple could reject software it considered malicious, unstable, privacy-invasive, technically inappropriate, or inconsistent with content and business rules. Review could catch behavior before publication and provide a response mechanism after complaints. It could not mathematically prove an application harmless, and signed code was not automatically good code. Security resulted from limited privilege, platform design, review, updates, and Apple’s ability to revoke distribution—not from any one gate.

The architecture narrowed common installation paths for malware because ordinary users did not download arbitrary executables from websites. It also made Apple the adjudicator of software legitimacy. A rejection caused by a technical defect and a rejection caused by a commercial policy had the same practical consequence: the developer lost access to the default retail channel.

“Only through the store” needs qualifications

Consumer distribution centered on the App Store, but the original program contained controlled exceptions. Enterprises could distribute internal applications to employees, and developers could install builds on registered devices for development and limited testing. Later tools expanded beta testing. These routes did not create a general public alternative store; they served identified organizational or pre-release uses under Apple’s certificates and program rules.

Web applications also remained available without store approval. They offered an open distribution route but operated within browser capabilities rather than possessing the same native privileges. The platform therefore did not divide neatly into “store or no software.” It divided capabilities and audiences among Apple-reviewed native distribution, restricted signed exceptions, and the web.

That distinction still structures policy debates. Sideloading concerns whether a user can install native software outside the platform owner’s store, not whether the browser can load a website. Alternative payment concerns who handles a transaction, not merely whether an application is free to download. Commission arguments concern the bundle of distribution, payment, discovery, and platform access rather than the cost of a file transfer alone.

The bargain changed mobile economics

For developers, the platform reduced fragmentation across carriers and payment providers and exposed a large installed base through one account system. Small teams could sell globally without negotiating shelf space. The immediate download numbers showed that customers were willing to treat a phone as a device whose functions expanded after purchase.

For Apple, applications increased the value of the iPhone and made the platform more difficult to leave. Developers invested in Apple’s frameworks and customer base; customers accumulated purchases and data. Apple earned a share of transactions and could shape privacy, content, and technical behavior. Those effects are complementary: the same integration that reduced friction created switching costs and gatekeeping power.

Competitors adopted their own application marketplaces, but not every ecosystem copied the same restrictions. Android, for example, paired a central market with support for installing applications from other sources, subject to warnings and evolving security controls. Carrier stores, console marketplaces, desktop package managers, and web distribution supplied other precedents. Apple’s historical innovation was not inventing downloadable software or digital stores; it was making a tightly integrated store the normal route for native mass-market phone software at enormous scale.

The legacy is an unresolved trade-off

The 2008 architecture made installation approachable, updates visible, payments routine, and mobile development commercially attractive. It also joined operating-system ownership to control over distribution and commerce. Privacy rules, parental controls, malware response, commissions, ranking, rejected applications, and competition law all became platform questions because the store was built into the platform rather than placed beside it.

Calling the change simply “opening” the iPhone misses half the design. Apple opened native programming interfaces and an exceptional market opportunity while closing supported consumer installation around signed, reviewed distribution. The SDK and App Store succeeded together because they offered developers power, customers convenience, and Apple control. Modern arguments persist because all three properties were present from the beginning. Related: How to Explore the Internet Archive’s Software Library · How to Preserve Old Software and Media Yourself