Localization Guide

iOS App Localization Guide

Learn how to localize SwiftUI and UIKit apps with Xcode String Catalogs, context-rich translation workflows, language-aware plurals and variations, accessible content, multilingual testing, and localized App Store experiences.

Explore the Guide Jump to the Checklist
Last reviewed: August 2026 35-minute read Product, engineering, localization, QA, accessibility, and release teams Reviewed by the Stepes App Localization Team

Key Takeaways

The central recommendations for planning a production-ready iOS localization program.

  • iOS app localization is a product discipline that connects internationalization, translation, interface design, locale behavior, accessibility, testing, and release operations.

  • Xcode String Catalogs provide the modern foundation for managing strings, plurals, device variations, comments, translation states, and localization exchange, but many enterprise apps still contain .strings, .stringsdict, storyboards, XLIFF, and other legacy resources.

  • Translators need functional and visual context. String keys alone rarely explain whether a word is a button, title, command, status, noun, or part of a longer user journey.

  • Plural logic, variables, locale formats, right-to-left behavior, Dynamic Type, and accessibility content must be designed and tested as part of the localized experience.

  • The app binary and its App Store product page are separate but coordinated localization workstreams.

  • AI can accelerate repetitive work, but production-ready localization still requires controlled terminology, protected technical content, appropriate expert review, and validation inside the working app.

  • Continuous localization is most effective when translation, review, engineering validation, testing, and App Store updates are connected to the software release cycle.

What iOS App Localization Includes

iOS app localization adapts the complete product experience for people who use different languages, locales, writing systems, devices, and accessibility features. Translation is part of that work, but translation alone does not determine whether the finished app is clear, functional, visually coherent, and ready for release.

Use this guide to coordinate product, engineering, localization, QA, and release teams—or prepare for professional app localization services.

A localized iOS experience may include:

  • Navigation, menus, tabs, buttons, forms, settings, dialogs, and search
  • Onboarding, registration, authentication, account recovery, and permissions
  • Error messages, empty states, validation, alerts, and status updates
  • Push notifications, widgets, Live Activities, and app extensions
  • Subscription, purchase, tax, pricing, renewal, and cancellation content
  • Help, support, troubleshooting, and customer communication
  • Accessibility labels, hints, values, image descriptions, captions, and transcripts
  • Dates, times, numbers, currencies, measurements, names, and addresses
  • Images, diagrams, tutorials, audio, video, and market-specific assets
  • App Store names, subtitles, descriptions, keywords, screenshots, previews, and release notes

Internationalization, Translation, Localization, and Testing

These activities are related, but they solve different parts of the problem.

Internationalization prepares the application architecture to support multiple languages and locales without major code changes for every market. It includes externalizing user-facing text, supporting plural rules, using locale-aware formatting, allowing flexible layouts, and preparing for right-to-left languages.

Translation converts written content from one language into another.

Localization adapts language, presentation, formatting, visuals, and behavior for a particular audience and market.

Localization testing validates the translated and adapted experience inside the working application.

Teams that begin translation before internationalization is ready often discover hard-coded text, fragmented sentences, inflexible layouts, incomplete plural structures, or content that cannot be mapped back to a screen. A focused internationalization review can identify these issues before they become multilingual release blockers.

The App and Its App Store Page Are Separate Workstreams

Adding languages to an Xcode project localizes the app binary and in-app experience. Adding localizations in App Store Connect localizes the product-page metadata that customers see before installation. Apple manages these as distinct systems, even though users experience them as one journey.13

A strong release plan coordinates both. The terminology, promises, screenshots, feature names, and release notes on the product page should match the language users encounter after download.

The Five Layers of Production-Ready iOS Localization

A useful way to plan iOS localization is to treat it as five connected layers. Weakness in any one layer can affect the final experience.

The Five Layers of Production-Ready iOS Localization
Layer Core Question Typical Work
1. Resource Integrity Can every required string, variable, variation, and asset move safely through translation? String Catalogs, legacy files, keys, placeholders, file validation, asset inventories
2. Language Context Do translators understand what the user sees and needs to do? Comments, screenshots, terminology, user flows, character guidance, build access
3. Locale Behavior Does the app behave correctly for the target language and region? Plurals, dates, numbers, currencies, measurements, RTL, input, sorting, fallback
4. Experience Validation Does the localized app read, display, and function correctly? Linguistic QA, visual QA, functional testing, accessibility testing, device coverage
5. Release Operations Can localization stay aligned with future app releases? Change detection, translation memory, approvals, repository or API workflows, regression QA

This model helps teams avoid a common planning error: treating localization as a single translation handoff. Production-ready localization is a system of connected decisions from source architecture through ongoing release governance.

The Current iOS Localization Environment

Modern iOS localization is increasingly integrated with Xcode, software delivery, accessibility, and App Store operations.

At the time of this guide’s review:

  • Apps uploaded to App Store Connect must be built with Xcode 26 or later using the applicable Apple platform SDKs. Apple made this requirement effective April 28, 2026.1
  • Apple’s current Xcode documentation places String Catalogs at the center of string management and also documents coding-agent assistance for adding languages, catalogs, and translations.57
  • App Store Connect now supports 50 metadata localizations. Apple added 11 localizations in 2026, including several major languages of India.23
  • Accessibility Nutrition Labels can appear on App Store product pages, making accurate evaluation of features such as VoiceOver and Larger Text part of release and product-page governance.4

These developments do not eliminate professional localization work. They make disciplined source preparation, context, review, and testing more important because automation can move content faster than teams can manually inspect it.

Platform requirements change. Verify current Xcode, SDK, App Store Connect, screenshot, metadata, and accessibility requirements before every major release.

Plan the Localization Scope

Good iOS localization starts with a product inventory, not a word count. A word count measures visible text volume, but it does not reveal whether the app contains multiple resource systems, server-delivered content, app extensions, inaccessible strings, or high-risk user journeys.

Inventory Every Content Source

Review the complete user experience, including content that may sit outside the main iOS target:

  • SwiftUI views and reusable components
  • UIKit views, storyboards, and XIB files
  • String Catalogs and legacy resource files
  • Shared frameworks and Swift packages
  • Widgets, notification content extensions, and other app extensions
  • Watch, iPad, Mac, or visionOS companion experiences
  • Content delivered by APIs or content management systems
  • Transactional email and SMS triggered by the app
  • Customer support and knowledge-base content
  • In-app purchase and subscription content
  • App Store Connect metadata and creative assets
  • Images, tutorials, audio, video, captions, and transcripts

A source audit should identify who owns each content stream, how it is updated, and how translations return to production.

Define Languages, Locales, and Markets

A language code is not always enough to define the target experience. Regional differences may affect terminology, spelling, tone, currency, taxation, legal language, measurements, address formats, payment methods, and App Store positioning.

Examples include:

  • English for the United States and United Kingdom
  • French for France and Canada
  • Portuguese for Brazil and Portugal
  • Spanish for different regional audiences
  • Simplified and Traditional Chinese
  • Arabic for markets with different commercial or regulatory requirements

Define target locales according to actual product and market needs. Avoid creating unnecessary regional variants when one carefully governed translation can serve multiple markets, but do not force markets together when the user experience genuinely differs.

Prioritize Critical User Journeys

Map the flows that carry the greatest commercial, safety, privacy, or usability risk:

  1. First launch and onboarding
  2. Registration, login, and account recovery
  3. Permissions and consent
  4. Search and product discovery
  5. Checkout, purchases, and subscriptions
  6. Security alerts and identity verification
  7. Data entry and form submission
  8. Error recovery and customer support
  9. Privacy settings and account deletion
  10. Core product tasks unique to the app

These flows should receive the strongest context, review, and testing coverage.

Route Content by Risk

Not every string needs the same level of review. A practical routing model considers consequence of error, visibility, ambiguity, subject matter, and reuse.

Route Content by Risk
Content Category Example Recommended Control
Routine, low-risk Standard navigation, repeated settings labels Translation memory, automated checks, professional linguistic review
Context-sensitive Short buttons, onboarding, empty states, feature names Screenshots or build context, terminology control, in-context review
High-impact Payments, security, permissions, privacy, medical or safety content Subject-matter review, stricter approval, targeted functional testing
Market-facing App name, subtitle, keywords, screenshots, promotional copy Local market adaptation, character-limit review, product and marketing approval
Accessibility VoiceOver labels, hints, image descriptions Accessibility-aware translation and testing with representative assistive features

This approach focuses human attention where it contributes the most value without treating every string as equally risky.

Understand iOS Localization Files and Resources

Enterprise iOS apps rarely use one resource type. Newer SwiftUI features may coexist with legacy UIKit modules, localized assets, server content, and App Store metadata.

iOS Localization Resource Overview

iOS Localization Resource Overview
Resource Common Use Main Localization Risk
.xcstrings Modern Xcode string management Missing context, incomplete variation handling, unmanaged states
.strings Legacy or UIKit string resources Ambiguous keys, duplicate content, escaping or encoding issues
.stringsdict Legacy plural and variable logic Incorrect category mapping or incomplete migration
XLIFF packages Localization exchange Damaged tags, placeholders, states, or resource relationships
Storyboards and XIB files Interface text and layout resources Clipping, fixed layouts, outdated source content
InfoPlist localizations Permission and system-facing descriptions Unclear or inaccurate explanations at sensitive moments
Asset catalogs Images, symbols, colors, and media variants Embedded source text or culturally unsuitable visuals
Server and CMS content Dynamic product or support content Mixed-language screens, inconsistent release timing
App Store Connect Product-page metadata and creative assets Misalignment with in-app terminology and positioning

Xcode String Catalogs (.xcstrings)

String Catalogs centralize localizable text, language variants, comments, translation states, plurals, and device variations. Xcode can discover localizable strings during a build and update catalogs as source content changes.5

String Catalogs are the modern default for many iOS projects, but they do not automatically provide every piece of context a linguist needs. Teams still need clear keys, useful comments, visual references, terminology, ownership, and a controlled exchange process.

Legacy .strings Files

Many mature applications continue to use .strings files. They may coexist with String Catalogs for years, especially in mixed SwiftUI and UIKit products.

Review legacy resources for:

  • Duplicate or inconsistent keys
  • Source text used as a key
  • Missing comments
  • Strings split into fragments
  • Unclear variable meaning
  • Obsolete or developer-only content
  • Encoding and escape-sequence problems
  • Multiple files with overlapping ownership

A migration to String Catalogs can improve management, but migration should be treated as a validated engineering change rather than a simple file conversion.

.stringsdict Resources

Existing applications may use .stringsdict files for plural and variable logic. When these resources are retained or migrated, confirm that all required language categories, variables, and runtime scenarios remain intact.

Do not assume that a structurally successful migration produces linguistically correct behavior. Test representative values after import and in the running app.

XLIFF Localization Packages

Xcode supports exporting and importing localization content through localization catalogs that include XLIFF files.15 XLIFF can be useful when content moves to external localization teams or translation systems, provided the workflow preserves:

  • Resource identifiers
  • Source and target text
  • Comments
  • Translation states
  • Variables and format specifiers
  • Plural and variation structures
  • Nontranslatable technical content

Localization-aware tools should process these files. Opening and editing them as ordinary text increases the risk of structural damage.

InfoPlist and Permission Descriptions

Permission explanations appear when users are deciding whether to grant access to sensitive features such as the camera, microphone, location, photos, Bluetooth, or health data.

These descriptions should be:

  • Accurate about the feature’s real purpose
  • Consistent with privacy and product language
  • Clear without technical jargon
  • Complete in every supported language
  • Reviewed in the context of the system prompt

A poorly localized permission message can reduce trust or create compliance risk even when the rest of the app is well translated.

Storyboards, XIB Files, and Interface Builder

UIKit applications may contain translatable content and layout constraints inside storyboards or XIB files. Review:

  • Auto Layout behavior
  • Fixed-width or fixed-height controls
  • Labels that cannot wrap
  • Buttons with limited space
  • Truncated navigation titles
  • Unlocalized accessibility attributes
  • Content that has moved in code but remains in an older interface file

Xcode previews can help identify layout issues before full runtime testing.

Localized Assets

Localization can extend beyond text. Apple supports localized variants in asset catalogs.16 Potential assets include:

  • Images containing words
  • Tutorial illustrations
  • Region-specific diagrams
  • Symbols that differ by writing direction
  • Audio and video
  • Captions and transcripts
  • In-app screenshots
  • Cultural or lifestyle imagery

Maintain an asset inventory with ownership, source files, locale requirements, and replacement rules.

Server-Delivered and Remote Content

An iOS app may be structurally localized while still displaying source-language content from an API, support platform, commerce system, feature-flag service, or content management system.

Define a shared locale strategy across the mobile client and connected services:

  • How does the app communicate the selected locale?
  • What happens when a regional variant is unavailable?
  • Does server content use the same terminology as the app?
  • Can content changes launch independently of app releases?
  • How are missing translations detected?
  • Who approves server-delivered language?

Build Effective Xcode String Catalogs

A String Catalog is only as useful as the source architecture and context behind it. The goal is not simply to collect strings; it is to make each string understandable, traceable, technically safe, and maintainable.

Use Clear and Stable Keys

A good key indicates meaning or function without depending entirely on the current English wording.

Weak key:

Save

Stronger key:

profile_edit_save_button

Stable semantic keys can reduce confusion when source copy changes. They also make it easier to locate strings in code, screenshots, issue reports, and translation systems.

Use a naming convention that reflects the app’s structure, such as:

feature.screen.element.purpose

The exact convention matters less than consistency, ownership, and long-term stability.

Organize Catalogs for Scale

Large applications may use:

  • One application-wide catalog
  • Catalogs by feature
  • Catalogs by Swift package
  • Catalogs by app extension
  • Shared catalogs for reusable components
  • Separate catalogs for platform-specific content

Choose an approach that supports code ownership, review, reuse, and source control. Too many catalogs can create fragmentation; one very large catalog can make ownership and review difficult.

Write Translator Comments That Answer Real Questions

Useful comments explain:

  • Where the string appears
  • Whether it is a button, title, label, error, or instruction
  • What the user is doing
  • Who the user is
  • The meaning of each variable
  • Whether text is visible or accessibility-only
  • Whether there is a hard limit or flexible layout
  • Whether a product term must remain unchanged
  • Whether the string appears before or after another message

Avoid comments that merely repeat the source text.

Manage Translation States

Establish a policy for:

  • New strings
  • Changed source strings
  • Reviewed translations
  • Stale translations
  • Obsolete content
  • Intentionally untranslated strings
  • Source text that changed only for punctuation or style

A source change should not automatically erase a useful translation, but it should trigger an appropriate review. The workflow should distinguish a meaning change from a minor source edit.

Use Generated Localizable Symbols Where Appropriate

Xcode can generate Swift symbols from String Catalog keys, including functions for strings with format specifiers.6 For suitable projects, this can improve discoverability and reduce mistakes caused by manually typed keys.

Generated symbols do not replace localization governance. Teams still need clear keys, comments, file organization, and review rules.

Exclude Internal and Non-User-Facing Content

Do not route the following for translation unless users actually see them:

  • Debug messages
  • Analytics event names
  • Internal identifiers
  • Test fixtures
  • Developer notes
  • Log output
  • API field names
  • Temporary placeholders

An accurate source inventory reduces cost and prevents internal content from appearing in production translations.

Anatomy of a Well-Prepared Catalog Entry

Anatomy of a Well-Prepared Catalog Entry
Field Example Why It Matters
Key checkout.order_total_label Locates and identifies the string
Source Total: \(amount) Provides the visible message
Comment “Label above the final purchase button. Amount includes localized currency.” Explains screen, purpose, and variable
Variation Standard and compact-width wording Supports constrained layouts
Plural Not applicable Confirms whether quantity logic is required
Screenshot reference checkout_review_01 Connects text to the interface
Status Ready for translation Supports workflow control
Owner Checkout product team Routes questions and approval

Give Translators the Context They Need

Short interface strings are often harder to translate than long paragraphs because they contain less evidence of meaning.

Consider the word “Charge.” It could be:

  • A noun describing a fee
  • A verb for charging a payment method
  • A battery status
  • An instruction to charge a device
  • A legal allegation

The correct translation depends on the screen, user action, and product domain.

Provide Functional Context

For each high-ambiguity string, capture:

  • Feature and screen
  • UI element type
  • Intended user action
  • Previous and next step
  • Whether the text confirms, warns, instructs, or labels
  • User role or audience
  • Relevant business or industry meaning
  • Variable behavior
  • Character or layout guidance

Provide Visual Context

Useful sources include:

  • Annotated screenshots
  • Figma frames
  • Storyboards
  • Screen recordings
  • Interactive prototypes
  • Test environments
  • TestFlight builds
  • Live product access
  • String-to-screen mapping

Context should be easy to retrieve. A folder of unlabeled screenshots is less useful than a direct association between a resource key and the relevant interface state.

Stepes’ in-context UI localization workflows can help connect strings with screens, designs, prototypes, and working product environments.

Treat Character Limits as Guidance, Not the Whole Solution

A maximum character count may be necessary for some components, but characters do not occupy equal space across languages and fonts. Final fit also depends on:

  • Glyph width
  • Font
  • Line height
  • Available width
  • Dynamic Type setting
  • Device size
  • Orientation
  • Wrapping rules
  • Adjacent controls

When the interface allows flexible wrapping, prioritize natural, clear language. When space is truly constrained, identify the reason and review the translation in context rather than forcing arbitrary abbreviation.

Build a Product Language System

Give linguists and reviewers access to:

  • Approved product and feature names
  • Terminology definitions
  • Tone and voice guidance
  • Preferred interface verbs
  • Prohibited translations
  • Existing translations
  • Translation memory
  • Market-specific terminology
  • Legal, medical, financial, or technical references

The same term should remain consistent across the iOS app, Android app, website, software platform, help center, emails, and App Store content unless the context requires a deliberate difference.

Sample Context Record

Sample Context Record
Field Example
Resource key security.freeze_card_action
Source text Freeze card
Screen Card controls
Element Primary action button
User intent Temporarily block new card transactions
Not the same as Permanently close or replace the card
Character guidance Prefer one short line
Screenshot card_controls_freeze.png
Terminology Use the approved equivalent of “freeze,” not “cancel”
Reviewer Payments product owner

Handle Plurals, Variables, and String Variations

English commonly uses a singular form and an “other” form. Other languages may require different plural categories, and some categories depend on values such as 0, 2, larger numbers, fractions, or the final digits of a number.

Unicode Common Locale Data Repository (CLDR) defines the plural category labels zero, one, two, few, many, and other, with each language using the categories it needs.10

Keep Complete Messages Together

Avoid assembling a sentence from translated fragments.

Fragile approach:

You have + number + new messages

This structure assumes every language can use the same word order and grammatical agreement.

Better approach:

A complete message with the number variable and all required plural variants managed together.

The translator should be able to reorder the sentence and adapt surrounding words according to the target language.

Protect Variables and Format Specifiers

Common runtime content includes:

  • Counts
  • User names
  • Dates and times
  • Prices
  • Percentages
  • Product names
  • File names
  • Format specifiers
  • Markup
  • URLs
  • Technical identifiers

The workflow should prevent translators from deleting, renaming, duplicating, or corrupting protected elements while still allowing language-appropriate reordering.

Automated checks should compare source and target placeholders, but automated matching does not prove that the sentence is grammatically correct. Human review is still required for meaning and syntax.

Support Device and Width Variations Deliberately

String Catalogs can manage plural behavior and variations for specific devices.5 Variations can be useful when one expression does not fit or read naturally across:

  • Compact and expanded widths
  • iPhone and iPad
  • Different Apple platforms
  • Widget and full-app contexts
  • Short and long interface states

Do not create variants simply to hide a rigid layout problem. Use them when the user experience genuinely benefits from different wording.

Test Meaningful Values

For quantity and variable-driven strings, test:

  • Zero
  • One
  • Two
  • Values that trigger additional plural categories
  • Large values
  • Fractions where the product supports them
  • Long user names
  • Long localized currency values
  • Negative values where possible
  • Empty or unavailable values
  • Maximum-length values

A string that works with “1 item” may fail with “1,000,000 items,” a longer currency name, or a language that places the number elsewhere in the sentence.

Design for Language and Locale Differences

Localization quality depends on interface flexibility and locale-aware behavior. Translating text cannot repair every design or engineering constraint after the fact.

Allow Text to Expand and Contract

Design for:

  • Flexible containers
  • Multiline labels
  • Content-driven height
  • Buttons with sufficient space
  • Navigation titles that can adapt
  • Alerts with variable-length content
  • Forms that remain usable with longer labels
  • Tab and toolbar labels that do not become ambiguous when shortened

Pseudolocalization and doubled-length test strings can reveal expansion problems before translation begins.9

Support Right-to-Left Interfaces

Arabic, Hebrew, and other right-to-left experiences may require more than reversing text alignment. Review:

  • Reading and navigation flow
  • Leading and trailing constraints
  • Directional icons
  • Back and forward controls
  • Swipe gestures
  • Mixed-direction text
  • Numbers and punctuation
  • Charts and timelines
  • Input fields
  • Media controls
  • Images that should or should not mirror

Apple’s human interface guidance recommends reversing interfaces where appropriate to match right-to-left reading direction.12 Use semantic layout concepts such as leading and trailing instead of hard-coded left and right positions wherever possible.

Use Locale-Aware Formatting

Foundation formatting APIs can account for locale-specific conventions for dates, times, numbers, currencies, percentages, and measurements.11

Avoid building user-visible values by manually inserting separators, currency symbols, or date patterns. Locale-aware formatting should be applied at runtime using the user’s language, region, calendar, and time-zone context as appropriate.

Review Names, Addresses, and Forms

Forms often reveal hidden source-market assumptions. Consider:

  • Different name orders and structures
  • Multiple family names
  • Characters outside the Latin alphabet
  • Address order
  • Postal code formats
  • Province, state, or region fields
  • Phone number formats
  • Keyboard types
  • Input validation
  • Sorting and search behavior

A localized label does not make a form internationally usable if the underlying data model rejects valid local information.

Define Language and Locale Fallback

Document what users see when:

  • A regional translation is unavailable
  • Server content is missing
  • An extension lacks a localization
  • A third-party component does not support the selected language
  • The app and device language differ
  • App Store metadata has no matching localization

Fallback should be intentional, consistent, and tested. Mixed-language experiences are confusing and may create risk in critical flows.

Review Visual and Cultural Assumptions

Evaluate:

  • Images and illustrations
  • Symbols and metaphors
  • Colors
  • Gestures
  • Holidays
  • Maps
  • Sample names and addresses
  • Humor and idioms
  • Clothing and lifestyle imagery
  • Payment and commerce conventions

The objective is not to redesign every market independently. It is to identify elements that may confuse, exclude, or mislead the target audience.

Localize Accessibility Content

Accessibility content is part of the product language system. Hidden strings may be the primary interface for people using VoiceOver or other assistive features.

Include Accessibility Strings in the Main Workflow

Localize and review:

  • Accessibility labels
  • Hints
  • Values
  • Custom control names
  • Image descriptions
  • Status changes
  • Captions and transcripts
  • Form guidance
  • Error descriptions
  • Text that replaces an icon-only control

Keep accessibility content associated with the screen and control it describes.

Review the Complete Spoken Experience

Do not evaluate each label in isolation. Listen to:

  • The sequence in which controls are announced
  • Whether visible and hidden labels duplicate one another
  • Whether the control’s purpose is clear
  • Whether hints are concise and useful
  • Whether state changes are understandable
  • Whether a language change occurs unexpectedly
  • Whether brand names, acronyms, numbers, and abbreviations are pronounced acceptably

A grammatically correct label can still be unusable if it repeats nearby text or fails to explain the action.

Test Larger Text and Dynamic Type

Translated text may expand differently at larger accessibility sizes. Check:

  • Reflow
  • Truncation
  • Overlap
  • Hidden controls
  • Scrolling
  • Touch-target visibility
  • Reading order
  • Hierarchy
  • Modal and alert layouts

Apple’s Larger Text evaluation guidance emphasizes testing substantial text scaling because issues may appear only beyond default sizes.17

Coordinate With Accessibility Nutrition Labels

Accessibility Nutrition Labels appear on App Store product pages and can describe support for features such as VoiceOver and Larger Text. Apple advises developers to evaluate common tasks for each feature and device before indicating support.4

Localization teams should coordinate with product and accessibility owners so that:

  • Localized accessibility content is complete
  • Common tasks work in each supported language
  • Declarations accurately reflect the released experience
  • Device-specific differences are understood
  • Product-page claims do not exceed actual support

Accessibility QA Questions

  • Does the spoken label match the control’s purpose?
  • Is the hint necessary and concise?
  • Is the reading order logical in the target language?
  • Are language changes intentional?
  • Can key tasks be completed without relying on visible text alone?
  • Does larger translated text remain usable?
  • Are captions, transcripts, and image descriptions localized?
  • Does RTL content follow a logical focus and reading sequence?

Prepare the Localization Handoff

A good handoff gives translators enough technical, visual, linguistic, and operational information to work accurately without forcing them to reconstruct the product.

Application Resources

Provide the resources used by the project, such as:

  • .xcstrings
  • .strings
  • .stringsdict
  • XLIFF exports
  • Storyboard and XIB content
  • InfoPlist localizations
  • Localized asset inventory
  • App Store Connect metadata
  • Structured exports such as CSV, XLSX, or JSON when part of the approved workflow

Context Materials

Include:

  • Annotated screenshots
  • Figma frames or exports
  • Screen recordings
  • User-flow diagrams
  • Test credentials
  • Test environment access
  • TestFlight builds
  • Product documentation
  • Existing localized versions

Linguistic Assets

Include:

  • Terminology database
  • Translation memory
  • Style guide
  • Brand voice
  • Market-specific requirements
  • Approved feature names
  • Prohibited terms
  • Existing translations
  • Subject-matter references

Technical Instructions

Document:

  • Source language
  • Target languages and locales
  • Placeholder and variable rules
  • Character guidance
  • Nontranslatable content
  • Catalog ownership
  • Import and export process
  • Branch or release information
  • Resource validation requirements
  • Security and confidentiality expectations

Workflow Information

Confirm:

  • Release date
  • Content freeze or cutoff
  • Priority features
  • Reviewer assignments
  • Query process
  • Approval stages
  • Testing responsibilities
  • Defect tracking
  • Retest expectations
  • Final sign-off owner

Responsibility Matrix

Scroll horizontally to compare responsibilities across all roles.

Responsibility Matrix
Activity Product Engineering Localization Language Reviewer QA / Accessibility Release
Define scope and markets Lead Support Support Consult Consult Consult
Prepare resources Consult Lead Support — — —
Manage terminology and context Lead Support Lead Consult Consult —
Translate and review Consult Support Lead Lead — —
Import and build validation — Lead Support — Support —
In-context linguistic QA Support Support Lead Lead Support —
Accessibility evaluation Consult Support Support Consult Lead —
App Store metadata approval Lead — Support Consult Consult Lead
Final release approval Lead Lead Consult Consult Consult Lead

The exact ownership model may differ, but each responsibility should have a named owner before production begins.

Follow a Controlled iOS Localization Workflow

1

Validate the Source

Before translation:

  • Confirm source copy
  • Remove obsolete and internal strings
  • Identify hard-coded content
  • Check comments and keys
  • Validate placeholders
  • Confirm plural logic
  • Inventory assets and remote content
  • Build and test the source language
2

Export or Exchange Localization Resources

Choose the exchange model that fits the development workflow:

  • Direct String Catalog processing
  • Xcode localization export and XLIFF exchange
  • Repository-based synchronization
  • Localization platform integration
  • API-based exchange
  • Structured files for approved custom workflows

Preserve source control and define which system is authoritative.

3

Prepare the Translation Environment

Set up:

  • File parsing
  • Protected content
  • Terminology
  • Translation memory
  • Context links
  • Workflow routing
  • Reviewer assignments
  • Automated quality checks
  • Query handling
4

Translate With Product Context

Native-language professionals should translate according to:

  • User intent
  • Product terminology
  • Interface function
  • Target locale
  • Subject matter
  • Tone and voice
  • Character and layout needs
  • Accessibility context
5

Review High-Risk and High-Visibility Content

Prioritize:

  • Onboarding
  • Purchases and subscriptions
  • Security
  • Privacy and consent
  • Permissions
  • Error recovery
  • Medical, financial, legal, or safety content
  • Accessibility strings
  • App Store acquisition language
6

Import and Validate Resources

Check:

  • File structure
  • Keys and identifiers
  • Variables and placeholders
  • Required plural categories
  • Translation completeness
  • Source-language leakage
  • Build errors
  • Catalog states
  • Asset placement
7

Build and Test the Localized App

Move from file-level validation to the actual user experience:

  • Run target languages and regions
  • Review critical journeys
  • Test locale behavior
  • Check text fit
  • Test accessibility
  • Validate device coverage
  • Record defects with context
8

Resolve, Retest, and Approve

Use a controlled issue process with:

  • Screenshot or recording
  • Device and OS
  • Language and region
  • Feature and screen
  • Reproduction steps
  • Expected and actual behavior
  • Severity
  • Owner
  • Correction
  • Retest status
  • Final approval

Test the Localized iOS App

A translation can be correct in a resource file and wrong in the product. Testing verifies the language, layout, behavior, accessibility, and task completion users actually experience.

Start Before Translation With Pseudolocalization

Pseudolocalization can reveal:

  • Hard-coded strings
  • Clipped or truncated text
  • Fixed-size controls
  • Unsupported characters
  • Concatenated messages
  • Unlocalized images
  • Bidirectional layout problems
  • Assumptions about word length

Xcode includes localization previews and pseudolanguage options, including doubled-length text for layout testing.9

Test Every Supported Language and Region

Apple recommends running the app in each supported language and region.8 Test both because region can affect:

  • Date and time formats
  • Number separators
  • Currency
  • Units
  • Calendars
  • Sorting
  • Address and phone conventions
  • Market-specific content

A French-language test with one region does not prove that every French locale behaves correctly.

Use Previews, Simulators, and Physical Devices

Each environment contributes something different.

SwiftUI and Interface Builder previews help teams spot early layout and content issues.

Simulators make language, region, device, and OS combinations easier to cover.

Physical devices are important for:

  • Real text rendering
  • Keyboards
  • Notifications
  • Camera, microphone, location, and permission flows
  • Performance
  • Device-specific integrations
  • VoiceOver and other assistive features
  • Real-world network and account behavior

Prioritize devices according to actual user distribution and release risk rather than attempting an unrealistic full matrix.

Perform In-Context Linguistic QA

Review:

  • Accuracy
  • Completeness
  • Grammar
  • Fluency
  • Terminology
  • Tone
  • User intent
  • Truncation
  • Line breaks
  • Visual hierarchy
  • Awkward abbreviations
  • Untranslated strings
  • Mixed-language screens
  • Consistency across journeys

The reviewer should understand the product and have a clear method for submitting defects.

Test Plurals and Dynamic Values

Trigger representative values rather than reviewing only the default state.

Include:

  • Zero and one
  • Values that activate additional plural categories
  • Large values
  • Long names
  • Long prices
  • Multiple currencies
  • Dates and time zones
  • Empty states
  • Error states
  • User-generated content

Test Right-to-Left Behavior

Check:

  • Alignment and mirroring
  • Navigation
  • Direction-aware icons
  • Gestures
  • Mixed Arabic or Hebrew and Latin content
  • Numbers and punctuation
  • Charts and timelines
  • Input fields
  • Media controls
  • Focus and reading order
  • Third-party components

Test Accessibility in Each Target Language

Review:

  • VoiceOver labels, hints, values, and state changes
  • Larger Text and Dynamic Type
  • Focus order
  • Captions and transcripts
  • Image descriptions
  • Voice Control terminology where applicable
  • Language switching
  • RTL accessibility behavior
  • Completion of common tasks

Use TestFlight for Representative Feedback

Apple recommends distributing localized builds to native speakers for better feedback.7 TestFlight can support review by regional stakeholders, language specialists, beta users, and subject-matter experts.

Give testers focused tasks and reporting guidance. “Please review the translation” produces less useful feedback than “Complete registration, change a subscription, recover an account, and report any unclear or incorrect language.”

Add Localization to Regression Testing

Retain repeatable coverage for:

  • Critical user journeys
  • Language selection and fallback
  • Plural values
  • Variable-driven messages
  • Locale formatting
  • RTL layouts
  • Accessibility
  • App extensions
  • Notifications
  • App Store-linked flows

Localization regression should follow meaningful product changes rather than waiting for a large annual review.

Recommended Defect Record

Recommended Defect Record
Field Example
Language / region German / Germany
Device / OS iPhone 17 / iOS 26
Feature Checkout
Screen Order review
Finding Primary button wraps and covers secondary action
Type Visual / usability
Severity High
Expected Both actions remain visible and tappable
Evidence Screenshot and screen recording
Owner iOS engineering
Retest Passed in build 4.18.2

For a broader QA framework, use the Mobile App Localization Testing Checklist.

Localize App Store Connect Content

Users begin evaluating an app before installation. Product-page localization should explain the app clearly, reflect local search language, and set accurate expectations for the in-app experience.

Localizable App Store Content

Depending on the field and platform, localization may include:

  • App name
  • Subtitle
  • Promotional text
  • Description
  • Keywords
  • Release notes
  • Screenshots
  • App previews
  • In-app purchase or subscription content
  • Privacy and support information
  • Market-specific custom product-page content

Apple currently limits the app name and subtitle to 30 characters each.14 Other fields have their own limits and edit rules, which should be verified in App Store Connect before production.

Translate for Discovery and Conversion, Not Word for Word

Search behavior and product expectations differ by market. Effective App Store localization may require:

  • Local keyword research
  • Market-relevant phrasing
  • Reprioritized benefits
  • Adapted calls to action
  • Locally natural feature names
  • Character-limit management
  • Creative transcreation for screenshots
  • Review of claims and required disclosures

A literal translation can be accurate but weak for discovery or conversion. Conversely, highly adapted marketing language should not promise features the localized app does not provide.

Localize Screenshots and Previews

Review:

  • Interface language shown in the asset
  • Overlay captions
  • Market-specific value propositions
  • Legibility
  • Device frame and dimensions
  • Sequence of benefits
  • Cultural relevance
  • Accuracy of product claims
  • Consistency with the current release

Do not reuse source-language screenshots under localized metadata unless the strategy is deliberate and appropriate for that market.

Understand Primary-Language Fallback

App Store Connect uses the primary language when a matching localization is unavailable. Apple also applies language and regional fallback behavior when selecting the metadata shown to a user.13

Plan fallback intentionally:

  • Which markets receive the primary language?
  • Are screenshots and descriptions complete?
  • Does the product support the language advertised?
  • Are localized keywords active in the intended storefronts?
  • Could a user see localized metadata and then enter an untranslated app?

Manage Localization at Scale

Apple supports automating localized metadata management through the App Store Connect API.2 Automation can help teams coordinate many languages and frequent releases, but approval and quality controls remain necessary.

A scalable workflow connects:

  • Source metadata
  • Translation and market review
  • Screenshot production
  • Release notes
  • App version
  • Approval status
  • API or App Store Connect upload
  • Final product-page QA

Coordinate Accessibility Information

Accessibility Nutrition Labels should reflect the actual released experience on each supported device.4 Coordinate the product-page declaration with localized content and accessibility testing before release.

Use AI Responsibly in iOS Localization

AI can accelerate source analysis, draft translation, terminology suggestions, repeated updates, and quality checks. Apple now documents agent-assisted localization within Xcode, reflecting a broader shift toward AI-supported development workflows.7

The central question is not whether AI is used. It is how output is governed according to context and risk.

Appropriate Uses of AI Assistance

AI may help with:

  • Initial translation drafts
  • Repetitive low-risk strings
  • Source-content classification
  • Terminology suggestions
  • Context consolidation
  • Changed-string detection
  • Query prioritization
  • Missing-translation checks
  • Placeholder and number checks
  • Consistency analysis

Where Human Expertise Is Most Important

Prioritize expert review for:

  • Ambiguous short strings
  • Permissions and privacy
  • Payments and subscriptions
  • Medical, financial, legal, or safety content
  • Security-critical messages
  • Brand and product positioning
  • Accessibility strings
  • Plurals and complex variables
  • App Store marketing content
  • High-visibility user journeys

A Practical AI + Human Routing Model

A Practical AI + Human Routing Model
Content Profile AI Role Human Control
Repeated, previously approved content Identify and apply translation-memory matches Validate reuse rules and changed context
Routine new interface text Produce a terminology-constrained draft Professional linguistic review
Ambiguous or context-sensitive UI Suggest options using available context In-context linguist or product review
Regulated or high-consequence content Limited assistive use under policy Qualified subject-matter review and approval
App Store acquisition copy Research support and draft alternatives Local market adaptation and marketing approval
Accessibility content Draft with linked screen context Accessibility-aware linguistic review and device testing

Give AI the Same Context a Human Needs

Output improves when the workflow includes:

  • Approved terminology
  • Translation memory
  • Style guidance
  • Screenshots
  • String comments
  • Feature descriptions
  • User-flow context
  • Prior approved translations
  • Protected variables
  • Target-market instructions

AI should not be asked to infer critical product meaning from isolated keys when better context exists.

Validate Output in the Running App

Fluency does not prove:

  • Functional correctness
  • Layout fit
  • Placeholder safety
  • Plural behavior
  • Accessibility
  • Locale formatting
  • Consistency with the user journey
  • Market appropriateness

Apply automated technical QA, professional review, and in-context testing according to content risk.

Protect Sensitive Product Information

Define governance for:

  • Confidential strings
  • Unreleased features
  • Personal data
  • Security content
  • Proprietary terminology
  • Regulated information
  • Model and vendor access
  • Data retention
  • Auditability

Enterprise AI localization should operate inside approved security, privacy, and quality controls.

Learn more about Stepes’ AI + human app localization approach.

Scale With Continuous Localization

Localization becomes easier to manage when it is part of the software delivery lifecycle rather than a large task immediately before release.

Connect Localization to Development

A continuous workflow may use:

  • Repository synchronization
  • Translation APIs
  • Structured file exchange
  • Branch-based handoffs
  • Automated build validation
  • Status notifications
  • Reviewer routing
  • Release orchestration

Stepes supports software localization API workflows for recurring product updates.

Translate Only What Changed

Classify content as:

  • New
  • Changed
  • Unchanged
  • Obsolete
  • Moved
  • Reused in a new context

Use Translation Memory to reuse approved content where the meaning and context remain valid. A source change should trigger review proportional to the change, rather than automatically discarding every prior translation.

Maintain Terminology as the Product Evolves

Product naming changes over time. Establish ownership for:

  • New feature terms
  • Deprecated terminology
  • Preferred interface verbs
  • Market-specific variants
  • Brand language
  • Regulated terminology
  • Reviewer decisions

A shared Terminology Management process keeps iOS, Android, web, support, and marketing content aligned.

Prevent Localization From Blocking the Release

Use:

  • Rolling handoffs
  • Priority features
  • Market release waves
  • Defined review windows
  • Clear content freezes
  • Fallback rules
  • Escalation paths
  • Release acceptance criteria

A continuous process still needs discipline. Constantly changing source text without ownership can create churn, stale translations, and repeated review.

Keep QA in the Release Cycle

Automate what can be checked reliably:

  • Missing strings
  • Placeholder mismatches
  • Changed tags
  • Source-language leakage
  • Build errors
  • Required plural variants
  • Character guidance
  • Catalog status

Retain targeted human testing for:

  • Meaning
  • Context
  • layout
  • User journeys
  • Accessibility
  • Market expectations
  • High-risk content

Measure the Program

Useful operational measures may include:

  • New and changed strings per release
  • Translation-memory reuse
  • Query volume
  • Review turnaround
  • Defects by type and severity
  • Reopened defects
  • Source changes after translation
  • On-time language completion
  • App Store metadata readiness
  • Post-release localization issues

Metrics should help improve source quality, workflow design, and release predictability—not encourage teams to approve language too quickly.

For deeper implementation guidance, read Continuous Localization for Mobile Apps.

Common iOS Localization Mistakes

01

Treating Localization as Translation Only

Why it fails: The app may contain correct text but broken layouts, wrong locale formats, incomplete accessibility content, or untranslated remote content.

Better approach: Plan language, engineering, design, testing, accessibility, and App Store work together.

02

Translating Strings Without Context

Why it fails: Short words can have multiple meanings.

Better approach: Provide comments, screenshots, screen IDs, user flows, terminology, and build access.

03

Concatenating Sentence Fragments

Why it fails: Other languages may require different word order or grammatical agreement.

Better approach: Externalize complete messages with variables and plural logic.

04

Assuming English Plural Rules Apply Everywhere

Why it fails: Languages may require multiple categories and different behavior for values or fractions.

Better approach: Implement language-specific plural structures and test representative values.

05

Hard-Coding User-Facing Text

Why it fails: Content cannot be translated or may remain hidden until a rare runtime state.

Better approach: Externalize all user-facing strings and scan critical flows for leakage.

06

Using Fixed Interface Dimensions

Why it fails: Longer translations, RTL, and Dynamic Type can clip or hide content.

Better approach: Use flexible layouts and test expansion before translation.

07

Ignoring Accessibility Strings

Why it fails: VoiceOver users may receive an incomplete or source-language experience.

Better approach: Include assistive content in translation, review, and QA.

08

Testing Only in the Simulator

Why it fails: Real devices expose keyboards, permissions, notifications, performance, and assistive-technology behavior.

Better approach: Combine previews, simulators, and prioritized physical devices.

09

Localizing the App but Not the App Store Page

Why it fails: Users may encounter source-language metadata or a product promise that does not match the localized app.

Better approach: Coordinate binary and metadata localization.

10

Translating Every Release From Scratch

Why it fails: Cost, inconsistency, and review effort increase.

Better approach: Reuse approved translations, terminology, context, and testing history.

11

Trusting Fluent AI Output Without Product Validation

Why it fails: A fluent sentence can be wrong for the control, variable, layout, or user journey.

Better approach: Apply risk-based human review and in-context testing.

12

Launching Every Market With the Same Risk Model

Why it fails: Markets, user volume, regulatory exposure, and internal review capacity differ.

Better approach: Prioritize languages and user journeys, use release waves where helpful, and define acceptance criteria.

Final iOS Localization Checklist

Scope and Planning

  • Target languages, locales, and markets are confirmed.
  • Critical user journeys are prioritized.
  • All app, extension, server, support, and App Store content sources are inventoried.
  • Regional variants are justified by real product or market needs.
  • High-risk and high-visibility content is identified.
  • Product, engineering, localization, QA, accessibility, and release owners are assigned.

Resource Preparation

  • String Catalogs are complete and organized.
  • Legacy .strings and .stringsdict resources are identified.
  • Storyboards, XIB files, InfoPlist content, and assets are inventoried.
  • Obsolete, duplicate, developer-only, and test strings are removed.
  • Keys are clear and stable.
  • Translator comments explain function and variables.
  • Plural and device variations are implemented.
  • Remote and server-delivered content has a locale strategy.
  • Export, import, repository, or API ownership is defined.

Linguistic Preparation

  • Approved terminology is available.
  • Translation memory and prior translations are supplied.
  • Style and brand guidance are documented.
  • Market-specific requirements are recorded.
  • Screenshots or other visual context are linked.
  • Character guidance reflects real interface constraints.
  • Language reviewers and subject-matter reviewers are assigned.
  • Query and approval processes are clear.

Engineering Validation

  • Source-language builds pass before translation.
  • Localized resources import successfully.
  • Keys, tags, variables, and placeholders are preserved.
  • Required plural categories are complete.
  • The app builds in all target languages.
  • No source-language leakage remains in critical flows.
  • Locale formatting behaves correctly.
  • Fallback behavior is intentional.
  • Localized assets appear in the correct contexts.

In-Context Quality Assurance

  • Critical user journeys are linguistically reviewed.
  • Text expansion and wrapping are checked.
  • Compact and expanded layouts are checked.
  • RTL behavior is checked where applicable.
  • Plurals and dynamic values are tested.
  • Dates, numbers, currencies, measurements, and time zones are validated.
  • Names, addresses, forms, search, and sorting are reviewed.
  • Notifications, widgets, and app extensions are checked.
  • Defects include evidence, severity, ownership, and retest status.

Accessibility

  • Accessibility labels, hints, values, and image descriptions are localized.
  • Spoken sequences are reviewed with VoiceOver.
  • Larger Text and Dynamic Type are tested.
  • Focus and reading order are logical.
  • Captions and transcripts are localized where required.
  • Common tasks are evaluated for declared accessibility features.
  • Accessibility Nutrition Labels reflect the released experience.

App Store Release

  • App name, subtitle, description, keywords, and promotional text are localized as required.
  • Release notes match the current version.
  • Screenshots and previews show the correct localized interface.
  • Local keyword and positioning decisions are reviewed.
  • Primary-language fallback is understood.
  • Product-page claims match actual app functionality.
  • App and metadata terminology are consistent.
  • Final approvals are recorded.

Continuous Operations

  • New and changed strings can be detected.
  • Translation-memory reuse rules are defined.
  • Terminology ownership is established.
  • Review windows align with the release cycle.
  • Regression tests are retained.
  • App Store metadata updates are included in release planning.
  • Localization performance and defects are reviewed after launch.

Frequently Asked Questions

What Files Are Needed to Localize an iOS App?

The required files depend on the application architecture. Common inputs include .xcstrings, .strings, .stringsdict, XLIFF localization packages, storyboards, XIB files, InfoPlist localizations, localized assets, structured exports, screenshots, terminology, and App Store Connect metadata. A representative build or TestFlight access can provide essential context for review and testing.

Are String Catalogs Replacing .strings Files?

String Catalogs are the modern Xcode approach for managing localizable strings, plurals, variations, comments, and translation states. Many established apps still contain .strings, .stringsdict, and storyboard resources. Mixed architectures are common, and migration should be validated carefully.

Can Stepes Translate .xcstrings Files?

Yes. Stepes can process String Catalog content while preserving keys, contextual information, variables, plurals, variations, and technical structure. The workflow is configured around the development team’s source-control, exchange, import, review, and release requirements.

How Is SwiftUI Localization Different From UIKit Localization?

SwiftUI and UIKit may use different APIs and resource patterns, but both require properly externalized text, useful context, locale-aware design, and in-app testing. Enterprise apps often contain both frameworks, so the localization inventory should cover the complete product rather than one UI technology.

How Should Plural Strings Be Localized?

Implement complete messages with variables and the plural categories required by each target language. Do not build sentences from fragments or assume English singular-versus-plural behavior applies everywhere. Test representative values in the running app.

How Do You Give Translators Context for iOS Strings?

Use developer comments, screenshots, Figma frames, screen IDs, storyboards, user-flow diagrams, character guidance, screen recordings, test environments, and TestFlight builds. Connect each high-ambiguity string to the interface state where it appears.

Does App Store Content Need to Be Localized Separately?

Yes. App Store Connect metadata is managed separately from the localized app binary. Coordinate app names, subtitles, descriptions, keywords, screenshots, previews, promotional text, and release notes with the in-app experience.

How Do You Test an iOS App in Multiple Languages?

Use pseudolocalization before translation, run each supported language and region, review SwiftUI or Interface Builder previews, test simulators and representative physical devices, conduct in-context linguistic QA, validate locale behavior and RTL, test accessibility, and retain regression cases for future releases.

Can AI Translate an iOS App?

AI can accelerate draft translation, repeated updates, terminology suggestions, classification, and automated checks. Production-ready results still require protected technical content, approved terminology, appropriate professional review, and validation inside the working app. High-risk and highly visible content generally needs stronger human controls.

How Long Does iOS App Localization Take?

Timing depends on source readiness, word and string volume, target languages, resource formats, context quality, reviewer availability, engineering integration, testing scope, device coverage, App Store content, and release cadence. A well-prepared app with established language assets can move faster than an app that first requires internationalization changes.

How Much Does iOS App Localization Cost?

Cost is influenced by new and repeated content, language count, translation and review model, engineering, terminology preparation, context creation, in-app QA, accessibility testing, device coverage, App Store assets, and turnaround requirements. See the App Localization Cost Guide for a complete planning framework.

How Often Should an iOS App Be Localized?

Localization should follow meaningful product and content changes. Teams with frequent releases benefit from continuous workflows that detect new and changed strings, reuse approved translations, route review, validate builds, and keep App Store content aligned.

Putting the Guide Into Practice

Connect Language Quality to the Complete iOS Release

A successful iOS localization program connects language expertise with sound resource architecture, visual context, locale behavior, accessibility, testing, and release operations. A practical next step is to audit the source resources and critical user journeys, assign clear ownership, and validate one representative language from export through release before scaling.

Sources and References

Official Guidance Used in This Guide

Platform requirements can change. Consult current Apple and Unicode documentation as part of release planning and technical review.

  1. 01Apple Developer — Upcoming SDK Minimum Requirements
  2. 02Apple Developer — Localization
  3. 03Apple Developer — App Store Expands Support to 11 New Languages
  4. 04Apple Developer — Accessibility Nutrition Labels
  5. 05Apple Developer — Localizing and Varying Text With a String Catalog
  6. 06Apple Developer — Using Generated Localizable Symbols in Your Code
  7. 07Apple Developer — Xcode Localization
  8. 08Apple Developer — Testing Localizations When Running Your App
  9. 09Apple Developer — Preparing Your Interface for Localization
  10. 10Unicode CLDR — Plural Rules
  11. 11Apple Developer — Foundation FormatStyle
  12. 12Apple Human Interface Guidelines — Right to Left
  13. 13Apple Developer — Localize App Information
  14. 14Apple Developer — App Information Reference
  15. 15Apple Developer — Exporting and Importing Localizations
  16. 16Apple Developer — Localizing Assets in a Catalog
  17. 17Apple Developer — Larger Text Evaluation Criteria

Related App Localization Resources

Move from iOS-specific implementation to cross-platform preparation, testing, continuous localization, cost planning, or end-to-end professional support.

App Localization Support

Launch a Better Localized iOS Experience

Stepes helps global product teams localize String Catalogs and legacy iOS resources, manage terminology and translation memory, protect technical content, review language in context, test multilingual builds, localize App Store content, and support recurring product releases.

Talk to an App Localization Expert Request a Translation Quote