Several branches belong in one app, and the part that makes it work is a location on every row.

Should each branch get its own app?

No, unless the branches are separate businesses. Apple's App Store Review Guidelines, read on 14 October 2026, put this under the heading Spam. Rule 4.3(a) says not to create multiple Bundle IDs of the same app, and the example it gives is submitting a separate map app for every city in the world instead of a single worldwide map that allows users to search any city. The rule goes on: if your app has different versions for specific locations, sports teams or universities, consider submitting a single app. Four salons under one name are the same app four times.

The same guidelines describe the shape that is fine. Rule 4.2.6 is written for app generation services rather than for you, and one of the options it names is a single binary that hosts all client content in an aggregated or picker model. Apple's own example is a restaurant finder app with separate customized entries or pages for each client restaurant. A branch picker is that model with one owner instead of many, which is worth knowing because people assume the picker is the workaround when it is the pattern.

Then there is the cost nobody prices in. Every extra listing needs its own screenshots, its own description and keywords, and its own trip through review. Ratings and installs split across them, and each new listing starts at zero while the old one keeps the history. Every fix ships as many times as you have branches. A customer who uses two of your shops needs two installs and two accounts, and the loyalty balance they expect to share sits in neither. None of that is a rule. It is just a weekly tax.

Separate apps do make sense in three cases. Different brands that share nothing but an owner. Separate legal entities that must not share customer data. And franchisees who want their own listing, because the developer account that uploads a build owns that listing, so an independent franchisee needs an account of their own. If none of those describes you, one app is both cheaper and the thing the guidelines point at.

Which parts of the business carry a location, and which do not?

One rule does most of the work. Anything a customer could see differently at two branches needs a location on it. Anything true of the business as a whole does not. Hours, prices, the service list, staff, stock and bookings are in the first group. The brand, the terms and the privacy policy are in the second. The mistake people make is holding the branch in app settings rather than on the row, which works perfectly right up to the day two branches disagree.

The shape that survives is boring. A locations table with the name, street address, phone number, time zone, opening hours and a flag for whether the branch is taking bookings at all. A services table holding each service once, with its name and duration. Then the piece people skip: a join between a service and a location carrying the price and the fact that it is offered there. Staff get the same treatment, a row per person per branch, so the stylist who covers Tuesdays at the second shop is one account with two links rather than two accounts.

Store every booking in UTC with the location beside it and render it in that branch's time zone. A single city chain gets away without this for years and then opens across a border. Holiday closures work the same way: a public holiday shuts one branch and not another, so closures hang off the location rather than a global list. Stock, rooms and chairs are counted per location too, because a shared pool is a different and much harder app.

Two more fields to settle before anybody writes a screen. A customer's home branch, the one the app opens on, is not the same thing as the branch of each booking, and you need both. And a service offered at one shop only has to be invisible in the others rather than greyed out, because a greyed out row is a support message. If you are mapping this out for a salon booking app, write the grid first: services down the side, branches across the top, prices in the cells.

Should the app find the nearest branch, or ask?

Ask, then offer to find. A list of four branches with the addresses under them is quicker than a permission prompt, and it works for the person sitting at home booking the shop near their office. Apple's Core Location documentation is direct about the timing: make authorization requests only when someone engages a part of your app that requires that data, because a request made immediately at app launch, or in a part of your app that does not clearly use location data, can lead the person to misinterpret your intent and deny the request. That answer is stored and you are not prompted again, so one badly placed prompt loses the feature for good.

There are two access levels and a usage string for each. When in Use makes location available only while someone is using your app, and Apple calls it the preferred choice because of its privacy and battery implications. Always makes updates available at any time and lets the system launch your app quietly. A branch picker needs When in Use and nothing beyond it. The strings go in the app's Information Property List, and these are the current key names: NSLocationWhenInUseUsageDescription, required when the app requests When in Use or Always authorization; NSLocationAlwaysAndWhenInUseUsageDescription, required when the app requests Always authorization; and NSLocationUsageDescription, which is macOS only. Apple adds the detail that costs an afternoon: add every usage description key before you make any authorization request, because requests fail immediately if the required keys are not present.

Apple, requesting authorization to use location services, read 14 October 2026

Android splits the same decision two ways, category and accuracy. Google's guide to requesting location permissions says to always include ACCESS_COARSE_LOCATION, and to include ACCESS_FINE_LOCATION only if your app benefits from precise location access. The gap between them is published. An approximate estimate from the platform providers is accurate to within about 3 square kilometres, and a precise one is usually within about 50 metres. Sorting four branches by distance does not need 50 metres. Google also notes that if someone grants the approximate permission your app only gets approximate location whatever it declared, and that your app should still work in that case, which is a decent argument for keeping the manual list on screen either way.

Background location is a separate permission and a separate conversation. ACCESS_BACKGROUND_LOCATION has to be declared on Android 10, API level 29, and higher before you can request background access at runtime, and Google notes that the Play Store has a location policy restricting background access to apps that need it for their core features. A branch picker does not qualify and does not need to. Nor does a check in, as a rule, because a tap at the counter is cheaper than a policy argument. In a React Native project these strings live in Info.plist and the permissions in the Android manifest. In an Expo project both files are generated from the app config, so you set them there once and they land in the build.

Google, request location permissions, read 14 October 2026

What breaks when you open the fifth branch?

Not the picker. What breaks is everything that quietly assumed one of something. One phone number on the contact screen. One set of opening hours in the footer. One notification audience, so a message about a closure in one town reaches four towns. One rota. One till. The fifth branch is also where a chain stops being a list and starts needing a search field, a map or a sort by distance, because scrolling five is fine and scrolling fifteen is not.

Loyalty is a decision rather than a field, and it is better made early. One balance across every branch means one customer row and a transaction log with a location on each line. A balance per branch means a customer and location row, and a conversation with everyone who walks into the wrong shop expecting their points. Most small chains want the shared balance: earned anywhere, spent anywhere, counted at the branch for the reporting. If you are adding a loyalty card app on top of a multi branch booking app, settle that before the artwork gets printed.

Deposits and no show fees come with a store question attached, and the answer is good news. Rule 3.1.3(e) of Apple's App Store Review Guidelines, headed Goods and Services Outside of the App and read on 14 October 2026, says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. A haircut at your second branch is consumed outside the app, so the deposit goes through an ordinary card payment and Apple's commission does not apply to it. That stops being true the moment you also sell something digital in the same app, a members only video library for instance, so check the rate before you add one.

Then the unglamorous half. A branch manager should see their branch and not the others, which means permissions on the staff and location row rather than one admin flag. Reporting has to work per branch and in total, and those two numbers get compared in every management meeting you will ever sit in. Refunds follow the branch that took the money. And a closed shop must not look like a broken app: an explicit closed today state on the location row reads far better than an empty list of slots with no explanation.