Why one person builds native Apple apps

There's a comment in the stylesheet of the ZaatarLABS home page that I like more than most of the code around it:

/* wraps because eight icons no longer fit one row on a phone */
.loader-stage { display:flex; gap: 18px; flex-wrap: wrap; justify-content: center;
                max-width: min(600px, 88vw); }

When the site loads, the app icons drop into a row one after another while a progress bar fills. For a while that row fit on a phone screen. Then it didn't. Nobody filed a bug. I noticed it myself, because I'm the only person who looks.

The fix was one line, flex-wrap: wrap. The comment is there for the next time I wonder why the icons sit on two lines. It's also the most honest summary I have of what this studio is. It's one person, the shelf has grown past what one row can hold, and the person keeps going back to fix the small things.

This post is about how that works and where it doesn't.

What the shelf is

The home page says it plainly: smart Apple apps for clinics, coaches and businesses. They're native apps for Apple platforms, built by me. I'm not porting them from somewhere else or wrapping a web view in an icon.

I'm not going to list the apps and their features here. Each one has a page for that. What I want to explain is the reasoning behind building them this way, because one developer making many apps sounds like a recipe for many half-finished apps. Sometimes it nearly is.

Why native, when there's only one of me

The usual advice for a solo developer is to pick one cross-platform stack, write the code once and ship it everywhere. That saves time, and I understand why people do it.

I went the other way, and the reason is narrow. The people these apps are for, like a clinic, a coach or a small business, already live inside Apple's tools. When an app behaves like the rest of the system, there's less to learn and less to get wrong. When it doesn't, they notice, even if they couldn't tell you what's off.

The cost is real. Everything I build is tied to Apple's platforms. When Apple changes something, I absorb it in every app on the shelf, one at a time. There's no team to split that work with.

The benefit is also real, and it compounds. What I learn building one app goes straight into the next one, because they're all built with the same tools. A fix I work out for one app can often be carried across to the others. That's the only reason one person can keep more than one or two apps alive.

Where the AI runs

Some of this work uses Apple Intelligence. I want to be exact about where that runs, because it's easy to get wrong in marketing copy. Our apps run their AI on Apple's Private Cloud Compute. They don't run it on the device, and I won't claim they do.

That's a deliberate choice. Using Apple's own infrastructure means I'm not shipping your data to a third-party AI provider I picked. The trade-off is that I depend on what Apple offers and when it offers it. If a capability isn't there, I can't patch around it with someone else's model and still keep that promise.

One studio, many palettes

Here's a smaller decision that taught me something.

Each app has its own colours. The Smart Budget, for example, has a bronze palette. The studio itself, meaning the logo, the website and anything that says ZaatarLABS rather than an app name, is green.

I found out how easily those blur. When I built a banner for the studio, it came out bronze, because that was the palette that had been open most recently. It looked fine, and it was wrong. That banner was for the studio, and the studio is green.

It's a small mistake, but it's typical of the failure mode of a one-person shop. The work doesn't go wrong in big ways. It drifts, because whatever you touched last leaks into whatever you touch next. The fix was to write the rule down: per-app colours stay with their app, and anything corporate is green. I don't trust myself to remember it on a busy day.

The same thing happened with icons. A logo file sitting in a marketing folder was not the app's real icon. Now, when the studio needs an app's icon, it comes from the app's own project. The marketing folder isn't trusted.

What I'd tell another solo developer

I don't think building many apps alone is a strategy anyone should copy wholesale. What I'd pass on is narrower.

Pick the constraint that matches your users, not the one that saves you the most time this month. For me that was native Apple apps, because that's where the people I build for already are.

Write the small rules down: which colour belongs to whom, where the real icon lives, why the row wraps. When you're the only developer, a written rule is the closest thing you have to a colleague.

Be precise about what your software does and doesn't do, especially with AI. "Runs on Private Cloud Compute" and "runs on your device" aren't the same claim, and your users deserve the true one.

And look at your own work on a phone now and then. Nobody else will tell you the icons stopped fitting.