What's new

1.0.0 — the first release#

PersistKit 1.0.0 is the first release. It changes the version number, the metadata, and the small amount of state PersistKit keeps between play sessions — not your saved games: the file format is still format 2, and a save written by any 0.1.0-preview.8 or later loads in 1.0.0 exactly as it did before. There is nothing to migrate.

The package declares what it uses. Two dependencies, both Unity's own: Unity UI (com.unity.ugui), because the save menu builds its own screen, and the Unity Test Framework (com.unity.test-framework), which the package's own test suite needs (editor-only; nothing extra reaches a player build). A clean install into a brand-new project is what found the first of them: without it, a project that did not already have Unity UI could not compile the package at all.
Session state is put back at the start of every play session. If you switch script-domain reloading off for a faster Enter Play Mode (Project Settings → Editor → Enter Play Mode Options), one session's cloud provider, passphrase, save folder, offline cap or cached scene data would otherwise leak into the next. All of it is now reset before the first scene loads, and a test fails the build if new static state is added without being dealt with.
The licence is stated. LICENSE.md names the licence that applies (the Unity Asset Store End User License Agreement) and records that the package bundles no third-party code.
Verified for this release: 462 Edit Mode and 74 Play Mode tests, 0 failures, on Unity 6000.3.25f1; a Windows x64 IL2CPP player built with 0 errors and run twice from a clean save folder (77 checks, 0 failures, exit 0 both runs); a clean install into a project of its own; and the three demo scenes played and saved from.
Still not in it: saving is synchronous — there is no background write; cloud providers other than the shipped folder and HTTP ones must be written by you; collections are arrays, List<T> and Dictionary<K,V> with one further level of nesting; and only Windows x64 has been built and run. Platforms says exactly what was run and what was not.

0.2.0-preview.1 — cloud copies, migrations and the field-level release#

Saving, and looking at what it saved#

Lists of references. Persist.SaveReferences / Persist.LoadReferences save a party, an inventory or the buildings on a grid in one call, each item written the way a single reference is — and the order is the list: an item that cannot be found leaves an empty position and is reported, so nothing shifts along.
The Inspector says what the settings mean. PersistKitAutoSave and PersistKitSaveMenu read their own settings back in plain words, name the two combinations that quietly never save anything, point out the one scene dependency a menu has, and show the live state while the game runs.
A tool that shows what is inside a save (Tools ▸ PersistKit ▸ Inspect or Compare Saved Games): the file, its status with the exact code when it cannot be read, every key with its kind in words, and what changed between two saves. It only ever reads — checked by comparing the file's bytes before and after.

Cloud#

A provider contract, and two complete providers. FolderCloudProvider (a Dropbox, OneDrive or network folder) and RestCloudProvider (any HTTP endpoint) upload, download, list, delete, report metadata, write conditionally, report progress and honour cancellation and timeouts. A third, MemoryCloudProvider, is a double for tests and for trying the workflow.
The whole behaviour, not just the transport. Deciding which copy wins, refusing to overwrite a copy that moved, remembering what was uploaded, queueing an offline save and reporting every failure with a code live above the provider seam, so a game gets them whichever provider it uses.
Conflicts are a question. PK-CLOUD-004 and an explicit choice: KeepLocal, KeepRemote or KeepBoth — the last because there is always an answer that loses nothing.

Migrations#

SaveMigration and Persist.Migrations. Rename a key, add a default, remove one, convert a value, or run your own code — as ordered steps from one saved-data version to the next.
Copy first, migrate in memory, validate, then write. A migration that fails leaves the file exactly as it was; one that cannot be written puts the copy back.

Objects, scenes and retirement#

Retiring something for good. Persist.Retire(id) records that the player destroyed something permanently, so a later load of a save that still lists it does not rebuild it — a small note beside the save, in the slot in use, with Unretire, IsRetired, RetiredCount, Retired() and ForgetRetired() alongside it. Spawn refuses a retired id with the new code PK-INSTANCE-001, LoadInstances skips retired entries and says how many it skipped, and SaveInstances leaves a retired object out of the write. The objects, scenes and retirement page writes down what identity means across additive scenes, unloads and DontDestroyOnLoad.
Three more playable scenes: a clicker with capped offline progression, a physics sandbox whose crates are saved and restored (and stay swept away once the player clears them), and a small top-down game with three save slots through the real save menu. Each one is a real .unity scene with the world, camera, light, panel and wiring already in it, so opening it and pressing Play is the whole setup.
A measured performance page in the package, and the probe it uses, so the advice about when to save comes from numbers taken on named hardware rather than from a feeling.
An Input System fix: the save menu's "Create Event System If Missing" helper (and the matching editor button) used to add a classic input module in every project, which throws every frame in a project that reads input through the Input System package. The module is now chosen when the code is compiled, and an Input System project gets a clear instruction instead of a module that throws.
Two defects found by testing rather than by reading: the save menu used to crash when a saved game had a picture beside it (a game object allows one Graphic, and the refused AddComponent returned null), and the package declared no dependencies at all, so it could not compile in a project that did not already have Unity UI. Both are fixed, and both have a test or a check that would catch them again.

Before that, in this line#

Field-level saving. Choose the fields that are saved and the fields that are loaded, independently, in the Inspector; a field that is not chosen is not in the file at all.
Asset references and spawned prefab instances. A save can point at a Sprite, a ScriptableObject or a prefab by registry key, and at the objects a game created from prefabs while it ran.
Protection, compression and the storage hardening that makes the same save behaviour hold on platforms whose file systems do not offer an atomic replace.
Slots, metadata, backups and the recovery ladder. Named slots with their own files and descriptions, rotating copies of every save, and a load that completes a damaged save from the newest copy that still works.

How each release is verified#

Every release is checked the same way: the 462 EditMode and 74 PlayMode tests, a source guard that refuses reflection, background threads and JIT-only APIs in the runtime, an assembly-boundary guard, and a package-version guard. What was run, and what was not, is on the platforms page — including an in-player IL2CPP run of 77 checks for this version and a clean install in a project of its own. Performance is measured rather than promised: the save and load cost of the storage pipeline, with the method and the probe that produced them, is in the package's Documentation~/performance.md.