Kickstart

Blog summaries

Every post from the Kickstart blog condensed to its key points – pick a category, skim the bullets, and read the full article when you want the detail.

App Ideas

How to pick your next app idea: the 10 → 3 → 1 funnel

  • Borrowed from Apple: an Apple design practice – produce ten mockups, consider three, land on one – forces you past the first plausible answer, and works just as well for picking your next app.
  • Five hunting grounds: collect ten ideas by scratching your own itch, mining 1-star reviews for pain points, piggybacking trends, building on APIs, and picking off weakly executed competitors.
  • Consider before you judge: YouTube, Twitter, and Instagram all sound unhinged as raw pitches, so brainstorm each idea freely first – then hunt for its drawbacks, because an idea with 30 minor drawbacks is significantly trickier than one with 3.
  • Problem, product, point, payoff: boil every idea into a four-sentence elevator pitch, because if you can’t, it’s just not going to work – if you’re explaining, you’re losing.
  • Five elimination rounds: cut ten to three by scoring with the RICE model, then cutting for weak conviction, low impact, whether you’d use it yourself, and revenue potential – and give each finalist a one-week validation sprint.
  • The Obsession Test: the best idea isn’t the one with the biggest market, it’s the one you’ll actually finish – so pick the one you’re personally obsessed with, then name it, frame it, and claim it.
Read the full article →

What kills apps, and why it isn’t being Sherlocked

  • Sherlocking isn’t a death sentence: nearly five years after iOS 15 shipped Background Sounds, Dark Noise’s RevenueCat-verified public page showed $4,731 in monthly recurring revenue and 2,606 active subscriptions.
  • Why Apple leaves room: the iPhone is just over half of Apple’s revenue ($209.6 billion of $416.2 billion in fiscal 2025), so system features must serve everyone – leaving specialists to win on depth, retention, maintenance, and distribution.
  • The four real killers: obscurity, chasing revenue instead of retention, stalling, and shiny object syndrome kill more apps than Sherlocking – and every one is self-inflicted and fixable by you.
  • Obscurity is the biggest: getting noticed is a campaign, not a launch-day event – it’s why Kickstart’s launch calendar runs from 45 days before release to 60 days after.
  • Retention before revenue: keep existing users coming back first, because a retained user is more valuable than ten bounced installs.
  • Don’t let it rot: under Apple’s App Store Improvements process, an app not updated within three years with very few downloads can be flagged for removal, with 90 days to submit an update.
Read the full article →

App Store Optimization

How to choose App Store keywords: a complete 7-step pipeline

  • Three core keywords: start with three plain words that nail what your app does, and know which one matters most.
  • Expand the long tail: mind-map synonyms and niche terms until you have 200 to 400 characters of candidates – brainstorm, don’t filter.
  • Harvest autocomplete: type your core words into the App Store on a real device and merge whatever it suggests into your list.
  • Mine your competitors: their names, subtitles, and top-3 rankings are free research, but no tool can read a rival’s hidden keyword field.
  • Set bounds before numbers: decide your popularity floor and difficulty ceiling before you look at any scores, and treat popularity as an ordering signal rather than gospel.
  • Order by intent: nudge ready-to-act searches like “JLPT practice” up the list and curious ones like “travel” down – and never delete a keyword.
  • Pack all 100 characters: commas with no spaces, and no words already in your name or subtitle, no plurals, no trademarks.
Read the full article →

Mac App Store optimization: the definitive guide

  • The missing toolkit: the Mac App Store has no Apple Ads, no A/B testing, no custom product pages, and no in-app events – your levers are metadata, screenshots, reviews, and featuring.
  • Same fields, easier odds: you get the familiar 30-character name, 30-character subtitle, and 100-character keyword fields, but broad terms that are almost impossible on iOS can be winnable on the Mac. (Note: With no Apple Ads there’s no search volume data, so we need to use rankings instead.)
  • The universal purchase catch: your app name and subtitle are shared across both iOS and macOS, so those 60 characters need to earn their keep in both stores. (In comparison, the keyword field, description, and screenshots stay per-platform.)
  • Screenshots are search results: Mac screenshots are 16:10 landscape and appear directly in search results, so upload at 2880×1800 with a huge benefit caption – and if you can’t read it scaled to 25% in Preview, redo it.
  • Featuring replaces ads: file a Featuring Nomination in App Store Connect for every significant release, pitching a specific moment a few weeks before launch – it takes an hour and the downside is zero.
  • The web front door: on the Mac, discovery happens on the open web, so a site that ranks for “[your category] app for Mac”, press, and communities do the job Apple Ads won’t – and notarized direct sales or Setapp are real alternatives to the store.
Read the full article →

10 App Store optimization mistakes you can fix in an afternoon

  • Fill your name field: the app name is the most heavily weighted search text you have, so use all 30 characters, not just your brand.
  • Give your subtitle a job: it’s the second-strongest ranking signal, so add new terms instead of restating the name.
  • Dedupe across fields: Apple pools your name, subtitle, and keywords and only needs each word once – repeats waste slots.
  • Clean the keyword field: single words, commas with no spaces, and no “app”, “free”, brand, or category names.
  • Caption your first screenshot: put one truthful benefit above a framed screen, in type readable at search-result size.
  • Front-load your best screenshots: people decide from the first three in search results, so move your strongest there.
  • Write real release notes: replace “bug fixes and improvements” with two or three specific sentences, leading with the most-requested change.
  • Prompt at the happy moment: call requestReview() after the user has succeeded a couple of times – it shows at most 3 times per 365 days.
  • Reply to bad reviews: replies are public, and the reviewer gets notified of your reply and can update their rating.
  • Run one A/B test: Apple’s product page optimization is free and tests up to three treatments against your current page.
Read the full article →

Indie Life

It’s fine to build apps just for the money

  • Profit is a purpose: nobody demands plumbers feel a spiritual connection to pipes – doing skilled work and getting paid is a completely normal arrangement, and building an app for money is no different.
  • The $26,000 party trick: a 20 Questions app built in six hours, with a downright ugly UI, made enough to fund a whole trip to Japan – because a simple proposition users immediately understand beats months of soul-searching about creative purpose.
  • If you’re explaining, you’re losing: start small and simple with an idea people grasp instantly, and remember that motive and quality are separate axes – wanting to get paid doesn’t make you a grifter, shipping garbage does.
  • No original idea needed: open the Top Paid charts, switch a top app’s reviews from “Most Helpful” to “Most Critical,” and look for a recurring unmet outcome you can deliver a distinct way – the opportunity is the customer’s problem, not somebody else’s expression of the solution.
  • Validate like a business: Sensor Tower gives modeled estimates, not the developer’s receipts, so confirm demand with interviews, a preorder or priced landing page, or a manual paid service before you build.
  • AI hasn’t changed the deal: as Iris Iványi argues, people don’t want infinite freedom, they want a strong opinion to follow – tools can reduce coding and drafts, but a finished, opinionated app still has value.
Read the full article →

Launch

How to avoid App Store rejection: an App Review checklist

  • Roughly 23 in 100: Apple’s 2025 transparency report counts 2,093,244 rejected submissions, with Performance (crashes, bugs, and incomplete apps) the largest category, and 387,087 rejections later approved after fixes.
  • Boring problems, boring fixes: The top rejection reasons are self-inflicted, so before the day you submit test the actual release build on a real device, try your support and privacy policy links, and log in with your own demo account.
  • Metadata must be true: Polished apps get rejected for what’s written around them: screenshots must show the real app, and the name and subtitle allow no keyword stuffing, price terms, or other-platform imagery.
  • Privacy keeps growing: Write privacy request text that explains why you need access, offer in-app account deletion, get explicit consent before sending personal data to third-party AI services, and update any old SDKs so missing privacy manifests.
  • Reviewers have minutes, not hours: Most developers leave the App Review Information box blank – fill it with demo credentials, what’s new or unusual, and a demo video for anything the reviewer can’t test themselves.
  • The 30-minute reviewer run: Before submitting, take a moment to try things just like the reviewer will on a clean device – install the release build, complete the core flow as a new user, log in with your demo credentials, restore purchases, delete an account, and trigger every permission prompt.
Read the full article →

The ultimate indie iOS app launch checklist

  • The 100-day launch: a great launch takes over 100 calendar days – 45 before you ship, launch day itself, and up to 60 after – because cramming all the marketing into day 0 is why most indie launches fail.
  • Foundations are cheap now: days −45 to −31 are for the decisions – your one-sentence value proposition, your direct and indirect competitors, your three core keywords, your price, and an App Store Connect record to reserve your app name.
  • Lead times or nothing: days −30 to −15 cover everything that can’t be rushed – App Store metadata, featuring nominations at least three weeks before launch, the external TestFlight beta, and a pre-order submitted with “Manually release this version” so approval doesn’t mean accidental launch.
  • Prewrite launch day: nothing that can be done in advance happens on day 0, so write the blog post, social posts, and email by day −9 and spend launch day itself replying to every comment and question – the replying is the marketing.
  • The feedback fortnight: the launch is a window, not a single moment – days +1 to +14 are for logging every piece of feedback, fixing the worst bug, replying to all reviews, shipping 1.0.1, and only then calling requestReview() at a moment of success.
  • Plan for a year two: aim for a real update every 2–4 weeks, start proper ASO at day +21 once you have real ranking data, and only try Apple Ads once your conversion and lifetime-value numbers show the economics work.
Read the full article →

Kickstart: launch retrospective

  • Preorders drove the launch: just shy of 3,000 first-week downloads and a #2 spot in the Mac App Store’s Developer chart came largely from preorders concentrating months of interest into release day – Apple says preorder volume can contribute to early visibility and stronger chart placement.
  • Long betas pay off: the first TestFlight build went out more than three months before launch, giving the initial release months of fixes behind it and no serious bugs on day one.
  • Cut the giant feature: the video editor consumed about half of the five months of development and nearly caused burnout – cutting it from v1 would have shipped the app almost three months earlier.
  • Press outreach can’t wait: the biggest launch mistake was repeatedly deferring press contact until the next feature shipped, leaving the press still uncontacted two months after release.
  • Users will surprise you: keyword tracking was planned around 20–50 keywords, but some people tracked several thousand, forcing a rebuild with background Swift concurrency, careful queuing, and improved caching.
  • The launch checklist: put every launch step on the calendar today, split remaining work into “must ship” and “can wait”, write down your procrastination pattern, and decide where feedback will arrive and how you’ll track it.
Read the full article →

Press & Featuring

How to get featured on the App Store: nominations, timing, and what editors want

  • The Nominations form: App Store Connect gives you a free, direct route to Apple’s editorial team – choose App Launch, App Enhancements, or New Content under Featuring in the sidebar.
  • Set realistic expectations: Michael Flarup estimates the best features today bring tens of thousands of downloads rather than millions, so treat featuring as an amplifier for an app that’s already strong.
  • Lead with your story: Editors are journalists who need material, so open with why you built the app and who your team is – not your feature list.
  • Know the published criteria: Apple’s “getting featured” page lists what editors look for – user experience, UI design, innovation, uniqueness, accessibility, localization, and your product page – and none of that work is wasted.
  • Submit weeks in advance: Apple asks for at least three weeks of notice, but always aim for more, particularly when targeting editorial moments like OS launches and seasonal collections by name.
  • Build human connections: WWDR folks are active on social media and at Apple’s developer events, and thanking engineers for what you built with their APIs opens doors where a direct ask for featuring never works.
Read the full article →

How to make an app press kit journalists actually open

  • One page, zero excuses: put the kit at yourapp.com/press on your own domain – not Google Drive, not Dropbox, and not an email attachment – so a writer can cover your app without emailing you a single question.
  • Seven boring facts: lead with a fact sheet of app name, one-sentence pitch, price in real numbers (not “freemium”), platforms, release date, developer, and store link – missing or vague pricing is the single most common gap.
  • Raw screenshots, not adverts: publications can’t run framed App Store shots as editorial images, so provide 6–12 full-resolution PNGs with realistic demo data, your 1024×1024 icon, and a single zip of everything.
  • Three sizes of copy: a quotable one-sentence pitch, a single paragraph, and a fuller write-up, plus feature bullets written as standalone sentences because they often get lifted straight into articles.
  • Prove you’re real: a two-sentence bio, links to your best coverage (skip the section entirely if you have none), and a real name and email at top and bottom – never a contact form.
  • Two to four weeks early: have the kit live and linked in a pitch before release rather than on launch day, and never move the URL – journalists bookmark it, and a 404 costs you the follow-up article too.
Read the full article →

Pricing & Revenue

How to price an app: the coffee test

  • The coffee test: decide whether your app is worth one coffee a week or one a month, then anchor there – one a month is your $4.99 a month price point, one a week roughly $19.99.
  • Prices are judged in context: in the Predictably Irrational Economist experiment, deleting a $125 decoy option nobody picked shifted internet-only choices from 16 to 68 of 100 students.
  • Annual pricing: start at around eight months of the monthly price (12 × $4.99 is $59.88, so about $39.99), make the saving visible, and judge it by conversion, churn, and net lifetime value.
  • Price on perceived value: RevenueCat’s top advice is to price on perceived value, not effort or what rivals charge – treat price as a hypothesis that real users confirm or refute.
  • The Van Westendorp survey: ask four questions (too cheap, bargain, expensive, too expensive) to plot a price band like $3–$7 a month, launch in the middle, then nudge while watching trial-to-paid and 60-day retention.
  • Someone should complain: a few users grumbling about your monetization is terrific, because if nobody complains your prices are comically low – and a 99-cent price makes customers assume the app can’t be very good.
Read the full article →

Research & Validation

How to user test your app with just 5 people

  • What the model claims: With an assumed 31% per-user discovery rate, Nielsen’s five-user model estimates that five similar users reveal about 85% of the usability issues that setup can expose – not 85% of bugs, accessibility needs, or problems across distinct audiences.
  • One tester beats zero: A single relevant participant already surfaces about a third of what there is to learn, because “the difference between zero and even a little bit of data is astounding.”
  • Small rounds, not big studies: Later participants increasingly repeat issues already observed, so test, improve, and test again – and give distinct groups like novices and VoiceOver users their own coverage.
  • Apple’s three questions: Ask “Do you know how to XYZ?”, “Is it easy to XYZ?”, and “How can we make this better?” rather than “do you like it?”, and while watching, don’t argue, defend, or dismiss.
  • Give them a task, not a tour: Set one specific task (“sign up for the app, then log your first workout”) and find your app’s equivalent of Mercury Weather’s Two-Second Glance Test.
  • Treat findings as hypotheses: Fix blockers and high-severity patterns first, weigh severity and recurrence before changing deliberate workflows, and give more time to anything users uniformly praise – that’s how Halide’s reduced-processing option grew into Process Zero.
Read the full article →

App Store competitor analysis: how to spy on your rivals (ethically)

  • Download three direct competitors: search your most important term on a real device and study three apps serving the same customer and job – everything else in the stack depends on this.
  • “What’s New” archaeology: every product page’s Version History shows the 25 most recent release notes – read them bottom to top to watch a competitor’s strategy unfold, and note their release cadence.
  • Take monthly metadata snapshots: save each rival’s product page, subtitle, screenshots, and prices into a dated folder, then for every change write what you observed, your best hypothesis, and the cheapest test that would settle it.
  • Read the four-star reviews: these are users who liked the app but still named one or more problems with it – sort by most critical, read 20 or 30 per competitor, and if three apps get hammered for a common complaint then you might have found a gap the whole market is leaving open.
  • Capture paywalls and ads: screenshot every onboarding step and paywall (trial length, plan count, pre-selected plan), then check the Meta Ad Library – free and public – to see which benefit each competitor’s adverts lead with.
  • Be the best at something: write a plain SWOT for each competitor, apply Chesterton’s Fence to features you don’t understand, and treat zero competition as a warning – it often means no market.
Read the full article →

Reviews & Ratings

When to call requestReview(): Apple’s rules and the timing that works

  • Three prompts per year: the system shows your request at most three times in any 365-day period, may suppress any individual call, and people can now disable in-app rating prompts globally – so nothing in your UI should depend on the prompt appearing.
  • Apple’s new guidance: the April 2026 Human Interface Guidelines for ratings and reviews say to wait at least a week or two between requests, and only re-ask after the person has demonstrated more engagement with your app.
  • Use the 2026 APIs: SKStoreReviewController is deprecated as of iOS 18 – UIKit and AppKit apps should call AppStore.requestReview(in:), while SwiftUI apps get the requestReview environment action from iOS 16 and macOS 13.
  • Ask right after the win: trigger the prompt immediately after your app’s “aha!” moment – their success, not yours – requiring around three wins first, adding a two-second delay so your success UI lands, and asking at most once per version with a date gate too.
  • Testing is misleading: development builds show the prompt every single time you call the API, while in TestFlight the call does nothing at all.
  • Skip the growth hacks: onboarding review prompts now risk rejection, “are you enjoying the app?” pre-prompts count as filtered feedback under Apple’s guidelines, and motivated fans should get a settings item that deep links with ?action=write-review instead.
Read the full article →