--- title: Local vs Global When to Adapt Your Mobile Strategy description: Learn when to localise your app and when a global strategy works. Covers devices, payments, regulation, connectivity and trust norms by market. image: https://weareaffective.com/hubfs/learning-centre-images/local-vs-global-when-to-adapt-your-mobile-strategy.webp --- [Skip to content](https://weareaffective.com/learning-centre/local-vs-global-when-to-adapt-your-mobile-strategy#main-content) [![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com) - [Home](https://weareaffective.com) - About Us - [Our Story](https://weareaffective.com/about) - [How We Work](https://weareaffective.com/how-we-work) - Our Services - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy) - [App Design](https://weareaffective.com/app-design-agency) - [App UX Design](https://weareaffective.com/app-ux-design) - [App UI Design](https://weareaffective.com/app-ui-design) - [App Technical Architecture](https://weareaffective.com/app-architecture) - [Existing App Audits](https://weareaffective.com/app-audit) - [Case Studies](https://weareaffective.com/case-studies) - [Pricing](https://weareaffective.com/pricing) - [Learning Centre](https://weareaffective.com/learning-centre) - [Get Started](https://weareaffective.com/get-started) Expert Guide Series # Local vs Global When to Adapt Your Mobile Strategy Table of Contents We worked on a currency exchange product with a neat idea behind it. People come home with leftover euros or dollars sitting in a drawer, so let them pass it to someone else at an agreed rate and skip the bank and bureau fees. Partway through the project we found out that the law, and Apple's own App Store requirements, wouldn't allow peer-to-peer transfers of that kind. The whole product had to change shape. That's an app localisation strategy question arriving late, from outside, and it cost us most of the original vision. > Localisation starts as a language question and ends up as a question about your entire business model. Localisation gets treated as translation, currency symbols and a date format. The expensive parts sit underneath all of that, in the rules about money, the phones people actually hold, the price of a gigabyte and what counts as normal behaviour in a market you've never lived in. So the useful question is [which parts of your product have to bend](https://weareaffective.com/app-planning-strategy) for a market, which parts can wait, and which parts you build once and ship everywhere. This article works through the evidence we use to decide that, drawn from products we've built and the ones where we got it wrong. ## What a Single Global App Strategy Quietly Assumes Every global app strategy carries a picture of a user inside it, and that picture is usually the team who built the thing. A recent phone, data that costs nothing to think about, a card saved in the wallet, an app store that happily takes the money, and a bar of signal everywhere that matters. We worked on a product aimed at African communities living abroad, built to help people keep a connection with their home communities. Technically it was viable and fairly straightforward from where we sat. The devices commonly used in several of those countries at the time were far more limited, and delivering half of the intended experience on them would have been incredibly challenging. The product worked on our side of the connection and fell apart on the other. #### Borrowed features travel badly The other quiet assumption is that a feature which works somewhere else will work here. Taking a product that does something similar to yours in a different scenario, and implementing it in your product, which runs in a different scenario, won't necessarily make it work. Context and emotional fit matter as much as whether the code runs. A wallet flow built for a market with instant bank transfers behaves differently in a market where people still prefer cash on delivery. ## Evidence That Tells You a Market Needs Its Own Approach On that same product for African diaspora communities, we ran a lot of focus groups with the target market. The result was blunt. There just wasn't a desire for that kind of product, and no amount of design work was going to manufacture one. The research saved a build that the device landscape would have undermined anyway. Numbers in a dashboard rarely tell you a market needs its own treatment. They tell you something is off and you go and look. The signals we trust are simple ones. - Drop-off at one single step that only spikes in one country - Store reviews in one language all circling the same complaint - Payment failures clustered around one method or one bank - A device and OS mix that looks nothing like your other markets - Support messages asking for something you assumed nobody wanted There's a trap in doing this research for one part of the product only. On a dating app we worked on, we put real emphasis on onboarding, validation and verification, and that work held up. Messaging got built generically, with no discovery behind it, and it allowed the very behaviour the onboarding existed to stop. Fake, automated messages walked in through the door we hadn't studied. Do that market by market and you get the same contradiction, with a border around it. ## Start your app project the *right* way We deliver the complete blueprint before a line of code is written. User research, psychology-driven design and full technical specifications. You choose who builds it. [See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started) No commitment ## Devices, Operating Systems and the Platform Split We worked on [a social football platform that launched iOS-only](https://weareaffective.com/learning-centre/going-mobile-7-ways-that-a-mobile-app-will-help-your-business). The audience was younger and proportionally skewed towards Android, so day-one adoption came in at around half of what it could have been. We'd built the better, more polished version of the product for the smaller part of its own market. > We built the more polished version of that football product for the smaller half of its market. The damage didn't stop at launch week. Without the user base to support it, the client had to cancel the subscription model and bring in advertising, which they'd specifically said they wouldn't do. A platform decision made for speed turned into a revenue model nobody wanted, and that strain stayed with the product. Android holds roughly 71% of the global market according to [RipenApps](https://ripenapps.com/blog/android-ios-users-comparative-study-impact-mobile-app-development/), which matters more the younger and more international your audience is. | Decision | iOS first | Android first | | --- | --- | --- | | Audience fit | Older, higher spend, US and UK weighted | Younger, wider global spread | | Revenue model | Subscriptions hold up better | Ad-supported tiers do more of the work | | Testing load | Small, predictable device range | Wide range of screens, chips and OS versions | | Risk if wrong | Polish for the smaller half of the market | Slower polish, broader reach | ## Connectivity, Data Costs and Offline Expectations Offline support is a market decision, and it's two decisions rather than one. The first is the use case and the destination type. A travel product built around remote safaris sits in a completely different position to one built around city hotels in well-connected Western markets. The second is [what level of support you actually need](https://weareaffective.com/learning-centre/what-mobile-app-design-and-development-services-does-your-business-actually-need), from pulling back cached data all the way up to queuing booking changes that sync when signal returns. Queuing changes is rarely worth building. Cost shapes this as much as coverage does. Data plans in some countries run to upwards of 10% of a typical monthly income, according to [Google Design](https://design.google/library/making-youtube-go/). A person in that position is rationing megabytes, and a 40MB auto-playing hero video is a reason to delete you. Write down the one screen a person must still be able to see with no signal. Build that properly, then stop. #### What good offline looks like Google Maps and Apple Maps handle this well. There's clear mode signposting, so you always know what you're looking at, prompts to pre-download before you lose signal, and caching of areas you visit often happening behind the scenes. Zoom right into street level without the data and the detail goes, but you're never dumped on a blank map with no idea where you are. The quality drops gently instead of falling off a cliff. ## Regulation, Payments and App Store Rules The currency exchange product is the clearest case we have of rules rewriting a product. The original design let two people agree a rate and move leftover holiday money between them remotely, cutting out the bank. Partway through, we found that [both the legal position and Apple's requirements](https://weareaffective.com/learning-centre/what-happens-if-apple-or-google-changes-their-push-notification-rules) ruled that out. The product had to become location-based and in person, so people meet up and physically swap the cash. Some of that pivot worked in our favour. Map pins, movement, the small event of meeting a stranger near Liverpool Street to swap forty euros, all of it gave the product a more social feel than the original ever had. The cost was scale. People could only trade with whoever happened to be nearby, which shrank the pool of exchange partners and undercut the wide, easy reach the whole thing was built on. #### Build the rules check into your app localisation strategy Pricing sits in the same family. Charging one global price in markets with very different incomes leaves money on the table, and [Mirava](https://www.mirava.io/blog/why-purchasing-power-parity-pricing-is-a-must-for-mobile-apps) reports revenue lifts of 15-122% within a month from matching prices to local affordability. Check the money flow against local law and store policy before a single screen gets designed, because this is the one constraint you can't design around later. ## How People Expect to Get Hold of Your Product Access habits differ by market in ways that catch teams out. In some places the default is a single app that does everything, with payments, messaging and booking in one place. Statista puts the share of global customers who prefer super apps at [66%](https://www.statista.com/topics/10296/super-apps/#topicOverview), driven by having daily services together. Standalone single-purpose apps have a harder job in those markets, and partnership or embedded distribution often beats a store listing. What people expect to see at the point of paying is just as local. On [a travel product we learned the hard way](https://weareaffective.com/learning-centre/what-a-travel-ota-learned-by-distributing-the-booking-form-across-the-whole-grou) that wrapping the platform fee into one tidy total made people anxious about hidden charges. Breaking it into line items showed them more information and gave them far more confidence that this was the real price. The itemisation matched what they expected a mobile platform to do. Show the fee rather than hiding it inside the total. More numbers on screen can mean less worry, not more. We handle account creation the same way across a number of products, including a gifting platform and [a second-hand sports marketplace](https://weareaffective.com/learning-centre/what-the-second-hand-sports-marketplace-taught-us-about-deferring-the-login). Login gets deferred until later in the process, and even then we only ask for what's needed at that exact point. Sign-up rates come out higher because people have already felt the product work before anyone asks them for anything. ## Growth Loops That Travel, and Ones That Don't We worked on a travel OTA aimed at group bookings for people in their early twenties to mid-thirties. After launch the team tried the usual list of acquisition tactics. Referral codes with a discount attached, push notifications to pull lapsed users back, social sharing of trips, email campaigns through Mailchimp. All of it produced small, polite numbers. > One person booking for ten gave us nine new users, each able to start their own group. What actually moved things was a loop built into the booking flow itself. When someone organised a trip, the app prompted every traveller in that group to download it, both to keep the conversation in one place and to submit their passport details. The growth came out of the job the product already did, which is why it kept working. That loop travels well, because group travel is group travel wherever you are. Others don't. Referral mechanics depend on which messaging app people live in and whether sharing a discount code with friends reads as generous or as spam. Social sharing depends on whether the platform you're sharing to has any reach in that country. Before copying a loop into a new market, check that the behaviour it depends on is actually a behaviour there. ## Privacy, Trust and Safety Norms by Market How you ask changes the answer, and it changes it more in markets where trust in apps runs low. Asking for permission before a request, rather than firing the system prompt and hoping, is a framing and tone of voice change with no technical component at all. The end result is identical. Someone turns on notifications or shares their address book either way. [People who feel they have control](https://weareaffective.com/learning-centre/why-do-some-apps-feel-easy-while-others-feel-hard) over a product are more engaged and more likely to stay. Safety norms shift too. On the dating app, the verification work we did at onboarding was the part the client cared about, and it held up. Messaging, built without the same discovery, let automated fake messages straight through. Trust was promised at the front door and broken two screens later. #### What to check before you localise your app Look at what each market treats as a reasonable thing to ask for. Phone number verification feels normal in some places and invasive in others. Photo ID is routine in one country and a hard stop in the next. Location sharing carries very different weight depending on local history with it. Then set the permission requests, the wording around them and the verification steps to match, instead of exporting one pattern everywhere. ## What Should Stay the Same Everywhere Plenty should hold still. The thing the product is for, the standard of care in the writing, the emotional promise the brand makes, and the honesty of your pricing. Those travel without adjustment, and pulling them apart per market is how a product stops feeling like one product. We worked on a mobile app in the health and wellness genetics sector where [the promise and the experience had come apart](https://weareaffective.com/learning-centre/is-dirty-data-ruining-your-mobile-apps-purpose-what-app-developers-need-to-know) completely. Packaging and the online presence were luxurious and aspirational, all about transformation and becoming a better version of yourself. The app that had already been built was cold and clinical, purely functional in its copy and its design. Someone moved from that aspirational marketing, ordered a kit, did the test, waited, opened the app for their results and hit a wall. The journey broke at the one touchpoint that mattered most. Put every feature through one question, in every market. Is this helping the person do what they came to do, or working against it? The same discipline applies to how often you interrupt people. Keep an eye on how frequently push notifications and in-app messages go out, and check that each one is timely and relevant to that person. Pressure tactics read as pressure everywhere. They just get forgiven less in some places than others. ## Deciding What to Adapt, What to Defer and What to Ship Once The decision gets easier once you separate the layers. Underneath sits one product with one purpose. Above it sit the things that have to answer to local conditions, which is money, devices, connectivity, permissions and distribution. In between sit the things you'd like to adapt eventually and can safely leave alone this year. A workable order looks like this. 1. Name the two or three markets you're genuinely resourcing, and ignore the rest for now. 2. Check the device and connection mix in each one before any design work starts. 3. Check your money flow against local law and store policy, early, while changing it is still cheap. 4. Run small, real research in the market you're least confident about. 5. Build one core product with market-specific layers switched on top of it. 6. Re-check after launch, because the signals that matter only show up once people are using it. Deferring is a real choice and worth stating out loud. Language variants, local payment methods beyond the big ones, country-specific content and regional growth loops can all wait a release or two. What can't wait is anything that would force a structural change later, which is exactly what the currency exchange pivot taught us. Finding out about Apple's rules partway through cost us the scale the whole product was designed around. ## Conclusion The pattern across these projects is consistent. The expensive surprises never came from language. They came from a platform choice made on instinct, from devices we hadn't held, from rules nobody checked until the build was underway, and from assuming a desire existed because it existed here. The football platform lost half its day-one adoption and its subscription model. The currency product lost its reach. The diaspora product never shipped, and that was the right call. So treat an app localisation strategy as a set of questions about constraints rather than a translation job. Which phones are people holding. What does their data cost. What will the law and the store allow. How do they expect to pay, and what do they expect to see before they pay. Then hold the rest steady, because the product's purpose and the promise your brand makes shouldn't change at a border. Where a market earns its own treatment, give it that treatment properly and in full. Where it doesn't, one well-built product does more good than five half-adapted ones. If you're weighing up a new market, or a launch that didn't land the way you expected, [let's talk about your app localisation strategy](https://weareaffective.com/get-started). ## Frequently Asked Questions What does localisation actually involve beyond translating the text? Translation, currency symbols and date formats are the surface layer. The costly parts sit underneath, in financial regulation, the devices people actually own, the cost of mobile data and what counts as normal behaviour in that market. Those factors can reshape your business model, not just your copy. Why do legal and app store rules matter so early in a project? Because they can invalidate the core idea rather than just a feature. On a currency exchange product, we discovered partway through that the law and Apple's App Store requirements would not permit peer-to-peer transfers of that kind, and the product had to change shape entirely. Checking those constraints before you build protects the original vision. What assumptions are hidden inside a single global app strategy? Most global strategies quietly picture a user who looks like the team that built the product, with a recent phone, cheap data, a saved card and reliable signal. When those assumptions do not hold, the experience can collapse on one side of the connection while working perfectly on yours. It is worth writing the assumed user down and testing each part of that picture per market. Can we copy a feature that works well in another market? Not reliably. A feature built for one scenario does not automatically fit a different one, because context and emotional fit matter as much as whether the code runs. A wallet flow designed for a market with instant bank transfers behaves very differently where people still prefer cash on delivery. Which signals suggest a market needs its own approach? Look for drop-off at a single step that only spikes in one country, store reviews in one language circling the same complaint, payment failures clustered around one method or bank, a device and OS mix unlike your other markets, and support messages asking for something you assumed nobody wanted. Dashboards rarely tell you the answer outright, they tell you something is off so you can go and investigate. Is research worth doing if we are confident the product is technically viable? Yes, because technical viability says nothing about demand. On a product for African diaspora communities, focus groups showed there simply was not a desire for it, and no amount of design work would have created one. That research saved a build that the device landscape would have undermined in any case. What goes wrong when you research only part of the product? You end up with strong areas sitting next to untested ones. On a dating app, onboarding, validation and verification received real attention and held up well, while messaging was built generically with no discovery behind it and allowed the very behaviour the onboarding was meant to prevent. Research needs to cover the whole journey, not just the parts you find interesting. How should we decide what to adapt and what to build once? Separate your product into parts that must bend for a market, parts that can wait, and parts you build once and ship everywhere. Anything touching money, identity, devices or local behaviour usually belongs in the first group. The rest can stay shared until evidence tells you otherwise. ## Related Articles [![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com) 20-22 Wenlock Road London, N1 7GU United Kingdom +44 20 4572 8062 [hello@weareaffective.com](mailto:hello@weareaffective.com) Services [App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit) Legal [Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70) Case studies [TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift) About us [Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work) Guides [Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth) Copyright © 2026, weareaffective.com. All rights reserved.