One account and one backend for twelve iOS apps: how FCT's apps sync without Apple's CloudKit
Twelve FCT apps now run on one account and one database we operate, Apple's CloudKit out. Your data should live where the people who built it can reach.
# One account and one backend for twelve iOS apps: how FCT's apps sync without Apple's CloudKit Twelve FCT apps now run on one account and one database we operate, Apple's CloudKit out. Your data should live where the people who built it can reach. By Fernando Caudillo Tafoya · FCT Technologies · August 21, 2026 import Callout from "../../components/content/Callout.astro"; import StatBlock from "../../components/content/StatBlock.astro"; import StatGrid from "../../components/content/StatGrid.astro"; import Diagram from "../../components/content/Diagram.astro"; import BeforeAfter from "../../components/content/BeforeAfter.astro"; Twelve FCT apps now run on one FCT account and one backend we operate. Sign in once, and the work you did in one app is already there in the next one. Apple's CloudKit is out of the picture. <StatGrid> <StatBlock value="12" label="Apps on one account" detail="Each one uses a shared sync engine and account layer rather than carrying its own copy of either." accent /> <StatBlock value="1" label="Backend, and one sync path" detail="One database we operate is the real copy. There is no second one to disagree with it." /> <StatBlock value="0" label="Data in a silo we cannot reach" detail="Support questions, business rules and a future web page are all possible because the data is somewhere we can go." /> </StatGrid> ## Why not just use Apple's sync Because we already run the account. Once that is true, CloudKit becomes a second sync engine doing the same job as the first. <BeforeAfter before={{ label: "Two engines", title: "The default shape", items: ["Two sync paths for one set of data", "Two ideas of which copy is correct", "Two ways to resolve a conflict, which can disagree", "Data tied to your Apple account, out of our reach", "No server-side rule, no web page, no support answer"] }} after={{ label: "One spine", title: "What the apps run on now", items: ["One account across the whole portfolio", "One real copy, one sync path", "A local copy that is fast and works offline", "Data we can reach, reason about, and take with us", "One place to build every surface that comes next"] }} /> Multi-device support already comes from running our own backend. The second engine buys nothing and costs a permanent source of disagreement. ## What the apps run on now <Diagram steps={[ { label: "You edit in the app", detail: "The write lands in the device's local store first, so the app is fast and works with no network at all.", kind: "input" }, { label: "The queue", detail: "Every change waits its turn and goes up when there is a connection. Losing signal delays a sync; it does not lose an edit.", kind: "step" }, { label: "Sign-out barrier", detail: "Clearing the device happens only once the queue is provably empty, photographs included. Otherwise it refuses and says why.", kind: "gate" }, { label: "Your account's store", detail: "One database we operate, the only route between devices, feeding every other one you signed in on.", kind: "output" } ]} /> The local copy is fast, works offline, and is never the source of truth. It is a rebuildable view of the real copy, which lives elsewhere. That is the ordinary shape behind most software a business depends on. ## The boundaries, because power without control is not a feature Signing out is the one people get wrong. A sign-out that tries to upload, fails quietly and clears the device anyway is data loss wearing the words that promised safety. So clearing the device is a proof rather than a best effort. It happens once everything queued has provably arrived, photographs and recordings included, or it refuses and explains itself. That rule is enforced in code, not left to a convention. Deletion got the same treatment. You can delete your whole account and its data, with per-app deletion offered as an addition rather than a substitute, which is both Apple's requirement and the honest shape. The deletion path went through an adversarial review before it deployed, on the principle that the code which destroys data is the code that gets attacked hardest before it ships. <Callout variant="takeaway" title="The rule the whole thing rests on"> The local copy is a cache. The account's store is the truth. Nothing is cleared off a device until the server can prove it already has it. </Callout> ## Why a shared account, and not twelve separate ones Twelve unrelated apps are twelve unrelated bets. Twelve apps behind one account mean the person who finds one of them arrives at the others already signed in, with their data waiting. That is the difference between a portfolio that compounds and one that merely accumulates. Running the account means running the responsibility. The data sits with us rather than in a silo nobody can reach, which is exactly what makes the boundaries above our job rather than a platform's default. That is the trade, and we took it on purpose. ## Availability, precisely Villain Arc was left out of the wave described here. It shipped to the App Store in February 2026 and ran there through version 1.3. It has since been rebuilt onto this same platform, and the listing is withdrawn while that version is finished, so there is nothing to download today. Transcription Studio's native app is built and running daily and is not on the App Store; its repository is public if you want to read how one of these apps meets the sync layer. The rest of the portfolio is not publicly released, and we are not putting a date on any of it here. This is the same argument we make to every client. The data your customers hand you should live somewhere you can reach, reason about, and take with you. We would not sell an architecture we were not willing to run ourselves, so we run it.Twelve FCT apps now run on one FCT account and one backend we operate. Sign in once, and the work you did in one app is already there in the next one. Apple’s CloudKit is out of the picture.
12
Apps on one account
Each one uses a shared sync engine and account layer rather than carrying its own copy of either.
1
Backend, and one sync path
One database we operate is the real copy. There is no second one to disagree with it.
0
Data in a silo we cannot reach
Support questions, business rules and a future web page are all possible because the data is somewhere we can go.
Why not just use Apple’s sync
Because we already run the account. Once that is true, CloudKit becomes a second sync engine doing the same job as the first.
Two engines
The default shape
- Two sync paths for one set of data
- Two ideas of which copy is correct
- Two ways to resolve a conflict, which can disagree
- Data tied to your Apple account, out of our reach
- No server-side rule, no web page, no support answer
One spine
What the apps run on now
- One account across the whole portfolio
- One real copy, one sync path
- A local copy that is fast and works offline
- Data we can reach, reason about, and take with us
- One place to build every surface that comes next
Multi-device support already comes from running our own backend. The second engine buys nothing and costs a permanent source of disagreement.
What the apps run on now
The local copy is fast, works offline, and is never the source of truth. It is a rebuildable view of the real copy, which lives elsewhere. That is the ordinary shape behind most software a business depends on.
The boundaries, because power without control is not a feature
Signing out is the one people get wrong. A sign-out that tries to upload, fails quietly and clears the device anyway is data loss wearing the words that promised safety. So clearing the device is a proof rather than a best effort. It happens once everything queued has provably arrived, photographs and recordings included, or it refuses and explains itself. That rule is enforced in code, not left to a convention.
Deletion got the same treatment. You can delete your whole account and its data, with per-app deletion offered as an addition rather than a substitute, which is both Apple’s requirement and the honest shape. The deletion path went through an adversarial review before it deployed, on the principle that the code which destroys data is the code that gets attacked hardest before it ships.
Why a shared account, and not twelve separate ones
Twelve unrelated apps are twelve unrelated bets. Twelve apps behind one account mean the person who finds one of them arrives at the others already signed in, with their data waiting. That is the difference between a portfolio that compounds and one that merely accumulates.
Running the account means running the responsibility. The data sits with us rather than in a silo nobody can reach, which is exactly what makes the boundaries above our job rather than a platform’s default. That is the trade, and we took it on purpose.
Availability, precisely
Villain Arc was left out of the wave described here. It shipped to the App Store in February 2026 and ran there through version 1.3. It has since been rebuilt onto this same platform, and the listing is withdrawn while that version is finished, so there is nothing to download today. Transcription Studio’s native app is built and running daily and is not on the App Store; its repository is public if you want to read how one of these apps meets the sync layer. The rest of the portfolio is not publicly released, and we are not putting a date on any of it here.
This is the same argument we make to every client. The data your customers hand you should live somewhere you can reach, reason about, and take with you. We would not sell an architecture we were not willing to run ourselves, so we run it.
Frequently asked questions
What changed across FCT's apps?
Twelve FCT apps now share one FCT account and one backend we operate. Each device keeps a fast local copy that works offline, and one database we run is the real copy and the only route between devices.
Why not use Apple's CloudKit?
Once we run our own account and database, CloudKit is a second sync engine doing the same job: two sync paths, two ideas of which copy is right, two ways to resolve a conflict, for one set of data. Multi-device support already comes from our own backend. Owning the layer is also what makes a business rule, a web page or a support answer possible at all, none of which are reachable when the data sits in your own iCloud account under someone else's rules.
What happens to data when a user signs out or deletes an account?
A sign-out clears the local copy only when everything the app holds has actually finished syncing, images included. If the upload cannot be confirmed, the clear refuses and says why. Account deletion removes the account and its data, with per-app deletion offered as an addition rather than a substitute.
Which FCT apps are affected?
Twelve apps run on the shared account and sync engine. Villain Arc was left out of that wave on purpose. It shipped to the App Store in February 2026 and ran there through version 1.3, and has since been rebuilt onto the same platform, so its listing is withdrawn and it cannot be downloaded today. Transcription Studio's native app is built and is not on the App Store; its repository is public. The remaining apps are not publicly released yet.