← Back to blog

App Localisation Cost: What UK Businesses Should Budget

November 2, 2026
App Localisation Cost: What UK Businesses Should Budget

Localising a mobile app typically costs from a few hundred pounds for a small app in one language to five figures for a larger app in several languages. Published UK rates run from £0.08 to £0.16 per source word, but translation is only one line of the bill. Engineering, testing, store assets and every later release all add to it. Below, we break down how quotes are built, show worked examples, and list what to send a vendor so the price you get is the price you pay.

Pocketapp
Plan Your App for New Markets
Pocket App designs, develops and deploys mobile apps, with strategic discovery to help businesses shape tailored app projects.
Explore Pocket App

TL;DR

  • UK agencies publish app localisation rates of £0.08, £0.12 and £0.16 per source word, depending on how much human review and QA is involved.
  • A 5,000-word app into one language comes to about £600 at £0.12 per word, before engineering and testing.
  • A larger app of about 15,000 words in five locales is indicated at £9,000 to £15,000.
  • Clean code, clear context and a planned release process cost less to localise than an app that was never prepared for it.
  • Budget for updates as well: every new feature adds strings that need translating and testing.

Table of Contents

What you are actually paying for

Most people hear "localisation" and think "translation". The bill covers more. A thorough localisation project includes extracting and reinserting resource files, reviewing text against screenshots, handling text expansion and layout, supporting plural rules and right-to-left scripts, linguistic QA, pseudolocalisation, testing on real devices, app-store assets and release integration, as one localisation platform's process guide lays out.

The scope can stretch further. Microsoft's globalisation guidance lists user-facing text, documentation, marketing material, images, video, audio, formatting, legal content and cultural adaptation as things that may need localising. For an app, you rarely need all of it, but you should decide which parts you do need before asking for quotes.

In practice, app localisation cost splits into five buckets:

  1. Translation and linguistic review of in-app text, notifications and onboarding.
  2. Engineering, such as extracting strings, fixing hard-coded text and adapting layouts.
  3. Testing, including language QA in context and checks on representative devices.
  4. Store content: listing text, screenshots and keywords for each market.
  5. Maintenance: translating and testing new strings with every release.

How quotes are calculated

There is no single pricing model. Quotes usually combine several units: per source or weighted word for translation, hourly rates for engineering and specialist work, per-language packages, per-build or test-cycle charges, fixed fees for defined deliverables and recurring pricing for continuous releases. When two quotes look very different, the cause is usually that they use different units or cover different scope, not that one supplier is cheaper.

Per-word rates in the UK

One UK provider publishes three tiers for app localisation: £0.08 per source word for suitable content using AI support with human review, £0.12 for standard human localisation and £0.16 for specialist or QA-focused work. The same page says the final price depends on language pair, word count, file format, app context, QA requirements and deadline.

Three UK app localisation per-word rate tiers

For comparison, Google's own help page says translation is calculated per word and that cost depends on text volume, language pair and vendor. Its example is around $50 for a typical app and store description in one language. That is a US-dollar figure for a small text volume, so treat it as a floor for a very simple app, not a UK quote.

Outside the UK, one guide gives directional rates of $0.09 to $0.20 per source word for standard or technical translation, and $30 to $55 per hour for engineering and specialist support. Those figures are in dollars, but they show the same shape: words are cheap relative to the skilled hours around them.

Hourly and fixed fees

Engineering work rarely fits a per-word rate. Extracting hard-coded strings, fixing layouts that break when German text runs 30% longer, or adding right-to-left support are developer tasks, charged by the hour or as a fixed fee for a defined deliverable. If your app was built without localisation in mind, this is where a quote can double.

Worked examples

The examples below come from published UK and international guidance. They are indicative, not offers, and your own quote will differ.

ScenarioIndicative costSource
5,000-word app, one language, £0.12 per wordAbout £600UK agency example
Same app with 40% reduction from prior translation memoryAbout £420UK agency example
Same app, same-day delivery with 35% rush surchargeAbout £810UK agency example
Same app plus four more languages at about £0.10 per wordAbout £2,400 totalUK agency example
iOS and Android app, about 15,000 words, 5,000 strings, five locales£9,000 to £15,000UK agency guide
App Store and Google Play listing, about 400 words, 10 localesFrom £300UK agency guide

Three lessons stand out.

Rush work costs real money. The same 5,000 words cost £600 on a normal timetable and £810 when it is needed the same day. Building localisation into your release plan avoids that premium.

Reuse pays. Translation memory stores previously approved translations. When an app is updated, repeated or similar strings are reused, which is how the 40% reduction in the example arises.

Scope matters more than words. The jump from £600 to £9,000 to £15,000 is not explained by word count alone. Five locales, two platforms, thousands of strings and testing all multiply the work.

Worked examples

A small-app example in dollars

One international guide builds an illustrative four-locale example with 2,500 source words, clean iOS and Android resource files, professional translation and testing on representative devices. Its directional subtotal is $1,620 to $4,640 before any additional scope. Another illustration, for about 3,000 in-app words plus a 650-word store listing in five languages, gives $1,642.50 at a standard human-translation rate or $3,285.00 at an advanced rate, excluding developer preparation. Both are US-dollar illustrations, but they confirm that a small app in a handful of languages sits in the low thousands, and that developer preparation is the line most often missing.

What makes app localisation cost more or less

The main variables, as one cost guide sets them out, are:

  • word and string volume
  • the number and type of target languages, and the language pair
  • how well the app was internationalised in the first place
  • cultural adaptation
  • engineering complexity
  • number of devices and QA cycles
  • regulated or specialist content
  • rush timing
  • store assets
  • whether updates are continuous

A UK localisation specialist adds some practical ones: repetition in the content, language variants by country, the condition of source files, delivery format and release stages.

Languages and variants

Not all languages cost the same, and "a language" is not always one locale. Spanish for Spain and Spanish for Mexico may need different wording, dates and currency. Decide which countries you are targeting, not just which languages, because each locale adds review and testing.

Preparation in the code

This is the biggest hidden driver. Good internationalisation means Unicode support, strings held in resource files, flexible formatting, enough interface space, bidirectional-language support and no unsafe string concatenation. Date, time, currency, measurement and text-length differences, writing direction, keyboard layouts and legal requirements all need handling, as Microsoft's guidance notes.

If you plan Arabic, Hebrew or another right-to-left language, the interface itself has to mirror. A guide to RTL interface design shows how much layout work that involves, and why deciding early is cheaper than retrofitting.

Skipping this step does not save money. It moves the cost from the translation invoice to the development invoice, usually at a higher hourly rate and later in the project.

Context

Short strings such as "Book", "Post" or "Charge" can be translated wrongly without context. UK specialists stress that screenshots, user-flow information and terminology resources prevent ambiguous strings being mistranslated, and that in-context review catches truncation and awkward line breaks. Supplying context up front reduces the correction rounds you pay for later.

Extra costs that catch teams out

Testing

Translated text that reads well in a spreadsheet can still break a screen. A proper process includes pseudolocalisation, screenshot-context QA and checks on real devices. Each build and test cycle may be charged, so the number of devices and cycles you ask for shapes the price.

Store listings and screenshots

Your App Store and Google Play pages are part of the product. One budgeting guide suggests counting store-listing text, product interface and flows, creative assets, review, screenshots, engineering and future updates as separate lines, and allowing for vendor minimum fees. That last point matters for small jobs: a 400-word listing can cost more per word than a large app, because of the minimum.

Ongoing updates

Localisation does not end at launch. With continuous localisation, a repository or translation-management system detects new strings, returns reviewed translations, runs pseudolocale and screenshot checks and merges changes through CI. That vendor says a small app in five languages with continuous updates starts in the low thousands of pounds a month, while larger programmes of ten or more languages are scoped individually. Treat that as a signal of scale, not a quote.

Plan this alongside your wider running costs. Our guide to app maintenance cost in the UK covers what to budget after launch, and localisation updates belong in that line.

If your site and app share content across markets, automation can also cut repeat work. A look at automating hreflang in CI/CD shows the same principle on the web side: regenerate on every change rather than fix by hand.

Localisation as part of the app budget

Localisation is cheapest when it is designed in. Adding it during the build means strings go into resource files from day one, layouts allow for longer text, and the first release can ship in several languages without rework. Adding it later means a developer goes back through the code.

That is why we suggest placing it in your initial scoping. Our UK guide to the cost of developing a mobile app sets out the wider budget, and our piece on reaching new markets with app localisation covers the market case. If you are choosing a technology approach, a cross-platform build can keep one codebase for every language, which keeps engineering work for localisation in one place instead of two.

Our perspective

We have built more than 300 apps, and the same pattern repeats: localisation costs are rarely a surprise when the app was planned for it, and nearly always a surprise when it was not.

Our advice is to decide your target markets in discovery, not after launch. In our workshops we ask which countries and languages are realistic in the first two years, and we then choose the technology and structure the code so extra languages are a content task, not a rebuild. As a technology-agnostic team, we recommend the platform that fits each project, and that choice has a direct effect on how easily text, layouts and right-to-left support can be extended.

Our second piece of advice is to keep the translators close to the product. Give them screenshots, a glossary and a build to review. Translation is quicker, cheaper to correct and better in the hands of users when linguists see the screens their words appear on.

Lastly, budget for the second year. An app with an active roadmap will keep generating new text, and a modest, planned monthly allowance for localisation is easier to manage than a string of urgent requests.

Paul

How to get an accurate quote

Vague briefs produce wide quotes. Gather the following before you contact anyone, in line with what vendors commonly ask for:

  • the app name, product type, platforms and framework
  • source and target languages and locales
  • resource files, with approximate word and string counts
  • store and help content
  • existing glossaries, style guides and brand terms
  • quality and testing requirements
  • your schedule and how often you release updates
  • whether you need continuous localisation

UK providers add detail. One asks for string files, the store listing, screenshots, UI copy, push notifications, onboarding text, release notes and help content, then reviews file structure, placeholders, character limits and QA needs. Another asks for source strings, product context, character limits, a style guide, glossary and instructions for variables and placeholders, and wants to know whether the live or staging app is available for in-context review.

Ask each supplier to separate translation, engineering, testing, store assets and maintenance on the quote. Then you can compare like with like.

A simple budgeting method

  1. Count the source words and strings in your app and store listings.
  2. Multiply by a per-word rate for each target locale, using the tiers above as a range.
  3. Add engineering hours for preparation, if the app is not yet internationalised.
  4. Add testing: cycles, devices and language QA.
  5. Add store assets for each locale.
  6. Add a recurring allowance for updates.
  7. Keep a contingency for rush work or scope changes.

Where we can help

If you are planning a new app, or want to make an existing one ready for new markets, we can build localisation into the plan. Our discovery, design, development and deployment process is where we agree target markets, technology and structure, so you have a realistic picture before committing to a build. If you already have an app and want an expert view on how ready it is for more languages, a Mobile App Clinic is a good place to start.

Pocketapp

We do not publish fixed prices for these services, because the right answer depends on your app and markets. Talk to us about your project and we will tell you what it involves.

FAQ

How much does it cost to localise a mobile app in the UK?

It depends on word count, languages and testing. UK per-word rates for app localisation start around £0.08 and rise to £0.16, so a 5,000-word app into one language is about £600 at £0.12 per word. Larger multi-language apps with testing are indicated at £9,000 to £15,000.

Is localisation the same as translation?

No. Translation converts text. Localisation also adapts formats, layouts, currency, imagery, store listings and cultural details so the app feels native, as Microsoft's overview describes. That wider scope is why quotes include engineering and testing as well as words.

Can I use machine translation to cut costs?

Sometimes. One UK provider offers a lower tier of £0.08 per word for suitable content using AI support with human review. Content with legal, medical or brand-sensitive wording usually needs full human localisation, and context review is still needed either way.

What drives the price up fastest?

Rush deadlines, apps that were not prepared for localisation, extra locales and repeated test cycles. A same-day request on a 5,000-word app added a 35% surcharge in one UK example. Planning ahead is the simplest saving.

Do I pay again when I update the app?

Yes, for new or changed text. Translation memory reduces the cost of repeated content, but new features still need translating and testing. Include a recurring allowance in your post-launch budget.

Sources