Short answer: the listing sells, the app keeps

App localization translates the text inside your app, such as buttons and menus, using string files and a translation system. App Store localization translates your store listing instead: the app name, subtitle, description, keyword field, and screenshots. Most indie apps should localize the listing first, since it brings new downloads before you touch a line of code.

What app localization actually covers

App localization means every word a user meets after the install. Button labels, menu items, onboarding copy, error notes, settings screens, push note templates. In an iOS codebase these live as key-value string files, and tools built for the job (called translation management systems, or TMS products such as Crowdin, Lokalise, and Phrase) move those strings through a fixed pipeline you can trust. You push your string files from the repo, translators or machine translation fill in each locale, a review step catches bad phrasing, and the finished files sync back into your build through an integration. The same system keeps glossaries and translation memory so your wording stays steady across releases, and it shows translators screenshots of each screen so they grasp context before they type. That pipeline is real, skilled work, and when your app UI must serve a market in its own tongue, nothing else replaces it.

Plan for per-word or per-seat pricing, a review round per release, and QA on device, since German runs long, Arabic mirrors right to left, and Japanese can break fixed-width layouts in ways no spreadsheet shows. Teams that skip this QA learn the price in one-star reviews, and those reviews stick to every storefront.

What App Store localization covers

App Store localization means every word and image a shopper meets before the install. The app name (30 characters), the subtitle (30 characters), the description (4,000 characters), the 100-character keyword field, plus screenshots and captions per locale. Apple treats this layer as separate from your binary: the languages on your App Information page in App Store Connect differ from the languages you add to your app in Xcode. Each locale you add gives you a fresh set of indexed strings, so English keywords never reach a shopper who searches in Japanese. Screenshots carry the heaviest weight here, since visitors read images before they read a word of text. Our screenshot-tools buyer guide maps the three ways teams produce them. A listing pass also ships far faster than app work: no code changes, no rebuild, no App Review risk on the binary. You'll draft text, render images, and paste both into App Store Connect. Our one-afternoon listing guide shows the full pass in a single sitting.

Five differences that decide your budget

First, location. App strings live in your codebase. Listing text lives in App Store Connect. A TMS syncs with your repo. A listing tool reads your public store URL. Neither tool reaches the other's layer, so "one tool for both" is a myth worth dropping early.

Second, skill type. String work centers on code plumbing: file formats, keys, placeholders, plural rules. Listing work centers on sales copy: 30-character names that still read well, keyword fields packed with terms shoppers type, screenshots whose captions survive translation. Different brains, different bills.

Third, cost shape. App localization prices per word or per seat and repeats each release. Listing localization prices per locale once and keeps earning with no monthly fee. Our cost guide puts a full listing locale between tool prices near $20 and agency bills in the hundreds, while in-app word counts run into the thousands for any app with real copy.

Fourth, review risk. String changes ride inside your binary, so each release passes through App Review. Listing text edits ship without touching the binary. You can test German keywords on Tuesday and revert Wednesday with zero review delay.

Fifth, payoff order. A translated listing pulls in shoppers who search in their own tongue, which lifts downloads in weeks. Translated app screens keep those shoppers from churning, which lifts ratings over months. Discovery comes first. Retention follows. Fund them in that order and each half pays for the next.

Which one should you fund first

For most indie apps, the listing wins. Three signs point that way. Your English listing already converts, so translation widens the reach of creative that works. App Store Connect shows views from storefronts whose language you don't serve, so live demand waits behind the language gap. And your budget fits one half, not both, so the half with weekly payback beats the half with quarterly payback. Our ROI guide runs the break-even math street by street.

Two cases flip the order. When your app handles money, health, or safety, shipping a Japanese listing over English-only screens reads as broken and earns harsh reviews that drag your rating in each storefront. Translate the screens first, or state the UI language plainly in your listing text so buyers opt in with eyes open. And when you already rank well in English worldwide, in-app cover unlocks markets where rivals all speak the local tongue. Outside those cases, it's the sound call. Our strategy guide lays out the revenue-ordered wave plan that follows.

The ship order that works for solo teams

Week one, run the listing pass for three locales. Pick markets your data already points to, or pick one long language, one mirrored script, and one character script to stress-test your flow. Draft names by hand (thirty characters leave no room for odd phrasing), fill keyword fields from terms shoppers type, and proof screenshots at full size for text spill. Week two, upload through App Store Connect and read installs per page view by market after six weeks. Grow where the line moves. Don't fund twenty locales on day one. Our locales reference lists each code worth funding, but treat it as a menu, not an order.

Only then start the in-app half. Push string files to a TMS, translate the core flows first (onboarding, paywall, settings), and leave edge screens for later. Ship one locale through TestFlight with a native speaker before you roll it to ten. Last comes support cover: canned replies in each language you sell in, plus a returns path for buyers who hit a wall. Each wave funds the next, and each wave teaches you what breaks while lessons are still cheap.

How App Store Localizer covers the listing half

App Store Localizer (https://asolocalization.com) fits the listing half this guide backs. Paste a public App Store URL. The tool pulls your title, description, icon, and screenshots through Apple's public lookup API. It translates the title, subtitle, description, and the 100-character keyword field per target locale. It drafts localized keywords from free heuristics over your listing. It re-renders your screenshots with translated captions in iPhone 14 Plus 1284x2778 and iPad Pro 12.9-inch 2048x2732 sizes. Coverage runs to 20-plus target locales, from Japanese, Korean, and both Chinese scripts through German, French, Spanish, and Brazilian Portuguese down to Hindi, Thai, and Vietnamese.

Prices are one-time per listing, which keeps the listing-first math friendly. Starter at $19.99 covers 3 languages with each available screenshot. Global at $99.99 covers all supported languages. No subscription, no per-seat fees. Two honest limits hold. The tool serves the store listing only, never app screens or code, so pair it with string cover through a TMS before you chase markets where the UI must be native. Keyword ideas come from listing heuristics rather than paid search-volume data, so check your top market's terms against our keyword-field guide before you ship. You download the finished assets or publish straight to App Store Connect.

Frequently asked questions

  • Is App Store listing translation part of app localization? In plain speech, yes, since both adapt your product for a market. In tooling and budget terms, no. Listing work lives in App Store Connect and uses store tools. App work lives in your codebase and uses a TMS. Plan and price them as separate line items.
  • Do I need to translate my app screens before I localize the listing? Usually not. Shoppers bear English UI behind a clear native listing far better than a listing they can't read. State the UI language in your text, ship the listing first, and translate screens for markets that convert. Skip markets where English screens would read as broken, such as finance or health apps.
  • Can Crowdin or Lokalise localize my App Store screenshots? No. A TMS moves string files and won't touch a pixel. Screenshots are images, so translating one means re-rendering the caption in the new language, reflowing layout so longer words fit, and exporting at store sizes. That's screenshot-tool work. Most teams need both: a TMS for the UI and a screenshot tool for the listing.
  • Does Apple treat the binary and the listing as separate localizations? Yes. Apple's own docs state that languages on the App Information page differ from languages added to your app in Xcode. You can ship a German listing over an English binary with no extra build. Each layer ships on its own schedule.
  • Which locales should a solo developer start with? Three. Pick the markets your App Store Connect data already points to, or pick German, Arabic, and Japanese to stress-test length, mirroring, and character scripts at once. Proof all three sets with care, then grow in revenue order.

Paste your App Store URL at https://asolocalization.com today and run the listing half this afternoon. Draft three locales, check German spill and Arabic mirroring tonight, upload through the publish path tomorrow, and read installs per page view by market in six weeks. Once the listing pulls its weight, fund the string half with the revenue it brought in.