Snapshot format (Rewind), version 1

Before every action on your albums and folders, Albarium records a snapshot. Deleting photos in the workbench is not such an action: the app records no snapshot for it, even though those photos disappear from your albums. This page describes exactly what a snapshot contains, so you can check for yourself what the app stores. A snapshot is a plain text file in JSON; you can export it in Rewind (open an action, then Snapshot from just before) and open it in any text editor.

What is and is not in it

In it:

• the names of your own albums and folders;
• the folder structure and the order of albums and folders;
• per album the list of photo IDs, in the order of the album;
• per album the IDs of photos you have hidden in Photos, if iOS gives them to the app; separately and without anything else about those photos (see hiddenAssetIDs);
• per visible photo in an album the iCloud ID, if Photos provides it;
• when the snapshot was made, why (which action followed), and with which app version.

Not in it:

• photos or videos themselves, thumbnails, or other image data;
• locations, dates, faces, captions or other metadata of photos;
• shared albums, synced albums (from a Mac) and smart albums: the app cannot change those and so cannot restore them either;
• anything about you: no account and no device ID. It does say when the snapshot was made and for which action (see above).

The app sends a snapshot nowhere. It is stored in the app's storage on your iPhone and, like other app data, goes into a backup of your iPhone (in iCloud or on your computer) if your iPhone makes one. Otherwise it only leaves the app if you export it yourself.

File

• Encoding: UTF-8, JSON (RFC 8259).
• Keys are sorted alphabetically and the output is indented, so two snapshots can be compared line by line.
• Dates are ISO 8601 in UTC, to whole seconds: 2025-10-14T08:52:45Z. Readers also accept fractions of seconds.
• Slashes in IDs are not escaped (/L0/040, not \/L0\/040).
• In the app each file is stored as <id>.json; an export is named albumbeheer-snapshot-<date>-<id-start>.json and is byte for byte the same file. The app prepares that export copy when you open Snapshot from just before for an action in Rewind, and deletes it when you close that screen (or otherwise at the next launch).

Fields

IDs are the localIdentifiers of Photos on this device (for example B84E5A21-…/L0/040 for an album, …/L0/001 for a photo). They are only valid on this device; the iCloud IDs make it possible to find the same photos on another device later.

Hidden photos

The app does not show, count or analyse photos you have hidden in Photos. In our tests in the simulator, on iOS 27.0 with the Hidden album locked (the default), iOS did not give them to the app at all: they were then not in the snapshot, not in assetIDs and not in cloudIDs. That applies to photos that were already hidden when the snapshot was made: a photo you hide afterwards stays in it, with its ID and, if Photos provided it, its iCloud ID. Without that lock, on iOS 26 and on a real iPhone this has not been tested. A hidden photo does stay in its albums. That is why the app deletes no album it thinks holds a hidden photo; when merging, such a source album stays. The app cannot be certain: it can miss a hidden photo, and leave an album in place that holds no hidden photo. If an album with a hidden photo does go, the photo stays in Photos in the Hidden album, but restoring does not put it back in the album.

If iOS does give hidden photos to the app, the snapshot records only their IDs per album in hiddenAssetIDs (sorted; their order is not visible), and restoring is built to put them back in exactly those albums. That has not been tested, because iOS did not give them in our tests. The field is missing for an album without known hidden photos. If an older snapshot has hidden photos among the assetIDs, the app first takes them out there when restoring.

Every album and every folder should appear exactly once in the tree: either in topLevel, or in the children of one folder.

Example

{
  "appVersion" : "1.0 (1)",
  "cloudIDs" : {
    "9A1B2C3D-4E5F-6A7B-8C9D-0E1F2A3B4C5D/L0/001" : "9A1B2C3D-4E5F-6A7B-8C9D-0E1F2A3B4C5D:001:AbCdEf0123456789"
  },
  "createdAt" : "2025-10-14T08:52:45Z",
  "formatVersion" : 1,
  "id" : "3F2A9C1E-7B4D-4E8A-9F21-6C0D5B8E4A17",
  "reason" : {
    "kind" : "merge",
    "title" : "Summer 2025"
  },
  "structure" : {
    "albums" : {
      "B84E5A21-0C3F-4D7E-A1B2-9F8E7D6C5B4A/L0/040" : {
        "assetIDs" : [
          "9A1B2C3D-4E5F-6A7B-8C9D-0E1F2A3B4C5D/L0/001",
          "1F2E3D4C-5B6A-7988-9AAB-BCCDDEEFF001/L0/001"
        ],
        "title" : "2025-07-14 Efteling"
      },
      "C95F6B32-1D40-4E8F-B2C3-A09F8E7D6C5B/L0/040" : {
        "assetIDs" : [

        ],
        "title" : "2025-07-15 Beach"
      }
    },
    "folders" : {
      "D06A7C43-2E51-4F90-C3D4-B1A09F8E7D6C/L0/040" : {
        "children" : [
          "C95F6B32-1D40-4E8F-B2C3-A09F8E7D6C5B/L0/040"
        ],
        "title" : "Travel"
      }
    },
    "topLevel" : [
      "B84E5A21-0C3F-4D7E-A1B2-9F8E7D6C5B4A/L0/040",
      "D06A7C43-2E51-4F90-C3D4-B1A09F8E7D6C/L0/040"
    ]
  }
}

How restoring works

Restoring puts the album structure back as it was in the snapshot. Albums that still exist are restored (name, photos, order, folder); albums that have been deleted since are created again with the same photos; albums and folders added since are deleted, except albums the app thinks hold a hidden photo: those stay (if they are in a folder that is being deleted, they first move to the nearest folder above it that stays, or to the top level). Photos themselves are never deleted in the process.

• A restore is itself an action with its own snapshot beforehand, so you can undo a restore as well.
• Photos you have deleted are skipped, even if they are still in Recently Deleted: PhotoKit no longer gives them to the app. After restoring, the app says how many there are, not which. The snapshot itself is kept unchanged, with the iCloud ID per visible photo if Photos provided it, so you can check in the exported file which photos were in which album.
• On iOS 26 and 27 the app can set the order at the top level, so restoring puts that back too. If iOS refuses anyway, or the order is not as planned afterwards, the restore stops at that step and counts as not completed, as with any step that fails.
• After a restore the app compares the library with the snapshot: per album the title, the photos in order and the hidden photos, per folder the title and contents in order. Albums that deliberately stayed because they hold a hidden photo are left out of that comparison; they must still be there. Only if the rest is the same does the restore count as successful.

Versions

• A reader refuses a file with a higher formatVersion than it knows, instead of reading it halfway.
• New optional fields or new values for reason.kind do not raise the version; readers ignore what they do not know.
• A change that alters the meaning of an existing field raises formatVersion. The app keeps reading older versions.