App Store localization mistakes that kill downloads

Mistake #1: Translating your listing but not your keyword strategy

This is the most common one, and it's subtle enough that most developers never catch it. You have a well-optimized English listing. You translate the title, subtitle, and description into Japanese. The translation is accurate. But the keywords people search in Japanese are not direct translations of your English keywords.

In English, someone might search "habit tracker." In Japanese, the equivalent concept gets searched as "習慣管理" (habit management) or "習慣化アプリ" (habit-building app). A direct translation of "habit tracker" would give you "習慣トラッカー" which nobody actually searches. The words are correct. The search behavior is wrong.

The fix is doing actual keyword research for each market. Not translating keywords, but finding what people in that market type into the search bar. Use App Store Connect's search ads feature (even if you don't run ads) to see search volume estimates for different terms in each country. Or simply search in the local App Store and see what autocomplete suggestions come up.

Your ASO strategy needs to be rebuilt from scratch for each language, not ported over. The subtitle and keyword field should contain terms people in that market actually use, even if they don't map cleanly to your English terms.

Mistake #2: Same screenshots, different language overlay

Here's what typically happens. You design your screenshots for the US market. They show your app in English, with English captions. For localization, you swap the caption text. Maybe the app UI in the screenshot is still English because you didn't want to take new screenshots in every language.

Users notice. When a Japanese user sees your App Store listing with Japanese captions but English UI in the screenshots, they assume the app itself isn't translated. First impression: this isn't for me. They scroll past.

Worse, some developers don't even translate the screenshot captions. They just use English screenshots globally. In markets like Japan, Korea, and Taiwan, where users strongly prefer native-language apps, this is a conversion killer. The listing might rank in search, but nobody taps the download button.

The real fix requires more work than most people want to do: set your device to each target language, use the app with realistic sample data in that language, and capture actual screenshots. Then write captions that match how users in that market talk about the problem your app solves. Not translated captions -- rewritten ones.

If you're doing this for three or four markets, it's a full day of work. For a solo developer it's tedious. But localized screenshots are the single biggest conversion factor in non-English markets, and skipping them is essentially throwing away whatever you spent on translation.

Mistake #3: Ignoring local pricing expectations

$4.99/month feels reasonable in the US. In Southeast Asia, it's expensive for a utility app. In Japan, users are surprisingly willing to pay for quality but expect a polished experience to justify it. In Germany, the psychology around subscriptions is different -- many users prefer a one-time purchase and distrust recurring charges for simple tools.

Apple lets you set different price tiers for different countries, but most indie developers use the auto-converted prices and never think about it again. Those auto-converted prices don't account for purchasing power or local norms. $4.99 auto-converts to roughly ¥800 in Japan, which is fine. But it converts to something that feels steep in markets like Brazil or India.

The pricing guide goes deeper on strategy, but the localization-specific point is this: look at what local competitors charge in each market. If every expense tracker in Taiwan is free with ads or <$1.99/month, your $4.99/month price point isn't competitive regardless of how good your app is. Price anchoring is local, not global.

Some developers offer cheaper plans in lower-income markets using Apple's regional pricing. This works, but be aware that users can switch their App Store region. If you price too aggressively low in one market, savvy users from expensive markets will switch regions to get the cheaper price. Keep the gaps reasonable.

Mistake #4: Machine translation without review

Machine translation has gotten good enough that most sentences come out grammatically correct. That's the trap. Grammatically correct and natural-sounding are different things, and native speakers can tell immediately.

The tells are subtle. Word order that's technically valid but sounds off. Formality level that doesn't match the context (Japanese has multiple levels of politeness, and getting the wrong one makes your app feel either stiff or rude). Using the literal term when a colloquial one is standard. Translating idioms word-for-word instead of using the local equivalent.

You don't need a professional translation agency. What you need is one native speaker to read through your strings and fix the things that sound weird. Pay a freelancer $100-200 on Fiverr or Upwork for a review pass. Or find a friend who speaks the language and buy them dinner. The cost is minimal compared to the conversion impact of an app that reads like a bad translation.

The App Store listing is especially worth getting right. Users might forgive a slightly awkward settings screen, but if your App Store description reads like it was run through Google Translate, they won't even install it.

Mistake #5: Translating content but not the experience

This is the deep one, and it's where the Asia localization guide goes into detail. Translation is text. Localization is experience. They're different projects.

Date formats. Number formatting (some countries use periods where others use commas for thousands separators). Currency symbols and placement. First-day-of-week settings. Name order (family name first in East Asia, given name first in the West). Default units (metric vs. imperial). Color associations (red means luck in China, danger in the West). And payment methods -- this one is huge. If your app sells anything and only supports credit cards, you're excluding a massive chunk of users in markets where mobile payments, convenience store payments, or local payment systems dominate.

Most of these are easy fixes individually. The problem is that nobody makes a checklist of them, so developers fix some and miss others. The result is an app that feels 80% localized, and that remaining 20% is the stuff users notice first.

A practical approach: download three popular local apps in your category in the target market. Note every place where their UX differs from your US version. Dates, currency, layout density, onboarding flow, payment options. Then match those patterns. You don't need to invent a localization strategy from scratch -- you just need to meet local norms.

Mistake #6: Launching in too many markets at once

The allure of "worldwide launch" is strong. App Store Connect makes it easy to add 30 languages. Some developers interpret this as a prompt to localize for every market Apple supports.

The problem is quality. If you spread your localization effort across 15 languages, each one gets minimal attention. The translations are machine-generated with no review. The screenshots aren't localized. The keywords aren't researched. You end up with 15 half-baked localizations instead of two or three good ones.

A mediocre localization can actually hurt you. Users who find your app through a localized listing, install it, and then discover the in-app experience is rough will leave bad reviews. Those reviews tank your rating in that market, which makes future localization efforts harder because you're starting from a low rating.

Better approach: pick one or two markets where you see real opportunity. The geo arbitrage scanner can show you where your type of app is underserved. Localize properly for those markets -- full keyword research, localized screenshots, native speaker review, regional pricing. Get downloads and good reviews there. Then expand.

Japan, Germany, and Korea are often the best second markets for English-language indie apps. High purchasing power, active App Store users, and less competition than the US. But each requires real localization effort, not a checkbox exercise.

Mistake #7: Not localizing your App Store category strategy

Your category choice is global -- Apple doesn't let you set different categories per country. But the competitive landscape within each category varies enormously by market.

A category that's hopelessly competitive in the US might have wide-open spaces in another country. Productivity in the US has thousands of well-maintained apps. Productivity in Taiwan has far fewer, and the ones that exist are often localized versions of US apps with middling reviews.

This matters because if you're primarily targeting a non-US market, your category decision should optimize for that market's landscape, not the US one. The category where you'd rank #300 in the US might be the one where you'd rank #30 in Japan. Since you can only pick one primary category globally, this tension requires a deliberate choice about which market you're optimizing for.

Mistake #8: Ignoring reviews in other languages

Once you're in a new market, reviews start coming in that language. Most solo developers don't read them because they can't read the language. This is a problem for two reasons.

First, you miss bug reports and feature requests that are specific to that market. Japanese users might report that your app doesn't handle full-width characters correctly. Korean users might flag that your date parsing breaks with their calendar format. These issues don't exist in your US user base, so you never hear about them unless you're reading international reviews.

Second, responding to reviews matters for conversion in every market. When potential users see that the developer responds (even to negative reviews), it signals active maintenance. If every English review has a response but every Japanese review is ignored, Japanese users notice.

You don't need to write fluent Japanese review responses. Use a translator to understand what the review says, write a response in English, and translate it back. Keep responses simple and direct. "Thank you for the report. We'll fix this in the next update" works in any language if translated properly. The bar is "the developer cares about users in my country," not "the developer speaks my language fluently."

Mistake #9: Treating localization as a one-time project

You localize your app for version 2.0. For the next six months, every update adds new features, new strings, new UI. But the localization effort was a one-time push. New strings ship in English-only. The Japanese version gradually becomes a patchwork of translated and untranslated text.

This happens constantly, and users are less forgiving about it than you'd expect. A settings screen that's half-Japanese and half-English feels broken. It signals that the developer doesn't care about this market, which is worse than never having localized at all. At least an English-only app is consistent.

The fix is making localization part of your development workflow, not a separate project. Every new string goes into your localization files. Every PR that adds user-facing text includes the localization keys. Whether you translate them immediately or batch translations weekly, the infrastructure should make it hard to accidentally ship untranslated strings.

If you're using a modern tech stack with i18n libraries (react-i18next, next-intl, etc.), you can set up fallback chains so untranslated strings show the English version instead of a blank space. But don't treat that fallback as permission to skip translations indefinitely. Users will see it.

Mistake #10: Not testing with local devices and networks

Your app works perfectly on your US iPhone with a fast Wi-Fi connection. In some target markets, the typical user experience is different. Slower networks, older phone models, different OS versions.

In some Southeast Asian markets, a significant share of users are on phones with 2-3 GB of RAM and spotty 4G. In Japan, users tend to have current-generation devices but may be on crowded train Wi-Fi that drops constantly. In Germany, mobile data is expensive enough that users notice and dislike apps that consume a lot of bandwidth.

These aren't localization issues in the traditional sense, but they affect your downloads because users who have a bad first experience in these conditions leave 1-star reviews and uninstall. Before launching in a new market, at minimum test your app on a lower-end device with throttled network speed. Xcode's Network Link Conditioner lets you simulate different network conditions.

Mistake #11: Forgetting about right-to-left and text expansion

If you're localizing into Arabic or Hebrew, your entire UI needs to mirror. Buttons, navigation, reading flow -- everything flips. iOS has built-in RTL support, but it only works if your layout uses standard Auto Layout constraints or SwiftUI's default alignment. Custom layouts with hardcoded leading/trailing values break in RTL.

Even without RTL, text expansion is a real problem. German text is roughly 30% longer than English. Finnish can be 40% longer. A button that says "Save" in English says "Speichern" in German. Labels that fit perfectly in your English layout overflow, get truncated, or wrap awkwardly in other languages.

Test your UI with pseudolocalization before doing real translations. Xcode lets you run your app with doubled-length strings to find layout issues. Fix them before you pay for actual translations, because you'll need to adjust your layouts anyway and it's cheaper to do it once.

A localization audit checklist

Before launching in a new market, run through these. Not all will apply to every app, but skipping the ones that do is how downloads stay flat.

App Store listing: Are keywords researched (not translated) for this market? Does the subtitle use terms people actually search? Is the description written (not translated) for local users?

Screenshots: Do they show the app in the local language? Are the captions in natural (not translated) phrasing? Is the sample data culturally appropriate (local names, local currency, local dates)?

Pricing: Have you checked what local competitors charge? Is your price point competitive for this market's purchasing power? Did you manually set regional prices instead of using Apple's auto-conversion?

In-app experience: Are all strings translated, including error messages, empty states, and onboarding? Are date/time/number formats correct? Are payment methods appropriate for the market?

Technical: Does the layout handle text expansion? Does RTL work if applicable? Does the app perform well on typical devices and networks for that market?

Post-launch: Do you have a process for reading and responding to reviews in this language? Are new strings translated with each update? Is someone monitoring ratings in this market?

The good news

Most of your competitors aren't doing any of this. Seriously. The average indie developer either doesn't localize at all, or does a minimal translation pass and stops there. If you do even half the things on the checklist above, you're ahead of 90% of the competition in non-English markets.

The geo arbitrage scanner exists because this gap is real and measurable. Apps that dominate in the US often have terrible or nonexistent localizations for other high-value markets. That's the opportunity: not building something new, but bringing something that works to a market where the existing options are poorly localized.

If you want the market-specific deep dive, the Asia localization guide covers Japan, Taiwan, and Korea in detail. The geo arbitrage guide covers how to find apps that work in one market and don't exist in another. And the validation guide can help you figure out whether a market is worth localizing for in the first place.

Localization done right is probably the highest-ROI growth lever most indie developers never pull. The work is tedious, but the competition in non-English markets is so thin that even decent execution produces results.