I am trying to understand one supported iOS lifecycle guarantee. Consider a generic app that stores a single SQLite database in its private Library/Application Support directory and keeps one SQLite connection open while its process is alive. During a supported platform operation such as iCloud restore that continues after setup, Finder or Apple Devices restore, Quick Start direct transfer, Quick Start using iCloud, reinstall or offload recovery, or an app update, can the app become or remain running, background executing, or suspended while iOS restores, replaces, or rebinds its data container or a file within it? More specifically, can an existing open file descriptor or SQLite connection continue to reference an old filesystem object while a later lookup of the same Application Support path resolves to a restored or replacement object? If iOS does not permit that condition, what supported lifecycle invariant prevents it? For example, does iOS terminate the app before restored data becomes visible, gate launch until the complete per-app restored container is finalized, or keep the container binding stable for the lifetime of the process? If the behavior differs by mechanism, please distinguish iCloud restore after setup, Finder or Apple Devices restore, Quick Start direct transfer, Quick Start using iCloud, reinstall or offload recovery, and app update. • Does the platform's restore ordering depend on SQLite locks? • Does NSFileCoordinator participate when platform services restore private Application Support files? • Is there Apple documentation or an Apple-staff explanation that defines this ordering, including supported versions, conditions, or exceptions? The POSIX issue is that an open descriptor may continue to reference an old object after pathname replacement while a new lookup reaches a different object. SQLite also documents risks when an open database file is renamed or unlinked. I am not treating a raw rename or unlink test as equivalent to an Apple restore. I am explicitly excluding arbitrary unlink, rename, overwrite, or other direct same-container filesystem attacks. My question is only whether Apple's supported restore and container services can create an equivalent old-open-object versus newly-resolved-path condition while the same app process survives.