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.

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.