Updating
move your changes onto a new version of the kit.

01Set yourself up for easy updates

• Keep the kit in git. Commit the original ZIP contents first, on a branch such as upstream. Make your changes on main.
• Change the brand files, not the code, wherever you can: brand_config.dart, white_label.dart, studio.config.json, .env, the native files listed in White label.
• Keep secrets out of git: .env, android/key.properties, keystores (*.jks, *.keystore) and ios/Flutter/Signing.local.xcconfig. The apps' .gitignore files cover key.properties and keystores, and NFC Crypto's also covers .env; add the rest to your own .gitignore.

02Update steps

1. Read the changelog of the new version (Changelog).
2. Unpack the new ZIP over your upstream branch and commit it.
3. Merge upstream into main and resolve conflicts. Conflicts are usually in the brand files; keep your values.
4. Get packages: flutter pub get in each Flutter app. For Card Studio, delete .venv if the requirements changed; run.sh recreates it.
5. Run the tests: flutter analyze and flutter test in each app, and the Card Studio tests (commands).
6. Test on real phones with real cards before you publish (checklist), then raise the build number and publish.

03Cards already issued

The card format is designed to stay compatible: records keep their bytes and their place, new records only go after them, and readers skip what they do not know. Cards written by an earlier version keep working. Do not change the record types or the backup format yourself, or issued cards will stop opening.

04Your users' data

Wallets, paired cards, roles and limits live on each user's phone. An app update keeps them, as long as the bundle ID and the Android signing key stay the same. Never change these for an app that is already published.