Three small iOS apps, and what each of them taught me

Five apps ship under CUTI LLC, the company I ran my counseling practice under. Three of them are small on purpose: Mutterly, a voice journal; iLovable, a box of therapy tools; and toss.it, a timer you start by throwing a die. Their App Store pages list them at 813.4 MB, 13.5 MB and 2.4 MB, and that spread turned out to be the most useful thing I took out of building them.

Why three small apps instead of one large one?

Because a small app can be finished, and a finished app is the only kind that teaches you anything.

The store keeps the receipts. Mutterly and iLovable went up on January 2, 2026, toss.it on January 6, and a fourth, panic.btn, on January 15: four first releases inside two weeks. Those dates come back from Apple's own lookup endpoint, itunes.apple.com/lookup?id=6757206887 and its siblings, which I checked again on September 4, 2026. Each one had a single job I could say in a sentence before opening Xcode.

Small numbers follow, and I am not going to dress them up. Each of the three carries exactly one rating on its product page, and I have no install figures worth publishing. They were instruments rather than hits: three answers to the same question, which is where a person's data should live when the thing they are holding is meant to help with something hard. The other half of the story, signing, TestFlight and a rejection I could not fix in code, is in a separate post on shipping native as a web studio. This one is about the products.

What did Mutterly teach me about a privacy promise?

That a promise a person can test is worth more than a promise they have to believe.

Mutterly's job is narrow: talk for twenty seconds, get the day back as writing. The store description caps the recording at "quick 20-second bursts (up to 40s for Premium)", and then makes the claim the whole app is built around. It "runs completely locally on your iPhone using the Llama 3.2 model", and "It even works offline in Airplane mode".

That second sentence is the design. A privacy policy is a paragraph you either trust or do not. Airplane mode is a switch on the phone already in your hand. Flip it, record, wait, and either the summary appears or the promise was false. It moved the app from something I had to argue for to something a stranger can check in ten seconds.

It cost 813.4 megabytes. That is the figure on the product page, and the app is that size because the weights ride along in the bundle: most of that download is the model rather than the app around it. The switch is dated in the release notes, in version 2.1 on January 24, 2026, titled "BIG UPDATE: Native On-Device AI is here!" and describing the engine as "Powered by Llama 3.2 (1B), optimized for Apple Silicon". Before that update, the writing happened somewhere else, and the build is its own case study.

Two honest footnotes. The first is that a cloud path still exists, and the store copy names it: a "Cloud AI Option" offering larger models "via the Cloud (Optional)". It is off until somebody turns it on and pays for it. The default is the promise and the option is an option, which I would rather write plainly than pretend the binary has no network code in it.

The second is a license. Open weights inside an App Store binary are still distributed weights, and the Llama 3.2 Community License Agreement is specific about what that obliges:

If you distribute or make available the Llama Materials (or any derivative works thereof), or a product or service (including another AI model) that contains any of them, you shall (A) provide a copy of this Agreement with any such Llama Materials; and (B) prominently display "Built with Llama" on a related website, user interface, blogpost, about page, or product documentation.

A blogpost is one of the places that clause names, so, plainly: Mutterly is built with Llama. If you are thinking about bundling a model, read the agreement before you write the About screen. The attribution is a shipping requirement, not a courtesy.

What did iLovable teach me about putting therapy tools on a phone?

That a paper exercise survives the trip to a phone only when it is already a list, a scale or a count.

iLovable is 13.5 MB, and its store page lists what is inside: a journal with daily prompts, a mood tracker with visual trends, a CBT chain for challenging a thought, an IFS parts map, a fear inventory, and a recovery coach with sobriety tracking and daily inventories. Six tools, no accounts, and one line in the description that is really the architecture: "All your data stays on your device. No cloud sync, no accounts required."

This is the section where my other decade shows up in the code. I spent ten years in mental health, residential treatment and then a private practice, and I still work in a county jail. The exercises I reached for most were the portable ones. A parts map is a page of names and roles. A CBT chain is a sequence: situation, thought, feeling, behavior. A mood rating is a number with a date on it. Sobriety is a count of days. Every one of those was already a small data structure that happened to be living on paper, which is why they port cleanly and why the app is 13.5 MB rather than something clever.

The day counter is the clearest case. I did not add it to manufacture a habit, which is what a streak in a productivity app is for. Recovery already counts days, out loud, in rooms, with chips at thirty and sixty and ninety, so the counter matches a count people are already keeping and shows the same milestone they are already watching for. Matching a practice that exists is a far safer design decision than inventing a new one for somebody to fail at. Where that instinct comes from is its own post about the clinical decade.

What is not in there is the part of the work that needs another person in the room, and it should not be. iLovable is a place to keep the work between sessions. It is not a stand-in for the sessions.

What happened to Toss It?

It shipped as a different app from the one I wrote down.

The case study I drafted for it, still unpublished on my own site, describes a letting-go ritual: write down what is weighing on you, crumple it, throw it away. What is on the store under that name is a focus timer. You flick the screen, a 3D die tumbles and settles on 15, 25 or 45 minutes of focus or a 5 or 10 minute break, and, in the description's words, "The timer starts the second the die stops. No 'setting time.' No backing out." It is 2.4 MB, rated 4+, and filed under Productivity rather than anywhere near Health.

My notes do not record the day the idea turned, and I am not going to invent one. What I can compare is what the two versions ask of a person. The letting-go version asks somebody to reach for an app in the worst minute of their day. The timer asks them to reach for it while they are avoiding something, which happens on a schedule and is a much easier moment to catch. That is a reading after the fact, not a note from the time.

The entry on my own site is still a draft, which is the right place for a case study describing an app that does not exist.

What do the three actually share?

One line, in the same place on all three product pages: Data Not Collected.

That panel is not marketing copy I wrote. Apple's page on app privacy details explains that a developer supplies the answers in App Store Connect and that "This information is required to submit new apps and app updates to the App Store", so the label is a declaration made under Apple's rules and shown to a person before they download anything.

Underneath the label they are the same shape: no account, no login, no row on a server with somebody's name on it. Nothing to breach, and nothing for anyone to come and ask me for later. The download column is where they stop being alike, and it is the interesting one. 813.4 MB against 2.4 MB is a factor of 339, with an identical promise attached to both. Keeping data on the device is free when the app only has to store it. It costs the weight of a model when the app has to think about it.

Why native, when a web app would have shipped sooner?

For two of the three, because the phone does something a browser tab cannot. For the third, honestly, because of where people look.

toss.it needs the die to feel like it landed, and MDN's browser compatibility data records Navigator.vibrate() as unsupported in Safari, with the iOS entry mirroring the desktop one. A web page cannot make a phone tap back. Take the haptics out of that app and what is left is a countdown with extra steps.

Mutterly is a closer call than it would have been a year ago. WebGPU landed in Safari 26 and the compatibility data mirrors that to Safari on iOS, so a browser tab can genuinely run a small model on an iPhone now. What a tab cannot do is guarantee the weights are still there. They arrive over the network into storage the browser is allowed to evict, and at that point "it works in Airplane mode" stops being a sentence I can put on the box. Bundling is the only version of that promise I know how to keep.

iLovable is the honest case. Almost all of it would work in a browser: forms, a chart, a counter, local storage. The reasons it is native are that the App Store is where a person goes looking for a therapy tool, and that the privacy panel above has no equivalent on the open web, where I would be asking for the same trust with nothing behind it but my own sentence. Where exactly that line falls, and what a home screen web app can and cannot do now, I worked through in the native post rather than here. All three are one-thumb interfaces before they are anything else, which is the point of designing mobile-first for one thumb.

What would I build differently now?

I would think a great deal harder before bundling the weights again.

Since iOS 26, Apple ships a model instead. The Foundation Models framework hands an app the on-device model behind Apple Intelligence, which Apple's own research write-up describes as "a compact, approximately 3-billion-parameter model", roughly three times the parameter count of the one Mutterly carries. The framework documentation is blunt about the catch:

To use Apple Foundation Models, people need a device that supports Apple Intelligence.

That is the whole trade in one sentence. Mutterly's floor is iOS 17, which reaches a much wider set of iPhones than Apple Intelligence does, and it pays 813.4 MB for that reach. An app built on Foundation Models downloads at an ordinary size and silently excludes every device Apple Intelligence does not cover. I do not know which side of that trade is right for a journal, because the answer is a distribution of the phones the people using it actually own, and I do not have that number. On a server I answer the same question with a cascade across providers. On a phone there is no cascade. There is a floor, and you pick it once.

So the next thing I owe Mutterly is not a feature. It is a stopwatch: how long a day's summary actually takes on the oldest iPhone that still runs iOS 17, because the minimum in that column is a promise made to that phone as much as to a new one, and I have never sat down and timed it.