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 Store Optimization

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: 10 App Store optimization mistakes you can fix in an afternoon

Launch

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: The ultimate indie iOS app launch checklist

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: Kickstart: launch retrospective

Press & Featuring

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: How to make an app press kit journalists actually open

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: How to price an app: the coffee test

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: When to call requestReview(): Apple’s rules and the timing that works