↓Skip to main content

Apple Could Make Open Source Apps Verifiable

·2 mins

When an app says it is open source, I want to know whether the published code is the code running on my phone. A developer could publish a clean repository, then submit a modified, malicious build to the App Store. Auditing that repository would miss the difference.

Why a checksum isn’t enough #

Compiling the same source does not automatically produce identical bytes. Toolchains, dependencies, settings, and timestamps can change the output. Reproducible builds address this: a specified source revision, environment, and procedure produce identical artifacts that anyone can compare. Reproducible Builds’ definition

Apple adds another hurdle. The App Store creates device-specific variants through app thinning, then applies DRM encryption and recompression. A checksum of a local build therefore generally won’t match the downloaded package. Apple’s documentation

Even projects engineered for verification face obstacles. Telegram’s documented iOS workflow requires a jailbroken device to extract the decrypted app and lists components its comparison cannot fully check. Verifying one delivered variant also doesn’t independently verify every other variant. Telegram’s instructions

What Apple could change #

Apple could offer an optional verification path for open source releases:

  1. Reproduce the submitted build. Record the exact source commit, dependencies, and build environment, with tooling that lets independent parties rebuild and compare it.
  2. Account for every store transformation. Make processing reproducible where practical and publish signed records connecting the verified upload to each delivered variant, including extensions, resources, and entitlements.
  3. Allow verification without jailbreaking. Give researchers access to the artifacts needed to check those records against actual store deliveries.
  4. Make releases publicly auditable. Record variants in an append-only transparency log that independent monitors can check. Devices could verify their installed package against that log.

A signature from Apple alone would still require trusting Apple. Accessible artifacts, reproducible processing, and public monitoring would make its claims independently testable.

For users, this could become a simple label: “Verified against public source.” It would link to the source revision, verification results, and installed variant. Each update would need fresh verification, with any coverage gaps disclosed.

This wouldn’t prove the code is safe or establish how a remote server behaves. It would establish something essential: that the public code people can audit corresponds to the app they actually receive. Apple controls the distribution steps that make this difficult today; it could make that connection checkable on an ordinary iPhone.