Platform support
What has actually been verified, on which machine, how to reproduce it — and every environment that has not been tested.
Verified#
"Supported" here means verified, and nothing else. A platform this package has not been exercised on is listed as unverified, however likely it is to work.
| Environment | What was verified | How |
|---|---|---|
| Windows x64, Editor 6000.6.0f1, Mono | Full pipeline: local storage, envelope, integrity, compression, encryption, versioning and migration, autosave and checkpoints, persistent objects, cloud sync with conflict preservation and the offline queue | 582 Edit Mode tests, run in the Editor that ships with this project |
| Windows x64, Editor, IL2CPP build support | A release IL2CPP player build compiles with zero errors | BuildPlayer for StandaloneWindows64 through Unity's own pipeline |
| Windows x64, IL2CPP release player, no Editor | The pipeline runs correctly under AOT: save/load with SHA-256 + Deflate + AES-256-CBC/HMAC, round-trip fidelity of dates, enums, decimals, nullables, dictionaries, arrays, nested and value-type collections, metadata, migrations, wrong-key refusal and diagnostics | The verification probe, run as a player; 12/12 checks passed, exit code 0 |
The probe writes its report beside the player's persistent data as nf_il2cpp_verification.txt, so the result can be re-checked rather than taken on trust.
What the IL2CPP run found#
Running in a player is not the same test as running in an Editor, and it showed it: the first AOT run failed, because timestamps were written using the current culture. A save produced on a device using dd-MM-yyyy either failed to load elsewhere or — worse — was silently reinterpreted. Fixed, and now covered by tests that impose deliberately hostile cultures and inspect the bytes actually written. That is exactly the class of defect an Editor-only suite cannot be trusted to find.
Unverified — and therefore not claimed#
| Environment | Status |
|---|---|
| Consoles (Switch, PlayStation, Xbox) | Not verified No SDK was available. Atomic rename within a directory and a writable persistent root are the assumptions most likely to need adapter work; IPathProvider and ISaveStorage exist so a platform adapter can supply its own rules. |
| iOS / Android / WebGL / Linux / macOS | Not verified The code paths are platform-neutral and no engine-internal API is used, but that is reasoning, not evidence. WebGL additionally needs an ISaveStorage adapter, because browser storage is not a file system with atomic renames. |
| Real cloud providers (Steam Cloud, PlayFab, Firebase, S3, Dropbox…) | Not verified No service was reachable. The cloud layer was verified against in-memory and HTTP-shaped doubles with failure injection — which tests the framework's behaviour, not a provider's semantics. |
| Unity versions other than 6000.6.0f1 | Not verified The package targets Unity 6000.6; nothing depends on 6.x-only APIs, but a lower bound has not been established. |
| IL2CPP with high or full managed stripping | Not verified The verified build used Unity's default stripping. Types reached only through reflection are the risk; a link.xml preserved through the affected assembly is the remedy. |
| AOT on ARM64 / Apple silicon | Not verified No arm64 build or run was performed. |
| Multi-process access to one save root | Not supported Atomic promotion keeps either version intact, but the later writer wins. Use separate roots. |
Re-running the verification#
1. Switch the Standalone scripting backend to IL2CPP (Project Settings -> Player).
2. Build the player (a scene must exist; the probe needs no scene object).
3. Run it:
NFVerify.exe -batchmode -nographics -nfVerify -logFile player.log
4. Read the result beside the player's persistent data:
%APPDATA%\..\LocalLow\<company>\<product>\nf_il2cpp_verification.txtExit code 0 means every check passed; a non-zero code means at least one failed, and the report says which. The scripting backend in the repository is Mono2x: the IL2CPP build is performed with a temporary switch that is reverted afterwards.
Next#
- Limitations — the design boundaries, stated before you find them.
- Performance — where the numbers came from.
- Support — how to report what you find on an unverified platform.
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 · Frequently asked questions · Troubleshooting