Store Review Guidelines: Why Is a Localised App Rejected?

Publishing an app in a store is not an automatic process. The platform reviews the app against its own rules and rejects it if it is not satisfied. These rule sets, known as store review guidelines, are often assumed to be a purely technical matter, yet they also contain clauses about text and language.

Contents

Jiménez-Crespo notes that the review guidelines of the Apple store define the compliance issues that have to be addressed before an app can be included in distribution (2024, p. 230). The same book also states that consistency with platform terminology must be maintained for a store to accept an app (2024, p. 229).

Below we look at the rejection reasons that originate in localisation, at how they are prevented, and at the checks that need to be made when a Turkish version is being prepared.

Where do store review guidelines intersect with localisation?

A review is not confined to whether the app works. The reviewer also looks at the store listing, the screenshots, the text inside the app and the purchase flow. All of these items fall within the scope of localisation, and any of them can become grounds for rejection.

The book stresses that the distribution and sale of apps depend on stores and operating systems (Jiménez-Crespo 2024, p. 230). A store, in other words, is not only a shop window but also a gatekeeper. Decisions about text have to pass through that gate.

This places an additional obligation on the translation process. The translator does not merely produce natural Turkish but also keeps the platform’s expectations in view. Some of those expectations are written down; others are conventions that have formed in practice.

Guidelines also change over time. A wording that passed without difficulty a year ago may be questioned today because the rules have been updated. The check carried out for the first release should therefore not be treated as sufficient; it should be repeated for major versions.

Consistency with platform terminology

The most concrete rule is terminological consistency. The book states that, for an app to be accepted by a store, consistency has to be maintained with the standardised terms used in Android, Samsung Galaxy, Huawei, Amazon or Apple products (2024, p. 229).

In practice this means you cannot name system functions however you like. Concepts such as notification, permission, settings, account and subscription already have Turkish equivalents on the platform. Using a different equivalent both confuses the user and may be queried during review.

The remedy is simple but takes discipline: the platform’s own Turkish interface is taken as the reference. The system settings on a device are opened and the relevant terms noted down. This short exercise settles every later terminology argument before it begins.

The consistency rule has a limit. Using platform terms does not mean bending the app’s own distinctive concepts to the platform’s language. Brand names and product-specific function names are your decision; the rule applies only to concepts shared with the system.

Compliance with local regulations

The book writes that some elements are adapted to the target locale, while certain matters of compliance with local regulations have to be resolved before the app is marketed and distributed (Jiménez-Crespo 2024, p. 229). This is a content decision more than a translation one, but the outcome shows up in the text.

The areas involved most often are personal data, advertising, age limits and payment terms. A disclosure text that is sufficient in the source market may fall short in the target market. Such a shortfall cannot be closed by translation; the content itself has to be expanded.

Legal texts should therefore be run through a separate workflow. The translator prepares the draft and the relevant department approves it. Texts that go live without approval carry a risk both for the review and for internal audit.

The time this workflow takes has to be factored in as well. Legal review usually takes longer than interface translation. If the texts are left to the final week, the app cannot be submitted even though it is ready. Reversing the order, that is, starting the legal texts first, is safer.

Cultural content and visuals

The book notes that some images and videos need to be localised either to widen the app’s appeal or to make sure they are not culturally offensive (Jiménez-Crespo 2024, p. 232). This assessment varies with the target market and cannot be reduced to a single list of rules.

The risk is not confined to screenshots. The app icon, the promotional video, the sample data and the illustrations inside the app are subject to the same scrutiny. The names, dates and maps used in sample data can read in unexpected ways in the target market.

There is no definitive solution in this area, but bringing a reviewer from the target market into the process reduces the risk markedly. For approaches to cultural assessment, you can read the articles in our knowledge centre.

The review should be carried out early. Changing visuals once they have been produced costs time and budget, whereas a warning given at the draft stage costs nothing. Cultural checking should therefore be planned during design rather than after translation.

Half-finished localisation

Most localisation-related problems arise from omissions. The app is listed in Turkish, but some screens have been left in the source language. For the user this is a quality problem; from the review’s point of view it can mean that the listing and the product do not match.

Symptom	Source	Preventive measure
Mixed-language screen	Missing string	Comparing source and target string counts
Wrong system term	No term list	Taking the platform interface as the reference
Error message in the source language	Text from an external service	Adding your own explanatory line
Mismatched screenshot	Outdated visual	Refreshing visuals after translation
Missing legal text	Content gap	Local regulatory review

None of the measures in the table is expensive. Every one of them is a step that can be written into a pre-delivery checklist. The cost arises when these steps are skipped and the problem surfaces during the review.

The book states that linguistic and functional testing are carried out together in app localisation, with linguistic testing performed on the source files and functional testing in simulated environments or on real devices (2024, p. 230). These two tests catch most of the symptoms in the table before release.

Not one store: different rules, different expectations

App distribution is not limited to the two large stores. The book notes that most commercial apps have Android and iOS versions, and that alongside these there are other stores such as Samsung Galaxy, Huawei and Amazon (Jiménez-Crespo 2024, p. 229).

Each store has its own rule set and its own terminological tradition. The same Turkish text may pass without difficulty in one store and raise a question in another. This can mean keeping several versions of the same content that differ in small ways.

The practical approach is to keep a shared core text and small store-specific variants. The core is managed from a single hand, and the variants diverge only as far as they must. The update burden then stays under control.

When deciding, it is worth seeing which store genuinely carries weight in the target market. Managing separate text for every store can create a cost with an uncertain return. Limiting the scope is a legitimate choice too.

When the scope is narrowed, putting that in writing matters. If it is left unclear which store will be updated in which release, different texts start circulating in different stores months later. A simple table is enough to track which text has been published in which store, and it prevents version confusion from the outset.

What happens after a rejection?

A rejection is not the end of the project, but it does upset the schedule. A fix is made, the app is resubmitted and a new review period begins. Text-related problems are usually corrected quickly, yet the submission cycle still costs days.

The real cost appears when a release coincides with a campaign schedule. If a launch has been tied to a particular date, a rejection affects that plan directly. Localisation checks should therefore be completed before submission.

Rejection notices are instructive as well. If the reason given is recorded and added to an internal checklist, the same problem does not occur a second time. After a few releases this list becomes the team’s most practical quality document.

The wording of these notices is sometimes general and it is not clear exactly what the problem was. In such cases, asking for an explanation through the platform’s review channel produces a faster result than guessing. A fix based on a wrong guess can mean a second rejection.

The Türkiye context

For apps entering the Türkiye market, the most common text problem is the free translation of system terms. The Turkish interfaces of the platforms have been established for a long time and users are accustomed to those terms. Using a different equivalent looks foreign even when it is a correct translation.

The second issue is personal data. Under KVKK, the disclosure obligation is shaped by the way the app processes data. The privacy information in the store listing and the disclosure text inside the app must not contradict each other.

The third issue is content sensitivity. Visuals containing maps, flags, dates and place names can attract more attention in the target market than expected. These elements should be brought within the scope of localisation from the start, rather than becoming a matter argued over later.

Finally there are age limits and advertising content. If the app shows adverts, the content of those adverts in the target market also counts as part of the user experience. Although this area is not directly a matter of translation, it affects how the quality of the localisation is perceived.

None of these four headings prevents a release on its own. Taken together, however, they show whether the Turkish version was genuinely prepared for the target market. Reviewer and user alike form the same impression from the same place.

What does this mean for you?

When you open up a new market, build the review process into the schedule and move the localisation checks ahead of submission. The sequence below closes off most of the risk.

1. Draw up a short list of the platform’s Turkish system terms.
2. Have the legal texts prepared and approved in a separate workflow.
3. Have the visuals inspected by a reviewer from the target market.
4. Compare source and target string counts before delivery.
5. Regenerate the screenshots with the final translation.
6. Add the rejection reasons you receive to a permanent checklist.

Most of these checks are set up once and then reused in every release. For app localisation and pre-release language checks you can request a quote, and you can send your questions through our contact page.

Frequently asked questions

How do review guidelines concern localisation?

The book states that the compliance issues defined in the review guidelines have to be resolved before an app can enter distribution in a store. Some of those issues relate directly to text.

Is using platform terms compulsory?

The book writes that terminological consistency with the platforms’ standardised terms has to be maintained for a store to accept an app. Inventing your own equivalent creates risk.

Why do visuals become a review problem?

The book notes that some images and videos need to be localised either to widen appeal or to make sure they are not culturally offensive. This assessment varies from market to market.

How long does a rejected app take to return to the store?

The time varies with the platform and with the type of problem. Text-related problems are usually corrected quickly, but they require a new submission and a new review period.

Sources

• Jiménez-Crespo, M. A. (2024). Localization in Translation. Routledge, pp. 229–232.
• Apple Developer, App Store Review Guidelines (2024).
• Google Play, Developer Program Policies (2024).

This article is for general information only and is not legal advice.