Platforms and limitations
What has actually been run, where, and what PersistKit deliberately does not do.
What has been run#
| Unity | 6.3.25f1 (6000.3.25f1), Windows editor |
| Scripting | Mono in the editor, for the test runs. IL2CPP for a Windows x64 release player on 1.0.0: built, and the package's in-player harness run inside it |
| Editor tests | 462 EditMode and 74 PlayMode tests, all passing, on 1.0.0 |
| Cloud | The folder provider over real files; the REST provider over a real socket against a local HTTP server |
| Static checks | A source guard that fails the build if the runtime ever asks for reflection, a background thread, or a JIT-only API |
Verified Windows, in the editor: 462 EditMode and 74 PlayMode tests passing on 1.0.0, and the folder and REST cloud providers exercised against real files and a real socket.
Verified **The IL2CPP player for 1.0.0 builds and was run. A Windows x64 IL2CPP player was produced from a project embedding 1.0.0 with 0 build errors (Unity 6000.3.25f1), and it was then run twice from a clean save folder: 77 checks, 0 failures, both runs** — fields and flags, nested fields, lists, an older whole-component save, handler refusals, the Transform and Rigidbody handlers with the physics step running, protection and compression, the no-code component, asset references through a registry, and objects made from a prefab while the game ran. The second run reads what the previous process wrote, after that process had exited.
Verified A clean install. A brand-new project created by Unity — nothing carried over from the development project, not even a Library — with the package installed through the manifest and the samples imported the way the Package Manager imports them: the package resolved and compiled, all three demo scenes opened with no missing scripts (buttons, camera and light intact), a first save and load round-tripped, slots and backups worked, the autosave component saved, and spawning plus retiring behaved exactly as documented — including a retired identity being refused with PK-INSTANCE-001.
That clean install also found a real defect, which is the point of doing it: the package declared no dependencies at all, so a project that did not already have Unity UI could not compile a package whose save menu builds its own screen. com.unity.ugui is now a declared dependency. What it did not cover: in-scene gameplay was played in the development project (a scripted Play Mode check does not advance in a headless batch editor), and the package was installed from a local path rather than from the Asset Store, which is the only install route that exists until the package is published.
Not verified Android, iOS, macOS, Linux, WebGL, consoles. The runtime is platform-neutral C# with no native code and no reflection, and its file handling goes through one place that answers questions instead of throwing — but no run has been made on those platforms here, so no claim is made for them. If you build for one of them, the behaviour worth testing first is what happens when a save cannot be written at all.
Deliberately not supported#
| Not supported | Why, and what to do instead |
|---|---|
| A scene object inside a component's field | Give it a PersistKitIdentity and save it under its own key |
| A list of references in one field | Save each reference under its own key |
| C# properties | Unity's serializer does not save them; use a field |
| Collections nested more than two deep | Flatten, or save two keys |
Collection types other than arrays, List<T> and Dictionary<K,V> | Convert to one of those before saving |
| Asynchronous save/load of the local file | A local save is a small file write; the cloud operations are the asynchronous ones |
| Addressables | The asset registry is the table, and PersistKitAssetRegistry.Instance lets you point it at your own resolver |
| A Dictionary field inside your own class | A documented limitation of Unity's serializer: a top-level dictionary is fully supported, so save it as its own key beside the class |
| Cloud SDK providers (UGS, Steam, Firebase, Supabase, PlayFab) | No adapter ships and none is claimed. The provider contract is five operations, and the folder and REST providers are complete, working examples of it |
Known edges#
- A save is on the player's machine. Protection stops casual reading and editing; it is not a secret store.
OnApplicationQuitis not guaranteed on every platform. A mobile app can be killed; a console can suspend the game. Save at your own moments as well — a checkpoint, a scene change — rather than only on the way out.- A damaged file is never deleted. It is left where it is, because it may hold data the backups do not.
- Two devices writing the same cloud file at the same instant are settled by the service, not by PersistKit. A provider with conditional writes closes that window properly; the folder provider cannot lock a file, and says so.
Next#
Something wrong on this page? Every page here describes behaviour that is checked in the repository. If a page and the package disagree, the package wins.
Report a documentation problem · Error codes · Platforms and limitations