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.

Compare two concrete app policies

MemoryRemains says its local captions, notes, saves, collections, and analysis do not sync and are excluded from device backup. Its originals remain in Apple Photos. Keeping the original photograph therefore does not preserve the journal entry attached to it.

EverTrace says records and originals may be included in device backups according to system settings, but the app cannot confirm that a usable backup exists. It does not offer its own cloud sync or export archive.

These are different recovery contracts. Neither should be described simply as “everything is safely backed up.” Check each app's current policy before relying on it; the comparison here reflects the policies available when this article was published.

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