DocumentationiPhone
Where the register lives
A register lives in one of two places: on the iPhone that made it, or in Starkive Cloud. This page is the choice, the move between them, and what each one keeps.
- For
- Explains the two places a register can live and how to choose or move between them.
- Will not
- Choosing Starkive Cloud is one-way: the register does not move back to one iPhone. A sign-out refuses to wipe if there is unsent work or if the phone holds the only copy.
- Writes
- Moving a phone-first register up uploads records to Starkive Cloud as an upsert keyed on existing ids; a sign-out clears the register on the phone.
- On iPhone
- The paired-Mac path is unchanged and still works; the Mac holds the original where the phone holds a replica.
The two residences
Manifest asks one question during setup, and the answer decides where every record you make from then on is stored.
On this iPhone is a register that exists in exactly one place. It works with no signal, it asks for no account, and nothing leaves the phone. It is the right answer for one operator with one device, and it is the only answer available before you have bought anything.
Starkive Cloud is a register that lives on a server and reaches every device you sign in on. It is what the product is sold on: a fleet that travels with the people carrying it, and that comes back after a phone is wiped or lost.
The two are not a setting you flip. Which one is in use is decided by whether this device is signed in to an organisation, not by a switch somebody has to remember to set. An operator should not have to know which transport carried their data, and a switch they have to remember to flip is a switch that is wrong on the day it matters.
Choosing
The setup step is titled Where it lives. It asks who else needs the register now, because that is a fact about your situation rather than about our architecture.
Each card carries reach first and its second fact second, in the same order, so the two can be read against each other without a comparison table. Starkive Cloud is badged Recommended and sits first. On this iPhone is badged No account needed, which is the fact somebody choosing it is choosing it for.
The recommendation is by order and by label only. There is no default: the cards start unselected, and Continue stays live whether or not you have tapped one. A pre-selected card would sit one tap away from being committed by somebody who never read the screen.
Tapping Starkive Cloud here does not commit anything. If you tap it and never buy a plan, setup finishes on the local register with every record intact. What is irreversible is a cloud register that already has rows in it, which is a state months away from this screen rather than a consequence of this tap.
What each choice tells you afterwards
Pick one and a note appears under the cards, on the branch it is true of and not the other.
Choose Starkive Cloud and the note is titled A permanent home. It says the register lives in the cloud from then on and does not move back to one iPhone, and that the records and tag numbers are unchanged. That is the whole disclosure: the direction you have chosen is one-way, and you are told so at the moment you choose it rather than after you have paid.
Choose On this iPhone and the note is titled Move up later. It says you can move to Starkive Cloud at any time, that every record and printed tag number carries over, and that you start a cloud plan when you do. Until then, your only copy is this iPhone.
Under both cards sits one shared line: this iPhone is free for seven days, Starkive Cloud is paid from day one, and you will see prices before anything is charged. No figures appear on this screen. The plan picker two steps on carries every price, the term, Restore, Terms and Privacy.
Moving a phone-first register up
If you set the phone up standalone, recorded a fleet during the trial, and then bought a cloud plan, the register has to travel. Settings → The register → Move it to Starkive Cloud is the way across.
Check the preamble
The first line counts what is on the phone and where it is going. The second says nothing is deleted and that a failed upload leaves the phone exactly as it was. If any photographs are still waiting to send, a note appears here naming how many, because the move waits for them and you would otherwise press the button and be told no.
Press Move it to Starkive Cloud
The button reads Uploads first. Nothing changes until it is all up. A stage nobody has reached yet reads Not started. rather than a zero, because a stage reported empty that was merely unvisited is how somebody concludes their vendors did not need moving.
Read the verdict
Moved counts the records now in Starkive Cloud and says everything is still on the phone too. Not moved says nothing changed, that the phone is exactly as it was and still holds everything, and to try again on a better connection.
The move is safe to retry. The upload is an upsert keyed on the ids the rows already carry, so a second attempt merges rather than duplicating. A failure leaves the phone local, holding everything.
The button is disabled with a reason rather than silently inert. It reads Sign in to Starkive Cloud first, from Account and plan. if you are not signed in, This phone is waiting to be admitted to your organisation’s keys. if the organisation has not admitted it yet, or This register belongs to another device. if the rows came from a Mac and are going up by their own route.
Founding an organisation from the phone
A subscriber with no fleet yet is offered the founding controls directly in the sign-in sheet, rather than being told to go and find an admin.
The section is headed Start your organisation and asks for two things: an Organisation name, and an Asset tag prefix. Under the prefix field is a sample of the first tag it will produce, so somebody typing a lowercase name sees the uppercase, punctuation-stripped form before it prints on a label rather than after.
The button is Create your organisation. Its footer says the register will live in Starkive Cloud, that anything added here is in it from the first asset, and that your own company name is the usual answer because it is what people you invite will see.
The tag prefix is asked here because this is where the row is written. A granted number is never reissued and the labels go on hardware, so it is the one setting a silent default cannot be walked back. Founding with an empty register also moves this phone into the organisation it just created. If the phone already holds assets, it does not: you are told to use Move it to Starkive Cloud instead, so nothing is wiped.
What a sign-out takes with it
Signing out of an organisation empties the register on this phone. What it refuses to do, and what it keeps, are both deliberate.
The wipe refuses in two separate cases, and they are separate on purpose because they are two different losses.
- Unsent work. If changes on this phone have not reached Starkive Cloud, the wipe stops and says how many. The count includes audit trail entries as well as queued edits, so a walk-round of sightings that has not synced is caught too. Sync first, or sign out and discard them.
- The only copy. If this phone created the register and it holds assets, the wipe stops and says how many. The message names the step that actually comes first: move the register to Starkive Cloud under Settings, then The register. Or, if the register is already held somewhere else, continue and discard this copy.
These were once one consent, and every caller that wanted to discard queued edits also waived the guard protecting the assets themselves. The cost was not theoretical: Run setup again in Settings sits under the sentence Nothing is erased. It re-asks, it doesn’t reset. A phone-first operator who re-ran setup and chose the cloud lost every asset they had recorded, having just been told in writing that they would not.
What survives a sign-out is short. The organisation settings row stays because the app reads it at launch and expects to find it; what it held about the departed organisation is cleared separately. Schema bookkeeping stays. Everything else goes, and the default is inverted so that a table added to the register tomorrow is cleared without anybody remembering to think about it.
Two things that used to survive are worth naming. The operator identity is a named human being, and it used to persist, so the next customer’s technician opened the app already attributed to somebody who had never worked there. The tag lease is a block of numbers granted by the arbiter of the organisation being left, and minting from it afterwards prints stickers out of another company’s number space. Both are cleared now.
Where the file is, and why it is not moved
The register is a SQLite file at Library/Application Support/Mirror/register.sqlite. The directory name is wrong and stays wrong.
The path says Mirror, which described the old design where the phone held a read-replica of a Mac. The type was renamed and the file on disk was not, deliberately. Moving it buys exactly one thing: a string that only engineers ever read.
Against that, the ways a file move loses data here are not hypothetical. SQLite in WAL mode keeps everything committed since the last checkpoint in a sidecar file, so moving the main file alone silently drops the newest writes. A kill between the main file and its sidecars splits the pair, and the next open recovers a WAL against the wrong main file, which does not fail: it produces a plausible, corrupt database. And with file protection on, a background launch on a locked device cannot read the old files at all, so naive code concludes there is no old register and initialises a fresh one at the new path.
The register is excluded from iCloud backup on a device that holds a replica, where the Mac holds the original. It is included on a standalone phone, which is the only copy in existence and so the one that most needs a restore path.
The phone’s own connection
A phone signed in to Starkive Cloud talks to it directly. The paired-Mac path is unchanged and still works.
These are two ways in, not one replacing the other. A phone on a customer site has no route to the Mac on the office LAN, and until the direct connection existed that meant it fell back to whatever it had cached the last time it was in the building.
Which one is used is decided by whether you are signed in, not by a setting. The session is kept in the iOS Keychain with ThisDeviceOnly, so it never travels in an iCloud Keychain backup. A session restored onto a different phone would be a device nobody authorised holding a live fleet credential, and losing the phone should mean losing the session with it.
Signing in and belonging to an organisation are different things. A colleague who was invited but never opened the link has an account and no fleet, and a phone that syncs zero assets without explaining why reads as broken. The app keeps those apart: it distinguishes a definite no from the server from a request that could not be made, and treats the second as say nothing and change nothing rather than accusing a perfectly good account of being empty every time the signal drops.
Sign in with Apple is offered on the phone and not on the Mac. The asymmetry is deliberate: only the phone requests the grant that creates an account from an Apple identity, so the door is offered where it can open and nowhere else.