I've talked to a few indie iOS devs in the past month — through dev.to comments, Substack replies, and the occasional cold email asking how I shipped 4 apps in 60 days. The same five anti-patterns keep coming up. None of them are catastrophic. All of them cost weeks of momentum that the dev didn't realize they were spending.
Posting them here so the next dev who Googles "why is my indie iOS app stuck" finds the diagnostic before the symptom.
Anti-pattern 1: Building the v1.5 product before shipping v1.0
The dev: "I want to add iCloud sync before I submit, otherwise users will complain on Day 1."
The reality: zero users on Day 1. The complaint they're afraid of doesn't exist yet. Meanwhile, the app sits in PREPARE_FOR_SUBMISSION for 3 weeks while iCloud sync gets debugged, which is its own 4-week project at minimum.
The cheaper alternative: ship the v1.0 with explicit "iCloud sync coming v1.1" copy in the Settings page. Users who care will email asking for it; that's your validation signal. Users who don't care don't matter.
I shipped 4 apps in 60 days following this rule. Each one has at least one feature I want to add. None of them have it. All of them are submittable.
Anti-pattern 2: Using a paid analytics SDK when you don't have users
The dev: "I'm setting up Mixpanel/Amplitude/PostHog so I can see retention from Day 1."
The reality: you don't have users. The retention graph will show 1 line going to zero. You're paying $20-100/mo for a placeholder.
Worse, you're now subject to App Store privacy review on a third-party SDK that can ship surprise breaking changes. I've seen indie apps get rejected because PostHog updated its tracking schema in a way that the dev's privacy manifest no longer matched.
The cheaper alternative: ship with zero third-party analytics. iOS gives you free os_log for crash + lifecycle. Apple's App Store Connect dashboard gives you free downloads, sessions, and crashes. That's enough to make the next decision until you have at least 100 paying users.
When you have 100+ paying users and need behavioral analytics, the data is then worth the SDK overhead. Until then, it's a footgun pretending to be a feature.
Anti-pattern 3: Pricing for "competitive parity" instead of for your actual buyer
The dev: "Other counter apps charge $0.99 lifetime, so I'm doing the same."
The reality: your buyer isn't comparing your app to Counter Apps Generally. They're comparing it to "the alternative I was about to build myself in 30 minutes." That alternative has infinite cost (because they aren't actually going to build it — that's why they're searching the App Store). Charging $0.99 says you don't believe in the differentiation that made them search.
The cheaper alternative: anchor at $2.99 - $4.99 lifetime for utility, $0.99-$1.99/month for ongoing-value apps. Use the App Store Connect price tier flow — it lets you A/B test. Watch conversion rates per tier in the first 50 buyers, then commit to whichever tier has the best $/MAU ratio.
I priced all 4 of my apps at $2.99 lifetime. Counter (DaysUntil), altimeter (AltitudeNow), prompt manager (PromptVault), decision wheel (AutoChoice). The ASO data so far suggests $1.99 might be optimal for the simpler ones, but I won't change it until I have 100+ buyers per app to test against.
Anti-pattern 4: Polishing the App Store screenshot before testing the install flow
The dev: "I've spent 2 days perfecting the screenshot designs. Now I'll set up the build pipeline."
The reality: the install flow has 4 places where it can break (build state, tester state, Apple ID conflict, Apple's 4-year TestFlight cache bug). The screenshots have one place to break (Apple rejects the design). The marginal hour spent on install diagnostics has 4x the leverage of the marginal hour spent on screenshots.
The cheaper alternative: do install testing in parallel with screenshot work. Use a real internal tester (not just a simulator) on Day 1 of TestFlight. If the install fails, you have 30 days to debug while you're polishing screenshots. If you wait until screenshot day, you've stacked the debugging on top of submission stress.
I learned this the hard way: 60 days of TestFlight install errors across all 4 apps because I didn't catch the 4-year Apple cache bug early. Could've been a 5-day discovery if I'd run install diagnostics on Day 1.
Anti-pattern 5: Ignoring Apple Forum threads because "they're 4 years old"
The dev: "This thread is from 2021, it's not relevant to my 2026 build."
The reality: Apple's ASC API and TestFlight infrastructure don't churn the way web frontends do. A bug reported in 2021 with no Apple-confirmed fix is more likely to still be live in 2026, not less. The age of the thread is data, not noise.
The cheaper alternative: search Apple Forums by exact error string in quotes. Sort by activity date. If a thread has 100+ replies, multiple workarounds reported, and no Apple staff resolution, you're probably hitting an Apple infrastructure bug that won't get fixed soon. Apply the most-replicated workaround.
I read 4 years of replies on thread 674932 (the TestFlight cache bug) and found one workaround replicated 5+ times: submit for App Store review, get approved, TF unblocks. Reading that thread cost me 1 hour. Trusting the replication count saved me weeks.
The pattern under the patterns
All five anti-patterns share a structure: prioritizing perceived professionalism (sync! analytics! pricing parity! polished screenshots! recent advice!) over verifiable progress.
The fix is the same for all five: do the cheap, ugly, verifiable thing first. Ship without sync. Ship without analytics. Price how you actually want to. Test the install flow before the screenshots. Trust forum data with replication evidence.
Each one of these felt obvious in retrospect. None of them were obvious in the moment. Posting in case it saves a week or three for someone reading.
If you want the full TF Debug Bible compressed to one PDF + working scripts: TF Debug Bible — $29. Three months of Apple Forum thread digging, condensed.
What anti-patterns have you hit (or seen)? Drop them in comments — I'm collecting for a longer post in a few weeks. The bigger the catalog, the more useful for the next indie dev.
GitHub: github.com/jiejuefuyou
Day 60 milestone post: 60 articles in 60 days
Top comments (0)