DEV Community: 孫昊

I Shipped a Web Edition of My iOS App Today — While the iOS Version Was Still Awaiting Apple Approval

孫昊 — Wed, 29 Apr 2026 16:23:25 +0000

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.writeText does 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.
localStorage for user state. When users start saving their own prompts, they go in localStorage. 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.writeText with a document.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.

How I Sniffed Xiaohongshu's Collection API in 90 Seconds — and Why CORS Made Me Rewrite the Whole Approach

孫昊 — Wed, 29 Apr 2026 15:45:05 +0000

TL;DR

I needed to pull a user's saved-posts list from Xiaohongshu (China's Instagram-meets-Pinterest) for offline analysis. Their web client renders the data, but their API has a request-signature scheme that defeats casual scraping. After three failed approaches — Playwright sniff, manual cookie injection, direct API fetch — the working solution turned out to be the inverse of "automate the API call": let the browser issue the request and listen for the response. 250 saved posts in 90 seconds. Here's what each approach taught me.

This is part 2 of a series. Part 1 covered shipping four iOS apps with one Claude Code agent; this part is one of the agent's harder side-quests.

The setup

I'm building an offline AI-prompt manager for iOS. I needed evidence that "AI-related content" was a real user interest signal, not just a guess. The cheapest evidence: my own saved-posts history on Bilibili and Xiaohongshu. Bilibili had a clean public API — 347 items pulled in 30 seconds. Xiaohongshu? Different story.

Stack used throughout:

Python 3.12
Playwright 1.50 with Chromium
macOS / Windows compatible (subprocess.run + pathlib)
Storage state persisted as JSON for re-entry without re-login

Attempt 1 — login + cookie polling

The standard Playwright pattern: launch a headed browser, let the user log in interactively, watch for a "logged-in" cookie to appear, save the storage state.

# login_and_save.py — first version
def has_login_cookie(context, name: str) -> bool:
    cookies = context.cookies()
    return any(c.get("name") == name and c.get("value") for c in cookies)

# Polling loop
while time.time() < deadline:
    if has_login_cookie(context, "web_session"):  # XHS sets this on login
        context.storage_state(path=str(state_path))
        browser.close()
        return 0
    time.sleep(2)

I ran the script. It happily reported "登录成功! storage state saved" within 5 seconds — even though I hadn't actually scanned the QR code yet. The cookie was set, but…

# Probe: am I really logged in?
resp = page.request.get("https://edith.xiaohongshu.com/api/sns/web/v2/user/me")
data = resp.json()
print(data["data"]["guest"])  # → True

Lesson 1: Xiaohongshu sets the web_session cookie immediately on first page load — for guest users too. The cookie is not a login signal. It's a session ID that gets associated with a user only after authentication.

The fix: poll for guest: false from the actual /me endpoint, not for cookie presence.

def _xhs_logged_in(page, context) -> bool:
    try:
        resp = page.request.get(
            "https://edith.xiaohongshu.com/api/sns/web/v2/user/me",
            headers={"Accept": "application/json"},
        )
        return resp.json().get("data", {}).get("guest", True) is False
    except Exception:
        return False

This works. After a real login, guest: false flips. Storage state saves cleanly.

Attempt 2 — direct API fetch

Now logged in. Time to find the collection endpoint.

I started with educated guesses based on naming conventions seen on similar Chinese apps:

candidates = [
    "https://edith.xiaohongshu.com/api/sns/web/v1/note/collect_page?num=20&cursor=",
    "https://edith.xiaohongshu.com/api/sns/web/v2/note/collect_page?num=20&cursor=",
    "https://edith.xiaohongshu.com/api/sns/web/v1/user_posted/collected?num=20",
    "https://edith.xiaohongshu.com/api/sns/web/v1/user/collected?num=20",
]

Every single one returned 404 page not found. Not 401, not 403 — a flat 404. Either the endpoints had been renamed, or my guesses were wrong on a fundamental dimension.

Lesson 2: When you guess endpoints and get 404 across all variants, stop guessing. Sniff what the browser actually does.

Attempt 3 — Playwright network sniff

I added page.on("request") and page.on("response") listeners and navigated to the user's profile in a headed browser. Then I let myself click around manually and watched what the browser fetched.

def on_request(req):
    url = req.url
    if "xiaohongshu.com/api/" in url or "edith.xiaohongshu" in url:
        captured.append({
            "method": req.method,
            "url": url,
            "headers": dict(req.headers),
        })

90 seconds of clicking and scrolling produced 41 captured API calls. The interesting one:

GET https://edith.xiaohongshu.com/api/sns/web/v2/note/collect/page
?num=30
&cursor=
&user_id=...
&image_formats=jpg,webp,avif
&xsec_token=
&xsec_source=

So the path is note/collect/page (singular note, slash-separated collect/page) — not note/collect_page, not user_posted/collected. None of my guesses had been close.

I copied that URL into a direct script invocation:

url = "https://edith.xiaohongshu.com/api/sns/web/v2/note/collect/page?num=30&cursor=&user_id=...&image_formats=jpg,webp,avif&xsec_token=&xsec_source="
resp = page.request.get(url, headers={"Accept": "application/json", "Origin": "...", "Referer": "..."})
print(resp.json())
# → {"code": -1, "success": false}

Lesson 3: A request that the browser issues successfully will not necessarily work when you replay it directly — even with the same cookies. The server is checking something else.

What broke: x-s signature headers

Xiaohongshu uses a request-signature scheme. Every API call from the official web client includes three headers:

x-s (a hash signature)
x-s-common (a "platform fingerprint" payload)
x-t (a timestamp)

These are computed by the front-end JavaScript before each fetch. The implementation lives in heavily-obfuscated bundle code that runs in the browser and signs each request based on the URL, body, and a per-session secret.

To reproduce these signatures from Python you'd need to either reverse-engineer the obfuscated signing code (hours; brittle to bundle updates) or run a JS engine alongside Python (overhead; jsdom doesn't quite work because the real bundle expects browser APIs).

Both options are bad-ROI for a one-shot offline analysis.

Lesson 4: When the platform makes API replay expensive, don't replay. Borrow the browser's signing for free.

The fix: let the browser issue the request, listen for the response

The signed-request problem disappears if you don't issue the request from your code at all. Instead:

Have Playwright drive the page to load whatever data you want (clicking the right tab, scrolling)
Let the front-end JS sign and issue the calls itself
Listen to the HTTP responses with page.on("response") and capture the JSON bodies

pages_data: list[dict] = []
last_response_time = [time.time()]

def on_response(resp):
    if "/api/sns/web/v2/note/collect/page" in resp.url and resp.status == 200:
        body = resp.json()
        pages_data.append(body)
        last_response_time[0] = time.time()

page.on("response", on_response)

# Navigate + click collection tab + scroll loop
page.goto(f"https://www.xiaohongshu.com/user/profile/{user_id}")
page.locator("[class*='reds-tab']:has-text('收藏')").first.click()
time.sleep(3)

for _ in range(60):  # cap
    page.evaluate("window.scrollTo(0, document.body.scrollHeight)")
    time.sleep(1.2)
    if time.time() - last_response_time[0] > 8:  # idle = done
        break

Each scroll triggers another collect/page request from the front end. The front end signs it correctly. The server returns paginated JSON. My listener captures the body.

250 saved posts in 25 paginated responses, ~90 seconds end-to-end.

The full output is structured cleanly:

{
  "data": {
    "notes": [
      {
        "note_id": "...",
        "type": "video",
        "title": "ai直接把我公寓租出去了 把我家具也卖了",
        "user": {"nickname": "L"},
        "interact_info": {"liked_count": "8650"}
      }
    ],
    "cursor": "...",
    "has_more": true
  }
}

What this enabled

With 250 collected posts in JSON, I ran simple keyword-based classification (regex against ~15 tightened patterns covering LLM/Chat, Image-Gen, Video-Gen, Coding-Agent, Agent/Automation, Voice/Music, RAG/Embedding, General-AI):

36 of 250 were AI-related (14.4%)
Top signal: 21 posts about LLM/Chat (Claude Code being the dominant brand — 11 posts mentioned it directly)
Second: Coding-Agent (Cursor / Aider / Continue) — 11 posts (notably 0 in my Bilibili sample, suggesting Xiaohongshu is where the user's "newer" interest pattern shows up)

These signals fed directly into product decisions for the iOS prompt-manager app I'm shipping. The "Claude Code starter prompts" section of the bundled prompt library got expanded from 0 to 7 items — driven by behavior data, not guess.

Generalized lessons for any "scrape from a hostile API" problem

A cookie isn't necessarily login state. Test with an actual identity-API call.
404 across multiple endpoint guesses = stop guessing. Sniff the browser instead.
API replay fails on signed requests. That's the platform's threat model talking.
Don't fight the signature scheme. Outsource it to the browser. Drive the page, listen to responses.
Idle detection > fixed scroll count. Loop until N seconds without new responses, not until N scrolls.
Keep the user out of the polling loop. A working "did the user log in" detector should poll an authoritative API, not a side-effect cookie.

Cost analysis

Approach	Engineer hours	Reliability
Reverse-engineer x-s signatures	4-8 hrs	Brittle to bundle updates
jsdom + bundle replay	6-12 hrs	Memory-heavy, fragile
Playwright + response listener (this post)	30 minutes	Works as long as the UI tab works

The browser-as-signer approach is also more honest: you're using the same code path the site expects you to use. You just happen to keep the data around.

Code

The full set of scripts (login, sniff, collected, analyze) lives in the AutoApp toolkit repo. License is MIT.

If you adapt the response-listener pattern to other Chinese platforms (Douyin / Zhihu / Jike), I'd love to hear what works.

I Let One AI Agent Ship My Entire iOS Portfolio. Here's What Broke.

孫昊 — Wed, 29 Apr 2026 15:45:04 +0000

Over the last two weeks, a single Claude Code agent — operating with my approval only at four "hard gates" (Apple Developer enrollment, payment info, App Store final-acceptance, and any third rejection of the same app) — has scaffolded, polished, and prepared four iOS apps for the App Store.

Total human time investment: probably 4 hours of decisions plus the time to read this post. The apps share an identity: every one is offline-first, ships a one-time IAP at $2.99, has zero analytics SDKs, and runs on a Privacy Manifest that is verifiable from the source code.

What follows isn't a "look how easy AI makes shipping" piece. It's a structural breakdown of where one autonomous agent works extraordinarily well, where it stalls, and the orchestration layer I had to build for it to operate without becoming a chaos engine.

The four apps (concrete, not abstract)

For credibility, the actual technical fingerprints:

AutoChoice (decision wheel, Lifestyle category) — com.jiejuefuyou.autochoice
AltitudeNow (offline barometric altimeter, no GPS, Health & Fitness) — uses CoreMotion's CMAltimeter
DaysUntil (countdown list, Productivity, no notifications) — single screen, JSON persistence
PromptVault (offline AI prompt manager with {{variable}} substitution, Productivity) — driven by the agent itself analyzing my Bilibili + Xiaohongshu saved-content history to find a real user need (this is the meta moment: agent built an app whose first user was the agent's own observed behavior pattern)

All four binaries run zero network calls. Verify:

nm -gU <app>.app/<app> | grep -iE 'URL|HTTP|Network'

returns nothing in any of them. The Privacy Manifest declares zero data collected; the source confirms it.

The orchestration layer (the part nobody else writes about)

Most "I used AI to build my app" posts stop at "I used Cursor / Claude Code." This one shows the layer underneath that makes the agent operable:

~/.claude/projects/.../memory/
  user_persona.md          — communication style; injected into every subagent prompt
  feedback_autonomy.md     — exactly what authority is delegated, exactly what isn't
  project_autoapp.md       — current state, identity facts, decision history

orchestrator/
  state.yml                — single source of truth across 4 product repos
  decisions.md             — append-only ADR log; every non-trivial choice has a paragraph
  RESUME.md                — what the agent reads first when re-entering a session
  verify_all.sh            — runs across all 4 repos, checks 32 ASC hard requirements
  setup-asc-secrets.sh     — one command to populate 8 secrets × 4 repos
  asc_sales_report.sh      — pulls daily TSV from App Store Connect API after launch
  dday_runbook.sh          — generates platform-specific launch posts on submission day

The lesson: the orchestration layer is the bottleneck, not the model. A 5-hour rolling token window is plenty if the agent doesn't waste cycles re-deriving context every session. The memory system + state.yml + ADR + RESUME.md is what makes the agent re-entrant. Without it, the same agent would burn half its context on "where was I?" instead of shipping code.

The toolkit is open source: github.com/jiejuefuyou/autoapp-toolkit (MIT).

Where it works extraordinarily well

Repository scaffolding. Cloning a working template into a new product, doing 50 search-and-replace operations, fixing the inevitable Swift "redeclaration of body" naming collision (because var body in a SwiftUI View clashes with the View.body requirement and you only catch it at compile-time), pushing to a fresh gh repo create-d origin. Hours → minutes.
Cross-platform reasoning. Every app is iOS but the build/sign/release surface area is one of the worst in software (Xcode + fastlane + match + StoreKit 2 + Privacy Manifest + ASC API). An agent that has all of this in context simultaneously beats the human pattern of "let me look up the right INFOPLIST_KEY_* again."
Cross-platform data ingestion. The agent built its own browser automation harness (Playwright + cookie polling) to pull 597 saved items from Bilibili (347) and Xiaohongshu (250), classify 63 of them as AI-related, and propose a fourth product (PromptVault) backed by direct user-behavior signal — then scaffolded that product. This is the kind of thing that's not "AI replaces engineer," it's "AI does something an engineer wouldn't bother to do."

Where it stalls

Be honest, this is what makes the post earn HN's respect:

Sensory taste decisions. App icons. Two attempts at CoreGraphics-drawn icons came out "fine but generic." A human designer in 30 minutes does better.
Domain expertise outside its training data. When Xiaohongshu added a new client-side request-signature scheme, the agent's first 5 attempts at the API endpoint failed silently. It needed me to say "the headers are signed by JS, you have to let the browser issue the request." Without that nudge it would have looped. (Full write-up coming in part 2 of this series.)
Reversible vs. irreversible action discrimination. Without explicit gates in feedback_autonomy.md, the agent over-asks ("should I commit this?") on reversible actions and under-asks on irreversible ones. The orchestration layer's job is to put those gates in the right places.

Pricing thesis (what makes this a startup story not just a tech demo)

Every utility iPhone app published in the last three years follows the same monetization playbook: subscription, $4.99-$9.99 per month, free tier crippled.

The thesis I'm testing: for utility apps, one-time IAP at $2.99 is a strictly better model in 2026.

App Store conversion benchmark in Utilities: 48.6%. One-time IAP shows 25-45% higher purchase rate vs. subscription in this category (Adapty 2024 report).
Subscriptions create churn surface area. One-time IAP has zero churn surface area.
For utility apps, "lifetime value" is a fiction — most users uninstall within 30 days. The subscription model overprices early users and underprices the long tail.
App Store reviewers (humans, with their own grievances) are softer on apps that don't pull subscription tricks.

If the AutoApp portfolio's first month shows revenue, the thesis confirms — and the agent can replicate it. If it shows $0, the thesis dies, and I fold this back into a personal-use side-quest. Either way it's testable.

What the agent didn't do

To preempt the snarky comment that says "you're just using AI as a glorified template engine":

The agent did not:

Write its own privacy policy from scratch (I reviewed and edited template output)
Make any decision about pricing, category, or "should I ship this app at all"
Touch my Apple Developer account or payment information
Ship anything to the App Store without my explicit go (still a hard gate)

It did:

Make 100% of small implementation decisions (variable names, file structure, error handling, when to refactor vs. when to leave it alone)
Decide which 4 apps to scaffold (with my opt-in to "go" on each)
Choose the brand identity per app (icons, color palette, copy tone)
Negotiate its own constraints — when it found a Swift 6 strict-concurrency warning that would block future Xcode upgrades, it fixed it without being asked, because feedback_autonomy.md says "fix the root cause, don't ship the symptom"

Coming next in this series

Part 2: How I sniffed Xiaohongshu's collection API in 90 seconds — and why CORS made me rewrite the whole approach. (Drops in 3-5 days.)
Part 3: Memory layers in a Claude Code agent — and why yours probably needs them.

The four apps will hit TestFlight as soon as Apple Developer enrollment clears. I'll publish first-week data either way it goes.

Either the orchestrator + agent layer makes shipping iOS apps a 4-hour decision cost, in which case the App Store is about to get a lot more crowded and the floor for "is this app worth it" rises. Or the model misses on something that humans currently don't even notice we're doing — and the next year is about discovering what that is.

Either way, the experiment is testable. I'll publish the revenue data either way.

Repos:

AutoChoice
AltitudeNow
DaysUntil
PromptVault
autoapp-toolkit (MIT — fork the orchestration layer)