This is part 6 of a series about shipping four iOS apps with one Claude Code agent. Previous parts cover shipping the apps, API sniffing, memory layers, and the verifier.
The bottleneck nobody talks about
I had four iOS apps scaffolded, polished, and ready to submit. Build pipeline green. Privacy Manifest declared. Metadata in en-US and zh-Hans. Fastlane match certs ready to bootstrap.
What I didn't have: an approved Apple Developer account.
Apple Developer enrollment takes 24-72 hours after you pay the $99 fee. I'd applied. I was waiting. The agent and I had nothing to do that depended on Apple — except actually putting the apps in front of users.
For 36 hours my portfolio was a paused product. The toolkit on my disk was theoretical until someone could install one of the apps and use it.
This is the moment most indie devs accept as part of the process. "Apple takes a few days, that's just iOS." But there's an obvious question I hadn't been asking: does the value prop need iOS?
For PromptVault — an offline AI prompt manager with {{variable}} substitution — the answer is unambiguous: no.
A native iOS app gives you:
- Native UI (good)
- Offline storage in the app sandbox (good but a browser has localStorage and the prompts are bundled)
- One-tap copy with system clipboard integration (good but
navigator.clipboard.writeTextdoes the same thing)
It costs you:
- Apple Developer enrollment + the $99 + tax forms (real)
- App Store Review (real, 24-48 hours per submission, can be rejected)
- The walled garden's mood
For users who don't have an iPhone, or who use prompts on their desktop, or who want to try before they commit — the web edition is better, not worse.
So I shipped a web edition.
The build, in 90 minutes
The decision: take the bundled starter_prompts.json (113 prompts, ~50 KB) and ship it as a standalone HTML page with embedded JSON + interactive UI.
What I wrote:
-
index.html— landing page (200 lines of HTML/CSS, brand-aligned with the iOS apps) -
prompts.html— the actual app (one HTML file, ~60 KB total including all 113 prompts inlined)
Stack:
- Vanilla HTML/CSS/JS
- No build step
- No framework
- No backend
- No analytics
- No third-party requests
It runs entirely in the browser. The prompts JSON is embedded into the script tag at build time. Variable substitution is a regex. Copy-to-clipboard is navigator.clipboard.writeText. Search is a string includes. Tag filter is an array find.
<script>
const PROMPTS = [/* 113 prompt objects, embedded inline */];
function renderPrompt(body, values) {
return body.replace(/\{\{\s*([^}]+?)\s*\}\}/g, (m, name) => {
const v = values[name.trim()];
return v && v.length > 0 ? v : `{{${name.trim()}}}`;
});
}
async function copyCurrent() {
const text = renderPrompt(activePrompt.body, values);
await navigator.clipboard.writeText(text);
}
</script>
Hosting: GitHub Pages, free, automatic deploy on push to main. URL: https://<username>.github.io/.
Total elapsed time from "let's ship the web edition" to "live in browser": ~90 minutes including the visual polish.
What I gave up
The iOS version, when it ships, will have:
- Native dark mode that follows system settings
- Haptic feedback on copy actions
- iCloud Drive document picker for backup
- Per-prompt usage statistics
- Native search performance for very large prompt libraries
The web edition has none of this. For a 113-prompt library, none of this matters yet. Native search is only meaningfully faster than browser-side filter at ~10,000+ items.
What the web edition has that the iOS version doesn't:
- Zero install friction. Click a link. Use the prompt. Close the tab.
- Cross-platform by default. Android users can't install my iOS app; they can use the web edition.
- No App Store gatekeeping. I shipped it the day it was ready, not 24-48 hours after Apple's review.
- Verifiable privacy in DevTools. Open Network tab; see zero requests to anywhere. I can't fake this.
The strategic angle
The web edition is not a replacement for the iOS app. They're complementary funnels for different users:
- Web edition → fast trial, low friction, casual user. Maybe converts to iOS install if they have an iPhone and want native polish.
- iOS edition → pays $2.99 for the native experience.
The honest pricing model:
- Web edition: free forever
- iOS edition: $2.99 one-time
This isn't "freemium with an upgrade nag." It's two products with overlapping value props at different points on the cost/convenience curve. Some users will only use the web. That's fine. They wouldn't have paid $2.99 for an iOS app anyway. Other users will discover via the web edition that they want it on their phone, and they'll buy.
The web edition is a funnel. The iOS edition is the conversion target.
The "why didn't you do this first" question
Honest answer: I didn't realize the web edition was an option until I'd already spent two weeks on the iOS version.
The default mental model when you hear "iOS app" is "iOS app." The agent wrote SwiftUI views. The toolkit handles XcodeGen, fastlane, App Store Connect. Nothing in that flow made me ask "wait, does this even need to be iOS?"
The moment I asked it — looking at my INBOX folder of "things you need to do" while the Apple email hadn't arrived — the answer was obvious.
If I were starting from scratch today, I'd ship the web edition first. Then decide if iOS is worth the additional ~$99 + 1-2 weeks of build/sign/release pipeline cost.
For most utility apps with no strong sensor / OS-integration story, the web edition first is the right ordering.
What this enables
The dev.to article you're reading has a link to the web edition. That link works today. People who read the article and click are using the product within seconds. The conversion funnel from "saw the article" to "tried the product" is one click, not "go to App Store, install, open app."
For the indie dev: this is enormous. Article + working product on the same day = real engagement loop. Article + "TestFlight invite-only" = mostly performance.
The technical wins of the web-first approach
For people considering this: the pattern that worked.
Bundle data, not reference it. All 113 prompts are inlined into the HTML. No backend; no API; no rate limits; no server costs; no DB to maintain. The HTML is also the database.
localStoragefor user state. When users start saving their own prompts, they go inlocalStorage. No accounts. No sync. If they want sync, they install the iOS app + buy the IAP.Embedded fonts + zero external requests. I didn't import a font, didn't import an icon library, didn't import an analytics SDK. The page loads from one HTTP request to one HTML file. Total transfer: ~62 KB.
navigator.clipboard.writeTextwith adocument.execCommand('copy')fallback. Works on every browser since 2016.GitHub Pages handles hosting. I push to
main, the page deploys automatically. No CDN to configure. No DNS to manage. Free.
The total cost of running this web edition for the next 5 years is $0.
What I'd tell anyone shipping a utility iOS app today
Ship the web edition first. Use it to validate your value prop with real users while you wait for Apple Developer enrollment. If 100 people use the web edition, that's 100 data points on what's working — before your first App Store submission.
The web edition is also the marketing surface. Every dev.to article, Substack issue, Reddit thread, HN comment can link directly to a working product. The conversion path is one click.
The iOS edition is the paid funnel endpoint. The web edition is the traffic source. Build them in that order.
Where to see it
https://jiejuefuyou.github.io/prompts.html — try it. Search "Claude Code". Click any prompt. Fill the variables. Hit copy.
github.com/jiejuefuyou/jiejuefuyou.github.io — fork the source if you want to ship a similar pattern for your own product.
The iOS edition will land on the App Store when Apple Developer enrollment clears. Updates here.
Coming next: the post-launch reckoning. First week of real ASC sales data, published either way it goes. Subscribe at autoappnotes.substack.com if you want the numbers.
Top comments (0)