Skip to main content
3Nsofts logo3Nsofts
iOS Architecture

Local-Only iOS Apps: Decide What Survives Deletion Before You Ship

A product decision framework for local storage, device backup, sync, and export, with a recovery matrix for photo journals and document apps.

By Ehsan Azish · 3NSOFTS··6 min read

“Stored on your device” does not tell a customer whether their writing will survive reinstalling an app or moving to another phone. Before shipping a private iOS app, decide what recovery you promise for each kind of data and say it where people make decisions.

This is a product architecture decision, separate from whether an app uploads content for AI processing. A product can avoid a developer-operated server and still participate in Apple-managed backups. Another can intentionally exclude its local data. Those choices create different responsibilities.

Separate four promises

  • Local storage. Question it answers: Where does the current working copy live?. What it does not establish: Whether another copy exists.
  • Device backup. Question it answers: Can a device restore potentially recover app data?. What it does not establish: That a current, usable backup exists.
  • Sync. Question it answers: Can changes reach another device?. What it does not establish: That an earlier version can be recovered.
  • Export. Question it answers: Can the person create an independent copy?. What it does not establish: That the app can import it back.

Do not use these words interchangeably in onboarding, support answers, or purchase screens. A restored purchase entitlement is also separate from restored personal content.

Inventory data by replacement cost

A generated thumbnail can usually be recreated from an available original. A paragraph someone wrote about a family photo cannot be regenerated faithfully. The two should not receive the same retention decision merely because both fit in a database.

Build an inventory containing originals, identifiers, captions, comments, collections, analysis, and temporary previews. For each entry, write its source of truth, whether it is reproducible, where it is stored, and what happens after uninstalling.

Apple's backup guidance explains excluding inappropriate or reproducible data and warns that file operations can reset exclusion values. Its resource-value reference frames this flag around files not needed in a backup. Treat exclusion of irreplaceable writing as a material product limitation, not an automatic privacy improvement.

Explain the recovery policy in concrete terms

Consider a photo journal whose captions, notes, saves, collections, and analysis stay local and are excluded from device backup. Its originals may remain in Apple Photos, but keeping the original photograph does not preserve the journal entry attached to it.

An app that includes records in device backups has a different recovery contract, but inclusion alone does not prove that a usable backup exists. Explain what is included, what is excluded, and how a user can check recovery. Avoid describing either model simply as “everything is safely backed up.”

Choose a release boundary you can actually support

For a small first release, local-only storage may reduce infrastructure work. It does not eliminate recovery support questions. If export is not available, disclose that before a person invests heavily in irreplaceable writing.

If you add export later, define the format, attachments, versioning, and restore behavior before calling it a backup. A text file that can be read elsewhere may be useful even without full import, provided the product describes it accurately.

If you add sync, decide how deletion propagates, how simultaneous edits are handled, and what the user sees when an account becomes unavailable. See the CloudKit production guide for implementation concerns rather than treating sync as a checkbox.

Test the recovery contract, not just saving

Use a disposable test device or test data for destructive scenarios. Verify uninstall and reinstall, access removal, source-photo deletion, purchase restoration, and migration to another device. A successful local save does not prove any of those outcomes.

Support should be able to answer: which data is gone, which originals remain elsewhere, and whether recovery is possible through a documented route. Avoid advice to reinstall an app before checking whether that step destroys the only journal copy.

For teams planning a photo feature, the PhotoKit loading guide addresses access and media availability. Those concerns belong beside, but do not replace, the recovery policy.

Authoritative References