Designing apps for museums, city tours and walking routes

Picture the person using a walking route app. They stand at the start of a trail with one bar of signal, a phone at 40 percent and a language setting from another country. A museum visitor is in a basement gallery with no signal at all, earbuds in, phone locked in a pocket. Those two scenes are the brief, and most of the decisions in a tourism or museum app follow from designing for them.

This guide covers the choices that matter most for route, city tour and museum apps: offline content, location triggers, beacons, audio, languages, accessibility, and what visitors pay for data abroad.

Contains affiliate links. As an Amazon Associate I earn from qualifying purchases.

Assume the signal is gone

Treat connectivity as a bonus. Old city centers with thick walls, river valleys, coastlines and museum basements all swallow signal, and a tour that stalls at the fourth stop is remembered for exactly that. Package each route as a download: map tiles for the area, the text, images and audio for every stop, and the route line itself. Offer the download at the hotel or in the museum lobby, show its size before it starts, and confirm clearly when it has finished.

Check the license before you package maps. Many commercial map SDKs limit what you may store on the device. OpenStreetMap data is published under the Open Database License, which allows offline use but requires attribution, so plan a visible credit on the map screen. Our guide to designing for the disconnected user covers local storage and sync in more depth.

Location triggers without a flat battery

Automatic triggers that offer the next story as you reach the windmill feel like magic when they work. Both platforms put hard limits on them, and the documentation is candid about it.

On Android, the geofencing API allows up to 100 active geofences per app per device user, and Google recommends a minimum radius of 100 meters. Alerts are not instant: Android's geofencing guide says latency is usually under two minutes, and up to six when the device has been stationary for a while. The geofence service depends on the network location provider, so without a reliable data connection alerts might not arrive at all. Apps that target Android 10 or higher also need background location permission for geofencing.

On iOS, Core Location lets one app monitor at most 20 conditions at a time. If the app isn't running when someone enters a region, the system relaunches it only when the person granted Always access. With When in Use access, a closed app stays closed.

A few design rules follow from those limits:

• Register only the next few stops and swap them as the visitor moves along the route.
• Never make a trigger the only way into a stop. A list of stops and a map with the visitor's position, both usable by hand, should always work.
• Use When in Use location while the app is open, and ask for background access only if the route truly depends on it, with a plain explanation at the moment it matters.
• Space trigger points well apart. Two stops 30 meters apart on a narrow street will fire in the wrong order.

Beacons indoors

GPS is weak inside buildings, so museums that want automatic triggers usually turn to Bluetooth Low Energy beacons: small battery-powered transmitters mounted in each room. They work, but they are hardware, with everything that implies. Batteries run down, a beacon behind a display case gets moved during a rehang, and somebody has to own the inventory.

On Android 12 and higher, scanning needs the BLUETOOTH_SCAN permission, and an app that uses scan results to work out a physical location must also hold fine location permission. Android's documentation warns that if you declare that your app never derives location from Bluetooth, using the neverForLocation flag, some beacons are filtered out of scan results. For a museum app that is precisely the wrong trade. Our guide to companion apps for connected devices goes further into Bluetooth permissions and pairing.

A low-tech fallback makes beacons less critical. Give every stop a short number on its label and let visitors type it in. It needs no permissions, no signal and no extra battery.

Audio guides that keep playing in a pocket

Most visitors listen with the phone locked. On iOS that means declaring the audio background mode; on Android, playing through a media session in a foreground service, so the system keeps playback alive and shows lock screen controls. Remember the playback position for each stop, pause when headphones disconnect, and keep loudness consistent across recordings so nobody reaches for the volume between rooms.

Keep stops short. We would aim for most of them under three minutes, with optional longer layers for visitors who want depth. Give every track a transcript, which also produces searchable text and a starting point for translation.

Languages: the phone may disagree with the visitor

A German visitor in Amsterdam may run their phone in English and want the tour in German, or the reverse. Offer a language choice inside the app at first launch instead of relying only on the system language. Android 13 added per-app language preferences, which helps, but an in-app picker works on every device.

Split content into a download per language, so nobody carries six languages of audio around. Recorded audio costs far more to translate than text, so many teams record two or three languages and offer screen-reader-friendly text for the rest. Test every layout with your longest language; a tidy English label can double in length elsewhere.

Accessibility on the route

Accessibility in a tourism app reaches beyond the screen. Alongside the basics (labels for every map pin and button, Dynamic Type and font scaling, strong contrast, which matters more in bright sunlight), publish the route facts people plan around: step-free sections, steep climbs, surfaces, benches, toilets and the distance between them. Offer the map's content as a list as well, since a map alone is hard to use with VoiceOver or TalkBack. Our mobile accessibility checklist covers the screen side in detail.

If the app sells tickets to consumers in the EU, look at the European Accessibility Act. It has applied since June 28, 2025 to services including e-commerce, although microenterprises that provide services are exempt.

Data costs abroad

Inside the EU and the EEA, roam like at home means visitors pay domestic prices within fair use limits, and the rules have been extended until 2032. Since January 1, 2026 they also cover Ukraine and Moldova. Visitors from the UK, the US or Asia may still pay roaming charges, so a 400 MB download over a roaming connection is a real cost to them. Set large downloads to Wi-Fi only by default, show sizes in megabytes, and keep the core route small enough to fetch over a café's Wi-Fi.

A test walk before launch

1. Download a route, turn mobile data off, and walk the whole thing.
2. Walk it again in Low Power Mode or battery saver and note how far the battery drops.
3. Lock the phone at the first stop and listen to the full route with the screen locked throughout.
4. Set the phone to a language you don't support and see what the visitor gets.
5. Complete at least three stops with VoiceOver or TalkBack turned on.
6. In the museum, check every beacon with a scanner app and log its battery level.

Questions

Does a museum app need beacons?

Not always. If rooms are distinct and visitors move in a predictable order, typed stop numbers and a good list view cover most needs without any hardware. Beacons pay off when automatic content is central to the experience and a staff member will look after them.

Should a walking tour ask for Always location access?

Only if the route relies on alerts while the app is closed, and even then ask at the first stop with a clear reason, not at launch. Most tours work well with When in Use access and a visitor who opens the app at each stop.

How large can an offline route package be?

There is no limit worth designing to, but every megabyte competes with roaming costs and free storage. Show the size, split by language, keep video optional and Wi-Fi only, and encode audio at a bitrate that sounds fine through earbuds rather than studio monitors.

Could a mobile website replace the app?

For a single exhibition, often yes: a site with offline caching can handle text, images and audio. Web pages can't register geofences, though, and background playback varies by browser, so a route with automatic triggers is still better served by an app.