We built the hard version
NutHub is a private iPhone app with end-to-end encryption, encrypted media, and an on-device model doing the thinking. It is our product, and it is also the clearest answer we can give to the question a prospective client actually has: can these people ship something where the difficult part is real.
This page is the studio's write-up. The app has its own home at nuthub.app, and if you came here to download it, go there instead — you will get a better pitch and actual screenshots of the current build.
Everybody says private. Almost nobody means it.
Most apps that call themselves private are describing a policy: the company could read your data, has decided not to, and will tell you if that changes. That is a perfectly ordinary product decision and it is worth very little, because a policy survives exactly as long as the company's incentives do.
NutHub is built the other way round. The encryption key is derived on the device from the user's password, or provisioned into iCloud Keychain for Sign in with Apple. What reaches the server is ciphertext. There is no server-side decryption path — not one we choose not to use, one that does not exist — so the honest answer to "what would you do if someone compelled you" is that we would hand over row identifiers, timestamps, an email address, and a set of opaque blobs.
That is the whole difference, and it is an engineering difference, not a marketing one. It also costs something, which is the next section.
If a user loses both their password and their recovery code, their content is unrecoverable. Not difficult to recover — unrecoverable, by us, by Apple, by anyone. We print that sentence in the app, in the privacy policy, and here, because a product that could rescue you from a forgotten password is a product somebody else can compel. Shipping that sentence rather than burying it was a design decision, and it is the one we would defend hardest.
A key that never leaves the phone
The password goes through a key derivation function on the device. The resulting key encrypts every record before it is transmitted and is never sent anywhere. Sign in with Apple takes a different route to the same place: a key generated on the device and provisioned through iCloud Keychain, which is end-to-end encrypted between the user's own devices under Apple's control rather than ours.
The part that takes the time is not the cryptography. It is every ordinary product behaviour that quietly assumes a readable server: search, sync, sharing, migration, and support. Each one had to be redesigned to work against opaque bytes, and that redesign is most of the engineering in this app.
The model runs on the phone. There is no other option in the code.
NutHub uses Apple Foundation Models, executing locally. We are precise about why that matters, because "on-device" gets said loosely: it is not that we decided against sending content to a model provider. It is that the app contains no network path that could carry it — no API key, no inference endpoint, no request that would deliver it.
The trade is a smaller model and a real latency budget on older hardware. What you get back is an app whose intelligence works in airplane mode and cannot leak, which for this product was obviously the right side of the trade.
Photos and video are ciphertext too
People assume images are the exception, and in most products they are, because thumbnails are generated server-side and that requires decoding. Here the stored bytes are not an image. No thumbnail is generated on the server, no dimensions are read, and nothing is indexed — the app does that work locally, after download, in memory.
What our infrastructure knows about a photograph is which account it belongs to, when it arrived, where it sits, and how many bytes it is. That is the complete list.
The parts that were actually difficult
A server that cannot read your records cannot index them. Search is built and maintained on the device, which changes what a first sync costs and how a large library behaves on an old phone.
Changing a password changes the derived key, which means re-wrapping rather than re-encrypting a whole library. Getting that right, resumable, and safe to interrupt is not a weekend.
We cannot look at an account to debug it. So the app has to explain itself, produce diagnostics that contain no content, and fail in ways a person can describe over email.
The recovery-code screen is the highest-drop-off moment in an app like this, and softening it would raise conversion. We wrote it straight and designed around the drop instead.
If your thing has a part like this in it
Cryptography you cannot fake, a model that has to run somewhere awkward, a consequence you would rather tell users about than hide — that is the work we want. Tell us the part you think is impossible.