The phone hit the tile floor of the kitchen in Palermo at 7:42 on a Tuesday — corner first, the way they always do — and the screen, when I picked it up, looked like a frozen pond someone had thrown a stone through. It still lit up. The camera worked. The recipe app I had been using for the milanesa de pollo on the counter would not open. The home button was unresponsive. The chicken was in the egg wash. The bread crumbs were on a plate. I had eight minutes before the oil was at temperature and no way to read the next step.
I cooked the milanesa from memory, which was fine, because I had made it perhaps forty times. I drove to the Apple Store in Recoleta the next morning. The replacement phone was set up in twenty minutes. The recipe app — the one I had paid for, the one in which I had saved perhaps three hundred recipes over four years — opened to an empty library. The sync had been a paid tier I did not know I had not paid for. The recipes, the developer's support email eventually clarified, were on the old device, in storage I could no longer access, in a database the new install could not read. The recipes were, in any meaningful sense, gone.
§ I.What a Library Is Worth
A recipe library is, if you cook from it for any length of time, a long-term asset. It accrues. The first hundred recipes are the ones you imported in a burst when you downloaded the app — old favorites, things from your mother, the cake you made every birthday. The next two hundred come slowly, one at a time, over years — a dish a friend made on a Sunday, a thing you tasted in Mendoza and tried to reverse-engineer, a clipped column from a Saturday paper. The notes accumulate. The edits accumulate. The library, by the end of a decade, is a quiet record of what you have eaten and who you have fed, and it is unreproducible.
The question of whether the app you chose to hold this library will still exist in a decade — and whether your library will exist with it — is the most important question you can ask of a recipe app, and almost no one asks it. We download the app for the import button or the cooking-mode screen or the colour of the icon. We do not ask, on day one, what happens on the day the phone breaks.
§ II.The Failure Modes
There are three, and they are all common.
The first is cloud-only with no local backup — the app stores your library on the developer's server, and if the server goes down or the company folds or the account is locked for reasons no human will ever explain, the library is unrecoverable. There is no copy on your device. There is no copy you can hold.
The second is vendor lock-in with no export. The library exists, somewhere, but it cannot be moved. There is no JSON dump, no plaintext archive, no PDF print. The data is in a proprietary format the app will read and nothing else will. The day you want to leave is the day you discover you cannot.
The third — the one that broke me in Palermo — is sync as a paid tier separate from the app. You bought the app. You did not, perhaps because the upsell was buried or because you tried it on the free tier and forgot, buy the sync. The library exists on one device. When that device breaks, the library breaks with it. The developer is sympathetic. The developer cannot help.
§ III.What Sync Should Be
Sync should be a feature, not a tier. It should be included because the alternative — a library that does not survive a dropped phone — is not a feature, it is a defect. It should use infrastructure the user already pays for, which on Apple devices means iCloud, which every iPhone owner already has, which is already syncing their photos and their notes and their messages, and which can sync a recipe library with no additional subscription and no separate account and no second password to forget.
Basil syncs to iCloud. There is no Basil cloud. There is no Basil account. The library lives on your device, and a mirror of it lives in your iCloud, and when you set up a new iPhone or add an iPad, the library appears there too — not after a manual restore, not after a paid upgrade, but as part of the ordinary process of signing into the device you already own. The recipe you imported on the iPad on Sunday is on the iPhone on Monday. The note you added in cooking mode is on both. There is nothing to configure. There is nothing to pay extra for.
Export, similarly, is not an upsell. The library can be exported — every recipe, in a readable format, including the photos and the notes and the edit history — and the export is yours. If you decide, in a year or in ten, that Basil is no longer the app you want, you take the library with you. The data does not become the app's hostage. It was never the app's to hold.
Sync should be a feature, not a tier. The alternative — a library that does not survive a dropped phone — is not a feature, it is a defect.
§ IV.The Long Quiet Test
There is a test I would propose for any app that asks to hold something of yours over a long horizon. Imagine the app's developer, three years from now, sells the company. Imagine the company that buys it pivots. Imagine the new owners shut the servers down with sixty days' notice. What, on day sixty-one, do you still have?
If the answer is nothing — no library on your device, no exportable archive, no readable file — then the app was never holding your library. It was renting it to you, and the lease has ended. If the answer is the library, intact, in a format you can read, then the app was a tool. Tools are interchangeable. Libraries are not.
The new phone is on the counter in Palermo. The case is on. The screen protector is on. The milanesa recipe — re-imported, since the old library was unrecoverable — opens in cooking mode at the step where the chicken goes into the oil. The iPad on the shelf above the stove shows the same step, same notes, same scaling. There is nothing to configure. The kitchen, for the first time since the drop, feels like a place where dinner can be trusted to be where I left it. Outside, it is 7:42 on another Tuesday. The oil is at temperature. The library, this time, will be there tomorrow.
