Question
NSCoding Archiver vs NSDocument Restoration: Which Is Safer for Offline Data Recovery?
Nia Vale
0 reputation · 23 Feb 2024, 22:18 UTC
142.7K views
Loading…
0 reputation · 23 Feb 2024, 22:18 UTC
When an Objective‑C application is uninstalled and later re‑installed on a device that has never connected to a network, the only source of user data is the local backup archive generated by the previous installation. The developer must decide how to archive the data to guarantee that, after restoration, the object graph is intact and can be programmatically verified.
Using NSCoding with NSKeyedArchiver preserves the full object graph, but the archive is just a binary blob. It offers no automatic checksum or version stamp, and verification must be performed by the application after unarchiving. Additionally, class names are stored verbatim, so any change in the class hierarchy between the archive and the runtime can silently corrupt data unless the developer explicitly handles class policies.
Subclassing NSDocument (or UIDocument on iOS) integrates the archive with the OS backup APIs. The framework automatically encrypts the document, tracks changes, and can invoke fileWroteContents: callbacks that can be used for integrity checks. However, this approach relies on the document handling semantics of the specific SDK version, and if iCloud sync is disabled or the local cache is cleared, the framework may skip restoring the user data altogether.
Given the constraint of an offline re‑installation, the trade‑off centers on whether the application can tolerate an ad‑hoc verification process with NSCoding or whether it prefers the built‑in, but version‑sensitive, restoration logic of NSDocument. The key uncertainty is how each method behaves when class definitions evolve across minor OS updates or when the backup attribute isExcludedFromBackup is set on the archive.
Which approach offers a more reliable path to data integrity when restoring from a local archive after an offline reinstall?
How can a developer detect and handle class mismatches during NSKeyedUnarchiver without relying on explicit class policy configuration?
Does NSDocument automatically preserve a version stamp across minor OS updates, and how does that affect the ability to verify restored data?
For a guaranteed offline reinstall from a local archive, a manually managed NSKeyedArchiver archive wrapped in your own versioned, checksummed container is the more reliably verifiable path. NSDocument/UIDocument restoration depends on OS backup and file-coordination semantics you do not control: if the file sits in an excluded location, the local cache is purged, or the backup set simply does not include it, the framework has nothing to restore and fails silently. A self-contained archive, by contrast, can be validated byte-for-byte by your own code before any object is instantiated.
This part is a likely explanation rather than a guaranteed behavior, and it is version-sensitive: NSDocument gives you encryption, change tracking, and fileWroteContents:-style callbacks, but actual recovery after uninstall/reinstall is governed by the system backup mechanism and sandbox rules, which differ between macOS and iOS and can shift across minor OS updates. If isExcludedFromBackup is set on the file or its directory, the archive is simply absent from the backup set — no archiving method survives that. So the first check in either design is confirming the archive lives in a backup-included location.
There is no reliable way to detect and remap class mismatches without an explicit policy. NSKeyedArchiver stores class names verbatim in an opaque binary format, so pre-scanning the blob is impractical, and under secure coding an unknown class causes unarchiving to fail or return nil rather than degrade gracefully. The practical options are:
objectivecschemaVersion integer and a checksum of the inner archive), so you can reject or migrate before touching the graph.setClass:forClassName: on the unarchiver to map renamed classes explicitly.If you truly cannot configure a class policy, the only safe fallback is to treat any unarchive error as a version mismatch and abort rather than accept a partially reconstructed graph.
No — not automatically. NSDocument exposes versioning hooks such as readFromURL:ofType:error:, but the application-level model version is yours to store inside the document contents. A minor OS update does not rewrite or preserve your schema version for you, so post-restore verification still depends on a version field you wrote yourself — which is the same work the manual NSCoding approach requires, on top of the framework's restoration uncertainty.
Archive with a versioned envelope plus checksum, store it in a backup-included directory, never set isExcludedFromBackup, and on restore validate the checksum and version before unarchiving with a defined class policy. Then prove it: perform a clean uninstall/reinstall on a network-isolated device, restore from the prior backup, and log successful unarchive and object-graph completeness for both paths. One open detail worth confirming on your target OS versions: whether the document directory you choose is actually included in the local backup set — that single attribute decides whether either approach can work at all.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.