An exported archive is a product contract that may outlive the application version that created it. Kotlin serialization can encode and decode data, but the team must decide what fields mean and how future versions will interpret them.
The Kotlin serialization documentation describes supported formats and platforms. Portability of the encoding is useful; compatibility of the business meaning still requires an explicit design.
Define the archive's purpose
Decide whether the export is a backup, a transfer format, a human-readable report or an interchange file for another application. Those purposes have different requirements.
Scan Pro Receipt describes importing a phone archive into a desktop companion and is listed under Kotlin. Its archive schema is not provided in the catalogue. The described workflow nevertheless makes compatibility a concrete question: can a later reader reconstruct the records that an earlier writer exported?
A PDF summary and a restorable archive should not be presented as equivalent.
Specify field meaning
Document identifiers, date interpretation, numeric units, optional values and relationships to attached files. Keep those definitions separate from internal class names.
Avoid letting a convenient property rename silently become a breaking archive change. An internal model can evolve while the external representation remains stable.
Include an explicit format version where the archive needs versioned interpretation. Define what an importer should do when it encounters a newer version it does not understand.
Validate before changing saved data
Parse into a controlled representation, check required relationships and present a meaningful failure before committing an incomplete import.
Use an isolated destination or a staged review when the import could overwrite existing records. Decide how duplicate identifiers and repeated imports are handled.
A syntactically valid JSON document can still contain inconsistent references or unsupported values. Successful decoding is not the final acceptance check.
Keep old fixtures
Save small synthetic archives produced by supported writer versions. Include missing optional fields, boundary values and attachments referenced by more than one record where relevant.
Run those fixtures through the current importer. Also check that a current export can be reopened by the version combinations the product claims to support.
Do not claim universal backward compatibility from one round trip in the same version. That test misses changes in field defaults, naming and interpretation.
Make recovery understandable
If an archive cannot be imported, identify the unsupported format or invalid relationship without exposing private contents in logs.
Preserve the original file and leave the existing database unchanged when the operation fails before commitment. If partial import is intentional, report exactly which records were accepted.
The Kotlin cancellation guide covers interruption during this workflow.
Review archive compatibility whenever the data model changes, not only when export code is edited. A new required relationship can affect old backups even if the serializer itself remains untouched.
Keep the user-facing promise narrow and testable: which archive versions are accepted, which application data is included and how a failed import can be corrected.
A durable export feature earns trust by preserving meaning across time, not merely by producing a downloadable file today.
Stardew Valley Tracker
IcyZip
Xeramail Temp Mail