When syncing app state using iCloud, it is difficult to reliably switch app state to a different one since an iCloud state change may occur at any time. This is particularly difficult when you want to completely change an app state to another one — not merely update it with some data from iCloud.
Maybe Swift could provide explicit support to reset an iOS app somehow? Maybe iOS frameworks could be annotated in some way to help Swift provide such a reset feature?
I'm not sure what exactly you have in mind, but it doesn't really sound like a feature of Swift the language—more something that either the Xcode "Devices and Simulators" window or an iOS API would do. In either case, you should probably use Feedback Assistant to suggest it; the relevant teams don't participate in Swift Evolution.
iOS was intentionally designed to prevent you from restarting your app. So now it becomes very difficult to support iCloud syncing between devices with any degree of confidence that the app won't become unstable/crash as a result of loading a new state from iCloud.
Even if you want to completely ignore actually syncing data and just reload the app, you don't need to restart the app to do so. You just need to trigger a reload of your view controller that hosts your content, which should then use the updated data to rebuild the UI. It's wasteful and probably not what the user expects, but it's straightforward without having to kill the app.
Reloading your view controller isn't guaranteed to work as a way to reset your app. You could easily end up with crashes that are hard to debug.
...
It should be just as reliable as your initial app loading.
Caching iCloud data in CoreData would allow you to easily propagate changes to the UI using an NSFetchedResulltsController or the NSManagedObjectContextObjectsDidChange notification.
Syncing is hard. Hard resetting the app is not the solution.
This is certainly a hard problem, but also one every app has to deal with at some level. It's not an issue of "resetting" a full application, but building it with an architecture that supports the level of updating your application requires.
You may want to review the MVC pattern and look into the MVVM pattern as these seem to be the most popular architectures for iOS.
More specifically here two approaches at solving this problem:
But wouldn't resetting an app (the equivalent of force quit and restart) work even in the presence of an app architecture not optimized for iCloud syncing?
That's still generally viewed as a bad UX, but it also depends on the app's architecture whether it will cause other problems.
E.g. say a user is trying to submit a payment. The same moment they push submit, you get an iCloud sync request where you need to restart the app. What happens to the payment submission? Corner cases like that will have to be handled and data loss problems are usually more problematic and harder to diagnose than properly syncing your data.
If you want to give more specifics about the specific issue you're trying to solve you can probably get more detailed help.
Regardless, according to Apple's guidelines an iOS app requiring a restart is broken and needs to be fixed 
Data loss in corner cases isn't that much of a problem for games — especially when the player is asked whether they want to switch to the iCloud save or overwrite it.
Consider the common scenario where you try to add iCloud sync to a mostly finished game. Learning at that point that properly doing a sync requires rearchitecting your entire app is not nice. A hard reset — if it were supported somehow — would probably be the best solution in this scenario.
By no calculation would that be the "best" solution, just the most expedient. But it is wrong, both from an app architecture standpoint and from a platform standpoint in general. That it might be difficult to retrofit into an app that wasn't properly architected is a failing of the app, not the platform's best practices.
Users don't care about the app architecture. They just want an app that is stable and doesn't crash.
An app reset for iCloud sync may result in a suboptimal UX but it is better than an unstable app or one that doesn't support iCloud sync.
Ideally you should be able to repeat the process of loading the save state the same way you would do it when the app launches. It may require going to a specific menu or loading screen where it should be (relatively) trivial to reset everything else.
If you want any application, game or not, to load from a saved state there are architectural considerations you have to make to support it properly. It's no different than whether to have a game's map only exist on screen or have an off-screen component.
This is not something “Swift”—the language, the compiler, or the runtime—can do. Most of the frameworks we use to write iOS apps, including the iCloud infrastructure, are written in Objective-C, C++, and C, not Swift. These frameworks keep lots of state that is outside the reach of Swift and thus cannot be reset by Swift.
If you want the frameworks to support a feature like this, you can file a feedback request with Apple. But all of those frameworks (except Foundation) are outside the scope of Swift and the Swift forums.
The aspect of the architecture which would be troublesome is global state. Global state is a bad idea even if you aren't trying to switch to a saved state dowloaded from iCloud. Any architecture which minimizes global state will be easy to modify to handle resets, and such an architecture is always better, all else being equal.
This is the key point and well-put. If you're interested in continuing this conversation, you should take it up at the Apple developer forums, but it's not a core-language question.