An audio tour guide app is a trigger problem with a soundtrack.
Recording the narration is the easy part. The hard part of an audio tour guide app is everything around the audio: what starts a track, what happens when somebody walks the route backwards, and whether the phone keeps talking once it goes back in a pocket. A self guided tour app that gets those three wrong is a folder of MP3 files with a map on top. Planning the route has a lot in common with travel itinerary apps. Delivering it is a different build.
This page covers the trigger budget iOS actually gives you, the single configuration key that decides whether audio survives a locked screen, what a museum audio guide app has to assume about signal, and what one stop has to hold beyond a file name.
See how many triggers fitThe short version
The recording is the cheap part, the trigger is the whole design.
Three constraints decide whether a tour works in the building rather than on the desk. How many stops the phone can watch at once, whether the audio keeps playing when the screen locks, and what the app still knows when there is no signal. All three are set by the platform, not by how good the script is.
Get them settled before you write a word of narration. Every one of them changes the shape of the tour itself: how many stops it has, how they are grouped, and what the visitor is asked to do at each one.
You get twenty automatic triggers on iOS, not forty
Most people plan the stops first and meet the ceiling later. Core Location does not let a single app watch more than 20 locations at once, of any type, so that is the budget for the whole app rather than for one tour. A 35 stop walking tour app cannot arm every stop at the same time, and no amount of code moves that number.
What you get in exchange is worth having. The system does the watching, so your app is not draining the battery with its own location loop, and iOS wakes the app when a location changes between satisfied and unsatisfied. If the app is not running at all, iOS tries to launch it. That is what makes a track start while the phone is still in a pocket. Google's geofencing documentation sets the Android limit far higher, at 100 geofences per app per device user, so a long tour can work on an Android phone and quietly fail on an iPhone if nobody tested the full version.
The way through is a moving window. Arm the next few stops, drop the ones behind the visitor, register the next set as they walk. For a museum audio guide app spread over four floors, arm one floor. Then keep a manual route in as well: a number on the label the visitor types, a QR code, a plain list they can tap. Automatic triggers are the delight, and a tour that only works when they fire is a tour that fails in the one room with the thickest walls.
Apple, monitoring the user's proximity to geographic regions
Try it
How many stops can arm themselves at once
iOS lets one app watch 20 locations at a time. Split the route into zones and arm one zone at a time.
28 armed at once
That is over the iOS budget of 20. Split the route into at least 2 zones, or give the extra stops a number the visitor can type. Android allows more, so test the long version on an iPhone rather than on whichever phone is in your pocket.
Audio that keeps playing with the screen locked
The next thing that decides whether the app feels finished is what happens when the screen locks. Somebody listening to an eight minute stop will put the phone away and look at the thing you are describing. That is the behaviour you want. By default, iOS suspends an app that goes to the background, and the audio stops with it.
The switch is one entry in the app's Info.plist. Apple's property list reference documents UIBackgroundModes as the key for services that need an app to keep running in the background, and audio is the value for playback. Two things have to be true, not one: the key has to be declared, and the audio session has to be set to keep playing while the app is in the background. Declaring the key for something else is a review problem rather than a clever trick. App Store review guideline 2.5.4 says multitasking apps may only use background services for their intended purposes, and lists audio playback among them. A tour that plays audio is squarely the intended purpose. Using the audio mode to keep a location loop alive is not.
On Newly the honest answer is that a new project does not set it. The starting app configuration carries no UIBackgroundModes entry, so a build nobody has asked to change will go quiet when the screen locks. Adding it is one line in the app configuration and you can ask for it in plain English, but ask explicitly, look at the configuration before you ship, and expect the next preview to take longer, because changing native configuration means the project has to be rebuilt rather than reusing the shared preview build.
Signal is the thing you cannot assume
Plan for no connection, because the interesting places rarely have one. Basements, stone churches, lift lobbies, the bottom of a valley, a car park at the trailhead. A museum audio guide app that streams is a museum audio guide app that stops halfway through the room everyone came to see.
So the tour downloads before it starts, on wifi, as one deliberate action the visitor can see finish. Budget the size honestly rather than optimistically. A three minute track at 128 kbps is about 2.8 MB, so a 25 stop tour is roughly 70 MB of audio before images or offline map tiles. That is a real download on a hotel connection, which is an argument for splitting a long tour into parts and letting people fetch one part at a time.
The same first question shows up in anything built for people who are outdoors and out of range, which is why a campground locator app starts in the same place: what does this still know when the network is gone. Decide what the offline copy holds, when it refreshes, and what the screen says while a track has not arrived yet.
A stop is a place with a track, a transcript and a radius
A stop is not a file. It is a record, and the fields are boring in a useful way: coordinates, a trigger radius, a position in the route, the track, its duration, a transcript, a still image and the language. Then add the two that always get forgotten. What plays when somebody arrives from the wrong direction, and what plays when they are standing between two stops.
The transcript is not an optional extra. It is the version that works for a visitor who is deaf or hard of hearing, the version that works in a loud hall, and the text that a search box can actually search. Store it as text beside the track rather than as words baked into a picture.
Structurally this is the same data as any app that puts places on a map, including a store locator app for shopify: a list of points with attributes attached. The difference is that every row owns a media file, and the app has to know whether that file is on the device yet, which is one extra state on every row.
Then log what happened. Which stops played to the end, which were skipped, where people stopped walking altogether. A tour is content, and content gets edited. Without those counts the second version of the tour is guesswork, and the stop everybody skips stays in the route forever.
What each way of running a tour gives a visitor
| Option | Works with no signal | Plays with the screen locked | Starts itself at the stop | You keep the recordings and the data |
|---|---|---|---|---|
| Rented handset from the desk | Yes | no screen to lock | visitor types the number | the hardware vendor holds both |
| QR codes to a web page | No | browser dependent | No | you hold the files |
| A podcast episode people download | Yes | Yes | No | the podcast app holds the data |
| A tour on a shared tour platform | if downloaded first | Yes | depends on the platform | the platform holds the data |
| A tour app you build | if you download it first | with the background mode set | within the trigger budget | Yes |
Building one for your own route
Shared tour platforms exist and they are a sensible answer when your tour looks like everyone else's: a linear route, one language, a cut of the ticket price, and a visitor who downloads an app with somebody else's name on it. What they tend not to do is the specific thing your site needs. A stop that only exists during summer opening. A route that changes when the east wing closes. A children's version with different tracks at the same points. Whether the audio keeps playing on the walk between two stops.
Newly is an AI app builder. You describe the app, including the rules your route actually has, and it writes a real React Native and Expo project you own, runs it on a cloud simulator while it builds, and ships it to TestFlight and to Google Play internal testing. Plans start at $25 a month and there is no free plan. It does not come with a media library, a content management system or licensed map data, and the iOS side still needs your own Apple Developer account.
Before you design a single screen, settle what the app does with nothing to connect to. Start with the place your visitors will find first, which is a basement gallery with no signal, and work back from there to what gets downloaded, what gets cached and what simply is not available.
Questions people ask about audio tour guide apps
It is an app that plays a recorded commentary tied to places: rooms in a museum, points on a walking route, stops on a trail. The audio is the visible part. The work is in what starts each track, whether the phone keeps playing when it is put away, and whether the whole thing still runs with no signal.
Write the route down before you write the script
List the stops, mark which ones have to start by themselves, decide what the visitor downloads before setting off, and build the tour around those answers.
Start building