I am qualifying a data-preserving update of my own development-signed iOS/iPadOS app (Target Keeper). I would like to understand the supported recovery guarantees and limitations before changing an existing installation, rather than treating a completed backup or successful model-open test as proof of full rollback.
Environment: iOS/iPadOS 27.0.1 and Xcode 27.1. Existing development installations must be retained. The original signed packages for the older installed builds are unavailable. No update, uninstall, device erase or restore has been performed as part of this qualification.
Evidence already retained privately:
- Completed encrypted Finder backup records for each device, with the password kept private.
- Apple Device Hub downloads of each existing app-data container, retained separately with file counts and SHA-256 manifests.
- Disposable copies of the actual prior SwiftData store, relevant WAL/SHM files, preferences and selected-photo data opened using the proposed version's existing model and guarded local-startup implementation. Model identities/content fingerprints were unchanged in those tests.
- The separate Codable Portfolio repository passed loading/reopening on disposable copies without changing the ledger bytes.
- Controlled process interruption/reopen tests passed on disposable local copies.
These tests did not run the entire signed app-update lifecycle on a physical device, validate Keychain continuity, establish an atomic source-side multi-store snapshot, or test restore on the original devices. CloudKit records are not being mutated. I have read Apple's update-testing and container-download/replace guidance:
https://developer.apple.com/documentation/xcode/testing-a-release-build
https://help.apple.com/xcode/mac/current/en.lproj/dev816c242e1.html
Specific questions:
- For a locally development-signed app that is not available from the App Store, what does an encrypted Finder backup preserve and what additional artifacts are needed to recover the usable app and its data if the original signed app package is missing? Does a backup completion record establish anything about restoration of that development executable?
- What consistency guarantees does Device Hub's app-container download provide when the app has multiple stores (SwiftData/SQLite with WAL, a separate JSON ledger, preferences and photos)? Is a quiescent/terminated app required, and what is the recommended way to qualify a coherent capture without modifying the original records?
- What is Apple's recommended recovery rehearsal on a disposable device/installation before an in-place update? Which identity, signing, file-protection and Keychain limitations must be considered, especially for ThisDeviceOnly items and same-device versus different-device restoration?
- Which preservation checks remain the developer's responsibility beyond successful container replacement or store opening? I do not want to mistake reinstalling an app binary for rolling back a migrated multi-store data set.
Separately, an earlier strict source read rejected a file-metadata change, but its paired content hashes were not retained. I am not asserting an Apple defect, corruption or an identified writer, and newer successful copies cannot reconstruct that missing observation. Is there a recommended narrowly scoped Apple diagnostic for future capture that records before/after file identity and content consistency without weakening integrity rejection?
No backups, passwords, personal device identifiers, private certificates, record contents or confidential logs are attached. I am seeking a supported qualification procedure, not instructions to bypass preservation safeguards or destructively test on the original devices.