What Took Longest in a Solo Developer App Release Wasn’t the Code
AI made building the app fast. Shipping it took a week — and less than half of that was writing code. Notes from releasing a small free PDF tool: the review delays, the fiddly work nobody sees, and the distance between a script and a product.

I Watched a "Waiting for Review" Screen for Six Hours
I had a small Python script I used at work — the kind of thing that converts PDFs to images and reorders pages. Pure chore code. A colleague who doesn't write Python asked whether I could make it usable for them too, so I decided to bundle it into an executable. I figured that was half a day of work.
Instead, the solo developer app release stretched past a week, and less than half of that time went into writing code. One day I sat watching Apple's notarization status say "In Progress" for over six hours. A separate app spent days stuck in App Store review. My first assumption was that I had done something wrong. Then I looked it up and found this wasn't my problem alone.
The Numbers Behind the Flood
According to app analytics firm Appfigures, worldwide app releases in Q1 2026 were up 60% year over year — and up 80% on iOS alone. Roughly 560,000 new apps landed on the App Store in the first half of 2026, close to the total released across all of 2025.
The usual explanation is vibe coding: building apps by describing them to an AI tool. When the cost of producing something approaches zero, a surge in submissions is the predictable result.
One caution: the "84% surge" figure quoted in several articles has no disclosed methodology or primary source. The numbers you can actually verify are the 60% worldwide and 80% iOS figures above.
Making Got Easier. Getting Through Got Harder.
The strange part is that the stores themselves are shrinking. Google Play went from roughly 3.4 million apps in early 2024 to about 1.89 million by July 2026. In 2025 alone, Google blocked 1.75 million apps for policy violations.
Apple revised its App Review guidelines at WWDC in June 2026. It can now remove apps that sit unmaintained, ship poor quality, or copy existing functionality — including apps already published. It also named saturated categories such as flashlights, wallpapers, simple timers, and soundboards, saying new submissions there won't be accepted unless they're meaningfully better. Repeat offenders were warned they could lose access to the Apple Developer Program entirely.
Submissions climb by double digits a year while downloads grow 2–3%. The entrance widened and the bottleneck tightened at the same time. Apple still reports reviewing 90% of submissions within 48 hours, but developers keep reporting that the remaining 10% has stretched badly. My six hours lived in that 10%.
What a Solo Developer App Release Actually Costs
The review queue isn't really my point, though. The point is that most of that week went to everything except the code.
Here's what actually broke in the free PDF tool I shipped:
- Saving failed on Windows only. I was writing over a file while its source was still open — Windows locks files; macOS doesn't care.
- The app quit instantly on Windows. I had bound a macOS-only event unconditionally. Because it was a windowed build, it died silently with no error dialog, which made it slow to trace.
- The icon shipped as a generic floppy disk. One missing line in the build command.
- A 455-page PDF froze the app. My test file had 20 pages.
- Two-finger trackpad scrolling didn't work. It's how I scroll every day, and I never once checked it during development.
None of It Was an Algorithm Problem
Read that list again and the pattern shows. Not one of those was "I wrote the logic wrong." Every single one happened at a boundary — between my code and an operating system, a real file size, a user's muscle memory, a distribution pipeline.
And every one of them surfaced only because somebody actually used the thing. AI built what I asked for, quickly and well. But it doesn't volunteer "does this even launch on Windows?" To ask that question, you have to know the boundary exists in the first place.
The Distance Between a Script and a Product
A script you run yourself and a product you hand to someone else are different objects. A script only has to work under conditions you already know. You know the file path, you know the file size, and when it breaks you fix it on the spot.
A product loses all of those assumptions. It runs on a machine you've never seen, on files you didn't anticipate, in a room you're not in. Closing that gap is the fiddly work: one warning message, one progress indicator, one icon, one launch on the other operating system. Each piece is trivial. Together they outlast the development.
That also explains the submission flood. The cost of making collapsed; the cost of finishing did not. So unfinished work arrives in bulk, the reviewing side buckles, and the rules tighten in response. Anyone planning a solo developer app release right now is walking into that queue alongside everything else that skipped the finishing.
So Where Does the Value Sit Now
My takeaway isn't that AI falls short. If anything it's the opposite: AI is the reason I even considered turning a private script into a product. A few years ago I wouldn't have started.
But the point where value gets assigned seems to have moved. As the ability to produce code becomes common, the people who finish things become scarce. And finishing is less a skill than a disposition. Do you think to boot it on the other OS? Do you think to open the 455-page file? Do you let a wrong icon slide?
It comes down to care, attention to detail, and how much time you're willing to spend on work nobody will notice. That's a different axis from coding ability, and for now it still seems to sit on the human side.
Whether it stays there, I don't know. What I do know is that one solo developer app release taught me the difference more sharply than years of writing code that only I ran. It felt like using a muscle I hadn't used before.