Making a Rork App Sell on the App Store — ASO, Pricing, and IAP Strategy

Keyword strategy — own the niche

iOS App Store Connect gives you 100 characters of keywords. Use them with care.

Step 1 — Competitor analysis

Pick five apps with similar functionality. Find which keywords each ranks 1-3 for. Sensor Tower and AppTweak have free tiers that surface this.

Step 2 — Prioritize medium-volume, low-competition

Search volume above 100, with top competitors having fewer than ~500 reviews. Skip massive single-word keywords like "game" or "language." Compound three-word phrases like "english shadowing beginner" win.

Step 3 — Pack the 100-character field

english,language,listening,shadowing,pronunciation,beginner,
toeic,toefl,daily,phrases,learning,study,travel,
business english

Comma-separated, no wasted spaces. Do not duplicate words already in the app name or subtitle — those count automatically.

Step 4 — Refresh monthly

Keywords are not set-and-forget. Each month, expand on the ones that produce installs and drop the ones that did not. The first three to four iterations are where you converge on the right mix.

Lifting product-page conversion

When someone lands on your page, the page itself decides whether they install.

App name design

The name affects both ranking and conversion more than any other field.

■ Bad
"English Pro" — too generic, no differentiation
 
■ Good
"Shadow English — 10 Minute Daily Shadowing for Real Conversation"
(Brand + function + differentiator)

A brand name plus subtitle is the modern App Store pattern. The subtitle (30 characters) also factors into search; budget keywords across the full 130-character span.

Screenshots are the actual ad

Five to ten frames sell the value. My template:

1. Most important moment of the experience + a tagline
2. Main features shown together with visual benefit
3. The differentiator — why us not the others
4. A user flow (before/after)
5. A pulled quote from a real review

Screenshots showing only the bare app screen convert poorly. Use the "advertising-style" treatment with overlay text.

Preview video

A 15-30 second preview lifts product-page conversion 30-50% according to Apple's own data. Quality matters — a low-effort screen recording can hurt rather than help. Real production polish (music bed, captions, screen-transition effects) is required.

First three lines of the description

Before anyone taps "more," the App Store shows the opening 150 characters or so. Make those words pull readers in.

■ Bad
"We developed this app to provide better English learning experiences
for our valued users, with rich features and an intuitive UI..."
 
■ Good
"For people who studied English for years and still can't speak it.
A shadowing app you can do in 10 minutes during your commute.
3,000 daily learners and counting."

Problem statement + concrete answer + social proof, in three lines.

Collecting the first ten ratings as fast as possible

The chicken-and-egg problem: nobody installs zero-rating apps. Three habits that solve this on a new launch.

Personal asks

Reach out to 10-20 trusted friends, family, and community members on launch day. Ask them to install and, if they like it, leave a rating. Five to ten ratings on day one breaks the cold-start barrier.

Public launch through your own channels

Blog post, X, Threads, Instagram. "Shipped this today" with a story about the build process pulls supporters into rating territory naturally.

In-app rating prompt timing

iOS limits the SKStoreReviewController prompt to three times per year per user. Spend those carefully. Never on first launch.

// 5th session + last action succeeded + no recent errors
if (sessionCount === 5 && lastActionSuccess && noRecentErrors) {
  StoreReview.requestReview();
}

This timing produces ratings at 10-20% of triggered users. A naive prompt-on-launch averages 2-3%.

Rating-channeling design

Some teams ask "are you enjoying the app?" first; only "yes" users see the store rating prompt while "no" users see a feedback form. This sits in App Store guideline grey area; I keep mine simple — a "Rate" and "Send Feedback" pair on a settings screen. Explicit branching has been flagged in the past.

Pricing model — purchase, subscription, or unlock

Choosing among the three depends on the category.

One-time purchase

Fits: simple utilities, single-purpose tools, finite content collections. Range: $0.99-$4.99. Strengths: low purchase friction, easier App Review. Weaknesses: no recurring revenue; you must keep acquiring new users.

Subscription

Fits: apps with continuously refreshed content, premium features, SaaS-style apps. Range: $2.99-$9.99/month or $24-$99/year. Strengths: compounding revenue, much higher LTV per user. Weaknesses: churn-sensitive, stricter App Review process.

Unlock-based IAP

Fits: free base app with paid premium content or features. Range: $0.99-$4.99 individual unlocks; $9.99-$29.99 packs. Strengths: lots of free users, heavy users can pay much more. Weaknesses: balance with ad revenue is tricky.

What I usually recommend

Utilities: free with ads, $4.99 IAP for ad removal. Content-update apps: free with ads, $4.99/month subscription for premium content. Collection apps: $2.99 one-time.

Resist over-complication. Three SKUs is plenty; six is too many.

Deciding purchase vs. subscription with twelve months of numbers

The category guidance above is a starting heuristic. The hard cases are the apps sitting right on the line, and for those I would rather look at numbers than at instinct.

The script below runs the same install volume through both models for twelve months and prints where subscription overtakes a one-time purchase.

// model-breakeven.mjs
// usage: node model-breakeven.mjs <monthly installs> <one-time price> <purchase CVR%> <sub price> <trial conversion%> <monthly churn%>
const [installs, oneTimePrice, oneTimeCvr, subPrice, trialConv, churn] =
  process.argv.slice(2).map(Number);
 
const FEE_FIRST_YEAR = 0.30; // first-year subscriptions and regular IAP
const FEE_SMALL_BIZ  = 0.15; // Small Business Program
 
let oneTimeCum = 0, subCum = 0, subscribers = 0, crossover = null;
 
for (let m = 1; m <= 12; m++) {
  // one-time: a single payment from that month's installs
  oneTimeCum += installs * (oneTimeCvr / 100) * oneTimePrice;
 
  // subscription: carry last month's base, subtract churn, add new conversions
  subscribers = subscribers * (1 - churn / 100) + installs * (trialConv / 100);
  subCum += subscribers * subPrice;
 
  if (crossover === null && subCum > oneTimeCum) crossover = m;
  console.log(`${String(m).padStart(2)} | ${oneTimeCum.toFixed(0).padStart(6)} | ${subCum.toFixed(0).padStart(6)} | ${subscribers.toFixed(0).padStart(5)}`);
}
 
const net = (g, fee) => Math.round(g * (1 - fee));
console.log(`crossover month: ${crossover ?? "not within 12 months"}`);
console.log(`after 30% fee: one-time ${net(oneTimeCum, FEE_FIRST_YEAR)} / sub ${net(subCum, FEE_FIRST_YEAR)}`);
console.log(`after 15% fee: one-time ${net(oneTimeCum, FEE_SMALL_BIZ)} / sub ${net(subCum, FEE_SMALL_BIZ)}`);
console.log(`average subscriber lifetime: ${(100 / churn).toFixed(1)} months`);

The important line is the one that carries subscribers forward. A subscription is a balance that survives into next month minus churn, not a fixed amount added each month. Model it as a flat multiplication and you will overstate subscription revenue badly.

Run with 1,000 monthly installs, $2.99 one-time at 8% purchase rate, $3.99/month at 3% trial conversion and 8% monthly churn, on Node v22.22.3:

Crossover lands in month 4. After the 30% fee, twelve months nets $2,009 from the one-time model and $4,952 from the subscription.

That gap hangs entirely on one input. Drop monthly churn from 8% to 5% and the same run nets $5,475 instead of $4,952, while average subscriber lifetime stretches from 12.5 to 20.0 months. Subscription revenue is decided by churn, not by price — that was the part that only became concrete once the two outputs sat side by side. How to actually move churn belongs to retention and LTV design.

When you plug in your own numbers, read the crossover month against how long you honestly intend to keep shipping updates. If crossover falls later than that horizon, subscription is the wrong choice, and a one-time price is the more honest offer. For how the three models sit inside a full revenue mix, see the ads, subscription, and one-time comparison.

The 70/85 boundary, seen over twenty-four months

When I wrote the script in the previous section, I collapsed the whole fee question into one constant, FEE_FIRST_YEAR = 0.30. For a twelve-month comparison that is fine. The trouble started when I tried to look further out. A subscription's split changes partway through, and my model kept applying the same number to the last month that it applied to the first.

Rereading the rules, I found I had been quietly translating "one year" into "one year on the calendar." What Apple counts is days of paid service, which is a different thing, and the gap between the two shows up in the ledger rather than in the model.

Read the rules before the spreadsheet

There are not many moving parts.

The third row from the bottom is the one that earns its keep. If monthly churn sits near double digits, very few subscribers ever arrive at the one-year mark at all. The primary sources are Auto-renewable Subscriptions and the App Store Small Business Program pages.

Running cohorts across twenty-four months

Same inputs as before, stretched to twenty-four months, with the split switching at the right moment. Each joining month becomes its own cohort, and the rate is chosen from that cohort's age.

// sub-proceeds-horizon.mjs
// usage: node sub-proceeds-horizon.mjs <monthly conversions> <price> <monthly churn %> <months> [free trial months]
const [joins, price, churn, months, trial = 0] = process.argv.slice(2).map(Number);
 
const RATE_Y1 = 0.70;           // under one year of paid service
const RATE_Y2 = 0.85;           // one year of paid service reached
const PAID_MONTHS_TO_Y2 = 12;
 
// cohorts[k] = the group that joined k months ago; trial months never count as paid
let cohorts = [];
let grossCum = 0, netCum = 0, netY1Cum = 0, netY2Cum = 0;
 
for (let m = 1; m <= months; m++) {
  cohorts = cohorts.map(c => ({ age: c.age + 1, n: c.n * (1 - churn / 100) }));
  cohorts.push({ age: 1, n: joins });
 
  let gross = 0, net = 0, netY1 = 0, netY2 = 0, y2Heads = 0;
  for (const c of cohorts) {
    const paidMonths = c.age - trial;   // months that count as paid service
    if (paidMonths <= 0) continue;      // no billing during the trial
    const g = c.n * price;
    const rate = paidMonths > PAID_MONTHS_TO_Y2 ? RATE_Y2 : RATE_Y1;
    gross += g;
    net += g * rate;
    if (rate === RATE_Y2) { netY2 += g * rate; y2Heads += c.n; } else { netY1 += g * rate; }
  }
  grossCum += gross; netCum += net; netY1Cum += netY1; netY2Cum += netY2;
 
  const heads = cohorts.reduce((s, c) => s + c.n, 0);
  console.log(`${String(m).padStart(2)} | ${Math.round(heads)} | ${Math.round(y2Heads)} | ${grossCum.toFixed(0)} | ${netCum.toFixed(0)}`);
}
 
const pct = n => (n / netCum * 100).toFixed(1);
console.log(`effective rate ${(netCum / grossCum * 100).toFixed(2)}%`);
console.log(`70% band ${netY1Cum.toFixed(0)} (${pct(netY1Cum)}%) / 85% band ${netY2Cum.toFixed(0)} (${pct(netY2Cum)}%)`);
console.log(`vs. a flat 70% across the whole period: +${(netCum - grossCum * RATE_Y1).toFixed(0)}`);
console.log(`vs. a flat 85% (Small Business Program): +${(grossCum * RATE_Y2 - netCum).toFixed(0)}`);

Thirty conversions a month, $3.99 monthly, 8% monthly churn — the same figures as the previous section. Output on Node v22.23.2, milestones only:

Month twelve reproduces the previous section's totals exactly, because the conditions are unchanged and only the horizon moved. What matters is what comes after: even at twenty-four months, revenue billed at 85% accounts for just 14.6% of net. The effective rate lands at 71.86%, which is $390 more than a flat 70% would have produced.

Why the bump is small, and what is not

Look at who is left. Of the 324 active subscribers in month twenty-four, only 87 have a full year of paid service behind them. At 8% monthly churn the average lifetime is 12.5 months, so most subscribers leave shortly before the better rate would have applied. Drop churn to 5% and the 85% band grows to 19.6%; push it to 12% and it shrinks to 9.5%. The second-year 85% is a reward paid only to developers who fixed churn first.

The other comparison in the same output moves far more. Against a flat 85% — which is what Small Business Program enrollment gives you — the gap is $2,764 over the same twenty-four months, roughly seven times the $390 earned by waiting for subscribers to mature.

I would rather claim the 15% I can apply for today than wait a year for the same 15%. Enrollment is open to developers whose proceeds were at or below one million USD in the prior calendar year, and to developers new to the store. Cross that threshold during a year and the standard rate applies to later sales; fall back below it and you can requalify the year after.

Free trials deserve one line here too. Adding a one-month trial to the same run pulls twenty-four-month gross down to $18,156 and shrinks the 85% band from 14.6% to 13.5%, because trial days never count toward paid service and push the crossover later for every cohort. A longer trial buys conversion and pays for it partly in this delay.

I started running this calculation after a year-end review where the deposits came in lower than my own arithmetic had promised. The cause was not the price or the conversion rate. It was me, applying one fee to a revenue stream that charges two. Lowering churn itself belongs to retention and LTV design.

Subscription design realities

A few specifics that materially move subscription numbers.

Free trial

A 7-14 day free trial substantially improves conversion. In my data, 7-day trials beat 3-day trials because most apps need a week to reach habituation.

Promo offers

You can issue special discounts to existing or lapsed subscribers — "first month 90% off," "three months at half price." This is a powerful win-back lever.

Country-aware pricing

App Store Connect lets you customize price per country, not just by tier. $4.99 in the US, ¥600 in Japan, $0.99 in Southeast Asia is a typical purchasing-power-aware pattern that materially improves total revenue.

Cancellation friction (the right kind)

iOS 17+ allows custom messages on cancellation. A polite "thank you for using us; if you are willing, please tell us why" combined with a downgrade option moves a meaningful slice of would-be cancellations into reduced-tier subscriptions. In my own portfolio this dropped churn from about 8% monthly to about 5%.

Newer App Store mechanics worth using

A few changes worth knowing about as of 2026.

Alternative payment processors

In the EU and parts of Japan, Apple's payment system is no longer mandatory. Implementing Stripe directly drops fees from 15-30% to about 3.6%, but you assume billing infrastructure responsibility.

For revenue under about $1,000/month, the savings do not justify the operational lift. Above that, alternative payments become worth implementing.

Family Sharing

You can choose whether your IAPs and subscriptions are shareable across a Family Sharing group. Enabling sharing lifts perceived value and conversion at the cost of revenue per user.

Fits family-oriented apps (household budgeting, parenting, education). Does not fit individual productivity tools or messaging.

Product Page A/B testing

App Store Connect now supports A/B testing on the product page itself — different icons, screenshots, or descriptions served to slices of traffic with conversion compared.

In my experience an icon-only A/B test can move conversion 30-50%. This is revenue improvement that requires zero code changes. The Japanese keyword field has its own quirks around word segmentation, which I keep separate in the Japanese keyword field write-up.

When to believe an A/B test result

The 30-50% figure above describes what happens once enough impressions accumulate. Indie apps run on small numbers, and at a few hundred product page views most of what looks like improvement is noise.

Deciding the required volume before you start saves you from checking the dashboard every morning and reacting to nothing.

// ab-page-views.mjs
// usage 1: node ab-page-views.mjs plan <baseline CVR%> <relative lift to detect%>
// usage 2: node ab-page-views.mjs check <A views> <A installs> <B views> <B installs>
const Z_ALPHA = 1.96; // two-sided 5%
const Z_BETA  = 0.84; // 80% power
 
function plan(baseCvr, lift) {
  const p1 = baseCvr / 100;
  const p2 = p1 * (1 + lift / 100);
  const pBar = (p1 + p2) / 2;
  const num = Math.pow(
    Z_ALPHA * Math.sqrt(2 * pBar * (1 - pBar)) + Z_BETA * Math.sqrt(p1 * (1 - p1) + p2 * (1 - p2)),
    2
  );
  return { p2, n: Math.ceil(num / Math.pow(p2 - p1, 2)) };
}
 
function check(nA, cA, nB, cB) {
  const pA = cA / nA, pB = cB / nB;
  const pPool = (cA + cB) / (nA + nB);
  const se = Math.sqrt(pPool * (1 - pPool) * (1 / nA + 1 / nB));
  const z = (pB - pA) / se;
  // two-sided p value, Abramowitz-Stegun approximation
  const t = 1 / (1 + 0.2316419 * Math.abs(z));
  const d = 0.3989423 * Math.exp(-z * z / 2);
  const p = 2 * d * t * (0.3193815 + t * (-0.3565638 + t * (1.781478 + t * (-1.821256 + t * 1.330274))));
  return { pA, pB, z, p };
}
 
const [mode, ...rest] = process.argv.slice(2);
const a = rest.map(Number);
 
if (mode === "plan") {
  const r = plan(a[0], a[1]);
  console.log(`baseline ${a[0].toFixed(2)}% -> target ${(r.p2 * 100).toFixed(2)}%`);
  console.log(`views needed: ${r.n.toLocaleString()} per variant / ${(r.n * 2).toLocaleString()} total`);
} else {
  const r = check(a[0], a[1], a[2], a[3]);
  console.log(`A: ${(r.pA * 100).toFixed(2)}%  B: ${(r.pB * 100).toFixed(2)}%  relative ${(((r.pB / r.pA) - 1) * 100).toFixed(1)}%`);
  console.log(`z = ${r.z.toFixed(2)} / p = ${r.p.toFixed(4)} -> ${r.p < 0.05 ? "hard to explain as noise" : "still inside the noise band"}`);
}

Planning output at a 3% baseline conversion rate:

Smaller effects get expensive fast. Detecting a 10% relative lift takes over 100,000 total views, which is months of traffic for a new app. That is the practical argument for starting with a whole new icon rather than a reworded subtitle: big swings are the only ones a small app can actually measure.

The check mode is the one I reach for more often. Here is the same apparent 30% improvement at two different sample sizes:

The headline improvement is nearly identical; the conclusion reverses. Call a winner at the first row and you will remember an ineffective change as an effective one, then carry it into your next app.

App Store Connect does report confidence intervals of its own. I still run the planning step first, because having the number written down beforehand is what lets me leave a running test alone.

Pricing psychology — finding the right number

A common pricing mistake: setting the price you would personally pay. That price is rarely what the buyer would pay.

Anchoring matters

Users judge price relatively. A $4.99/month app feels cheap next to a $11.99 competitor and expensive next to a $2.99 one. Position your price in the middle to upper-middle of the visible range. Going for cheapest signals "low quality."

Digit psychology

$0.99, $2.99, $4.99 dominate because the leading digit reads smaller. In Japan, prices ending in 80 or 280 are the equivalent. For a perception of "deliberately calibrated rather than carelessly chosen," prices like $3.79 or ¥398 occasionally outperform.

Price testing

In a new app's first three months, run one or two price experiments — say from $4.99 to $3.99 — and compare monthly revenue and conversion. App Store price changes deploy instantly, so these experiments are practical.

Review response strategy

Every well-rated app accumulates low ratings too. Replying to all of them — especially the low ones — improves both ranking and conversion.

Tone

Open with thanks. Acknowledge the specific issue. Name a concrete next step ("scheduled for the May update"). Avoid blame ("must be your environment," "no other users report this"). Future readers see the response; defensive replies hurt conversion more than the original review did.

Mining low ratings for product direction

Three-star and below reviews carry signal. Once a month, read all of them, cluster recurring complaints, and feed them into the next update's release notes. "We listened" is a real feature.

Worked example — a $1,000/month one-time-purchase app

A real apps from my own portfolio: a curated wallpaper app at $2.99 one-time.

• Category: high-quality wallpapers, 1,000+ items across themes
• Pricing: $2.99 base; premium wallpaper IAP $1.99 each
• ASO: 3-4 medium-volume keyword combinations across "wallpaper, aesthetic, hd, minimalist"
• Screenshots: real wallpapers composited into Apple's official device frames
• Rating: 4.6/5 across ~1,200 ratings
• Monthly new purchases: ~280
• Net monthly revenue: ~$1,000 after store fees

Build was about a month. The path to $1,000/month came from three months of disciplined ASO, screenshot iteration, and rating accumulation after launch.

A 90-day store-strategy plan

Days 1-14: Competitor analysis, keyword selection, product page assets prep (name, screenshots, copy, video). In parallel with Rork build.

Days 15-30: Submit, set initial ASO, personal asks to first 20 supporters. Public launch on social and blog. Aim for first 10 ratings.

Days 31-45: Analyze search-traffic data, refresh keywords for the first time. Begin product-page A/B testing.

Days 46-70: Analyze D7 retention of new installs and ship improvements. Add subscription tier if appropriate.

Days 71-90: Stabilize search rankings. Push monthly new installs above 100. Reach $500-$1,000 monthly revenue.

What to do next

Today, pick five direct competitors of your current or planned app. Tabulate name, screenshots, copy, and rating count side by side. The picture of how to compete forms quickly when you see them together.

Then run the keyword selection process for one month. Three to four iterations later, the search-install signal will look very different from where you started.

Long-term thinking — store strategy as compounding work

A note on time horizons. Treating ASO and store strategy as one-and-done work leaves the lion's share of revenue on the table. The apps in my portfolio that earn the most are the ones I have been quietly tuning every month for years.

The math: a 5% conversion-rate improvement compounds. So does a one-position move up in search ranking, an additional 50 reviews per month, a slightly better rated than the alternatives. None of these individually is dramatic. Stacked over twelve months, the revenue line bends meaningfully upward.

This is also why "set the store fields and never touch them" indie developers tend to plateau. The discipline is light — perhaps two hours per app per month — but the absence of it is what separates the long-term portfolios from the static ones.

Common store-strategy mistakes I have made

Three failures I have made and you can skip.

Translating only the description, not the screenshots. A Japanese app launched in English with English description but Japanese-text screenshots converted at a third of the rate of fully-localized versions. Localization is screenshots first, copy second.

Letting reviews go unread for weeks. A burst of one-star reviews about a regression went unanswered for two weeks because I was not checking. By the time I noticed, the rating had dropped 0.4 stars and a month of work to recover. Two minutes of daily checking is the cheapest insurance you can buy.

Pricing for myself, not for the market. I once launched an app at $1.99 because that felt fair to me. Six months later I tested $4.99; conversion rates barely changed but revenue per install nearly tripled. Test the price; do not assume.

A short note on alternative ecosystems

A footnote on platforms beyond the iOS App Store. Google Play has slightly different ASO mechanics — keywords are inferred from app description rather than a dedicated field, and review velocity matters more than total count. Setapp, App Store outside the US, and the alternative iOS marketplaces in the EU all have their own playbooks worth understanding once your primary platform is humming.

For most indie developers, mastery of one platform comes first. Replicate to others once you have proven the model.

Closing

Building a great app is half the job. Selling it well is the other half, and most of that half lives inside the store listing, the price tag, and the in-app moments where users decide to rate and to subscribe. The discipline is light, the compounding is real, and the difference between a $50/month app and a $5,000/month app is more often store strategy than code.