How We Maintain 53 iOS Apps

Pocket Grove has 53 apps on the App Store. There is no team of fifty. The interesting question isn't how you write that many apps — it's how you keep them alive once they exist, because a shipped app is a standing commitment. Every iOS release, every App Store policy change, every expired certificate arrives for all 53 at once.

The answer is that almost none of the code lives in the apps.

One package, every app

There is a single Swift package that every app depends on. It holds the things that are identical everywhere and have nothing to do with what any individual app actually does:

• Purchases. One StoreKit 2 implementation, one paywall screen. An app declares what Pro unlocks; it doesn't implement buying.
• Settings. A scaffold that assembles the same rows every app needs — restore purchases, contact us, rate this app, privacy policy — from a description rather than hand-built screens.
• Onboarding. Same idea. An app supplies three or four pages of content; the flow, the paging, the "don't show this again" storage are all shared.
• Design system. Cards, buttons, spacing, colour. Apps that use tokens rather than hardcoded values inherit visual fixes for free.

When we found a bug in the review-prompt logic — prompts silently never firing — the fix went into the package. Every app picked it up on its next build. Had that logic been copy-pasted into 53 targets, it would have been 53 investigations, and realistically it would have been fixed in two of them and quietly left broken in the rest.

That's the whole trade. Shared code means a bug is one fix instead of fifty-three. It also means a mistake ships everywhere at once, which is a real cost and the reason the package changes slowly and deliberately.

New apps start from a template, not a blank folder

Creating an app is a script. It copies a template project, renames things, and fills in placeholders. What you get before writing a single line of feature code: purchases wired up, a settings screen, onboarding, localisation files, a privacy manifest, App Store metadata folders, and a working build.

The point isn't speed for its own sake. It's that the boring parts are already correct. Nobody forgets the privacy manifest, because nobody adds it — it was there from the first commit. The failure mode of shipping many small apps is not that any one of them is hard; it's that each carries a dozen small obligations, and doing those by hand fifty-three times means getting a few wrong.

Localisation happens at write time

Every user-facing string is translated when it's written, not in a push before launch. Four languages minimum — Japanese, Korean, German, Simplified Chinese — with more where it makes sense.

Doing this later doesn't work. "We'll localise before we ship" turns into a hunt through every screen for hardcoded English, and it always misses things: the error message that only appears when the network drops, the empty state nobody saw. Writing the translation alongside the string costs almost nothing. Retrofitting it costs a day per app and still leaks.

What we deliberately don't share

Not everything belongs in the package. Anything a specific app is about stays in that app. A fishing app's solunar calculations, a card scanner's recognition model, a countdown app's date arithmetic — none of that is reusable, and pretending otherwise produces an abstraction that fits nothing.

The test we use: if a second app would need this, and would need it in almost the same shape, it goes in the package. If sharing it would require adding options to make it fit, it stays where it is. Configuration flags are usually a sign that two things that look similar are actually different.

The honest limitation

A catalogue this size means no single app gets daily attention. That's a real trade-off, not a secret. What shared infrastructure buys is that neglect doesn't equal decay — an app nobody has opened in three months still gets the security fix, the iOS compatibility update, and the corrected settings screen, because those arrived through the package rather than through someone remembering.

It doesn't buy new features. Those still need someone to sit down and build them, one app at a time, like anyone else.