How do you manage app store localisation requirements?

App store localisation is one of those things that looks straightforward from a distance and reveals its complexity only when you are deep into a release cycle. You translate the description, you resize a few screenshots, and you assume the work is done. Then Apple rejects the build, or downloads in a new market are a fraction of what you expected, or a compliance requirement you never knew existed blocks the whole launch.

The store listing is the first product decision you make for each market, and it carries the same weight as the product itself.

We have been through each of these scenarios, sometimes in the same project. On the peer-to-peer currency exchange product we built, we had the core transfer mechanism working well before Apple flagged the entire product as a potential vehicle for money laundering. We had not factored in anti-money laundering requirements at all. What followed was a long, expensive process of retrofitting KYC checks, adding enhanced transfer security, and imposing hard limits on transfers between any two parties, all of which should have been considered before we wrote the first line of code.

That experience shaped how we approach localisation now. The store listing, the compliance work, and the technical requirements are all part of the same release decision, and they need to be handled together rather than treated as a checklist you work through after the product is built. This article covers how to manage that process from the ground up.

What app store localisation actually covers

Localisation is often treated as a translation task. Someone takes the English copy, sends it to a translator, and the work is marked complete. But translation is a small part of what a well-localised store listing requires.

The full scope includes metadata (title, subtitle, description, keywords), visual assets (screenshots, preview videos, the icon itself), age ratings, content classifications, privacy labels, legal text, pricing tiers, and payment method compatibility. Each of these can vary by market, and some of them are dictated by local law rather than platform preference.

Beyond the technical checklist, localisation includes the question of what message lands in a given market. A wellness product positioning itself around scientific credibility reads differently to a Japanese audience than it does to a German one. From our work on the genetics product, we found that language sits in a narrow band: too simple and users distrust the science, too clinical and they disengage entirely. That balance shifts by market because the baseline expectation of what a credible wellness product looks and sounds like varies significantly between cultures.

The visual layer matters just as much. Colour associations, the reading of social proof, the weight given to certification badges, and the hierarchy of information in a screenshot all carry cultural assumptions. A screenshot layout that converts well in the UK does not automatically perform the same way in Japan or Brazil. Localisation done properly accounts for all of this, not just the words.

Metadata requirements by region

Both Apple and Google set metadata requirements at the platform level, but individual markets add their own constraints on top of those. Character limits, supported character sets, and keyword field rules are consistent within each platform, but what you are permitted to say, and how you are permitted to say it, shifts by region.

Apple's App Store gives you 30 characters for the title, 30 for the subtitle, 100 for keywords, and 4,000 for the description. Google Play works differently: a short description capped at 80 characters and a long description capped at 4,000, with no separate keyword field (Google indexes the description directly). Neither platform translates your metadata automatically. If you submit English copy into a French or Korean storefront, that is what users see.

Keyword strategy by locale

Keyword research needs to be done separately for each language, not translated from the English set. The terms people actually search in French, German, or Mandarin are not literal translations of English search terms. Search volume, competition, and intent vary, and a keyword that works well in one locale may return almost no searches in another.

Restricted claims by market

Health and wellness apps face the tightest metadata restrictions. Claims that are acceptable in a US listing may be prohibited under EU advertising standards or by local healthcare regulation. Germany and France both have stricter rules around health claims than the UK, and Japan has its own framework entirely. Writing metadata that passes review across multiple markets means knowing those rules before you write a word, not after the first rejection lands.

Screenshot and preview specifications

Screenshot requirements are set at the device level rather than the market level, which means the specification burden comes from screen sizes and orientations, not geography. Apple currently requires screenshots for 6.9-inch (iPhone 16 Pro Max), 6.5-inch (iPhone 14 Plus), 5.5-inch (iPhone 8 Plus), and for iPad Pro if you support it. Google Play has its own set of requirements. Neither platform will generate the missing sizes from what you provide, if you submit for the wrong device, the listing either fails or displays incorrectly.

Localising the visual content

The more demanding question is what the screenshots should show in each market. A single set of English-language screenshots deployed globally is a missed opportunity at best and a conversion problem at worst. Screenshots are the fastest way a user judges whether an app is for them, and a set that reads in a language they do not speak sends an immediate signal that the product was not built with them in mind.

Screenshots are the fastest judgement a user makes, and they are making it before they read a single word of your description.

Beyond translation, consider the scenes and people shown. Social proof elements, lifestyle imagery, and the implied context of use all carry cultural weight. A screenshot showing a shared meal communicates differently across cultures, and the same is true for gesture, colour, and spatial layout. The production overhead of a full per-market screenshot set is real, but the conversion impact of getting it right is also real. Iconikai reports that localising the full listing, description, screenshots, and keywords, can increase downloads by 20-30% in non-English markets.

Create a master screenshot template set in a design tool rather than rasterised images. This lets you swap text and imagery per locale without rebuilding layouts from scratch each time.

Age ratings and content classifications

Both Apple and Google derive age ratings from a questionnaire that asks about the content your app contains: violence, sexual content, gambling, drug references, social interaction, and so on. Your honest answers to that questionnaire determine the rating applied to your listing. The platforms do not audit the answers at submission, but if the actual content of your app does not match the rating you declared, you risk rejection or removal.

The complication is that age rating systems are not uniform across markets. Apple applies different content thresholds depending on the country. An app rated 12+ in the UK might receive a different classification in Germany under USK standards, or in South Korea under the GRAC system. Some markets require a local rating body to classify your app before it can appear on the store, which adds time and cost to any launch plan.

Gambling and in-app purchase classifications

Apps that include loot boxes, random reward mechanics, or real-money wagering attract additional scrutiny in several markets. Belgium and the Netherlands have particularly strict rules around randomised purchase mechanics, and several other European markets are tightening their frameworks. An app that qualifies as a casual game in one jurisdiction may be classified as a gambling product in another, which triggers both a different age rating and different compliance obligations.

The practical implication is that you need to run each market's classification requirements against your content before submission, not assume that a clean rating in your home market transfers everywhere. Build that review into your pre-launch timeline, and be specific about the content you are declaring. Vague answers to the questionnaire cause problems that specific ones avoid.

Legal and compliance requirements per market

Legal requirements are the part of localisation that teams most consistently underestimate, and the consequences of getting them wrong are proportionally larger. A poorly translated description costs you downloads. A compliance failure can cost you the listing entirely.

The currency exchange product we built makes this concrete. We had the product working as intended: users could exchange leftover foreign currency with other travellers at interbank rates, avoiding commission. What we had not factored in was anti-money laundering regulation. Apple flagged the product as a potential vehicle for money laundering because there were no limits on how many transfers could happen between any two parties. We had to go back and retrofit KYC checks, enhanced transfer security, and hard caps on transfer volumes. That retrofit cost significant time and money, all of which could have been avoided with a compliance review before we started building.

Privacy and data regulations

GDPR governs apps available in the EU and EEA, and its requirements touch the store listing directly: privacy nutrition labels on Apple, data safety forms on Google, and the accuracy of both relative to what your app actually does. California's CPRA imposes similar obligations for US users. Brazil's LGPD, Japan's APPI, and South Korea's PIPA each add their own requirements. If your app collects location, health, financial, or biometric data, the disclosure requirements in each of these frameworks need to be reflected accurately in your store listing.

Run your intended compliance disclosures past a local legal adviser in each major market before you submit. Platform review does not catch every regulatory issue, and a rejection after a local authority gets involved is harder to resolve than one from Apple or Google.

When compliance gaps block a release

Apple's review process is not a neutral quality gate. On the currency exchange project, we addressed every objection Apple raised, only to receive a new objection each time. We capped transactions at €150 specifically to address Apple's stated concern about money laundering and criminal activity. The cap should have removed the basis for rejection. Apple rejected the app again. The client ran out of budget and abandoned the product entirely.

It later became clear that Apple's repeated rejections coincided with the build-up to the launch of Apple Pay. The review process has no effective mechanism for a developer to challenge this kind of behaviour. Each rejection arrives as a compliance issue, and the developer has no way to prove that the compliance concern is not genuine. A well-resourced incumbent can use this to block a compliant competitor from reaching the market, indefinitely if they choose to.

This is something we experienced directly on that project, and it is worth factoring into any launch plan that touches payments, financial data, or health information, the categories where Apple has either a competing product or a strategic reason to restrict entry. Understanding which category your product falls into is part of the pre-submission work, and if you are entering a space where Apple competes, you need a longer compliance runway and a clearer appeals strategy than you would in a neutral category.

Document every compliance decision you make during development, including the rationale. When Apple raises an objection, a detailed written response with supporting evidence gives you more to work with than a verbal argument through the reviewer interface.

Front-loading your store listing when the app cannot speak for itself

On the anonymous messaging app we built, we had to require authentication right at the start of the experience. The product was anonymous in the sense that users appeared to each other without identifying information, but we had to tie every message back to a specific user account on the back end. This was a legal requirement, specifically to handle cases of abuse or harassment. We could not let users into the product and start sending messages without that link in place.

The consequence for the store listing was significant. Normally, an app can drip-feed its value over the first few sessions: you see a feature, you understand what the product does, you form a view. When registration sits at the very start, users have to make a commitment before they have seen anything. That changes what the store listing has to do.

We had to communicate everything about the product before users even opened it. The copy, screenshots, and preview content had to carry the full weight of what the product was and why it was worth registering for. Every piece of messaging that would normally unfold through use had to be front-loaded into the store presence instead. That is a much harder brief than a standard listing, and it requires a different kind of specificity in the copy and a more deliberate sequence in the screenshot narrative.

A localised version of this challenge applies to any market where the product is unknown. If the brand has no recognition in a new region, the store listing is doing even more work than usual. The listing is the product's first impression, its pitch, and its proof all at once.

ASO as part of localisation, not separate from it

We worked on a gifting and wishlist platform where the client was reluctant to invest in app store optimisation. Their reasoning was that the product was inherently social and group-oriented, so referral would drive downloads and ASO would matter less. Our position was that ASO cannot be bypassed by a referral mechanic, however strong it is.

When someone receives a referral and visits the store listing, they are making a judgement in seconds. The icon, the first two lines of the description, the first screenshot, and the rating are all that most people see before deciding whether to download. If any of those elements are unclear or misaligned with what the product actually is, the referral is wasted. The person downloads, finds the product is not what they expected, and leaves.

The goal of ASO in a localisation context is to make sure that users who download from a given market already understand what they are getting. They should be self-selecting in because the listing told them accurately what the product does and who it is for. The stores that handle localisation as a separate, later-stage activity end up with ASO that is translated but not localised, which is a different thing. The category choice, the keyword set, the icon treatment, and the screenshot narrative all need to be considered per market, not just translated from the English original.

Account structure and access control during deployment

On the social football product we worked on, the client held the App Store Connect Account Holder role because the account was registered under their name. We received admin access to the majority of the account and set up three testing groups: one for our team, one for the client's internal reviewers, and one external beta group for the client's own testers. The structure was designed to give us control over which builds went to which groups at each stage of the deployment process.

As the project moved toward launch, the client began bypassing the structure. They had full account holder access, which meant they could go into App Store Connect directly and send uploaded builds to whichever group they chose, regardless of where we were in the testing cycle. Because everything sat on their account, there was no mechanism that prevented this. It caused problems, specifically around builds reaching external testers before they had cleared internal review.

How to structure access before you start

The lesson from that project is that access structure needs to be agreed and documented before a single build is uploaded, and the account holder's role in the deployment process needs to be explicit. A table helps here:

When deploying across multiple markets, the account structure becomes more complex. Separate developer accounts are sometimes needed for specific regions, particularly China, which operates through a distinct App Store infrastructure with its own regulatory requirements. Plan the account architecture before you start building, not after the first market rejection.

Platform choice and its localisation implications

On the bootstrapped social football platform, the original plan was to launch on both iOS and Android simultaneously. As the project progressed, scope expanded. Features kept being added, design kept changing, and the budget came under significant pressure. Midway through the project, we made the decision to pause all Android development and redirect the remaining budget to the iOS product. The client launched with iOS only, reaching roughly half of their potential market.

That decision is worth examining in a localisation context. iOS and Android do not have the same global market share, and the split is not consistent across markets. In many emerging markets, Android commands 80% or more of the installed base. A decision to launch iOS-only is not neutral from a geographic reach perspective: depending on where you are targeting, it may exclude the majority of the audience in those regions.

Platform reach by region

Before committing to a platform strategy, it is worth mapping the target markets against platform share. A fitness app targeting urban users in the UK or Australia will find a relatively even iOS/Android split. The same app targeting users in India or Southeast Asia will find Android dominant. That changes the priority order, and in some cases it changes the platform you should build for first.

Localisation requirements also vary by platform. Google Play's review process is faster and generally less prescriptive than Apple's, which has implications for how quickly you can iterate in response to market-specific feedback. Apple's more structured review adds time to every update cycle, which compounds across multiple markets. Factor that into your release planning from the start.

Managing Apple's review process across markets

Apple reviews apps against a global ruleset, but the outcomes can differ by market. An app that passes review for a US release may face additional scrutiny when submitted for specific territories, particularly where local laws around financial services, health, or data handling are stricter than Apple's baseline.

On the currency exchange project, we did not just face a single rejection. Apple raised one objection, we addressed it, and Apple raised a new one. This happened repeatedly. The process has no neutral arbiter. Each time we responded with what we believed was a compliant solution, Apple's next objection invalidated the work we had done on the previous one. The client spent significant money on legal counsel and compliance work that was rendered moot by each successive rejection, and eventually ran out of budget to continue.

The practical implication for teams launching across markets is to treat Apple's review not as a binary pass or fail but as a process that can extend over multiple cycles. Build that time into your launch plan. Keep detailed records of every submission, every rejection reason, and every change you make in response. If you reach the point where the rejection pattern no longer reflects genuine compliance concerns, that documentation is the basis of whatever escalation path you pursue.

1. Submit with complete compliance documentation from the start, not as a response to a rejection.
2. Log every reviewer comment and your exact response to it.
3. Request an escalation to the App Review Board if the same concern is raised after you have already addressed it.
4. Contact Apple Developer Relations directly if escalation through the standard channel produces no movement.

None of these steps guarantee a different outcome. But they give you a clearer picture of whether you are dealing with a genuine compliance gap or something more structural, and they give you something concrete to act on.

Building a localisation workflow that holds

Localisation works best when it is built into the production process from the start rather than added as a release-stage task. By the time you are submitting to the store, the decisions that matter most, category, compliance architecture, account structure, screenshot strategy, are already made. Trying to fix those things under launch pressure produces the kind of retrofitting we had to do on the currency exchange project.

A localisation workflow that holds looks roughly like this:

1. Market selection and compliance mapping before any build decisions are made.
2. Platform and account architecture agreed with the client and documented.
3. Metadata drafted per locale by someone with market knowledge, not just translation software.
4. Screenshot strategy developed per locale, with localised copy baked into the design files.
5. Age rating questionnaire completed honestly and reviewed against each target market's classification framework.
6. Privacy labels and data safety forms completed to reflect what the app actually does.
7. Internal review cycle completed before any external testing groups receive builds.
8. Submission documentation prepared, including compliance rationale for anything that might attract scrutiny.

This sequence is not complicated, but it requires starting earlier than teams typically do. The work that gets skipped is almost always the compliance mapping and the per-locale metadata work, because both feel abstract before the product is built. They feel very concrete after the first rejection.

Assign a named owner for each market's localisation requirements at the start of the project. Without ownership, compliance and metadata work drifts until someone catches it at submission, which is the wrong moment to catch it.

Conclusion

App store localisation is a series of connected decisions about compliance, account structure, visual communication, platform strategy, and review management, and those decisions need to be made in the right order, before the build.

The currency exchange project taught us what happens when compliance is treated as a post-build task. The social football project taught us what happens when account access is not structured from the start. The anonymous messaging app taught us what happens when product constraints push all the communication work into the store listing. Each of these was a real cost, in time, in money, and in some cases in the viability of the product itself.

The research supports the case for doing this properly. CSA Research found that 40% of users will not buy a product if the content is in a foreign language. That is a substantial portion of any market you are entering, and it is recoverable with localisation work that goes beyond translation into genuine market adaptation.

The teams that manage this well are doing the same work in a more deliberate order, catching the compliance and structural questions early enough that they shape the build rather than disrupt it. Getting to launch in multiple markets without a rejection cycle, without an account access problem, and without a screenshot set that does not convert is entirely achievable with the right sequence. It just requires starting the localisation conversation at the same time as the product conversation, not after it.

Let's talk about your app store localisation strategy

Frequently Asked Questions