DEV Community: Phinn Shen

37 days of zero App Store sales: I pulled the data on all 41 of my apps

Phinn Shen — Wed, 07 Oct 2026 14:58:18 +0000

A real post-mortem from an indie dev. All numbers come from the App Store Connect API and GitHub Traffic API — reproducible.

The short version

I have 41 apps on the App Store. In early October I pulled the Sales Report: from Sep 1 to Oct 7, 37 straight days, daily units = 0. Not "sales slowed down" — not a single sale for over a month.

The contrast stings more: in the same period my GitHub repo was cloned by ~1,000 real users over 70 days (deduplicated, CI excluded), peaking at 80 clones/day. Same developer, same products. A thousand people watching on GitHub, zero transactions on the App Store.

This post is the diagnosis and the fixes. If you ship indie apps, you can skip this hole entirely.

1. First, rule out a broken billing system

Obvious first suspect: the data. Pulled ASC Sales Report day by day:

2026-09-01 units: 0
2026-09-15 units: 0
2026-09-30 units: 0
2026-10-07 units: 0

Side quest discovered here: ASC only keeps ~30 days of Sales Reports. Older requests return 400. If you don't snapshot your sales data locally, long-window retrospectives become impossible. That's also why I now snapshot GitHub traffic into the repo daily.

The data is fine. It's just zero.

2. Then the store structure: 15 live apps, 0 free

Of the 41 apps, 26 are invisible (in review, rejected, delisted). 15 are actually downloadable.

Pulled pricing for all 15 via iTunes Lookup:

$0.99 ×2 · $2.99 ×4 · $3.99 ×1 · $4.99 ×4 · $5.99 ×2 · $9.99 ×2 · $12.99 ×2 (flagship AI workbench)

Number priced at zero: 0.

All paid upfront. No free entry point anywhere.

What that means: no matter where traffic comes from — GitHub, X, dev.to — the user lands on a product page whose first screen is a buy button. No brand, no ratings (0 ratings store-wide, a separate death loop), no trial. The paywall is a wall.

My mistake was classic: when content marketing brought ~40 GitHub clones/day in August, I thought "traffic → trust" was established. Actually the funnel was broken earlier: not one app could be opened and used for free.

3. The fix: a free window

Four apps are now free to download until Oct 31, including my main product KinetBrief (an AI note app). This isn't a clearance sale — it's fixing "can this be used at all" before asking "will you pay".

An ASC gotcha worth recording: iTunes Lookup API caches prices for hours. Don't verify a price change via the API right after making it — you'll see the stale price and panic. The ASC backend price schedule is the source of truth.

4. Traffic-side autopsy: three channels died at once

Reddit (dead, not salvageable)

My account u/PhinnShen now shows "suspended". Post-mortem: in early September I posted product threads across multiple subreddits at a rate of 3 per 24h. By mid-September every post was nuked by the site-level spam filter (115 comments, comment_karma = 0 — not a single one counted).

Two lessons: (1) shadow removal is always visible to the author — you think it's live; nobody else can see it. Verify via third-party archives like Arctic Shift. (2) comment_karma stuck at 0 is the fastest health check that your account is flagged. Flagged accounts have no appeal path; rebuilding takes weeks, so factor that latency into any promotion plan.

X (alive, but dormant)

Account survives, 57 followers, top tweet 89 likes (the build story of a local-first task app). Last post: Sep 30. No ban — I just stopped posting. (Now also carrying a "temporary label" that may reduce reach, so links go in replies, not main posts.)

juejin (my only proven engine, also stopped)

In early August I published a hands-on comparison of 4 AI agent engines running the same real-world task. For those two weeks: 40 GitHub clones/day, the all-time peak. Then I stopped publishing in late September. The one channel the data actually validated — and I went quiet at the best moment.

5. Why 1,000 GitHub clones didn't become downloads

The most interesting finding. 70 days, 1,592 person-days, ~1,000 unique cloners. The traffic was real. But:

They clone the source, not the product. Someone cloning a macOS AI workbench repo can compile it themselves; the App Store build adds nothing for them.
The repo had no conversion hook. The README CTA pointed to GitHub Releases (133 downloads total), not the App Store page. The last meter was never wired up.
The two funnels overlap less than you'd think. GitHub = developers who want to read the implementation. App Store = users who want a working thing. Additive, not interchangeable.

Fix: repo front page now has a 30-second TL;DR and an App Store link; release notes go out on both channels.

6. Summary: 0 downloads = structure × traffic, both zero

Dimension	September state	Fix
Store structure	15 live apps, all paid, zero free entry	4 apps free until Oct 31
Reddit	account site-flagged	rebuild slowly (weeks), short-term write-off
X	alive but silent 37 days	resume weekly posting
juejin	stopped (the only proven engine)	this post is the restart
GitHub → MAS	1k+ clones, zero conversion hook	README redesign

The mirror image: fix structure without traffic, and nobody knows it's free. Fix traffic without structure, and you pour water into a paywall. Indie distribution is multiplication: any factor at zero means the result is zero.

Finally

This is post one of a series. Next: 90 days of building a SwiftUI task manager (FTS5 Chinese search, on-device AI tiering, menu-bar form-factor trade-offs), and a follow-up agent-engine benchmark.

The four free apps (incl. KinetBrief) are searchable as "Kinet" on the App Store, or via the README on my GitHub profile. Bring data-backed criticism, I can take it.

Data sources: ASC Sales Report API + iTunes Lookup API + GitHub Traffic API, pulled 2026-10-07.

I built a task app that stores everything in one plain SQLite file — and I don't regret skipping Core Data

Phinn Shen — Fri, 25 Sep 2026 14:06:45 +0000

This is the engineering story behind KinetTask, a Mac/iOS task app I shipped last week. It's a Show HN-adjacent story but dev.to gets the parts HN would skewer me for. Numbers and regrets included.

The decision everyone told me was wrong

When I started building a local-first task app, every senior Swift dev I asked said the same thing: "Use GRDB. Or SwiftData. Writing SQLite by hand is masochism."

I did it anyway: the SQLite3 C API, directly, in Swift 6.1. Not because I'm tough — because I wanted exactly three things and none of them needed an ORM:

The database file is the export format. Copy tasks.sqlite3 to another machine, it just opens. No "export" feature needed.
Every agent action lands as an append-only journal row — so when the AI planner retries a task, I can diff what actually changed instead of replaying blindly.
Checkpoints store a hash of the normalized artifact. Hash the normalized artifact, not the raw output — timestamps will gaslight you into thinking two identical results differ.

The actual surface area (it's small)

// The whole "ORM":
// - open with WAL + busy_timeout
// - one prepared statement per query
// - one user_version pragma per schema migration step

That's it. A few tables, WAL mode, prepared statements, PRAGMA user_version for migrations. The entire persistence layer is ~600 lines including the journal and checkpoint logic. GRDB would have been 150 lines of my code plus a dependency I'd have to reason about during every weird concurrency bug.

The honest cost: I wrote two use-after-free bugs against sqlite3_stmt in the first week. C API gives you exactly enough rope.

The bug that justified the whole approach (v1.2.1)

My iOS widget was silently losing every checkbox tap. Root cause, the fun kind:

Main app's DB lived in its sandbox Application Support
The widget wrote to the App Group container — a different physical file
Both files happily existed forever. No crash. No error. Just… widget taps vanishing.

Fix: unify the data root (App Group on iOS), migrate legacy DBs, turn on WAL + busy_timeout(2s) because now two processes share one file, and add a snapshot-reconciliation pass when the main app becomes active — because the widget writing to SQLite doesn't magically invalidate the main app's in-memory cache, and its next UPDATE would happily overwrite the tap with stale state.

None of this was exotic. All of it was invisible until a real user compared widget state with list state. With Core Data this specific bug would've been harder to create (shared store coordinator handles cross-process hints) — that's the fair counterargument, and I'd still make the same trade, because I can sqlite3 tasks.sqlite3 on a user's machine during support and see everything.

What on-device LLM actually feels like

The AI features (natural-language capture, "what should I focus on") run on-device: Apple's foundation model where available, a GGUF model via llama.cpp in-process otherwise.

The real numbers nobody puts in marketing:

Cold inference on a 3B model: noticeably dumber than any cloud model. For "parse this sentence into a task with due date" it's fine. For "reorganize my projects" it's… enthusiastic.
The failure mode isn't hallucination, it's over-triggering: the model wants to help when it shouldn't. Fix wasn't a better model — it was an anti-filler gate: if the parse adds no fields beyond what you typed, don't create filler structure.

What I'd do differently

Ship the widget after verifying both processes write the same file. Obvious in hindsight; it always is.
The journal + hash checkpoint design came from my agent-engine side project, and it's the only reason I could debug the retry-drift cases at all. If your app has any automated writes, an append-only log is cheap insurance.
I still don't have sync. The file is yours — iCloud Drive it if you want. v1.2 added a .kinettask backup format for machine moves, which covers 90% of what people actually ask for.

Free for 50 tasks, one-time $4.99, no subscription, no account, no telemetry: App Store

Ask me anything about the SQLite internals in the comments — especially if you think skipping GRDB was stupid, I genuinely want that thread.