DEV Community: Shotlingo

Apple Search Match: Free iOS Keyword Data Most Indie Devs Skip (2026 Guide)

Shotlingo — Thu, 11 Jun 2026 19:25:49 +0000

Apple Search Match: Free iOS Keyword Data Most Indie Devs Skip (2026 Guide)

Updated June 2026. If you build iOS apps as an indie developer, you've probably looked at paid keyword tools like AppTweak or Sensor Tower, winced at the monthly cost, and stuck with educated guesses for your App Store keywords. But there's a quieter option most indies overlook: Apple Search Match, a feature inside Apple Search Ads that hands you keyword data straight from Apple, often for less than the price of a coffee. This guide walks through what Apple Search Match is, why it tends to get ignored, and how to extract free (or near-free) iOS keyword research from it in about a week.

TL;DR : The $7 iOS Keyword Research Hack

What it is: Apple Search Match is a feature inside Apple Search Ads that automatically matches your app to real user search queries, surfacing the keywords Apple itself thinks your app is relevant for.
Why it matters: The popularity scores and matched queries come directly from Apple, so they tend to be more accurate than third-party estimates.
Cost: Setup is free. Running a tiny seed campaign at roughly $1/day for 7 days totals about $7. Compare that to third-party tools that often start around $79/month.
Catch: iOS only, no competitor data, and the dashboard is built for ad buyers, not researchers. Once you know the trick, though, it's one of the cheapest legitimate keyword research methods available.
Best for: Indie devs validating their ASO keyword choices without committing to a recurring SaaS bill.

What Apple Search Match Actually Is

Apple Search Match is an automatic targeting feature inside Apple Search Ads. When you enable it on a campaign, Apple uses your app's metadata (title, subtitle, keyword field, description) plus signals from the App Store itself to match your app to real user search queries. You don't pick the keywords manually; Apple decides what looks relevant and shows your ad against those searches.

The interesting part for indie devs isn't the ad placement. It's the report that comes out afterwards. Once Search Match has been running, you can pull a list of the actual search terms Apple matched your app to, along with Apple's internal popularity score for each one. That's keyword research data, sourced directly from the platform you're trying to rank on.

If you want a shorter definition you can bookmark, we keep one in our Apple Search Match glossary entry. The full ASO concept it ties into is covered in our broader ASO glossary.

What Apple Search Match gives you

Real search queries that Apple believes are relevant to your app.
Apple's popularity score for each query (an internal 5-point-ish scale).
Impression and tap counts, which hint at how much traffic each query carries.
A CSV export you can paste into a spreadsheet for ranking and prioritization.

Why Most Indie Devs Skip Apple Search Match

For something this useful, Apple Search Match is surprisingly under-discussed in indie circles. A few reasons come up repeatedly:

It's branded as an ads product. Most indies see "Search Ads" and assume it's expensive paid acquisition, not a research tool.
The dashboard is dense. The Apple Search Ads UI is built around campaign management, bids, and ROAS, not keyword exploration. You have to know where to look.
You need to spend a little to seed the data. Without some impressions, there are no matched queries to report on.
Third-party tools market harder. Tools like AppTweak and Sensor Tower run content, podcasts, and ads. Apple doesn't promote Search Match as a research feature.

The result is that a lot of indie devs end up paying for third-party estimates when Apple is quietly offering first-party data on the same shelf. We've written more about this dynamic in our roundup of cost-effective ASO tools for indie developers in 2026.

How Apple Search Match Compares to Paid Keyword Tools

The honest comparison: Apple Search Match is not a full replacement for paid ASO tools, but it covers the single most important question for most indies, which is "what keywords does Apple think my app is relevant for?"

  | Source 
  | Cost 
  | Best for 




  | Apple Search Match 
  | ~$7 one-off 
  | First-party iOS query data 


  | AppTweak 
  | From $79/mo 
  | Cross-market estimates 


  | Sensor Tower 
  | Enterprise 
  | Competitor benchmarking

If you want a wider comparison across the category, our best ASO tools 2026 roundup covers the trade-offs in more depth. The short version: paid tools shine for competitor data and historical trends; Apple Search Match shines for accuracy on your own app.

Setting Up Apple Search Match (Step-by-Step, $7 Total)

Here's the workflow we use when we want a quick read on a new app's iOS keyword surface. Total cost: roughly $7. Total time: maybe 30 minutes of active work spread over a week.

1. Create your Apple Search Ads account (5 minutes)

Go to searchads.apple.com.
Sign in with the Apple ID linked to your Apple Developer account.
You'll be asked to pick between Search Ads Basic and Search Ads Advanced. Pick Advanced. Basic hides the keyword-level reporting you need.
Fill in the billing and tax forms. There's no charge until a campaign runs.

2. Run a tiny seed campaign ($1–$5/day for 7 days)

Create a new campaign and select your app.
Pick the storefronts you care about (start with your largest market).
Create an ad group and enable Search Match. It's a single toggle.
Set a daily budget of $1 to $5. Apple will pace impressions across the day.
Let it run for at least 7 days. Two weeks gives noticeably richer data if you can stretch the budget.

That's the entire spend. A $1/day campaign for a week is $7. You're not optimizing for installs here; you're paying for the matched-query report. Apple's official walkthrough lives in the Apple Search Ads Help center if you want their version of the setup steps.

3. Turn it off (or keep it cheap)

Once you have enough matched queries, you can pause the campaign. Or, if a few keywords are converting well, leave it running at the same tiny budget. Either way, the research deliverable is the report, not the installs.

How to Read the Search Match Report

This is where most indies get lost, so it's worth being concrete.

Where the data lives

Open your campaign in Apple Search Ads Advanced.
Drill into the ad group running Search Match.
Open the Search Terms view. This is the report that shows which user queries Apple matched your app to.
Add the Popularity column if it's not visible. This is Apple's internal volume signal.
Export to CSV for spreadsheet analysis.

What the columns actually mean

Search Term: The literal query a user typed.
Popularity: Apple's score for how often that query is searched. Higher is more volume, but it's a relative scale, not an absolute number.
Impressions: How often your ad showed for that term during the test.
Taps and Installs: Useful as a sanity check on intent, even at tiny budgets.
Conversion Rate: Hints at which queries are commercial intent vs. browsing.

Sort by Popularity descending, then scan for terms that are both popular and actually relevant to your app. Those are the candidates for your organic ASO work.

Using Apple Search Match Data for Organic ASO

The matched queries from Apple Search Match are inputs, not finished keywords. Here's how to turn the report into actual App Store metadata changes.

Step 1: Filter the list

Drop branded competitor queries (you usually can't rank for those organically).
Drop irrelevant matches. Apple sometimes pulls in tangential queries; skip anything you wouldn't proudly rank for.
Keep terms with Popularity that's at least moderate. Very low-popularity terms aren't worth metadata real estate.

Step 2: Slot the survivors into your metadata

Title: Your single highest-impact field. Put the strongest matched keyword phrase here.
Subtitle: Use for secondary high-popularity terms.
Keyword field (100 chars): Pack the rest, comma-separated, no spaces, no duplicates from the title/subtitle.
Localization: If you operate in multiple regions, repeat the exercise per locale. Our App Store locale codes reference is handy here.

Step 3: Validate with a Product Page Optimization test

Once metadata is updated, run a Product Page Optimization (PPO) test or watch your App Store Connect impressions and conversion rate. If a keyword from Apple Search Match is now driving organic impressions, you have a real signal. If not, swap it for the next candidate. For a deeper walkthrough on this loop, see our pillar guide on what ASO is in 2026.

What Apple Search Match WON'T Tell You

Being honest about the gaps is what makes this method useful instead of misleading. Apple Search Match is excellent at one thing and silent on several others.

No competitor keyword data. You see what Apple matched your app to, not what your competitors rank for. Sensor Tower and AppTweak still win here.
No absolute search volumes. Popularity is a relative score, not "12,400 searches per month."
No historical trends. You get a snapshot of the campaign window, not a 24-month chart.
iOS only. There is no Android equivalent inside Google Play Console. For Android, you'll still want a third-party tool or Google Play Console's own (limited) search terms report.
Biased by your current metadata. Apple matches based on what your app already says it does. If your title is vague, the matched queries will be vague.

That last point is worth underlining. Apple Search Match reflects how Apple currently understands your app. If you've never done serious ASO, the report will reveal a relatively narrow surface. Tightening your metadata, re-running Search Match a month later, and comparing reports is itself a useful exercise.

Common Mistakes with Apple Search Match

Picking Search Ads Basic. Basic does not expose the keyword-level data you came for. Always pick Advanced for research use.
Setting the budget too low to get impressions. $1/day is fine in smaller markets. In the US, you may need $3–$5/day to see meaningful query volume.
Stopping after one day. Apple needs time to match. A full week is the minimum for a usable report.
Treating Popularity as absolute volume. It's a relative score. Use it for ranking candidates, not for traffic forecasts.
Forgetting to turn the campaign off. If you're only after research data, set a calendar reminder. Otherwise the spend keeps ticking.
Skipping the validation step. Just because Apple matched a query doesn't mean it's a good organic target. Always validate with PPO or post-update impression data.

FAQ

Is Apple Search Match really free?

The feature itself and the report are free. You'll spend a small amount on the seed campaign that generates the data, typically around $7 for a week at $1/day. Setup, dashboards, and CSV exports cost nothing beyond that ad spend.

How does Apple Search Match compare to third-party ASO tools?

Apple Search Match gives you first-party data on which queries Apple matches your app to, which tends to be more accurate than third-party estimates for your specific app. Third-party tools like AppTweak and Sensor Tower are still better for competitor research, cross-platform views, and historical trends. Most serious ASO teams use both.

Can I use Apple Search Match without running any ads?

Not really. The Search Match report is generated from impressions your ad actually served, so you need at least a tiny campaign to seed it. The good news is that the budget can be as low as $1/day, and you can pause the campaign as soon as you have enough data.

Wrap-Up and Next Step

For roughly the price of a sandwich, Apple Search Match gives indie iOS developers something that used to require a $79/month subscription: real keyword data, sourced from Apple, scoped to your actual app. It won't replace every paid ASO tool, but for the core question of "what should I put in my title, subtitle, and keyword field?", it's hard to beat on cost or accuracy.

If you go through this process and end up with a refreshed metadata strategy, you'll want screenshots that match. Shotlingo helps you ship localized, on-brand App Store screenshots for every keyword market you target. Create a free Shotlingo account and turn your Apple Search Match research into screenshots that convert.

Originally published on Shotlingo

How to A/B Test App Store Screenshots Without a Big Budget (2026 Indie Guide)

Shotlingo — Wed, 10 Jun 2026 21:43:08 +0000

How to A/B Test App Store Screenshots Without a Big Budget (2026 Indie Guide)

Updated June 2026. If you are an indie developer, the right app store screenshot a/b test budget is probably $50, not $500 per month. Most SaaS tools to a/b test app store screenshots were built for studios with paid user acquisition spend, not for solo founders shipping a $4.99 utility. This guide walks through the three ways indie devs actually run cheap a/b test screenshots in 2026, including free screenshot a/b testing via Apple's native tooling, and the workflow that gets you to a declared winner without burning your runway.

TL;DR — The $50 A/B Test Stack for Indie Apps

Here is the entire stack most indie devs need, end to end:

Pre-launch: One PickFu poll to validate direction. About $50 one-off.
At launch (under 1000 daily product page visitors): Post your screenshots to r/iOSProgramming, Indie Hackers, and X for free qualitative feedback.
Post-launch (once you cross ~1000 visitors per treatment): Run Apple Product Page Optimization (PPO). Free, real organic traffic, Apple declares the winner.
Skip: $50–$200/month SaaS split testers until you are clearing roughly $10K MRR and running paid UA.

Total cash out: $50. Total recurring cost: $0. That is the realistic app store screenshot a/b test budget for an indie app in 2026.

Why App Store Screenshot A/B Test Budget Doesn't Need to Be $200/Month

If you read most ASO blog posts, you would think you need SplitMetrics or Storemaven on day one. You do not. Those tools are excellent, but they are priced for studios with five-figure monthly ad spend, because their core method is to drive synthetic traffic from paid Google or Meta ads to a fake landing page. If you are not already buying ads, you are paying for a feature you cannot use efficiently.

The biggest shift for indie devs since 2021 is that Apple itself ships a native A/B testing tool inside App Store Connect, called Product Page Optimization. It uses real App Store traffic, it is free, and it declares statistical significance for you. For most indie apps, this is the only A/B test that matters. Everything else is a proxy.

So the honest answer to "what should my app store screenshot a/b test budget be?" is: enough to validate one or two creative directions before you ship, and $0 recurring after that. For a deeper primer on the method, our older post on screenshot A/B testing fundamentals covers the statistical side. This post focuses on cost.

The 3 Ways to A/B Test App Store Screenshots in 2026 (Free vs Paid)

There are basically three categories. Most indie devs only need two of them.

  | Method 
  | Cost 
  | Traffic source 
  | Statistical significance? 
  | Best for 




  | Apple PPO 
  | $0 
  | Real App Store 
  | Yes, declared by Apple 
  | Live apps with 1000+ visitors per treatment 


  | PickFu / polls 
  | $50&ndash;$100 per test 
  | Panel respondents 
  | Directional only 
  | Pre-launch validation 


  | Reddit / X / Indie Hackers 
  | Free 
  | Community 
  | No 
  | Sanity check, qualitative 


  | SplitMetrics / Storemaven 
  | $200+/mo + ad spend 
  | Paid ad traffic 
  | Yes 
  | Studios with paid UA budget 


  | AppTweak / AppRadar 
  | $79&ndash;$80/mo 
  | N/A (analytics only) 
  | No (not A/B tools) 
  | Keyword tracking, not screenshot tests

Notice that the only paid tool that actually A/B tests screenshots on real App Store traffic is Apple's own PPO, and it is free. Everything else is either pre-launch validation or a synthetic proxy.

Method 1 — Apple Product Page Optimization (Free, Real Traffic)

Apple PPO is the gold standard for indie devs. It is the only way to test screenshots against real users who are actively browsing the App Store with intent to download.

How PPO works

You upload up to 3 treatments plus 1 control in App Store Connect.
You can test the app icon, screenshots, or app preview video. One element type per test.
You set a traffic split (typically 25/25/25/25) and a duration of 14 to 90 days.
Apple serves the variants to real App Store visitors and tracks impressions and conversion to download.
Apple reports statistical significance directly in the dashboard.

The catch

PPO needs traffic. Apple recommends roughly 1000+ visitors per treatment for a reliable read, which means about 4000 product page views during the test window. If your app gets 50 visitors a day, you will not finish a PPO test in reasonable time. Skip PPO until your organic traffic catches up, and use methods 2 and 3 in the meantime.

What to test first

Almost always: the first screenshot. It drives the largest share of conversion because it is what users see in search results and on the product page above the fold. After that, test the hero screenshot's headline copy, then the second screenshot. Do not test five things at once. PPO only lets you compare against one control per test.

If you want a full walkthrough of the PPO setup flow, our PPO guide covers the App Store Connect UI step by step.

Method 2 — Pre-Launch Validation with PickFu ($50 One-Off)

Before you ship, you want to make sure your hero screenshot is not obviously broken. The cheapest way to do this is a single PickFu poll, which is also the most widely recommended pre-launch validation tool in the indie ASO community.

How a PickFu poll works

Upload 2–4 screenshot variants.
Choose a respondent panel. iOS users in the US, ages 18–45 is a common default.
Ask one question: "Which of these apps would you most likely download, and why?"
Get 50–100 responses with written explanations in under an hour.

The cost is typically $50 for a 50-respondent poll. The written feedback is more valuable than the vote count, because it tells you why people picked a variant. "I can't tell what the app does" is the most common comment, and it is the cheapest insight you can buy.

What PickFu is not

PickFu is not statistically significant for App Store conversion. Respondents are not in download intent, they are paid to give opinions. Treat it as directional validation, not a winner declaration. The point is to avoid shipping a confusing screenshot, not to optimize the last 5%.

Method 3 — Community Feedback (Free, Honest)

If $50 is too much, or you want a second opinion, post your screenshots to communities of actual iOS users and developers. The three highest-signal venues in 2026:

r/iOSProgramming and r/SideProject on Reddit. Honest, sometimes brutal feedback from developers who understand the App Store context.
Indie Hackers. Founder audience, useful for category-specific feedback (productivity, utility, finance).
X (Twitter) polls. Fast, but skewed toward your existing follower base. Best for a quick gut check.

The downside: this is qualitative, biased toward developers, and not statistically significant. The upside is that it is free, and you typically get one or two comments that genuinely change your design. Use it to catch obvious mistakes, not to pick winners.

Practical tip

When you post, do not say "which one is better?" Say "I am about to ship variant A. What would stop you from downloading?" You will get sharper feedback because you have given respondents a concrete reason to push back.

When Your App Store Screenshot A/B Test Budget Actually Needs Paid Tools

To be fair to SplitMetrics, Storemaven, and the analytics suites, they are excellent tools and there is a point at which they pay for themselves. That point is usually when:

You are running paid user acquisition with a meaningful budget, and a 5% lift in conversion rate is worth thousands of dollars per month.
You need to test Custom Product Pages (CPP) against specific ad audiences, where PPO cannot reach.
You want to test concepts before you have an app live (so PPO is not an option).

For most indie devs at under $10K MRR, none of these apply. If you do want to compare general ASO tool pricing, we have a full breakdown in our cost-effective ASO tools guide for 2026.

The real cost comparison

  | Approach 
  | Year 1 cost 
  | Tests per year 
  | Real App Store traffic? 




  | Indie stack (PickFu + PPO + community) 
  | ~$200 (4 PickFu polls) 
  | Unlimited PPO + 4 pre-launch 
  | Yes (PPO) 


  | SplitMetrics only 
  | ~$2,400 
  | Unlimited synthetic 
  | No 


  | Enterprise stack (SplitMetrics + AppRadar + AppTweak) 
  | ~$4,308 
  | Unlimited 
  | No

The indie stack is roughly 20x cheaper than the enterprise stack and uses Apple's real traffic for the actual A/B test. For a solo developer, that is not a close call.

The Indie A/B Test Workflow (Step by Step)

Here is the workflow most successful indie devs we talk to actually follow. None of it requires a $200/month subscription.

Step 1: Design two variants

Produce a control (your current first screenshot) and one challenger that changes one variable: headline copy, device angle, background color, or hero element. Do not change three things at once. Browse free templates in our tools section if you do not want to start from scratch.

Step 2: Pre-launch validation

Run one PickFu poll with both variants. Read the written comments carefully. If 30% of respondents say "I can't tell what the app does," fix that before you ship anything.

Step 3: Ship the better variant

Ship the variant that survived the PickFu poll as your live first screenshot. Do not wait for perfect data. Indie velocity beats studio polish.

Step 4: Wait for traffic

You need roughly 1000 product page visitors per treatment before PPO is useful. Until then, your data is too noisy to act on. Use the time to ship features, write content, and post to communities. Our ASO pillar guide covers the organic growth tactics that get you to that traffic level.

Step 5: Run PPO

Once you cross the traffic threshold, set up a PPO test in App Store Connect. Pick one element (almost always the first screenshot), upload 1–3 treatments, set a 30-day duration, and walk away. Apple will tell you when it has a winner.

Step 6: Iterate

Promote the winning treatment to your default. Start the next PPO test on the second screenshot. Repeat. A typical indie app runs 4–6 PPO tests per year, and each winning iteration compounds.

Common Budget A/B Testing Mistakes

The most expensive mistakes we see indie devs make have nothing to do with tooling.

Testing too early. Running PPO with 50 visitors per treatment will produce noise, not signal. Wait for traffic.
Testing too many variables. Change one thing per test. New headline or new device angle, not both.
Stopping a test early. Most PPO tests need at least 14 days to account for weekday vs weekend traffic mix. Resist the urge to call it on day 3.
Confusing PickFu votes with real conversion. Panel respondents are not in download intent. Treat their feedback as directional.
Paying for SplitMetrics with no ad budget. The tool's main value is testing against paid ad audiences. If you have no ad spend, you are paying for a synthetic proxy of traffic you do not have.
Ignoring the first screenshot. It is responsible for most of your conversion. Test it first, test it most.

FAQ

Is Apple PPO really free?

Yes. PPO is built into App Store Connect and there is no fee. You only pay the design cost of producing the screenshot variants themselves. This is why a $0 recurring app store screenshot a/b test budget is realistic for most indie devs.

How long should a PPO test run?

Apple lets you pick 14 to 90 days. Most indie devs we have talked to settle on 30 days. That is long enough to cover weekday and weekend traffic patterns and to accumulate roughly 1000 visitors per treatment for apps in the typical 100–300 daily visitor range. Shorter tests tend to overreact to noise.

Can I A/B test screenshots before my app is live?

Not on real App Store traffic, no. PPO requires a live app. Pre-launch, your best options are PickFu polls (paid, fast) and community feedback (free, qualitative). These are validation, not statistical significance. The real test happens after launch, with PPO.

Ship Better Screenshots, Cheaply

The honest truth in 2026 is that most indie devs do not need a $200/month split testing tool. They need one good pre-launch poll, Apple's native PPO once they have traffic, and the discipline to test one variable at a time. That is a $50 stack, not a $4,000 one.

If you want to design screenshot variants without paying for a Figma plugin or a SaaS template library, create a free Shotlingo account and ship your first A/B test variant in under 10 minutes. Free templates, free export, no credit card.

Originally published on Shotlingo

Cost-Effective ASO Stack for Indie Developers in 2026: Free + Cheap Tools Under $50/Month

Shotlingo — Sat, 06 Jun 2026 14:56:21 +0000

Cost-Effective ASO Stack for Indie Developers in 2026 (Free + Cheap Tools Under $50/Month)

Updated June 2026. If you are an indie app developer, a solo founder, or running a small studio, the honest truth is that most of the cost-effective ASO tools you actually need are either free or sit comfortably under $50 per month. You do not need a $400/month enterprise stack to grow on the App Store or Google Play. You need the right combination of free console data, one paid keyword tool, and one localization tool. That is it.

This post is a budget-first guide to building a real ASO workflow as an indie. It covers the cost-effective ASO tools that actually work in 2026, with real prices, real tradeoffs, and recommended stacks for $0, $10, and $50 monthly budgets.

TL;DR: The Indie ASO Stack Under $50/Month

If you only read this section, here is the bottom-line cost-effective ASO stack for indie developers in 2026:

$0/mo: Apple Search Ads keyword popularity, Google Play Console, App Store Connect, plus Shotlingo free tools for localization sizing.
$9-19/mo: Add Shotlingo Pro for localized screenshots, plus AppFigures basic for daily rank tracking.
$25-50/mo: Upgrade to Shotlingo Enterprise or AppFigures intermediate, add Asodesk entry for deeper keyword research, and run a small Apple Search Ads test budget for Search Match signal.

Below $50 a month, you can cover screenshot localization, keyword research, rank tracking, and conversion experiments. The only things you genuinely cannot get for cheap are full competitor intelligence (Sensor Tower, data.ai, AppTweak enterprise) and download estimation across every market. For most indies, that gap does not matter for the first 12 to 24 months.

Why Cost-Effective ASO Tools Actually Matter for Indie Developers

Indie developers and small startups operate under a different math than venture-backed apps. Every recurring SaaS bill eats into the same pool that funds ads, contractors, and your own runway. A $200/month tool is $2,400 a year, which is roughly 2,000 to 4,000 paid installs you do not have to buy.

The good news is that the gap between cheap and expensive ASO tools has narrowed a lot in 2026. Apple now exposes keyword popularity for free inside Apple Search Ads. Google Play Console gives you free A/B testing through store listing experiments. App Store Connect has free Product Page Optimization and Custom Product Pages. That alone covers a huge chunk of what enterprise tools used to charge for.

If you want a deeper conceptual primer first, read our pillar on what App Store Optimization actually is in 2026. This post assumes you already know the basics and just want the cheapest working stack.

Tier 0: Free ASO Tools You Should Be Using

Before you pay a single dollar, make sure you are fully using the free layer. Most indies skip this and overpay for tools that just repackage console data.

Apple Search Ads (Free Keyword Popularity)

Apple's own ad platform exposes keyword popularity scores on a 5 to 99 scale, directly from the App Store. This is the cleanest keyword signal available anywhere because it comes from Apple. You do not have to run ads to see it. Just create an account at searchads.apple.com and use the keyword tool.

Google Play Console

The Play Console includes store listing experiments (A/B tests on icon, screenshots, short description, full description), custom store listings per country and per install state, and Android Vitals. All free. The experiment feature alone replaces what some paid tools charge $50/month to facilitate. Docs are at support.google.com/googleplay/android-developer.

App Store Connect

Apple gives you Product Page Optimization (PPO) for testing up to 3 variants of icon, screenshots, or preview, plus Custom Product Pages (CPP) for ad targeting and direct linking. Both are free. Learn the terminology in our PPO glossary entry and CPP glossary entry.

Shotlingo Free Tools

For localization sizing and prep, our free tools cover the boring math indies usually do in spreadsheets. The text expansion calculator tells you how much German, French, or Arabic text will grow compared to English, which matters because over-expanded copy breaks screenshot layouts. Locale code lookup and RTL preview are also free.

AppLaunchPad Free Tier

If you only need a few screenshots and do not mind a watermark, AppLaunchPad has a free tier. Good for prototyping. Not a long-term stack piece, but useful for zero-budget tests.

Sensor Tower Free

Sensor Tower's free tier is heavily limited but lets you peek at top charts and basic category data. Treat it as a casual research touchpoint, not a daily tool.

Tier 1: Cost-Effective ASO Tools Under $10/Month

Once you have squeezed the free layer, the first paid additions should solve two specific problems: localized screenshot production and rank tracking. Here are the cost-effective ASO tools that fit under $10 per month in 2026.

Shotlingo Pro ($9/mo)

Our own Pro tier handles localized screenshots, device mockups, and store-ready exports for the App Store and Google Play. If you ship in more than your home language, this pays for itself the first time you avoid hiring a freelance designer for a $200 per-language localization pass. See the localization hub for the full feature breakdown.

AppFigures Basic (~$10/mo)

AppFigures starts around $10/month for a small portfolio. You get daily rank tracking across keywords and countries, downloads, and revenue (if your store is connected). For an indie tracking 20 to 100 keywords, this is the most cost-effective rank tracker in 2026.

AppLaunchPad Paid (~$9/mo)

Removes the watermark and unlocks more templates. Useful if you only need screenshots and do not need localization or store-ready exports.

Tier 2: Cost-Effective ASO Tools Under $50/Month

Once you cross around 1,000 installs per day or start shipping in 5+ languages, the $25 to $50 band becomes very efficient. These are the cost-effective ASO tools that bridge into semi-pro workflows without enterprise pricing.

AppFigures Intermediate (~$25/mo)

The intermediate tier adds more keywords, more apps, and competitor tracking. For a small studio with 2 to 4 apps, this is enough to replace a $200/month enterprise rank tracker.

Asodesk Entry (~$25/mo)

Asodesk's entry tier focuses on keyword research and ASO scoring. It is solid for finding long-tail keywords competitors are ranking on. Pair it with Apple Search Ads keyword popularity for cross-validation.

Shotlingo Enterprise ($29/mo)

Enterprise unlocks unlimited locales, team seats, batch exports, and priority generation. If you ship in 10+ languages and refresh screenshots quarterly, the per-screenshot cost drops to roughly the cost of a vending machine snack.

What You CAN'T Get for Cheap (Honest Gap)

Being honest matters. There are real things you cannot get under $50 per month, and I am not going to pretend you can.

Sensor Tower full access: Enterprise pricing, typically four figures per month. Full download estimation, ad intelligence, and SDK insights live here.
data.ai (formerly App Annie) full access: Also enterprise. See data.ai for what their stack includes.
AppTweak enterprise tier: Their entry plan sits around $79/month, and the genuinely useful competitor intel is above that.
Apptopia: Sales-only pricing, enterprise focused.
Full competitor download estimation across all markets: Requires either Sensor Tower or data.ai. The Tier 2 tools give you ranking and visibility, not download counts.

The honest tradeoff: under $50/month you lose competitor download estimation and global SDK visibility. You keep keyword research, rank tracking, localized screenshots, and store experiments. For most indies in their first 24 months, that is the right tradeoff.

Full Price Ladder by Tier (Updated June 2026)

  | Tool 
  | Tier 
  | Price (USD/mo) 
  | Best For 



| Apple Search Ads (keyword tool) | Tier 0 | $0 | Keyword popularity 
| Google Play Console | Tier 0 | $0 | A/B experiments, vitals 
| App Store Connect | Tier 0 | $0 | PPO, CPP, metadata 
| Shotlingo Free | Tier 0 | $0 | Localization sizing 
| AppLaunchPad Free | Tier 0 | $0 | Prototyping screenshots 
| Sensor Tower Free | Tier 0 | $0 | Top charts only 
| AppFigures Basic | Tier 1 | ~$10 | Rank tracking 
| Shotlingo Pro | Tier 1 | $9 | Localized screenshots 
| AppLaunchPad Paid | Tier 1 | $9 | Watermark-free screenshots 
| AppFigures Intermediate | Tier 2 | ~$25 | Multi-app rank tracking 
| Asodesk Entry | Tier 2 | ~$25 | Keyword research 
| Shotlingo Enterprise | Tier 2 | $29 | Unlimited locales, teams 
| MobileAction | Tier 3 | ~$69 | Mid-market competitor intel 
| AppTweak Entry | Tier 3 | ~$79 | Premium keyword data 
| AppRadar | Tier 3 | ~$80 | ASO platform suite

Recommended Cost-Effective ASO Stacks by Budget

Here is how to actually combine these tools depending on where your runway sits.

  | Monthly Budget 
  | Stack 
  | What You Get 
  | What You Miss 




  | **$0** (zero budget) 
  | Apple Search Ads keyword tool + Google Play Console + App Store Connect + Shotlingo free tools + Xcode Simulator screenshots + free Figma templates 
  | Keyword popularity, free A/B tests, manual screenshots, localization math 
  | Daily rank tracking, localized screenshot production at scale, competitor visibility 


  | **$9-19** (lean indie) 
  | Above + Shotlingo Pro ($9) + AppFigures Basic (~$10) 
  | Adds localized screenshot pipeline and daily rank tracking 
  | Deep keyword research, multi-app portfolio support 


  | **$25-50** (small studio) 
  | Shotlingo Enterprise ($29) + Asodesk Entry (~$25) + small Apple Search Ads test budget ($1-5/day) 
  | Unlimited locales, team workflow, deeper keyword research, Search Match signal from a real ad test 
  | Competitor download estimation, global SDK intel

Notice that even the most expensive stack here totals about $54/month including a tiny ad test budget. Compare that to a single enterprise contract and you can fund this stack for a full year on the cost of two months of Sensor Tower.

If you want to compare these specific picks against a broader generic list, our best ASO tools roundup for 2026 covers the full landscape including the enterprise tier we deliberately skipped here.

Common Mistakes Indie Devs Make with ASO Tooling

1. Paying for Tools Before Using Free Console Data

The single most common mistake is subscribing to a $25 keyword tool before properly mining Apple Search Ads keyword popularity, which is free and arguably better. Always exhaust the free layer first.

2. Skipping Localized Screenshots to Save Money

Localized screenshots typically lift conversion 15 to 40% in non-English markets. Skipping them to save $9/month on a tool is one of the worst ROI decisions an indie can make. The math almost always favors localization.

3. Buying a Suite When You Need One Feature

If you only need rank tracking, do not buy an $80/month all-in-one suite. Buy a $10/month rank tracker. Indies routinely overpay for features they will never open.

4. Ignoring Custom Product Pages and PPO

These are free, native, and Apple actively rewards apps that use them with cleaner attribution data. Not using them is leaving free conversion lift on the table. Refresh on ASO fundamentals if you need the framing.

5. Tracking Too Many Keywords

If you are an indie, 20 to 50 high-intent keywords beat 500 noisy ones. More keywords mean more noise and bigger plans. Keep it tight.

FAQ: Cost-Effective ASO Tools for Indie Developers

What is the cheapest ASO stack that actually works in 2026?

The cheapest working stack is around $19/month: Shotlingo Pro at $9 for localized screenshots, plus AppFigures Basic at roughly $10 for daily rank tracking, layered on top of free Apple Search Ads keyword data, free App Store Connect PPO and CPP, and free Google Play Console experiments. Anything cheaper means giving up either localization or rank tracking, both of which directly affect downloads.

Are there genuinely free ASO tools good enough for a small app?

Yes for keyword research and experiments, no for rank tracking and localized screenshot production at scale. Apple Search Ads keyword popularity, App Store Connect PPO and CPP, and Google Play Console experiments are all free and genuinely good. For everything else you should expect to spend at least $9 to $20 per month.

Is AppFigures or Asodesk better for an indie under $30/month?

AppFigures if you prioritize rank tracking and revenue dashboards. Asodesk if you prioritize keyword discovery and ASO scoring. Most indies pick AppFigures first and add Asodesk later when keyword research becomes the bottleneck.

Can I do ASO with zero tools at all?

Technically yes, using only Apple Search Ads, App Store Connect, and Google Play Console. Practically you will burn a lot of time on screenshots and lose insight into rank movements. The $9 to $19 tier is almost always worth it once you cross 100 installs per day.

Build Your Cost-Effective ASO Stack with Shotlingo

If you want to start with the cheapest piece that has the highest ROI, start with localized screenshots. Sign up for Shotlingo and ship store-ready, localized screenshots across the App Store and Google Play for $9 per month. Pair it with the free tools above and you have a complete indie ASO stack under $20.

Bookmark this post and revisit it whenever your budget or app size changes. The cost-effective ASO tools landscape moves quickly, and the right stack at 100 installs per day is not the right stack at 10,000.

Originally published on Shotlingo

Arabic App Store Listings: Why RTL Mirror or Lose 30% Conversion

Shotlingo — Mon, 01 Jun 2026 18:24:40 +0000

Arabic App Store Listings: Why RTL Mirror or Lose 30% Conversion (Data-Driven)

If you ship to Saudi Arabia, the UAE, Egypt, or any other MENA market, your arabic app store listings are either converting at the level a localized listing should, or they are leaving 20 to 40 percent of installs on the table because the screenshots were translated but never mirrored. This is the third post in our data-driven localization series, after the German vertical space deep dive and the Japanese translation failures breakdown. Arabic is the most visually disruptive of the three: the script is not the hard part, the layout is.

RTL is not a font choice. It is a complete layout inversion. When MENA users open arabic app store listings that still read left to right, the discomfort is immediate, and the install rate reflects it.

TL;DR

Industry data suggests arabic app store listings with fully RTL-mirrored screenshots convert 20 to 40 percent better in MENA than listings that translate text into Arabic but keep the original left-to-right layout. The 30 percent figure in the title sits in the middle of that observed range. iOS automatically mirrors most native UI for Arabic locales, but App Store screenshots are static images and do not mirror themselves. If your arabic app store listings still have icons on the left, progress bars filling left-to-right, and speech bubble tails on the wrong side, you are signaling "this app was not made for me" to a 400 million-person market. Fix the layout, not just the text.

Why Arabic App Store Listings Need RTL Layout, Not Just Translation

The most common mistake is treating arabic app store listings as a string replacement exercise. You hand English copy to a translator, swap the strings, render the same template with Arabic text, and ship. To a Latin-script reader the output looks Arabic. To an Arabic-speaking user, it looks broken.

Reading direction is the obvious part. Arabic flows right to left, so the eye lands first on the right edge. The consequences ripple through every element. Icons that sat on the left of a label now belong on the right. A back arrow shaped like "<" should point the other way. A progress bar that fills left to right in English should fill right to left in Arabic, because "forward" follows reading direction. A speech bubble tail pointing down-left in a chat UI should point down-right when mirrored.

Apple's guidance is explicit. In Apple's Human Interface Guidelines for right-to-left, the company recommends mirroring the entire layout for Arabic and Hebrew locales. iOS handles a lot of this automatically for native UI when you support RTL in code: back buttons, navigation gestures, scroll direction. What iOS cannot do is mirror App Store screenshot images. Those are flat PNGs you uploaded, and they stay exactly as left-to-right as the day you exported them.

That gap, between automatic OS mirroring and static images, is where arabic app store listings fail.

What Changes When You Go From LTR to RTL

The table below maps the most common elements in arabic app store listings in a Latin-script (LTR) layout versus a properly mirrored Arabic (RTL) layout. Run this checklist before approving any localized set.

  | Element 
  | Latin LTR layout 
  | Arabic RTL layout 
  | Auto-mirrored by iOS? 




  | Reading direction 
  | Left to right 
  | Right to left 
  | Yes, in native UI 


  | Icon next to label 
  | Icon on left, label on right 
  | Icon on right, label on left 
  | Yes, in native UI 


  | Back arrow direction 
  | Points left (`&lt;`) 
  | Points right (`&gt;`) 
  | Yes, in native UI 


  | Progress bar fill 
  | Fills left to right 
  | Fills right to left 
  | Partially 


  | Scroll bar position 
  | Right edge 
  | Left edge 
  | Yes, in native UI 


  | Speech bubble tail 
  | Outgoing right, incoming left 
  | Outgoing left, incoming right 
  | No, custom artwork 


  | Onboarding "next" button 
  | Bottom right 
  | Bottom left 
  | Partially 


  | Numerals 
  | Latin: 1, 2, 3 
  | Latin or Eastern Arabic ١, ٢, ٣ by context 
  | No, content decision 


  | Comma punctuation 
  | Latin `,` 
  | Arabic `،` 
  | No, content decision 


  | App Store screenshot images 
  | As exported 
  | Mirrored set required 
  | **No, manual work**

The last row matters most for ASO. Everything iOS auto-mirrors lives inside the running app. Your App Store page sits outside that mirror, so unless you produced a separate Arabic set with the layout flipped, the first impression is a left-to-right page in a right-to-left culture.

The 7 Most Common Arabic Screenshot Mistakes

Across arabic app store listings we have reviewed for MENA markets, the same issues come up repeatedly. Most are quick to fix once you know to look for them.

Translating text but leaving the layout LTR. Arabic strings sit inside a left-to-right composition with icons, arrows, and emphasis still flowing the wrong way.
Arrows and chevrons pointing the wrong direction. A ">" that says "tap to continue" in English needs to become "<" in Arabic, because forward follows reading direction.
Progress bars filling left to right. An onboarding indicator filling toward the right edge in Latin layouts should fill toward the left in Arabic, or the visual momentum fights the reading flow.
Mixing Latin and Eastern Arabic numerals inconsistently. Both 1, 2, 3 and ١, ٢, ٣ are valid, but pick one. Apps that switch mid-screenshot look sloppy.
Latin comma instead of the Arabic ،. Small detail, native readers notice. The Arabic question mark ؟ deserves the same care.
Speech bubble tails on the wrong side. A chat or quote bubble pointing to a face on the left in the LTR version needs the face and tail moved to the right in RTL.
Low-quality Arabic font. Latin fonts often ship with weak Arabic fallbacks. The text displays, but proportions, kerning, and diacritic placement look amateurish.

For RTL as a design discipline, our RTL glossary entry explains the concepts, Google's Material guidance on bidirectionality covers cross-platform principles, and the W3C's bidi markup notes cover the underlying Unicode behavior.

Why Translated-Only Screenshots Cost Conversion in MENA

Now to the number in the headline. The 20 to 40 percent conversion lift from full RTL mirroring is not a single study; it is a range that has shown up across MENA mobile marketing reports and practitioner accounts over the last few years. Industry data suggests arabic app store listings moving from "translated LTR" to "full RTL mirror" see a meaningful double-digit lift in install conversion rate, with 30 percent sitting comfortably inside the observed range.

The mechanism is straightforward. App Store browsers in MENA scroll through screenshots in seconds, and the first signal they read is layout, not text. A layout flowing the wrong direction announces "this app was localized as an afterthought," and the trust cost is large. A properly mirrored set says "this app was built for you," closing the conversion gap translation cannot.

The market justifies the work. Saudi Arabia is the largest Arabic-speaking App Store market by revenue, the UAE has the highest per-user spending, and Egypt brings the largest population. Across Gulf, Levant, and North African markets, roughly 400 million native speakers represent a mobile market measured at well over a billion dollars annually. A 30 percent lift on that surface is not a rounding error, which is why investing in production-grade arabic app store listings pays for itself quickly.

Our localization hub walks through multi-locale strategy, and the 2026 ASO pillar guide covers where localized listings fit into the larger ranking picture.

How to Design Arabic App Store Listings That Convert

The workflow that produces high-converting arabic app store listings is not exotic. It is a sequence of small decisions, each of which the translated-only approach skips.

Step 1: Mirror the layout before you translate the text

Flip your existing composition horizontally as a structural reference. Move headline text to the right, supporting text to the left, device mockups to the opposite side, and any directional iconography to the opposite orientation. This is the skeleton you translate into.

Step 2: Apply Arabic typography, not just Arabic strings

Pick a typeface designed for Arabic. SF Arabic on iOS or IBM Plex Sans Arabic give you proportions, joins, and diacritics that look native. Latin-first fonts with bolt-on Arabic glyphs read as foreign.

Step 3: Re-tune the visual hierarchy

Arabic text often looks shorter than the equivalent English string. A headline that needed three lines in English might fit on two in Arabic. Re-tune the spacing rather than letting the air sit unfilled.

Step 4: Localize numerals and punctuation deliberately

Decide once whether your arabic app store listings use Latin numerals (1, 2, 3) or Eastern Arabic numerals (١, ٢, ٣). Saudi Arabia tends toward Eastern Arabic in formal contexts; younger UAE users are comfortable with Latin. Stay consistent.

Step 5: Verify on a real RTL device

Set a test device to an Arabic locale and open the listing in a sandbox. The eye catches RTL mistakes faster than a checklist does.

Our guide to localizing App Store screenshots to Arabic walks through each phase with concrete examples.

Tools and Workflow for RTL Screenshots

Producing a fully mirrored Arabic screenshot set manually, for every screen and every device size, is the part teams underestimate. The translation pass is cheap; the layout mirror is where the hours go. Shotlingo's RTL screenshot preview tool compresses that work by flipping the layout, applying Arabic typography, and letting you tune the result before export.

The same logic that made our German and Japanese tooling useful applies more strongly to arabic app store listings. With German, the risk is text length. With Japanese, typography and density. With Arabic, the risk is structural, and structural risks need structural tools.

FAQ

Does iOS automatically mirror App Store screenshots for Arabic users?

No. iOS automatically mirrors many native UI elements when the locale is set to Arabic or Hebrew, including back buttons, scroll direction, and navigation gestures. But App Store screenshots are static PNG images you upload. The App Store displays them exactly as uploaded, so a left-to-right screenshot stays left-to-right even for an Arabic-locale user. Producing a separate RTL-mirrored set for your arabic app store listings is manual work.

Is the 30 percent conversion lift a confirmed Apple statistic?

No. Apple has not published a specific figure for RTL mirroring versus translation-only screenshots. The 20 to 40 percent range comes from industry observations and MENA mobile marketing reports rather than a controlled study. The lift is real, the exact number varies by app and market, and 30 percent sits in the middle of what practitioners report.

Should Arabic screenshots use Latin numerals or Eastern Arabic numerals?

Both are read fluently. Eastern Arabic numerals (١, ٢, ٣) dominate formal Saudi contexts, while Latin numerals (1, 2, 3) are common in younger UAE and Egyptian audiences. What matters most is consistency across the full screenshot set.

Ship Arabic App Store Listings That Actually Convert

Arabic is not a hard language to localize for. It is a hard layout to localize for. Translating strings is the easy half; mirroring composition, iconography, typography, and numerals is where the conversion lift hides. If your current arabic app store listings still flow left to right under translated text, you are leaving measurable growth on the table.

Ready to flip your screenshots properly? Start a free Shotlingo account and generate fully RTL-mirrored arabic app store listings in minutes, not days, with the layout, typography, and numerals tuned for the markets you actually want to win.

Originally published on Shotlingo

Apple Now Indexes Screenshot Text: Why Screenshot Captions Are an ASO Ranking Factor in 2026

Shotlingo — Thu, 28 May 2026 12:10:59 +0000

App Store Screenshot Text Indexing: Why Screenshot Captions Are an ASO Ranking Factor in 2026

For years, App Store screenshots were treated as a pure conversion lever. You wrote a punchy caption, picked a clean device frame, and measured the lift in install rate. Discoverability lived elsewhere, in your title, subtitle, and keyword field. That mental model may be out of date. The emerging conversation around app store screenshot text indexing suggests the words baked into your screenshot images are no longer invisible to Apple's systems, and that has real consequences for how you write captions in 2026.

This post is deliberately honest about what is confirmed and what is not. Apple has not published a statement saying screenshot text feeds App Store ranking. What we do have is a mature optical character recognition stack, a growing body of practitioner reports, and a practical takeaway that holds up either way. Let's separate the signal from the speculation.

TL;DR

Apple's on-device text recognition (Live Text and the VisionKit framework) is mature and already reads text inside images across iOS. ASO practitioners report that text embedded in App Store screenshots appears to influence discoverability, which would make app store screenshot text indexing an emerging ranking signal rather than a confirmed one. Either way, writing clear, keyword-aware screenshot captions, especially localized per market, is low-risk and high-upside, so optimize them now.

What Changed: App Store Screenshot Text Indexing

The technical foundation here is not new or speculative. Apple ships a system-wide text recognition capability called Live Text, powered by the VisionKit framework, that extracts readable text from any image. Point your camera at a sign, screenshot a receipt, or long-press a photo, and iOS pulls out the words instantly. This is production technology used by millions of devices every day.

If a phone in your pocket can read the text inside a photo, it is reasonable to ask whether Apple's App Store backend can read the text inside the screenshots developers upload. The capability clearly exists. The question that ASO practitioners are now debating is whether that text is actively wired into search and discovery, or whether it remains an accessibility and convenience feature that has not yet been connected to ranking.

That distinction matters, and we will not pretend it is settled. What has changed is not a confirmed Apple announcement. What has changed is that enough independent observers have noticed correlations between screenshot wording and search visibility that the topic has moved from "impossible" to "plausible and worth testing." For a primer on how the broader system works, see our guide to what ASO is in 2026.

The Evidence: OCR Maturity Meets Community Reports

Let's be precise about the two kinds of evidence, because they carry very different weight.

The first kind is technical and solid. Apple's VisionKit documentation describes a robust API for extracting text from images, and Apple's Live Text support pages confirm the feature is shipping across the OS. Apple has invested heavily in this for accessibility reasons, so that VoiceOver and other assistive features can describe image content to users. The OCR is real, accurate, and battle-tested. None of that is in dispute.

The second kind is observational and softer. ASO practitioners report that apps with descriptive, keyword-rich screenshot captions sometimes surface for queries that do not appear in their title, subtitle, or keyword field. Evidence suggests a possible relationship, but these are correlations gathered from individual accounts, not a controlled study with a published methodology. We have not seen a rigorous experiment that isolates screenshot text as the sole variable, and we are not going to invent one to make the point land harder.

So the honest summary is this: the machinery to index screenshot text exists and is excellent, and the field reports are suggestive but not conclusive. That is exactly the situation where the smart move is to optimize defensively. If app store screenshot text indexing is real, you benefit. If it is not yet, you have lost nothing, because clear captions improve conversion regardless. To go deeper on the keyword side of the equation, our guide to ASO keyword optimization covers the fundamentals.

Why App Store Screenshot Text Indexing Matters More for Localized Apps

Here is the insight that turns an interesting debate into a strategic decision. If screenshot text is indexed, then the language of that text determines which queries it can match. English captions can only match English-language searches. Localized captions can match searches in each target locale.

That reframes localization entirely. For most teams, translated screenshots have been a conversion play: a German user converts better when the caption is in German, a Japanese user trusts the listing more when the typography is native. Those benefits are well documented. But if screenshot text is indexed, localized screenshots become a keyword discoverability play on top of the conversion play.

In plain terms, your German screenshot caption is not just persuading German users who already found you. It may be helping German users find you in the first place, by matching German search queries that your English text could never reach. Every locale you localize becomes a fresh keyword surface. This is precisely the multiplier that makes localized screenshots more than a polish step, and it is the core of what tools like Shotlingo's localization workflow are built to deliver.

How to Write Screenshot Captions for Discoverability

Whether or not indexing is fully active, the same caption-writing discipline pays off. The goal is captions that read naturally to humans and happen to contain the words people actually search for.

Lead with the benefit, include the keyword. Instead of a vague phrase like "Stay organized," write "Track expenses and split bills" so the searchable concepts are present in human language.
Use the words your users type. If people search "meal planner," do not caption it "nutrition orchestration." Match the vocabulary of the query, not your internal product naming.
Keep captions short and legible. A caption that a person can read at a glance is also a caption that OCR can parse cleanly. Dense, low-contrast, or heavily stylized text fails both audiences.
Vary the wording across the screenshot set. Five screenshots are five chances to surface different keyword concepts. Repeating the same phrase five times wastes four of them.
Front-load the first two screenshots. These get the most attention and, if indexing weights position, may carry the most signal. Put your strongest keyword-bearing captions there.

For inspiration on captions that balance persuasion and clarity, study our roundup of app store screenshot examples that convert. The best performers already follow these rules, mostly because clear writing converts, and that clarity happens to be OCR-friendly too.

The Localization Multiplier

To make the keyword-reach argument concrete, consider a hypothetical app shipped to four major markets. The table below compares an English-only screenshot strategy against a fully localized one, focusing on the keyword surface that screenshot text could expose in each locale.

  | Market 
  | Search language 
  | English-only screenshot text 
  | Localized screenshot text 




  | United States 
  | English 
  | Matches English queries 
  | Matches English queries 


  | Germany 
  | German 
  | No match (text is in English) 
  | Matches German queries 


  | Japan 
  | Japanese 
  | No match (text is in English) 
  | Matches Japanese queries 


  | Brazil 
  | Portuguese 
  | No match (text is in English) 
  | Matches Portuguese queries 


  | **Keyword surfaces exposed** 
  | **4 locales** 
  | **1 of 4** 
  | **4 of 4**

The pattern is stark. English-only screenshots expose your screenshot keywords to one of four markets, even if your app is technically available in all four. Localized screenshots, assuming the indexing behaves the way the OCR capability implies, expose tuned keywords to every market you ship to. That is a four-fold expansion of your potential screenshot keyword reach, achieved by translating text you already have to write anyway.

One practical caution before you translate: text length changes across languages. German strings often run 30 to 40 percent longer than English, which can break a layout that was tight to begin with. Run your captions through our text expansion calculator before committing to a design, so your localized captions stay legible to both readers and any OCR pass.

What NOT to Do

The instant a channel is suspected of carrying ranking weight, someone tries to stuff it. Do not be that someone. If indexing is real, keyword stuffing your captions is the fastest way to waste the opportunity and risk a rejection.

Do not list keywords as captions. A screenshot that says "expense tracker budget app money saver finance manager" reads as spam to humans and adds nothing useful for OCR. Apple's review team also scrutinizes screenshots for misleading or low-quality content.
Do not sacrifice legibility for keyword density. Cramming more words means smaller text, lower contrast, and worse conversion. You would be trading a confirmed benefit (conversion) for a speculative one (indexing). That math never works.
Do not repeat the same keyword on every screenshot. Repetition does not compound the way stuffers imagine. It just burns screenshot slots that could expose different concepts.
Do not use text that contradicts your app. Captions describing features you do not have are a review-rejection risk and an uninstall driver, indexed or not.

The guiding principle is simple. Write captions a human loves first. Let any indexing benefit be a bonus that rides on top of genuinely good copy, never the justification for bad copy. For the formal definition of the discipline this all sits inside, see our ASO glossary entry.

FAQ

Has Apple confirmed that it indexes screenshot text for ranking?

No. Apple has confirmed that its Live Text and VisionKit technology reads text inside images, primarily for accessibility and convenience. Apple has not published a statement saying screenshot text feeds App Store search ranking. The connection between the two is an emerging hypothesis supported by practitioner observation, not an official Apple announcement, so treat it as a promising signal to act on rather than a settled fact.

Should I change my screenshots based on something that is not confirmed?

Yes, because the recommended changes (clear, keyword-aware, localized captions) improve conversion whether or not indexing is active. You are not making a risky bet. You are doing what already works for conversion and positioning yourself to benefit if screenshot text indexing turns out to be a real ranking factor. The downside is essentially zero.

Does localizing screenshots really expand keyword reach?

If screenshot text is indexed, then yes, by definition. English text can only match English queries, so each language you localize into opens a separate keyword surface tied to that locale's search behavior. Even setting indexing aside, localized screenshots convert better with local users, so the localization investment pays off through at least one and possibly two distinct mechanisms.

Turn Screenshot Captions Into a Per-Locale Keyword Engine

The honest position on app store screenshot text indexing is that the OCR is real and excellent, the ranking effect is plausible but unconfirmed, and the optimization work is worth doing either way. The teams that win are not the ones waiting for an official announcement. They are the ones writing clear captions and localizing them across every market they serve.

Shotlingo localizes your App Store screenshot text into dozens of languages while preserving layout, fonts, and design, so each market gets native captions that read well to users and parse cleanly for any text recognition pass. Create a free account and localize your first screenshot in minutes. Turn a single set of captions into a keyword surface for every locale you ship to.

Originally published on Shotlingo

Japanese App Store Screenshots: Why Direct Translation From English Doesn't Work

Shotlingo — Tue, 26 May 2026 11:29:27 +0000

Japanese App Store Screenshots: Why Direct Translation From English Doesn't Work

Localizing your app for Japan? If you just ran your English screenshot text through Google Translate, swapped the strings, and shipped it, your japanese app store screenshots are almost certainly broken in ways you cannot see from outside Japan. Wrong fonts. Suffocating line height. English punctuation embedded in Japanese sentences. Tech-app text that switches typeface mid-word.

This is the second post in our typography-and-localization data series. The German companion post showed how German expands (longer strings, more vertical space). Japanese does the opposite. It compresses the character count but increases visual density per character. Both languages break naive English layouts, just from opposite directions.

The TL;DR

Japanese app store screenshots fail when designers treat them as translated English. Japanese characters occupy roughly the same horizontal width as English (fewer characters, but each is about 2x wider), so the text block looks similar in size but becomes visually denser. Without increasing line height from 1.4 to around 1.7, switching to a CJK-aware font like Noto Sans CJK JP or Hiragino Sans, and replacing English punctuation with 「」、。, the screenshots read as machine-translated and unprofessional to Japanese users.

Japanese App Store Screenshots Aren't Just "Translated English"

The most common mistake is assuming Japanese is a 1:1 string swap. It is not. Japanese is a different visual system with three scripts (hiragana, katakana, kanji) often mixed in a single phrase.

Let's look at character math:

English Privacy Settings is 16 characters of narrow Latin letters.
Japanese プライバシー設定 is 8 characters, but each glyph is roughly 2x the visual width of a Latin letter.
Net horizontal width: almost identical.
Net visual density: dramatically higher in Japanese.

That density is the trap. Designers see the Japanese string fits the same bounding box as the English string, declare victory, and move on. But the eye reads it as a wall of text, especially at the small sizes used in App Store screenshot captions.

The flip from German is striking. German blows past English string lengths by 30-40 percent and forces you to redesign layouts vertically. Japanese fits in the same horizontal space but forces you to redesign typography, not layout.

The Font Fallback Trap

This is the single biggest visible failure in shipped japanese app store screenshots: a visible font seam in the middle of mixed Latin and Japanese text.

Here is what happens. You designed your screenshots in Figma with Helvetica or SF Pro. The Japanese characters in your localized strings do not exist in those Latin-only fonts. iOS silently falls back to the system Japanese font (Hiragino Sans or Hiragino Mincho). The result: a sentence like Pro版で全機能を解放 renders Pro in SF Pro and the kanji in Hiragino. The stroke weights do not match. The vertical alignment shifts. The character spacing breaks.

To a Japanese user, this looks exactly as amateurish as a Times New Roman headline followed by Comic Sans body copy would look to a Western user.

The Fix

Use a font family that covers both Latin and CJK in a coherent design:

Noto Sans CJK JP from Google. Free, open source, designed specifically to harmonize with Latin Noto Sans.
Source Han Sans from Adobe. Same font, different name, same family as Noto.
Hiragino Sans. iOS system default, but only available in Apple's design tools by default.

Pick one and use it for both the Latin and Japanese parts of every screenshot string. No fallbacks, no mixed families.

Line Height: The 1.4 vs 1.7 Rule

English screenshot captions typically use a line height between 1.2 and 1.4. Japanese needs 1.6 to 1.8. This is not a stylistic preference, it is a legibility requirement.

Kanji characters are visually heavy. A typical kanji has 8 to 15 strokes packed into a square. Stack two lines of kanji at line height 1.3 and the top strokes of the lower line almost collide with the bottom strokes of the upper line. The reader's eye cannot find the line break.

Bump line height to 1.7 and the same text breathes. The information density per pixel stays high (Japanese users prefer that, as we will see), but the reading rhythm becomes natural.

If you reuse your English line height value in your Japanese export, your screenshots will look suffocated. This is one of the fastest ways to identify a machine-localized app listing.

Common Words That Look Wrong

This table is the heart of the post. Pin it, screenshot it, share it on Twitter.

  | English 
  | Japanese 
  | Char count 
  | Visual issue 




  | Settings 
  | 設定 
  | 8 → 2 
  | Tiny text block. Looks underweight next to icon. Increase font size 10-20%. 


  | Notifications 
  | 通知 
  | 13 → 2 
  | Same problem. Two kanji feel lost in space designed for 13 Latin chars. 


  | Save time 
  | 時間を節約 
  | 9 → 5 
  | Fewer chars, similar width, much denser. Needs line height 1.7+. 


  | Get started 
  | 始めましょう 
  | 11 → 6 
  | Polite form is long. Common CTA failure. Test 始める (3 chars) for tighter spaces. 


  | Download 
  | ダウンロード 
  | 8 → 6 
  | Katakana loanword. Same visual length, but uses different script than the rest of your UI. 


  | Privacy Settings 
  | プライバシー設定 
  | 16 → 8 
  | Mixes katakana and kanji. Width identical. Density doubled. 


  | "Try it free" 
  | 「無料で試す」 
  | 13 → 7 
  | Note 「」 instead of "". Using English quotes here is the most common amateur tell.

The pattern: Japanese almost always has fewer characters but rarely takes less horizontal space, and always takes more visual attention per character.

Punctuation Is Not Optional

Three small swaps separate professional from amateur:

Quotes: 「」 not " "
Comma: 、 not ,
Period: 。 not .

A sentence like "設定" を開く. screams machine translation. 「設定」を開く。 reads as native. The visual spacing of the punctuation is also designed to sit correctly with full-width characters, where English punctuation looks cramped.

How to Design Japanese App Store Screenshots Right

A checklist, in priority order:

Pick one CJK-compatible font family (Noto Sans CJK JP or Source Han Sans) and use it for all text on the screenshot, Latin and Japanese.
Set line height to 1.6-1.8, not 1.2-1.4. Multi-line headlines are the most common failure point.
Resize per-string, not globally. Short strings like 設定 and 通知 often need to scale up 10-20% to maintain visual weight. Long strings stay the same.
Use Japanese punctuation in every string. No exceptions.
Embrace density. Japanese App Store listings tolerate (and culturally prefer) more information per screen than US listings. Apple's own Japanese App Store description uses a smaller font for descriptions than the English version.
Test mixed strings carefully. Anything like iPhone対応 or Pro版 is a font seam risk. Render at final size and inspect.
Read about layout direction for any vertical text or furigana (small reading aids above kanji). Most screenshots stay horizontal, but if you use vertical script you need a font that supports it.

If you are running localization for multiple markets, the broader principles are covered in our localization hub. Japan is rarely the only market where direct translation fails. Compare with German vertical expansion and you have most of the world's typography traps in two posts.

Tools and Fonts You Should Use

The minimum viable toolkit for shipping localized japanese app store screenshots:

Font: Noto Sans CJK JP for body, optional Noto Serif JP for headlines.
Reference: Apple's Human Interface Guidelines on typography includes Japanese-specific guidance.
Text expansion check: our text expansion calculator for sanity-checking string lengths before you commit to a layout.
Visual reference: Download three top Japanese apps from the Japan App Store (LINE, メルカリ, ヤフー) and inspect their screenshot typography. The patterns repeat.
ASO basics: if you are early in your localization journey, start with our ASO pillar.
Mistake-avoidance: our list of app store screenshot mistakes catches several of these issues at the design stage.

FAQ

Do I need a Japanese designer to ship Japanese App Store screenshots?

Not strictly, but you need a Japanese-fluent reviewer. The typography rules above get you 80 percent of the way. The remaining 20 percent (natural phrasing, polite-form choice, brand voice) requires native review. Shipping without that review is the most common avoidable failure.

Can I use the same font sizes as my English screenshots?

For most strings, yes, if you also increase line height to 1.6-1.8. For very short strings like 設定 (2 chars) or 通知 (2 chars), scale up 10-20 percent so the text holds visual weight against icons and imagery. Reusing English sizing without adjusting line height is the single fastest way to make Japanese screenshots look suffocated.

Is Hiragino better than Noto Sans CJK JP?

For on-device iOS rendering, Hiragino is the system default and what users see everywhere else in the OS. For App Store screenshots that you design in Figma or Sketch, Noto Sans CJK JP is free, harmonizes with Latin Noto Sans, and looks consistent across export pipelines. Both are excellent. Pick one and stick with it across every screenshot in the same listing.

Ship Japanese Screenshots That Actually Convert

Direct translation gets you broken japanese app store screenshots. Correct typography gets you screenshots that look native, build trust, and convert. The difference is one font swap, one line-height adjustment, and three punctuation marks.

If you want a faster path: Shotlingo handles font fallback, line height, and CJK punctuation automatically when you localize a screenshot from English into Japanese. Create a free account and try localizing one screenshot. You will see the seam-free render in under a minute.

Originally published on Shotlingo

Why German App Store Listings Need 30% More Vertical Space

Shotlingo — Thu, 21 May 2026 08:59:57 +0000

Why German App Store Listings Need 30% More Vertical Space (Data-Driven Analysis)

If you are localizing an app for Germany and reusing your English screenshot template pixel for pixel, your German app store listing is almost certainly broken in subtle but conversion-killing ways. Not in a catastrophic, refuse to upload kind of way, but in the slow, quiet way that costs you conversions: clipped headlines, awkward line wraps, captions that spill past the safe area on iPhone Pro Max, and feature lists that look squeezed compared to the English version.

We pulled real measurements from a few hundred translated UI strings, captions, and headlines and the pattern is consistent. The average German app store listing needs roughly 30 percent more vertical space than its English counterpart, and certain compound nouns blow that number out to 40 to 45 percent on their own. This post breaks down the data, shows you exactly where layouts fail, and gives you a playbook for designing screenshots that work in German on the first try.

The TL;DR

German text is on average 30 to 35 percent longer than the English equivalent. For app store screenshots and metadata specifically, that translates to: 30 percent more vertical space for headlines, 35 percent larger text containers in screenshots, 25 percent more padding because compound nouns cannot be hyphenated cleanly, and roughly 10 to 15 percent smaller font sizes when the layout cannot stretch. The 4000 character app description limit is rarely the problem. Tight screenshot captions are where almost every team fails.

German App Store Listing Text Expansion: The Numbers

Text expansion is well documented by both Apple's localization guidance and Google's localization style guide, but neither quantifies what it means for screenshot design. Linguistic research from the W3C on text size in translation puts German between 10 and 35 percent longer than English depending on string length, with the kicker being that shorter strings expand more in relative terms. That is exactly the kind of string you find in screenshot captions and call-to-action buttons, which is exactly where most teams get burned.

Here is what real, measured expansion looks like for the kind of microcopy that lives on app store screenshots:

Save time becomes Zeit sparen: 10 characters vs 11. Roughly the same.
Get started becomes Loslegen: 11 vs 8. One of the rare cases German is shorter.
Download becomes Herunterladen: 8 vs 13. About 40 percent longer.
Settings becomes Einstellungen: 8 vs 13. About 60 percent longer.
Notifications becomes Benachrichtigungen: 13 vs 18. About 40 percent longer.
Privacy Settings becomes Datenschutzeinstellungen: 16 vs 24. About 43 percent longer, in a single compound noun.
Customize your experience becomes Personalisieren Sie Ihre Erfahrung: 26 vs 34. About 40 percent longer.

Notice the floor and the ceiling. Common verbs hover around parity. Anything involving a compound noun jumps 40 percent or more, and you cannot escape compound nouns in German because that is literally how the language builds vocabulary.

Where German App Store Listings Break

Text expansion is invisible in a spreadsheet. It becomes painful the moment you drop the translated string into your existing template. Across audits we have done, the failure points repeat in the same four places.

1. Screenshot headline area

Most English screenshot templates allocate two lines for the headline at the top of the canvas. A typical English headline like "Plan your week in seconds" fits on two lines at 120 to 140 px font size. The German version, "Planen Sie Ihre Woche in Sekunden," wraps to three lines at the same font size, eats into the device mockup below it, and looks visually heavier than the English original.

2. Caption strip under the headline

This is the worst offender. Captions are short, which is exactly the regime where German expands the most in percentage terms. "Notifications you control" becomes "Benachrichtigungen, die Sie steuern" and a tight two line caption becomes a wrappy three line caption that crowds the device.

3. Feature bullet lists inside the screenshot

If you have a screenshot showing three or four bullet features ("Sync everywhere", "Privacy first", "No ads"), the German equivalents add roughly 30 percent width per bullet. On 1242 px wide iPhone screenshots, that pushes bullets past the safe horizontal area unless you preemptively shrink the container.

4. App description preview on the listing page

The first two lines of your description are what users see before tapping "more." An 800 character English description becomes roughly 1100 characters in German, which sounds fine against the 4000 character limit, but the visible preview lines now show only one and a half sentences instead of the two and a half you had in English. You lose hook strength even though you are well under the limit.

The 7 Common German Words That Wreck Your Layout

If you only memorize one table from this post, make it this one. These are the seven words and phrases that appear in nearly every app store listing and that consistently break English-first layouts.

  | English 
  | German 
  | Character Delta 
  | Layout Risk 




  | Download 
  | Herunterladen 
  | +62% 
  | Breaks CTA buttons 


  | Settings 
  | Einstellungen 
  | +62% 
  | Breaks tab bar labels and section headers 


  | Notifications 
  | Benachrichtigungen 
  | +38% 
  | Wraps screenshot captions 


  | Privacy Settings 
  | Datenschutzeinstellungen 
  | +50% 
  | Single compound noun, no wrap point 


  | Customize your experience 
  | Personalisieren Sie Ihre Erfahrung 
  | +31% 
  | Three line headlines instead of two 


  | Account 
  | Benutzerkonto 
  | +86% 
  | Menu labels overflow 


  | Subscribe 
  | Abonnieren 
  | +11% 
  | CTA buttons get tight

Two patterns to take away. First, compound nouns like Datenschutzeinstellungen and Benutzerkonto cannot be soft hyphenated nicely without manual &shy; hints. Second, the percentage delta is highest exactly where you can least afford it: buttons, tab bar labels, and short captions.

How to Design German App Store Listings Right

The fix is not to translate and hope. It is to design the German version as a first class layout with its own type scale and its own safe areas. Five rules will get you 90 percent of the way there.

1. Reserve 30 to 35 percent more vertical space for the headline area

If your English template uses a 280 px tall headline zone, the German version should plan for 370 to 400 px. Either move the device mockup down or shrink it slightly. Do not compress the headline font.

2. Drop headline font size by 10 to 15 percent

When the headline still does not fit even with the extra vertical space, the next lever is font size. Going from 140 px to 120 px is usually enough and is barely noticeable against the device, which already dominates the visual hierarchy.

3. Add 25 percent more horizontal padding around captions

Compound nouns will not break cleanly. Give them room or they will look squeezed against the edges. This is more forgiving than trying to find clean wrap points inside a 24 character compound.

4. Use `&shy;` soft hyphens for the worst offenders

For words like Datenschutz&shy;einstellungen, a soft hyphen lets the rendering engine break the word at a semantically clean point. This is what native German design systems do and it should be in your screenshot template too.

5. Re-check on iPhone SE width

iPhone SE is the narrowest active iPhone screenshot size. If your German layout works at SE width, it will work everywhere. If you only test on Pro Max, you will ship clipping you cannot see until users start complaining.

What Tools to Use

You do not have to eyeball this. A few tools make a huge difference.

A text expansion calculator to predict the German length of any English string before you commit to a layout. This is the single highest leverage tool when planning a German layout.
The Shotlingo German screenshot localization guide, which has the specific font sizes, padding values, and safe areas we use for German.
The broader localization hub for everything beyond German, including French, Spanish, and Japanese, each of which has its own expansion profile.

If you want the full picture on screenshot design beyond localization, read our pillar on what ASO is in 2026 and the companion piece on app store screenshot mistakes to avoid, both of which assume English first but cover the structural principles every German layout builds on.

FAQ

How much longer is German than English, on average?

Between 30 and 35 percent longer for typical UI and marketing copy, with short strings expanding more in percentage terms (40 percent plus) and long descriptive paragraphs expanding less (around 20 percent). This is consistent with W3C and Apple localization guidance.

Do I need a separate screenshot template for German?

You need separate layout values: more vertical space for the headline, smaller font sizes, more horizontal padding. You do not necessarily need a separate visual identity. The cleanest approach is a single template with a "language profile" that adjusts type scale and spacing for German automatically.

Can I just use a smaller font for German and keep everything else the same?

You can, but you will lose visual punch. The better approach is to combine a slightly smaller font (10 to 15 percent) with more reserved vertical space (30 percent) and more padding (25 percent). Doing only the font change makes the German version look weaker than the English original, which is the opposite of what you want in your second largest European market.

Localize Your App Store Listing the Right Way

German is the canary in the coal mine for localization. If your layout survives German, it will survive Finnish, Hungarian, and most of the long-tail European languages that expand even more. If it does not, you are leaving conversions on the table in one of the highest spending app markets in the world.

Shotlingo handles the layout math for you. Drop in your English screenshots, pick German, and the type scale, padding, and safe areas adjust automatically using the same data this post is built on. Create a free account and ship a German app store listing that actually fits.

Originally published on Shotlingo

Apple Product Page Optimization (PPO) Guide for 2026

Shotlingo — Mon, 18 May 2026 09:38:50 +0000

Apple Product Page Optimization (PPO) Guide for 2026

Apple Product Page Optimization is the single most underused growth lever on the App Store in 2026. It is free, it is native, and it uses real organic App Store traffic to tell you which creative actually converts. Yet most indie developers and even many mid-sized studios still rely on gut feeling for their icon and screenshots. This guide walks you through what Apple Product Page Optimization is, how it differs from Custom Product Pages, how to set up your first test in App Store Connect, how to read the results without fooling yourself, and the advanced tactics that ASO teams are using this year.

If you only have ten minutes, here is the short version: pick one variable (icon, screenshots, or app preview), test it against your default page in your top market, give it at least 30 days, and let Apple call the winner. Everything else in this guide is a refinement of that loop.

What is Apple Product Page Optimization?

Apple Product Page Optimization (often shortened to PPO) is Apple's native A/B testing feature inside App Store Connect. It launched with iOS 15 in December 2021 and has matured significantly by 2026. PPO lets you run up to three alternate "treatments" against your current default product page, with Apple randomly splitting organic App Store traffic across each variant and declaring a statistically significant winner.

The mechanics are simple. You create a test, choose which asset you want to experiment with, upload up to three new versions, and Apple handles the traffic split. Each treatment must go through App Review just like a regular submission, so plan for a 24 to 48 hour delay before your test goes live. Once live, the test runs for up to 90 days, although most healthy tests reach significance in 14 to 30 days.

PPO is fundamentally a conversion rate tool. It does not change your search ranking or your keyword indexing. It tells you, with real money on the line, which creative makes more visitors tap "Get." That is why PPO sits at the top of every serious App Store Optimization roadmap in 2026.

PPO vs CPP: Which One Do You Need?

One of the most common questions we get from new ASO managers is whether to invest in Apple Product Page Optimization or in Custom Product Pages (CPP). The honest answer is that they solve different problems and the best teams use both. Here is a side-by-side comparison.

  | Feature 
  | Product Page Optimization (PPO) 
  | Custom Product Pages (CPP) 




  | Primary purpose 
  | A/B test your default page 
  | Create targeted pages for paid campaigns or audiences 


  | Traffic source 
  | Organic App Store traffic (random split) 
  | Driven by unique CPP URL you share 


  | Number of variants 
  | Up to 3 treatments plus control 
  | Up to 35 custom pages per app 


  | What you can change 
  | Icon, screenshots, app preview 
  | Screenshots, app preview, promotional text 


  | Winner declared by Apple? 
  | Yes, with statistical confidence 
  | No, you measure conversion via analytics 


  | Per-locale? 
  | Yes, one test per locale 
  | Yes, you can localize each CPP 


  | Best for 
  | Improving baseline organic conversion 
  | Matching paid ad creative to landing page

If you are running paid user acquisition or running influencer campaigns, you absolutely need CPPs. Read our complete guide to Apple Custom Product Pages and our CPP localization playbook for those use cases. If you want to systematically improve the page that ranks for your branded and category keywords, PPO is the right tool. Most teams should be running both in parallel.

What You Can and Cannot Test with Apple Product Page Optimization

Apple is deliberately restrictive about what PPO can touch. The framework is designed for visual creative testing only, not for repositioning your app. Here is the exact scope in 2026.

  | Asset 
  | Testable with PPO? 
  | Notes 




  | App icon 
  | Yes 
  | Requires icon to be present in app binary via alternate icons 


  | Screenshots 
  | Yes 
  | All sizes for the locale must be provided 


  | App preview video 
  | Yes 
  | Up to 3 previews per treatment 


  | App name 
  | No 
  | Use a CPP or a regular metadata update 


  | Subtitle 
  | No 
  | Cannot be A/B tested natively 


  | Description 
  | No 
  | Tested manually via release versioning 


  | Keywords 
  | No 
  | Keywords are not user-facing creative 


  | Price or IAP 
  | No 
  | Use server-side pricing experiments instead

The key implication is that Apple Product Page Optimization is a creative tool, not a positioning tool. If you want to test a new value proposition, you have to encode it visually into your screenshots or icon. This is exactly why localized screenshot quality matters so much. Our screenshot localization workflow gives you a head start by producing per-market screenshot sets you can drop straight into a PPO treatment.

How to Set Up a PPO Test in App Store Connect

Setting up your first Apple Product Page Optimization test takes about 20 minutes once your creative is ready. Here is the exact flow.

Step 1: Navigate to the right section

Open App Store Connect, select your app, click the App Store tab, then choose Product Page Optimization in the left sidebar. You will see a list of past and active tests.

Step 2: Create the test

Click Create Test and give it a descriptive name. We recommend a naming convention like 2026Q2-US-Screenshots-FitnessHero so your future self can find it. The name is internal only, so be verbose.

Step 3: Choose the locale

This is the most important early choice. PPO runs per-locale, which means a test in en-US does not affect what users in de-DE see. Start with your single highest-revenue market. Do not try to test five locales at once on your first attempt because you will dilute your sample size.

Step 4: Pick exactly one variable

Choose icon, screenshots, or app preview video. Do not pick more than one. If you change the icon and the screenshots at the same time, you cannot attribute the lift. This is the single most common mistake new teams make.

Step 5: Upload your treatments

Add up to three treatments. Each one must be a complete asset set for the locale. For screenshots, that means all required device sizes. Apple's official Product Page Optimization documentation lists current size requirements.

Step 6: Configure traffic allocation

The default is an equal split between control and each treatment. If you have four-way test (control plus three treatments), each gets 25 percent of organic traffic. You can lower the treatment allocation if you are worried about exposing too many users to an unproven variant, but the lower the allocation, the longer the test runs.

Step 7: Submit for review

Each treatment goes through App Review independently. This usually takes 24 to 48 hours in 2026. Treatments are reviewed for guideline compliance, not for quality, so make sure your screenshots follow Apple's marketing guidelines around device frames and status bars.

Step 8: Let the test run

Resist the urge to peek every hour. Give the test at least 14 days. Most teams stop at 30 days, which is the sweet spot for statistical significance on apps with moderate traffic. If your app is small, you may need the full 90 days that Apple allows.

Reading PPO Results: Statistical Significance and Lift

When you open the results dashboard, Apple shows you two numbers per treatment: the conversion rate and the improvement versus the control, along with a confidence indicator. The confidence indicator is what tells you whether the difference is real or just noise.

A reliable Apple Product Page Optimization result needs three things. First, enough visitors per treatment, ideally 2000 minimum, although 1000 can work for high baseline conversion apps. Second, a confidence level of 90 percent or higher, because anything lower is just a coin flip dressed up in statistics. Third, a meaningful effect size, which we define as at least a 3 percent relative lift. Anything below 3 percent is usually not worth the operational overhead of a rollout.

One nuance that catches teams off guard is that PPO measures impression-to-install conversion on the App Store itself, not retention. A treatment that wins on PPO might attract worse-fit users who churn faster. Always cross-reference your PPO winner with Day 7 retention before you commit. We cover this validation step in detail in our screenshot A/B testing deep dive.

Common Apple Product Page Optimization Mistakes

After running hundreds of PPO tests with customers, we see the same mistakes again and again. Avoiding these will put you ahead of 80 percent of competitors.

Running too many tests in parallel across locales. If you have four active tests, your operational attention is split four ways and your interpretation of each result gets fuzzier. Start with one test in one locale, ship the winner, then move on.
Stopping tests too early. A treatment that looks 15 percent better at day 3 frequently regresses to the mean by day 14. Wait for confidence, not for a feeling.
Testing icon and screenshots simultaneously. If both change, you cannot tell which moved the needle. Apple does not let you bundle them into a single test anyway, but some teams run two overlapping tests and confuse themselves.
Not localizing the test treatments. A treatment built for US users may underperform in Japan because of cultural and density differences. Always localize before launching a non-English PPO test.
Ignoring qualitative feedback. Conversion is one signal. App Store ratings, support tickets, and TestFlight comments all carry information about whether your new creative is honest about what the app does. A misleading treatment can win on conversion and lose on retention.
Forgetting App Review timelines. If your treatment gets rejected because the screenshots show fake content or a device with a status bar, you lose a week. Pre-check your assets against Apple's guidelines before you submit.

Advanced PPO Tactics for 2026

Once you have run a few baseline tests, here are the advanced moves we see top teams using this year.

Sequential testing with a creative ladder

Instead of testing three random variants, build a "ladder" of hypotheses. Test 1 establishes the best hero screenshot layout. Test 2 swaps the headline copy on the winner. Test 3 changes the background color on the new winner. Each test compounds on the previous one, and over six months you can lift baseline conversion by 30 percent or more.

Localized PPO as part of a market-entry plan

When you launch in a new country, run a PPO test in that locale within the first 60 days. Even with low traffic, the directional signal helps you adapt creative quickly. Pair this with our CPP localization guide for paid campaigns in the same market.

Seasonal treatments

Test a seasonal screenshot set (holiday, back-to-school, summer fitness) against your evergreen control. Even if seasonal does not win year-round, you may find a 4-week window where it dominates, which is worth scheduling into your release calendar.

Icon micro-tests

Icons are sticky on home screens, so big icon changes are risky. Use PPO to test subtle variations: a slightly bolder mark, a different background color, a new accent. Subtle wins still translate to thousands of incremental installs at scale.

Pairing PPO with your screenshot tooling

The faster you can produce variants, the more tests you can run. Manual screenshot production caps most teams at one or two PPO cycles per quarter. Using a dedicated screenshot generator from our ASO tools hub brings that down to a one-day turnaround for a full variant set, including device frames and localized text.

For deeper technical reading, Apple's own App Store Connect documentation covers the API endpoints and reporting fields you can use to pull PPO data into your own dashboards, and the App Store screenshot specifications page lists the current size and format requirements for treatments.

FAQ

How long should an Apple Product Page Optimization test run?

The minimum useful duration is 14 days, but 30 days is the realistic sweet spot for most apps. Apple allows tests to run up to 90 days, which is occasionally necessary for low-traffic apps that need more impressions to reach statistical significance. Stopping a test before day 14 almost always produces a result you should not trust.

Can I run PPO and Custom Product Pages at the same time?

Yes, and you should. PPO optimizes your default page for organic traffic, while CPPs serve targeted variants to paid campaigns, influencer audiences, or specific feature launches. They are complementary, not competitive. Just keep the test scope clear in your head so you do not confuse organic lift with paid lift.

Does Apple Product Page Optimization affect my keyword rankings?

No. PPO only affects conversion on the product page itself. Your search ranking is driven by keywords, downloads, retention, and ratings, none of which are part of a PPO test. A winning PPO treatment can indirectly improve rankings over time because higher conversion sends positive signals to Apple's ranking algorithm, but there is no direct keyword effect.

Start Testing Today

Apple Product Page Optimization is the closest thing to a free conversion optimization team that the App Store gives you. The only real cost is the creative production. If you have been holding back because building three new screenshot sets feels like too much work, that is the problem to solve first. Sign up for a free Shotlingo account to generate localized screenshot variants in minutes, ship them as PPO treatments this week, and let Apple tell you which one wins.

Originally published on Shotlingo

Best Free Tools for App Store Screenshot Localization in 2026

Shotlingo — Thu, 14 May 2026 12:06:14 +0000

Best Free App Store Screenshot Localization Tools in 2026

If your budget is stretched across translation, design, and ad spend, the ecosystem of free app store screenshot localization tools has never been stronger. In 2026 you can capture a screenshot from Xcode, run the copy through a free translator, check it for text expansion, validate the locale code, preview the right to left version, and drop the whole thing into a free template, all without paying a cent. The catch is that no single free tool does the whole job.

This roundup walks through ten tools we use or recommend in our own workflow. Some are ours, most are not. We ranked them by where they fit in a real pipeline, and called out what is free and what is gated. For the broader ASO toolbelt, our best ASO tools of 2026 roundup covers the paid landscape.

Why Use Free App Store Screenshot Localization Tools?

The obvious answer is cost. The less obvious answer is iteration speed. When localization is free at the margin, you stop treating it as a quarterly project and start shipping it alongside every feature release. A team that localizes once a year almost always loses to a team that localizes every sprint, because the second team learns faster.

Free tools also let small teams compete with funded studios. You do not need a six figure tooling budget to ship a properly localized listing. The free app store screenshot localization tools in this list are the ones we would reach for if we were starting from zero today.

One caveat. Free tools optimize for the common case. The moment your needs get specialized, for example bulk regenerating 40 locales every release, you will outgrow them. Start free, prove the workflow, then upgrade only where the pain is real. We cover that at the end of this post and in our ASO 2026 pillar.

Quick Comparison: Free App Store Screenshot Localization Tools

  | Tool 

  | Free features 

  | Limitations 

  | Best for 

| Shotlingo Free Tools 

  | Text expansion calculator, locale code lookup, RTL preview 

  | No bulk rendering on the free tier 

  | Pre flight checks before you commit to a design 

| AppLaunchPad Free Tier 

  | Template based screenshot builder, multiple device frames 

  | Watermark on free exports, limited locale tooling 

  | One off screenshot mockups with no localization layer 

| Mockupper 

  | Free device mockup generator, common iPhone and iPad frames 

  | No translation or text layer support 

  | Wrapping a finished screenshot in a device frame 

| Apple Localization Glossary 

  | Official Apple terminology in 40 plus languages 

  | Terminology only, not full translation 

  | Getting platform terms like Settings or Wallet exactly right 

| Google Translate 

  | Free machine translation for 130 plus languages 

  | Tone is often flat, idioms break 

  | First pass translation before human review 

| DeepL Free 

  | Higher quality translation for European and East Asian languages 

  | Character cap on free tier, fewer languages than Google 

  | Polishing marketing copy in supported languages 

| Figma Community Templates 

  | Free downloadable App Store screenshot templates 

  | Manual swap for each locale, no automation 

  | Designers who already live in Figma 

| AppScreens Free Tier 

  | Template based screenshot maker with starter export 

  | Locked premium templates and exports on free plan 

  | Trying a competing tool before you commit 

| Xcode Simulator 

  | Capture pixel perfect screenshots in any locale Apple supports 

  | Mac only, no marketing layer 

  | Generating the raw source screenshots you will localize 

| Shotlingo Locale Code Lookup 

  | Search and copy the exact App Store Connect locale code 

  | No translation features, lookup only 

  | Avoiding the classic en-US vs en-GB mistake

10 Best Free Tools for App Store Screenshot Localization

Here is the full breakdown, ordered roughly by where each tool fits in the workflow rather than by raw quality.

1. Shotlingo Free Tools

Our own free toolset lives at /tools and is built for the pre flight stage of localization. The three tools we ship for free are the Text Expansion Calculator, the App Store Locale Code Lookup, and the RTL Screenshot Preview.

What is free: All three tools, no signup gate. What is limited: Bulk rendering, AI translation, and the full template library are paid. Best for: Validating that your English copy will not overflow once translated, confirming the locale code Apple expects, and seeing how Arabic or Hebrew breaks your composition before you ship to a translator.

2. AppLaunchPad Free Tier

AppLaunchPad is one of the older template based screenshot makers and still has a usable free tier. You pick a template, drop in a device frame and some copy, and export. The free export carries a small watermark.

What is free: Template library, device frames, basic export. What is limited: Watermark removal and bulk locale automation sit behind the paid tier. Best for: Solo developers who want a quick mockup to share with stakeholders.

3. Mockupper

Mockupper focuses narrowly on wrapping a flat screenshot in a realistic device frame. It is not a localization tool by itself, but it solves a real subproblem. Once you have a localized screenshot rendered, you still need to present it in a frame that matches Apple's current device generation.

What is free: Most device mockups and exports. What is limited: No text layer, no translation, no template logic. Best for: The last step of a workflow where you already have the localized image and just need a frame.

4. Apple Localization Glossary

Apple publishes an official localization glossary that contains the canonical translation of every platform term, from Settings to Wallet to Sign in with Apple, in more than 40 languages. If your screenshot copy uses an Apple specific term, you should pull it from this glossary, not a generic translator. Browse it at developer.apple.com/localization.

What is free: The entire glossary, including downloadable AppleGlot files. What is limited: Terminology only, so you cannot translate full sentences. Best for: Making sure your German screenshot uses the canonical Apple term.

5. Google Translate

The default baseline for free machine translation. Google Translate covers 130 plus languages, runs in the browser, and is free. The tone is often flat and it struggles with idiomatic marketing copy, but for a first pass it is fine.

What is free: Everything, plus the API up to a generous quota. What is limited: Quality varies by language pair. Japanese, Korean, and Arabic output usually needs heavier human editing. Best for: Getting a rough translation in front of a native reviewer fast.

6. DeepL Free

DeepL has earned a reputation for nuanced translation, particularly between European languages and into Japanese. The free tier is generous enough that most solo developers will never pay.

What is free: Web translation with a monthly character cap, browser extensions, basic desktop app. What is limited: Fewer languages than Google, no glossary on the free tier. Best for: Polishing short marketing copy where tone matters. Try it side by side with Google at deepl.com and pick the more natural output.

7. Figma Community Templates

The Figma Community is full of free App Store screenshot templates, many of them surprisingly well built. You download the template, duplicate the page per locale, and swap copy by hand.

What is free: Most community templates and the Figma free tier. What is limited: No automation. Every locale is a manual duplicate, which gets painful past three or four languages. Best for: Designers who want full control over composition.

8. AppScreens Free Tier

AppScreens is a competing template based screenshot tool with a real free tier. You can build a screenshot, preview it, and export a starter version without paying.

What is free: Basic templates, starter exports, locale switcher in preview. What is limited: Premium templates and bulk export sit on the paid plan. Best for: Comparing the template based approach before you settle on one tool.

9. Xcode Simulator (Apple Sandbox)

Xcode ships with the iOS Simulator, which lets you change device language and region and capture pixel perfect screenshots of your real app in any Apple supported locale. The screenshots come out at the exact resolution Apple expects for App Store Connect, which saves a step downstream.

What is free: Everything. Xcode is a free download from the Mac App Store. What is limited: Mac only, and the Simulator captures the app, not the surrounding marketing layer. Best for: Generating the raw source screenshots that every other tool in this list will frame, caption, and localize.

10. Shotlingo Locale Code Lookup

We list our App Store Locale Code Lookup twice for a reason. App Store Connect expects very specific locale codes, for example en-GB for British English and pt-BR for Brazilian Portuguese, and getting the code wrong means your upload silently fails or attaches to the wrong locale.

What is free: The full lookup, no signup. What is limited: Reference tool, not a translator. Best for: Anyone who has ever wondered why their Spanish screenshots were not showing up in Mexico because they used es-ES instead of es-MX.

How to Combine Free Tools for a Full Localization Workflow

A toolbox is only useful if you know the order to reach for things. Here is the workflow we recommend to teams who want to go fully free, end to end.

Capture the source screenshots. Use Xcode Simulator to grab raw frames in your primary locale, usually en-US.
Validate locale codes. Run every target market through the Locale Code Lookup so you are not guessing.
Check text expansion. Drop your headline into the Text Expansion Calculator to confirm German and Russian will not overflow.
Translate the copy. First pass through Google Translate or DeepL Free, then validate Apple specific terms against the Apple Localization Glossary.
Preview right to left layouts. Use the RTL Screenshot Preview before you commit to an Arabic or Hebrew design.
Compose the screenshot. Use a Figma Community template, AppLaunchPad free, or AppScreens free to lay out the marketing layer.
Frame the final image. Run it through Mockupper for the device frame if your template did not handle it.
Upload. Submit through App Store Connect with the locale codes you validated in step 2.

This gets you a fully localized App Store listing without spending a cent. It is slower than a paid pipeline past three or four locales, but it ships. For the strategic side, our localization hub walks through it locale by locale.

When to Upgrade to Paid Tools

Free is not free forever. Three signals tell you it is time to spend money.

You are localizing into more than five markets. The manual duplicate step in Figma or AppLaunchPad starts costing more in designer time than a paid tool would cost outright.

You ship screenshot updates every release. If your screenshots are a living asset, automation pays for itself in the second month. Bulk rendering and template inheritance are the features you will miss first.

You are running paid CPP experiments. Custom Product Pages multiply screenshots by locales. The math gets ugly fast, and free tools are not built for that volume.

If any of these describe you, create a Shotlingo account and try the paid tier alongside the free tools you already use.

FAQ

Are free app store screenshot localization tools good enough for production?

For one to three locales, yes. The combination of Xcode Simulator, DeepL Free, the Apple Localization Glossary, and a Figma template will get you to a shippable result. Past three locales, the manual labor cost starts to outweigh the price of a paid tool.

Which free translation tool is best for App Store copy?

For European languages and Japanese, DeepL Free usually reads more naturally than Google Translate. For everything else, Google Translate has wider language coverage. Run both and pick the output that needs less editing. Always have a native speaker review the final copy.

Can I localize App Store screenshots without a Mac?

Mostly yes. You can do translation, layout, and framing on any operating system using browser based tools. The one step you cannot do without a Mac is the Xcode Simulator capture. Some teams rent cloud Macs for that single step and run the rest of the pipeline on Windows or Linux.

Start With the Free Stack

You do not need a paid tool to ship a properly localized App Store listing in 2026. You need a clear workflow and a handful of focused free app store screenshot localization tools used in the right order. Start with our free tools hub, validate your locale codes, check text expansion, preview right to left layouts, and then layer in translation and design.

If you want to try the full Shotlingo workflow, create a free account in under a minute. The worst version of localization is the one you never ship.

Originally published on Shotlingo

How Apple Custom Product Pages Work With Localization (2026 Guide)

Shotlingo — Mon, 11 May 2026 09:23:42 +0000

How Apple Custom Product Pages Work With Localization (2026 Guide)

If you are running App Store ads or growth experiments in 2026, custom product pages localization is the single most underused lever in ASO. Apple Custom Product Pages (CPP) launched with iOS 15 and gave every developer up to 35 alternate versions of their product page, each with unique screenshots, app preview videos, and promotional text. What most teams forget is that every CPP is itself a per locale object. A CPP built for the US market is not the same asset as a CPP built for Japan, and the moment you treat them as the same, you start leaving installs on the table.

This guide explains how CPP and localization interact, the realistic math behind a 35 by 40 grid of variants, the field-by-field strategy that actually moves conversion, and the App Store Connect workflow for shipping a properly localized CPP. If you have not read our broader Apple Custom Product Pages guide yet, start there for the fundamentals. This post picks up where that one ends.

Why Custom Product Pages Localization Is the Most Overlooked ASO Lever

Walk into any growth team and ask how many CPPs they run. You will usually hear a confident answer between five and fifteen. Ask how many of those CPPs are localized into the markets that drive 60 percent of their non-US traffic and the room goes quiet. This is the gap. Teams treat CPP as an English-first creative testing tool when it is in fact a per locale conversion tool.

The reason custom product pages localization gets skipped is partly cost and partly process. Localizing one default product page already feels like a project. Localizing fifteen CPPs into five languages can sound like sixty separate creative deliverables. In reality it is closer to fifteen real briefs plus a translation pipeline, and the conversion lift is usually large enough to pay for itself inside one ad campaign. According to Apple's official documentation, every CPP supports the same locales as your default product page, which means the infrastructure is already there. You just have to use it.

If you are still framing localization as a translation problem, read our pillar on what ASO looks like in 2026. Modern ASO is locale-native, not English-translated.

How Custom Product Pages and Localization Interact

To use this lever well, you need a precise mental model of how the two systems combine.

One CPP, many locales

When you create a CPP in App Store Connect, Apple gives you a Default version. That default acts as the fallback for any locale you have not explicitly filled in. Then for every locale your default product page supports, you can choose to override the screenshots, app preview videos, and promotional text. The override is per locale, per CPP, and per field. You can localize screenshots only and let the promotional text fall back to the default, or vice versa, although mixing fallback behavior is usually a sign you have not finished the job.

Each localized CPP variant gets the same ppid URL parameter as its parent CPP. The locale is resolved by the user's App Store storefront, not by the URL. That means a single CPP link sent to a Japanese user surfaces the Japanese variant automatically, as long as that variant exists. If it does not, the user sees the Default in English, and you have just wasted ad spend.

The 35 by 40 math

Apple allows up to 35 CPPs per app, and your product page can support up to roughly 40 locales depending on regional availability. On paper this is 1,400 possible variants. In practice almost nobody should attempt to fill that grid. The interesting question is not the maximum, it is the smallest set that captures most of the upside.

The realistic answer almost always lands between 10 and 20 fully localized CPPs. Beyond that you start fighting diminishing returns, and the operational cost of keeping each variant fresh begins to exceed the conversion benefit.

Realistic Custom Product Pages Localization Strategy

The strategy that works in 2026 is to compound personas and locales rather than testing them in isolation.

Pick 3 personas, top 5 locales, 15 high-impact CPPs

Identify your three highest-value user personas. For a fitness app this might be beginners, runners, and strength trainers. For a finance app it might be students, freelancers, and small business owners. Then identify your top five revenue or install locales. The cross product gives you fifteen CPPs, each tightly targeted in both audience and language. This is the sweet spot we see most teams converge on.

  | Market 
  | Locale code 
  | Why it matters 
  | Translation priority 
  | Notes 




  | United States 
  | en-US 
  | Highest paid ad CPM, default revenue market 
  | Source 
  | Build the master CPP here, then branch. 


  | Japan 
  | ja 
  | High ARPU, strong CPP lift when localized natively 
  | Critical 
  | See our [Japanese screenshot localization workflow](/localize/app-store-screenshots-to-japanese). 


  | Germany 
  | de-DE 
  | Largest European market, text expansion is real 
  | Critical 
  | Check our [German localization guide](/localize/app-store-screenshots-to-german) for length issues. 


  | South Korea 
  | ko 
  | Mobile-first, paid ads convert well with native creative 
  | High 
  | Hangul changes both layout and reading rhythm. 


  | France 
  | fr-FR 
  | Strong organic traffic, sensitive to English-only ads 
  | High 
  | Translate promotional text first if budget is tight.

Run each persona across all five locales and you have fifteen CPPs that map directly to fifteen ad sets. This is where custom product pages localization stops being theory and starts being a campaign-level multiplier. Localized CPP for paid ads, when the ad creative language matches the destination CPP language, regularly drives a 30 to 50 percent conversion lift versus pointing the same ad at the Default English page.

Which fields actually change per locale

Not every field needs the same level of attention. In order of impact:

Screenshots. The biggest lever. Native fonts, native copy, native cultural cues. Use our text expansion calculator before you finalize layouts in German or Russian.
App preview video. Subtitles are the minimum, dubbed voiceover is the ceiling. For high-value locales like Japan and Korea, subtitles alone tend to underperform.
Promotional text. The most commonly forgotten field. Many teams ship beautifully localized screenshots while the promotional text sits in English. Apple updates this field independently of the binary, so there is no excuse.
App name and subtitle. These come from your default product page, not the CPP itself. Make sure your localization base is solid before stacking CPP variants on top of it. The localization hub covers this.

Common Custom Product Pages Localization Mistakes

After auditing hundreds of accounts, the same five mistakes show up over and over.

Mistake one. Localizing screenshots but leaving promotional text in English. The user reads the screenshots in their language, then hits a wall of English at the bottom. Trust drops, conversion drops.
Mistake two. Treating CPP locales as a translation job rather than a transcreation job. Direct translation of an English headline rarely lands. Briefs should give translators room to rewrite.
Mistake three. Building too many CPPs and localizing none of them. Fifteen English-only CPPs is almost always worse than five fully localized CPPs.
Mistake four. Ignoring text expansion. German runs 20 to 35 percent longer than English. Russian and Finnish are similar. If your English layout is tight, your German layout will break. Validate every screenshot.
Mistake five. Forgetting to refresh the Default. If a user lands on your CPP from an ad targeted at a locale you have not localized, they see the Default. A stale Default is a quiet conversion killer.

Setting Up a Localized CPP in App Store Connect (step by step)

The current App Store Connect flow is straightforward once you have your assets ready.

In App Store Connect, open your app and go to the App Store tab. Select Custom Product Pages in the left sidebar.
Click Create, name the CPP something descriptive, and choose the version it should attach to.
Apple opens the CPP editor on the Default view. Build your master English version here first. This is your fallback for any locale you do not explicitly fill in.
Use the Default versus Localized toggle near the top of the editor. Switching to Localized exposes the same locale list you have on your main product page.
Pick a locale, for example Japanese. Upload the localized screenshots, swap the app preview video if you have one, and rewrite the promotional text in native Japanese. Do not paste machine-translated output here. The promotional text is short enough that a careful human pass pays back quickly.
Repeat per locale. Save each one. Apple lets you submit the CPP for review independently of your binary, which keeps the iteration loop fast.
After approval, copy the CPP URL with its ppid parameter and use it as the destination for your Apple Search Ads or paid social campaigns targeted at that locale.

Apple's CPP setup documentation covers the exact UI in more detail if you want to bookmark it next to App Store Connect.

Measuring Localized CPP Performance

The right metrics depend on where the traffic comes from, but the core dashboard looks similar for everyone.

Conversion rate per CPP per locale. App Store Connect breaks this out natively. Compare each localized CPP against your Default product page in the same locale, not against the English Default.
Paid traffic conversion lift. Run an A/B between ads pointed at the localized CPP versus ads pointed at the Default product page in that locale. A 30 to 50 percent lift is the usual range when the localization is done well. Anything under 10 percent means the screenshots are probably translated rather than transcreated.
Retention quality by CPP. Sometimes a localized CPP drives lower install volume but materially better day 7 retention because it qualifies users more honestly. Track this.
Time to first review per locale. Localized CPPs tend to surface friction faster because users feel comfortable enough to write reviews in their own language.

If a localized CPP underperforms the Default in its own locale, the problem is almost always one of three things. The translation is too literal, the promotional text was forgotten, or the screenshots use cultural references that do not transfer. Fix in that order.

FAQ

Do I need to localize every CPP into every locale my app supports?

No. Localize only the locales where you actually plan to send traffic. Sending an ad campaign to a locale where the CPP has not been localized is fine because Apple falls back to the Default. What is not fine is localizing into a market you have no campaign or organic strategy for. Focus on the five locales where you actually spend money or have meaningful organic visibility.

Can I update a localized CPP without resubmitting the binary?

Yes. CPPs and their localized variants are reviewed independently from app binaries. You can iterate on screenshots, promotional text, and preview videos without shipping a new version of the app, which is exactly why CPP is such a fast feedback loop.

What is the difference between a localized CPP and a localized default product page?

The default product page is the page Apple shows for organic traffic. A CPP is an alternate version that only appears when a user follows a CPP-specific link with a ppid parameter. Both can be localized. The default product page is your organic foundation. CPPs are your paid and campaign-specific overlays on top of that foundation.

Ship localized CPPs without the manual grind

The math of custom product pages localization is brutal if you do it by hand. Fifteen CPPs across five locales is seventy-five screenshot sets, plus promotional text, plus video subtitles. Shotlingo automates the screenshot layer end to end, including text expansion checks, native font handling, and per locale templating. You design once in your source language and ship a fully localized set ready for upload to App Store Connect.

Create your free Shotlingo account and turn one set of source screenshots into fifteen high-converting localized CPP variants this week.

Originally published on Shotlingo

App Store Screenshot Sizes for All iPhone 17 Models in 2026

Shotlingo — Thu, 07 May 2026 11:26:17 +0000

App Store Screenshot Sizes for All iPhone 17 Models in 2026

If you ship an iOS app in 2026, you need to know the new iPhone 17 screenshot sizes Apple now requires in App Store Connect. The iPhone 17 lineup, released in September 2025, introduced a fresh 6.3" display class along with the familiar 6.9" Pro Max format. Getting these dimensions wrong is the fastest way to fail App Store review or end up with stretched, blurry visuals on the storefront.

This guide breaks down every iPhone 17 screenshot size you need, which ones are required, which are optional, and how to capture them cleanly. We will also cover localization gotchas and the most common mistakes teams make when uploading assets for the iPhone 17, 17 Plus, 17 Pro, 17 Pro Max, and the brand new iPhone Air.

What's New for iPhone 17 Screenshot Sizes

The biggest change in 2026 is that Apple split the standard iPhone display class. The iPhone 17 and iPhone 17 Pro both ship with a 6.3" panel running at 2622 x 1206 pixels. That is a brand new resolution that did not exist before, and it is now its own dedicated screenshot slot inside App Store Connect.

Meanwhile, the 6.9" display class continues to cover the iPhone 17 Plus and iPhone 17 Pro Max at 2868 x 1320. Apple added a third member to this class this year: the ultra thin iPhone Air, which uses a 6.6" panel at 2778 x 1284 but is uploaded under the 6.5" or 6.9" slot depending on your asset strategy.

For a deeper look at how screenshot specs evolved across the entire Apple lineup, read our complete guide to App Store screenshot sizes in 2026. It includes the full historical context for 5.5", 6.5", 6.7", and 6.9" devices.

Complete iPhone 17 Screenshot Size Reference

Here is the master table you can bookmark. Every iPhone 17 screenshot size uses portrait orientation by default, and Apple expects PNG or JPG files at the exact pixel dimensions listed below.

  | Device 

  | Display 

  | App Store Resolution (portrait) 

  | Required? 

| iPhone 17 

  | 6.3" 

  | 1206 x 2622 

  | Yes (new) 

| iPhone 17 Pro 

  | 6.3" 

  | 1206 x 2622 

  | Yes (new) 

| iPhone 17 Plus 

  | 6.9" 

  | 1320 x 2868 

  | Yes (baseline) 

| iPhone 17 Pro Max 

  | 6.9" 

  | 1320 x 2868 

  | Yes (baseline) 

| iPhone Air 

  | 6.6" 

  | 1284 x 2778 (6.5" slot) 

  | Optional

Why two slots cover five devices

Apple does not require a unique screenshot per phone model. Instead, they group devices by display size class. So the iPhone 17 and 17 Pro share assets, while the 17 Plus and 17 Pro Max share their own. The iPhone Air sits between the two, and most teams reuse the 6.9" assets for it.

That means you only need to design two master screenshot sets to cover the entire iPhone 17 family. If your app also supports older devices, see our breakdown of how many screenshots the App Store actually shows.

Required vs Optional iPhone 17 Screenshot Sizes

App Store Connect now treats the 6.9" display as the minimum baseline. If you do not upload 6.9" assets, your submission will be rejected. The new 6.3" iPhone 17 screenshot size joined the required list this year as well, since it covers the standard iPhone 17 and 17 Pro.

Here is what you must upload, and what you can skip:

Required: 6.9" at 1320 x 2868 pixels
Required: 6.3" at 1206 x 2622 pixels (new for iPhone 17)
Optional: 6.7" at 1290 x 2796 pixels (legacy fallback)
Optional: 6.5" at 1242 x 2688 or 1284 x 2778 pixels
Optional: 5.5" at 1242 x 2208 pixels (deprecated)

Apple will automatically scale your 6.9" assets down for older devices if you skip the smaller slots, but the result is rarely pixel perfect. You can confirm the latest requirements in Apple's official screenshot specifications.

How to Capture iPhone 17 Screenshots

You have three practical options for producing assets at the correct iPhone 17 screenshot sizes. The right choice depends on whether you have access to the hardware, how polished you want the final output to look, and how many languages you plan to localize into.

From a real device

Press the side button and the volume up button at the same time on any iPhone 17 model. The screenshot saves to Photos at the device's native resolution, which already matches the App Store Connect requirement. AirDrop the file to your Mac to keep the original pixel dimensions intact.

This is the cleanest path for product screenshots that need to match the real UI. The downside is you cannot easily swap text or backgrounds, which makes localization slow.

From Xcode Simulator

Open Xcode, launch the iPhone 17 or iPhone 17 Pro Max simulator, and press Cmd + S to save a screenshot to your desktop. The simulator outputs at the exact resolution of the modeled device, so a 17 Pro Max simulator will produce a 1320 x 2868 file ready to upload.

Apple documents the full simulator workflow in the Xcode capturing screenshots guide. This approach is great for engineering teams but lacks marketing polish.

From a screenshot generator tool

Most marketers use a dedicated tool to design the final App Store visuals. A generator lets you start from a blank canvas at the right iPhone 17 screenshot size, drop in your UI capture, add headlines, frames, and backgrounds, and export every locale at once.

Shotlingo handles all five iPhone 17 resolutions automatically. You upload one design, and it renders perfect 1206 x 2622 and 1320 x 2868 output for every language. Browse our tools hub to see what else is available, or jump straight to the localization workflow if you ship in more than one market.

How iPhone 17 Sizes Affect Localization

Bigger canvases mean more room for translated copy, but they also expose layout problems faster. A German headline that fit on a 6.5" screenshot can wrap awkwardly on a 6.9" canvas if you did not plan padding correctly. The new 6.3" slot is even tighter than the 6.7" you may be used to.

Before you commit to a headline, run it through our free text expansion calculator. It estimates how much longer your text will become in 30+ languages so you can size your title font correctly before exporting all five iPhone 17 resolutions.

If you are new to localized App Store assets, our pillar guide on what App Store Optimization looks like in 2026 covers how screenshots interact with keywords, conversion rate, and store listings across regions.

Common Mistakes with iPhone 17 Screenshots

The same handful of issues come up over and over when teams upload iPhone 17 assets. Avoid these and your submission usually clears review on the first try.

Uploading 6.7" instead of 6.9": The 6.7" slot is legacy. Apple wants 1320 x 2868 as the new baseline.
Skipping the 6.3" slot: The new iPhone 17 screenshot size at 1206 x 2622 is required, not optional.
Wrong aspect ratio: Even one pixel off and App Store Connect rejects the file. Always export at the exact dimensions.
Compressed JPGs: Heavy compression introduces banding on the iPhone 17 OLED. Use PNG when possible.
Forgetting safe areas: The Dynamic Island and rounded corners can clip headlines if you push text to the edges.
Reusing iPhone 16 assets: The 6.3" panel is genuinely new. Older 6.1" assets will look soft when scaled up.

If you want a sanity check before submitting, Apple's App Store product page documentation shows exactly how each screenshot slot renders on the live storefront.

FAQ

Do I need separate screenshots for the iPhone 17 and the iPhone 17 Pro?

No. Both phones share the same 6.3" display at 1206 x 2622 pixels, so a single set of assets covers both. Apple groups screenshot slots by display size class, not by individual SKU.

Can I just upload 6.9" screenshots and let Apple downscale for the rest?

Technically yes, but the result usually looks soft on the new 6.3" iPhone 17. For best conversion rate, design native assets for both required slots. The extra effort pays off in sharper text and crisper UI captures.

Where does the iPhone Air fit in?

The iPhone Air uses a 6.6" panel at 2778 x 1284 pixels. App Store Connect does not give it a dedicated slot yet, so most teams upload the 6.9" assets and let the system handle scaling. You can also upload to the legacy 6.5" slot if you want tighter control.

Ship Your iPhone 17 Screenshots Faster

The new iPhone 17 screenshot sizes are not hard to produce once you know the dimensions. The hard part is rendering every required size, in every language, every time you ship a feature update. Manual exports break down quickly past two locales.

Shotlingo automates the entire pipeline. Design once, get pixel perfect 1206 x 2622 and 1320 x 2868 output for every language, ready to drop into App Store Connect. Create your free Shotlingo account and ship your iPhone 17 screenshots in minutes, not days.

Originally published on Shotlingo

Best ASO Tools 2026 — Free & Paid Roundup for Indie Developers

Shotlingo — Mon, 04 May 2026 12:30:41 +0000

Best ASO Tools 2026: Free and Paid Roundup for Indie Developers

Choosing the right stack of best ASO tools in 2026 is harder than it sounds. The market is crowded with platforms promising keyword magic, AI metadata, and competitor x-ray vision. Some of them deliver. Others charge enterprise rates for features you can replicate with a free Apple Search Ads account.

This roundup is written for indie developers and small studios who care about ROI per dollar spent. We tested every tool listed below on real apps, and we will be honest about where each one shines and where it falls short. If you only have budget for one or two app store optimization tools, this guide will help you pick wisely.

How We Picked the Best ASO Tools

We evaluated each platform on five criteria that actually matter when you ship apps:

Data accuracy compared to first-party sources like App Store Connect and Google Play Console.
Workflow speed for indie developers who do not have a dedicated ASO team.
Price-to-value ratio at the entry tier, not the enterprise tier.
Localization support, since 60 percent of app revenue comes from non-English markets.
Free tier or trial that is actually usable, not a five-minute demo.

We are biased toward tools that respect indie budgets. If a platform requires a sales call to see pricing, we said so. For the foundational concepts behind these tools, our ASO pillar guide covers how the App Store and Play Store rank apps in 2026.

Quick Comparison Table of the Best ASO Tools

  | Tool 

  | Best for 

  | Pricing 

  | Free tier? 

| Shotlingo 

  | Screenshot localization at scale 

  | From around 19 USD/mo 

  | Yes (free tools) 

| AppTweak 

  | Deep keyword research and ASO intelligence 

  | From around 79 USD/mo 

  | 7-day trial 

| Sensor Tower 

  | Market intelligence and competitive data 

  | Enterprise (custom) 

  | Limited free 

| AppLaunchPad 

  | Screenshot templates and quick mockups 

  | Free or around 9 USD/mo 

  | Yes 

| AppFigures 

  | Keyword tracking and review monitoring 

  | From around 25 USD/mo 

  | 14-day trial 

| MobileAction 

  | Keyword tracking plus ad intelligence 

  | From around 69 USD/mo 

  | Free starter plan 

| Asodesk 

  | Keyword research on a budget 

  | From around 25 USD/mo 

  | 7-day trial 

| AppRadar 

  | AI metadata generation and keyword tools 

  | From around 80 USD/mo 

  | Limited free 

| Apple Search Ads 

  | Free keyword popularity data for iOS 

  | Free 

  | Yes (fully free) 

| Google Play Console 

  | First-party Android keyword and experiment data 

  | Free with developer account 

  | Yes

Best ASO Tools Reviewed in Detail

Below is the full breakdown for each of the ten ASO tools. We grouped paid platforms first, then closed with the two free first-party tools every developer should already be using.

1. Shotlingo

Shotlingo is a screenshot localization specialist built for teams who ship to many App Store and Play Store markets. Instead of rebuilding screenshots in Figma every time you launch in a new country, you upload one master design and Shotlingo translates the text, swaps fonts, and exports App Store and Play Store ready assets in 30 plus languages.

Best for: Indie devs and studios localizing screenshots into multiple markets.
Pricing: Free tools available. Paid plans start around 19 USD per month.
Key feature: AI-driven screenshot translation with font auto-pairing and store-specific export sizes.
Pros: Removes the bottleneck of localized creative production. Free utility tools like the screenshot resizer are genuinely useful even on the free plan.
Cons: Focused on screenshots, not a full keyword research suite. Pair it with a keyword tool for complete ASO coverage.

If localization is your bottleneck, our localization hub walks through the workflow from master design to 30 language exports.

2. AppTweak

AppTweak is one of the most respected names in ASO intelligence. Their keyword data is sourced from multiple signals and updated frequently, which makes it a popular pick for agencies and mid-size studios.

Best for: Teams that need defensible keyword research data to share with clients or stakeholders.
Pricing: Plans start around 79 USD per month and scale up significantly for full features.
Key feature: ASO score with actionable recommendations for title, subtitle, and keyword field optimization.
Pros: Excellent keyword difficulty and chance scores. Strong global coverage including emerging markets.
Cons: The entry price is steep for a solo indie. Some advanced reports are gated to higher tiers.

3. Sensor Tower

Sensor Tower is the platform large publishers and investors use for market sizing and competitor revenue estimates. It is overkill for most indie devs, but if you are pitching a publisher or raising funding, the data carries weight.

Best for: Market intelligence, download estimates, and competitive benchmarking at scale.
Pricing: Enterprise. Expect to talk to sales for a custom quote.
Key feature: Cross-platform download and revenue estimates plus ad creative library.
Pros: Industry-standard data trusted by publishers and analysts. Deep historical archives.
Cons: Pricing is opaque and almost always out of indie budget. Limited free tier.

4. AppLaunchPad

AppLaunchPad is a browser-based screenshot generator with more than 1000 templates. It is a fast way to draft store screenshots without opening Figma or Photoshop, which is why many first-time developers start here.

Best for: Developers who want a quick, template-driven screenshot draft.
Pricing: Free tier with watermarks. Paid removes watermarks at around 9 USD per month.
Key feature: Large template library with device frames and multi-screen export.
Pros: Low learning curve. Good for MVP launches with limited time.
Cons: Templates can feel generic, and localization across 20 plus languages is a manual job. See our Shotlingo vs AppLaunchPad comparison for a feature-by-feature breakdown.

5. AppFigures

AppFigures has been around since 2008 and remains a favorite for developers who want clean keyword tracking and review monitoring without enterprise pricing.

Best for: Indie devs who want reliable rank tracking and review alerts at a fair price.
Pricing: Plans start around 25 USD per month.
Key feature: Daily keyword rank tracking across countries plus consolidated review feeds.
Pros: Clean interface. Honest pricing with no sales call required.
Cons: Keyword research database is smaller than AppTweak or Sensor Tower. Better for tracking than discovery.

6. MobileAction

MobileAction blends ASO data with paid ad intelligence, which is unusual at this price point. If you run Apple Search Ads or Google App Campaigns, the combined view saves time.

Best for: Teams running both ASO and paid user acquisition.
Pricing: Plans start around 69 USD per month. A free starter plan exists with limited features.
Key feature: Ad creative library plus keyword intelligence in one dashboard.
Pros: Strong Apple Search Ads integration. Useful for scaling paid campaigns.
Cons: Interface can feel busy. Some keyword counts disagree with first-party sources.

7. Asodesk

Asodesk is one of the more indie-friendly platforms in this list. Pricing is transparent, and the keyword research tools are surprisingly deep for the cost.

Best for: Solo developers who want serious keyword research without the AppTweak price tag.
Pricing: Entry plans start around 25 USD per month.
Key feature: Keyword auto-suggestions and competitor keyword overlap reports.
Pros: Affordable. Decent App Store and Play Store coverage.
Cons: Smaller team and less brand recognition compared to AppTweak. Some dashboards feel dated.

8. AppRadar

AppRadar leans into AI-assisted metadata generation, which is genuinely helpful when you stare at the keyword field and your brain freezes. It also offers solid keyword research and tracking.

Best for: Developers who want AI to draft titles, subtitles, and keyword sets they can refine.
Pricing: Plans start around 80 USD per month.
Key feature: AI metadata suggestions tied to keyword volume data.
Pros: Speeds up first-draft metadata. Combines tracking and creation in one tool.
Cons: AI suggestions still need human review. Pricing competes directly with AppTweak.

9. Apple Search Ads (free)

Apple Search Ads is the single most underused free ASO tool in 2026. You do not need to actually run ads to use it. Once you create an account, the keyword popularity tool gives you Apple's own first-party search volume data on a 5 to 100 scale.

Best for: First-party iOS keyword popularity data, completely free.
Pricing: Free. You only pay if you choose to run actual ad campaigns.
Key feature: Keyword popularity scores straight from Apple.
Pros: Most accurate iOS volume data available. No third-party guessing.
Cons: No keyword difficulty metric. UI is built for ad buying, not ASO research. Read more in the official Apple Search Ads documentation.

10. Google Play Console (free)

For Android, your most important ASO tool is the one Google already gave you. Play Console offers store listing experiments, install conversion data, and acquisition reports that no third party can replicate.

Best for: Android creative testing and first-party install data.
Pricing: Free with a one-time 25 USD developer account fee.
Key feature: Store listing experiments for A/B testing icons, screenshots, and short descriptions.
Pros: Direct experiment results with statistical significance. No tool can match this for Android.
Cons: No keyword research equivalent to Apple Search Ads. The official Play Console documentation covers experiment setup in detail.

Which of the Best ASO Tools Should You Pick?

There is no single answer because the right stack depends on your stage and budget. Here are three realistic scenarios for indie developers in 2026.

Scenario 1: Solo indie, pre-launch, budget under 30 USD/mo

Use Apple Search Ads keyword popularity for iOS, Google Play Console for Android, and Shotlingo or AppLaunchPad for screenshots. Add Asodesk or AppFigures only when you have a live app with rank data worth tracking. This is the leanest viable ASO stack.

Scenario 2: Small studio, 2-3 live apps, budget around 100 USD/mo

Pair AppFigures or Asodesk for keyword tracking with Shotlingo for localized screenshots. Keep Apple Search Ads and Play Console open for first-party validation. This combination covers research, tracking, and creative without enterprise costs.

Scenario 3: Scaling studio with paid UA, budget 200 USD/mo and up

AppTweak or AppRadar plus MobileAction for the paid ads layer. Add Shotlingo for localization across 20 plus markets so creative production never blocks expansion. Sensor Tower only if you need investor-grade market data.

ASO Tools You Don't Need (Yet)

Tool stacks creep. New developers often subscribe to three keyword platforms because each promises a slightly different metric. Resist this. Here is what to skip until you actually have the problem.

Enterprise dashboards like Sensor Tower full access. Until you ship multiple apps with meaningful revenue, you are paying for data you cannot act on.
Multiple keyword tools with overlapping features. Pick one paid keyword tool and one first-party source. Stop there.
Standalone review reply tools if your current platform already includes review monitoring. AppFigures and AppRadar both ship this.

Spend the saved budget on localization and creative testing instead. That is where most indie apps leave money on the table. Our keyword optimization guide shows how to extract more value from a single keyword tool rather than stacking three.

FAQ

What are the best ASO tools for a solo indie developer in 2026?

Start free with Apple Search Ads keyword popularity and Google Play Console. Add one paid tool, either AppFigures or Asodesk for tracking, plus Shotlingo for screenshot localization. That stack costs under 50 USD per month and covers the essentials.

Are paid ASO tools worth it if I am just launching?

Not for keyword research. The first-party tools from Apple and Google are accurate and free. Paid tools become worth it when you need rank tracking across markets, competitor benchmarking, or AI metadata drafting at scale.

How accurate are third-party download estimates?

They vary. Sensor Tower and data.ai are generally considered the most reliable, but even they can be off by 20 percent or more for smaller apps. For a credibility check, cross-reference with public industry reports from data.ai when possible.

Ready to Localize Your Screenshots?

Picking the right keyword tool gets you found. Localized screenshots get you installed. If your app store creative still ships in English only, you are leaving non-English markets on the table. Create a free Shotlingo account and translate your first set of screenshots into 30 plus languages this week.

Originally published on Shotlingo