Locara

Apple App Store (iOS) — Review Process

What it is: The reference example of a curated, gatekept app marketplace. Hybrid automated + human review, enforced sandbox via entitlements, mandatory IAP for digital goods. Status: Mature, dominant on iOS. Frequently litigated and politically contested (DMA, Epic v. Apple). Most relevant to Locara: The cleanest precedent for “trusted store with a capability-based runtime.” Locara’s review system is essentially a much smaller, automated-first version of this.

Background

Every iOS app passes through Apple’s App Review before it can ship. The review combines automated malware/static analysis, binary inspection, and human reviewers exercising judgment on metadata, content, and edge cases. The runtime enforces capabilities via the entitlements system at the kernel level. Apple’s monopoly on distribution + payments has made this the most-studied app-store model in the world.

Key design decisions

  • Mandatory review for every binary, every update. No opt-in/out. Even unchanged binaries are re-reviewed for metadata changes.
  • Hybrid automation + human. Malware scan + API compliance check are automated; subjective judgment (“is this objectionable”) is human.
  • Five guideline categories (Safety, Performance, Business, Design, Legal) — published, specific, evolved through case-by-case rule additions.
  • Entitlements as the capability surface. App declares entitlements in a plist; OS kernel enforces. Notable entitlements: network.client, network.server, files.user-selected, device.camera, device.microphone, etc.
  • Sandbox is mandatory and kernel-enforced. Apps run as non-root, in a per-app container, blocked from arbitrary FS/network/IPC.
  • “Self-contained” rule — apps may not download, install, or execute code that adds features. (Banned: dynamic code loading. This explicitly outlaws something Pinokio does.)
  • In-App Purchase mandatory for digital goods, with carve-outs for “reader” apps, enterprise, p2p services.
  • Privacy nutrition labels — apps self-declare data collection, displayed on store listing.
  • Specific entitlements as “exceptions, not rules.” CarPlay Audio, alternative browser engines, external purchase links, etc. all gated by per-developer entitlement grants.
  • “Living document” — Apple updates guidelines and adds rules in response to new app categories, gaming the system, etc.

What worked

  • Trust at scale. Users implicitly trust App Store apps. Malware exists but is rare. Enterprise IT will allow App Store apps that they wouldn’t allow as direct downloads.
  • Sandbox enforcement is real. Apps cannot escape their containers; entitlements gate sensitive resources at the kernel level. The “principle of least privilege” works in practice.
  • Privacy labels (despite gaming) raised the floor of data-practice transparency industry-wide.
  • Entitlement-based exceptions turn case-by-case judgment calls into permanent published rules.
  • IAP control lets Apple enforce subscription standards (cancel anywhere, etc.) and provides revenue.

What failed / criticisms

  • Inconsistent and opaque rejections. Two reviewers can read the same guideline differently. Indie devs report wildly different experiences for similar apps.
  • Slow approvals at peak times — days, sometimes weeks for edge cases.
  • 30% IAP cut is contentious and increasingly regulated against (DMA, Epic).
  • Developer relationship is adversarial — Apple holds all the cards; devs walk on eggshells.
  • “Self-contained” rule kills legitimate use cases. Plugin systems, modding, low-code platforms must use elaborate workarounds.
  • Editorial choices feel arbitrary — feature placement is opaque and seen as political.
  • Privacy labels are self-declared and lightly enforced. Many apps lie or under-disclose.
  • Anti-competitive enforcement — Apple has used review to favor own apps over competing ones (browsers, music, etc.).

Specific learnings for Locara

  1. Hybrid automated + human review is the right architecture. Locara should automate everything that can be automated (manifest validation, capability compliance, static analysis, binary signing) and reserve human judgment for the borderline cases. Initially, “human” = you.
  2. Entitlements / capabilities at kernel level >> capabilities at framework level. macOS App Sandbox + custom entitlement enforcement at the Locara runtime layer give you a defensible “fully local” property. See mac-app-store.md for specifics.
  3. Specific entitlements as exceptions, not rules is the right pattern. Locara’s manifest should have a default “deny most things” stance, with apps declaring specific capabilities and the runtime enforcing them.
  4. “No dynamic code loading” should be a Locara default. Apps can’t fetch and execute new code at runtime — only the bundled, signed, reviewed code runs. This kills entire classes of supply-chain attacks. (Optional opt-in for advanced apps that need it, with clear capability flag.)
  5. Privacy labels work — copy the format. Locara’s “app card” should include a structured “what this app touches” section auto-generated from the manifest. Verifiable by the runtime, not self-declared.
  6. Avoid IAP monopoly drama. Locara is not a payments company. Apps charge via Mac App Store / Stripe / Lemon Squeezy / Gumroad — Locara doesn’t take a cut and doesn’t enforce a payment provider.
  7. Avoid arbitrary editorial. Make rejection reasons fully mechanical (manifest violation, capability declaration mismatch, signature failure) until human judgment is genuinely required. Build trust through predictability, which Apple has lost.
  8. Update review on metadata is overkill for v1. Apple re-reviews even trivial metadata changes. Locara can ship: code/binary changes trigger full review; metadata-only changes trigger automated checks only.
  9. Start very strict, loosen later. Apple’s mistake-cost is asymmetric — easier to relax rules than tighten them. Same for Locara.

References