FREE HISTORY OF COMPUTING COMPANIES LESSON

2007: Put a market inside the phone

Apple, Android, HTC, Samsung, and the app economy

The 2007 iPhone and Android announcements preceded the 2008 App Store launch and the first Android devices. Keeping those dates distinct matters: a device, a development platform, and a software marketplace are separate releases. Apple's original App Store announcement and the Open Handset Alliance statement show different ways of coordinating hardware, software, developers, distribution, and commercial partners. Both are participant documents that describe intended benefits and deserve critical reading.

An app platform joins several contracts. An SDK defines capabilities available to developers. A runtime executes applications. A signing mechanism identifies a publisher or approved artifact. A store handles discovery and distribution. Payment and account systems mediate purchases. Review and update processes determine which versions users can obtain. A user experiences one installation button, but that button crosses several authority boundaries.

Consider a fictional application selling for ten units. If the marketplace retains three and payment handling is already included, the developer receives seven before taxes, refunds, development, hosting, and support. With a fixed development cost of 7000 and no other costs, one thousand paid copies recover that initial amount. Add two units of ongoing service cost per copy and the contribution becomes five, raising the break-even volume to 1400. These are illustrative numbers, not current fees or a business forecast.

Distribution can lower costs that every developer would otherwise solve independently: payment trust, malware screening, updates, and account recovery. The same mechanisms create control points. A changed review rule can delay a release; a ranking change can alter discovery; a new required API can force maintenance. Evaluate the rule's purpose and effect separately. A security review can reduce real harm while also imposing inconsistent or difficult-to-appeal decisions.

Android's open-source base illustrates why openness has several dimensions. Source licensing, trademark use, compatibility testing, preinstalled services, application stores, and device updates can have different rules and owners. A vendor's ability to modify code does not mean every service remains available or every application behaves identically. Conversely, a controlled distribution channel does not imply that developers receive no useful safety or integration benefits.

Updates are a long-term promise. A platform should define supported versions, deprecated interfaces, user migration, and security maintenance. Developers need to distinguish an application-level change they can ship themselves from a system update requiring device or platform cooperation. A successful initial launch says little about whether a device remains supported years later.

Map a complete developer and user journey, including rejection, refund, accessibility failure, lost credentials, and device replacement. Then identify who can resolve each problem and what evidence supports an appeal. The institution is part of the technical system because it determines which code reaches which machines, under whose identity, and for how long. A rigorous comparison makes these costs and benefits explicit rather than using one label such as closed or open to decide the answer.

Reconstruction exercise

Using the fictional ten-unit price and three-unit marketplace share, compute developer contribution with and without a two-unit service cost and the volume needed to recover 7000 units. A review delay of two weeks blocks a bug fix. Identify two alternative designs that reduce this risk without abandoning all review, and one user protection that could be weakened by an overly broad exception.

Worked solution

Without service cost, contribution is 7 and break-even volume is 7000/7=1000. With two units of service cost, contribution is 5 and break-even volume is 1400, ignoring all other costs. A fast path for narrowly scoped security fixes with post-release audit can reduce delay; staged rollout with rollback and a documented emergency appeal process can also help. An exception allowing any developer to label a release urgent could bypass meaningful checks and distribute malware or permission changes. The design should define eligibility, evidence, monitoring, and revocation. The comparison is between concrete governance mechanisms and their failure modes, not between unlimited control and no control.

Test the limits and transfer the idea

1. State-machine trace · allow 25 minutes

A valid signature does not make an old update safe

A fictional app updater trusts the platform's signing key. Version 5 fixes a vulnerability in version 4; both packages have valid signatures. An attacker replays version 4 after version 5 is installed. Show why signature verification alone accepts the package. Design an anti-rollback rule and an emergency rollback procedure that does not let an arbitrary old signed package bypass it. This is a teaching updater, not a description of Apple or Android internals.

Get a starting hint

A signature authenticates the signed bytes, not their freshness relative to installed state.

Compare your reasoning with the worked solution

Both packages verify under the trusted key, so the signature-only updater has no rule rejecting 4 after 5. Persist a trusted monotonic version or security epoch and accept ordinary updates only when their signed epoch meets the current minimum. An emergency rollback can require a separately authorized signed recovery instruction naming the exact permitted package, device scope and expiration or one-time recovery state, with an audit record. Simply adding an always-available ignore-version flag would erase the guarantee. Persisting the minimum must survive reboot and resist untrusted reset under the stated threat model. Original launch announcements establish product announcements and intended distribution arrangements, not the internal security properties of this constructed updater.

Check your reasoning

  • Distinguishes authenticity from freshness.
  • Defines persistent monotonic state and normal acceptance.
  • Provides a narrowly authorized rollback path rather than a universal bypass.

2. Measurement and transfer · allow 25 minutes

Evaluate rollout success using the eligible population

A platform has 10,000 active devices. An update supports 6000 of them; 4500 install successfully, 300 attempt and fail, and 1200 do not attempt. Marketing reports 93.75% success because 4500/4800 attempts succeeded. Compute successful coverage among eligible and all active devices. Propose separate measures for rollout reach, installer reliability and long-term support. Explain what a launch-week download announcement cannot establish about those measures years later.

Get a starting hint

A conditional installation success rate omits devices that cannot or do not attempt the update.

Compare your reasoning with the worked solution

Installer success conditional on attempt is correctly 93.75%. Eligible-device coverage is 4500/6000=75%, and total active-device coverage is 4500/10000=45%. Report all three with dates and eligibility criteria. Reach can measure offered updates or attempted installs among eligible devices; reliability measures completion and failures conditional on attempt; support measures the fraction of active devices still eligible for security fixes and time since their last supported version. Counts need stable device definitions and privacy-preserving aggregation. Apple's 2008 download announcement is a primary contemporaneous statement about a launch metric, while the OHA announcement states a platform initiative. Neither proves a later installed population's security coverage or repair delivery.

Check your reasoning

  • Computes 93.75%, 75% and 45% with correct denominators.
  • Separates reach, reliability and support eligibility.
  • Limits historical launch evidence to its actual date and metric.

Check your understanding

An app sells for 10, the store retains 3, and service costs 2 per sale. How many sales recover 7000 fixed development units?

  • 1000.
  • 3500.
  • 700.
  • 1400.
Explanation

Per-sale contribution is 10−3−2=5, so 7000/5=1400 before other costs.

A platform wants faster urgent security updates without abandoning review. Which design addresses both aims?

  • Treat download count as proof that a patch is safe.
  • Delay every update until the next annual device cycle.
  • A narrow evidence-based fast path with staged rollout, monitoring, rollback, and accountable audit.
  • Allow every self-declared urgent release to bypass all checks permanently.
Explanation

A scoped process can reduce delay while retaining mechanisms to detect and reverse harmful releases.

Sources and further reading