The next appointment gets booked in the ten seconds after the card clears, or it does not.
A rebooking prompt is one screen your app shows the moment a visit is paid for, offering the next appointment with the service, the staff member, the location and the usual gap already filled in. The customer taps a date or taps not now. That is the whole feature. It works because they are standing in front of you with their phone already open, and it stops working the second they are back on the street. Apple's own advice on end of flow prompts points the same way: make the request at a time that does not interrupt what someone is trying to achieve in your app, for example at the end of a sequence of events that they successfully complete. Read on 14 October 2026. Most people meet this while building a booking app for business.
What follows is where the prompt sits in the checkout sequence, what it has to know before it appears, whether it can share a screen with an App Store review request, and the notification rule that decides whether you may chase a not now. Then the one case where the next booking has to be paid for through the store instead of on a card.
Start hereThe short version
One screen, one date, already chosen.
A rebooking prompt is not a booking flow. A booking flow asks for four decisions: a service, a person, a date and a time. A rebooking prompt makes all four from the visit that has just finished and asks the customer to accept or decline. If tapping your prompt opens a calendar, you have built a second booking flow and the answer rate will tell you so.
Order matters as much as content. Take the money, confirm the money, then ask. Anything that sits between the card and the receipt reads as a surprise charge, and a customer who is not sure whether they have paid will not commit to a date six weeks out. Two store rules sit close enough to touch this screen, and neither one is about rebooking. One governs review requests. The other governs the notification you send when somebody says not now.
Where in a checkout flow does the rebooking prompt belong?
After a successful charge, on the confirmation screen, under the receipt. Not before authorisation, not as a sheet over a payment that is still spinning, and not on the card entry screen as a tickbox. The sequence that works is short: authorise, confirm, ask. Three screens or three blocks on one screen, in that order, and the ask is the only one with a decision in it.
Apple's guidance on end of flow prompts is written about review requests, but the reasoning transfers exactly. Make the request at a time that does not interrupt what someone is trying to achieve, for example at the end of a sequence of events that they successfully complete. Avoid showing it immediately when a user launches your app, even if it is not the first launch. A rebooking prompt on cold start is the same mistake with a different payload: the customer opened the app to check their next appointment, and you asked them to make one.
The failure case is the one people skip. If the charge fails and you have already written a future booking, you are holding a slot against nothing, and you have two records to unpick instead of one. Create the next booking only once the payment and the visit it belongs to are both settled. Keep the prompt stateless until the tap lands, so closing the app mid-decision leaves no half-made appointment behind.
Then there is cash. Plenty of visits are paid at the counter, by card machine or in notes, and the app sees no charge at all. If your prompt only fires on a successful in-app payment, every one of those customers walks out unasked. Give it a second trigger: a staff member marking the visit complete. In a salon booking app that is usually the stylist tapping done on the chair, and the prompt then arrives on the customer phone as a notification rather than as a screen. Same content, different doorway, and the notification rules below start to apply.
One more rule of placement. Ask once per completed visit, and not again in the same session. A customer who declined four minutes ago has not changed their mind, and a prompt that reappears is the fastest way to teach somebody to dismiss your screens without reading them. Store the decline against the visit, not against the customer, so the next visit gets a fresh ask.
What should the prompt already know before it appears?
Everything it can read off the visit that just ended. The service, its length, the staff member, the location, the weekday and the hour. Those six fields are already sitting in the booking you are closing out, and every one of them you make the customer choose again is a chance for them to stop. The single best guess you have about their next appointment is the same weekday at the same hour, because it already fitted into their week once.
The gap belongs on the service, not in the prompt. A colour might want six weeks and a fringe trim three, and that is data a shop owner changes on a Tuesday afternoon without touching code. Store the interval as a field on each service, add it to the date of the visit, and let the prompt ask the calendar for the nearest two or three open slots after that. Offer those slots as buttons. A suggested date works much harder than an empty calendar, because it turns a planning task into a yes or a no.
Give it exactly one escape hatch and label it honestly. Not now is better than Maybe later, because it tells the customer what will happen, which is nothing. Three buttons is the limit: a date, another date, and no. If you want a fourth, make it See more times, and send it into the real booking flow rather than growing the prompt into one.
Do not ask for money again on this screen. The customer paid two seconds ago, and the payment method you used is the one to re-use for a deposit or for a card on file. The mechanics are the same as adding payments anywhere else in the app, with one judgement call: a rebooking deposit taken on this screen will cost you some acceptances. If your no show rate is low, take the booking and leave the deposit for the reminder a few days before.
Last, decide whether you hold the slot while they think. If you do, hold it for minutes rather than hours and put the number on the screen. If you do not, do not imply that you do, because a prompt that said your slot is reserved and then lost it to a walk-in is worse than no prompt. The safe default is no hold and an instant write on the tap, with a clear error if somebody got there first.
Plan yours
What your prompt should already know
Tick the kinds of visit you sell. Each one tells you what to carry over from the visit just finished, and which payment rail the next booking has to sit on.
Nothing ticked. If you sell only one kind of visit, one prompt covers you, and it should carry over every field the visit just finished already holds.
Can the same screen ask for an App Store review?
No, and Apple hands you the argument. Its documentation on requesting App Store reviews, read on 14 October 2026, gives three best practices. Make the request at a time that does not interrupt what someone is trying to achieve in your app, for example at the end of a sequence of events that they successfully complete. Avoid showing a request for a review immediately when a user launches your app, even if it is not the first time it launches. And the one nobody quotes: avoid requesting a review as the result of a user action. A rebooking prompt is the result of a user action. Firing a review request off the same tap is exactly what that third bullet is warning about.
There is a hard number too. Apple states that the system displays the review prompt to a user a maximum of three times within a 365-day period. Three is a ceiling, not an allowance. Apple's own sample project treats it as a thing to ration: it only prompts from the completed scene, only if that bundle version has never prompted before, only after the person has finished the flow at least four times, and only if they have paused on the completion screen for a few seconds. Apple is explicit that those conditions exist purely to delay the call, so days, weeks, or even months can elapse without the app prompting a user for a review, and that this is the point, because people who have used the app more can give better feedback.
Two further things worth knowing before you build a review ask into your checkout. Apple notes that people can disable requests for reviews from ever appearing on their device, so the call can be a no-op and you will never know. And the StoreKit action is described as telling the system to request a rating or review if appropriate, so the system, not your code, decides whether a sheet appears. That makes any logic of the form ask for a review, then show the rebooking prompt unsafe. You cannot know whether anything happened.
So split them. Rebooking lives at checkout, every visit. A review request lives weeks away, on a customer who has come back twice, and fires once in that app version. If somebody actually wants to leave a review now, Apple's sample shows the honest route: deep link to your App Store page with the query parameter action=write-review appended. That is customer initiated, it is not the system prompt, and it does not spend one of your three.
Does a reminder to rebook count as a marketing notification?
If it is pushing somebody towards a booking they have not made, yes, and the guideline is specific. App Store Review Guideline 4.5.4, read on 14 October 2026, says push notifications should not be used for promotions or direct marketing purposes unless customers have explicitly opted in to receive them via consent language displayed in your app user interface, and that you provide a method in your app for a user to opt out from receiving such messages. The same guideline adds that push notifications must not be required for the app to function, so a booking app that will not work until somebody allows notifications is already in trouble.
The line is easier to hold than it looks. A reminder about an appointment the customer already holds is service: you are telling them about a commitment they made. A nudge to create one they have not made is marketing. Build them as two separate switches in settings, worded in plain language, and show the consent text in your own screen before you ever reach for the system permission sheet. The system sheet asks about notifications in general, which is not the same thing as consent to be sold to, so leaning on it is the mistake that gets a reviewer reading your settings screen.
Incentives have their own rule, and it is sharper than most people expect. Guideline 3.2.2(x) says apps must not force users to rate the app, review the app, download other apps, or other store-related actions in order to access functionality, content, or use of the app. It then allows the opposite direction: apps may otherwise incentivize users to take specific actions within apps. So ten per cent off the next appointment for booking it today is an in-app action and it is fine. Ten per cent off in exchange for five stars is a store action behind a reward, and it is not.
Practically, that gives the decline path a shape. A customer who taps not now gets nothing unless they are on your marketing switch. If they are, one message, timed off the service interval rather than off the day they declined, so a six week service gets a nudge in week five. Keep it to one, give the opt-out in the message as well as in settings, and treat a second decline as a standing no.
The payment rail changes when the next booking is a class
A rebooking prompt is a payment decision as well as a calendar one, and the store rule is a prohibition rather than a favour. Guideline 3.1.3(e), headed Goods and Services Outside of the App, 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. Read that twice. In-app purchase is not something you are being let off for a haircut. It is closed to you.
The clause next door is the one that catches people, because it splits appointments from classes. Guideline 3.1.3(d), Person-to-Person Services, allows purchase methods other than in-app purchase where the app enables the purchase of real-time person-to-person services between two individuals, and Apple names tutoring students, medical consultations, real estate tours and fitness training. Then it closes the door: one-to-few and one-to-many real-time services must use in-app purchase. So a single video consultation can take a card, and the same trainer teaching eight people live through your app cannot.
Put those together and a rebooking prompt has two shapes. For a visit in the world, a chair, a room, a doorstep, it is consumed outside the app and the next booking takes a card. For a class delivered live inside the app to several people at once, the next booking has to open a store purchase, and your prompt is launching a store sheet rather than a payment sheet. A timetable can contain both. If you are building a class schedule app, mark each class as in person or streamed before you write the prompt, because the two cannot share a button.
One correction worth printing, because it has sent people down the wrong path. Guideline 3.1.5 is Cryptocurrencies, not real world services. If a checklist or a forum post points you there for the rule about appointments, the checklist is wrong. The clauses you want are 3.1.3(d) and 3.1.3(e), and both were read on 14 October 2026. The guidelines describe themselves as a living document, so check them again before you ship rather than trusting a quote from a page like this one.
Five places to put the ask, and what each one can actually do
| The spot | When it fires | What it can pre-fill | Needs explicit opt-in |
|---|---|---|---|
| The confirmation screen | The second the charge clears | Service, staff, location, the same weekday and hour | No |
| The receipt, inside the app | Same visit, one tap later | Everything the confirmation screen can | No |
| A push a few days later | Whenever you schedule it | Service and staff, but not what their week looks like now | Yes |
| The next time they open the app | Only if they come back on their own | Service and staff, plus anything booked since | No |
| An email receipt | Minutes after the visit | A link that carries the service and the staff member | Marketing consent rules, not Apple's |
Only the first two need no permission from anybody, which is most of the reason the confirmation screen wins. The push row is the one with a store rule attached. The email row is governed by marketing law in your country rather than by Apple, which is a different conversation and usually a stricter one.
Measure it as a rate, not a count. Future bookings created by the prompt, divided by the visits where the prompt was actually shown. Log the shown event separately from the accepted one, because otherwise a bug that stops the prompt appearing looks identical to customers losing interest. Count the declines too. A prompt that nobody declines is usually a prompt that nobody sees.
Where this lands if a builder generated your app
Nothing in the rules above changes because an AI wrote the screen. You still choose the trigger, you still own the consent wording, and on iOS you are the one who presses submit. Guideline 4.2.6 is why: apps created from a commercialized template or app generation service will be rejected unless they are submitted directly by the provider of the app content. Reviewers read the settings screen and the notification copy, so the two switches and the opt-out are your work, not the builder's.
Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project you own, with two-way GitHub sync, so the prompt is a component you can open and change rather than a setting in somebody else's dashboard. It uploads iOS builds to TestFlight, publishes to Google Play internal testing and builds a standalone Android APK. It does not submit to the App Store for you, because 4.2.6 requires the content owner to do that. It is $25 a month and there is no free tier.
The practical ask for a builder is short. Put the interval on the service record, fire the prompt on both a successful payment and a staff completion, write the booking only after both are settled, and keep the marketing notification behind its own switch. Say those four things in the prompt you give the agent and you will get a screen that passes review. The honest limit is that no builder can decide your intervals or your tone for you, because those come from knowing how often your customers actually come back.
Questions people ask about rebooking at checkout
It is a single screen your app shows once a visit is paid for, offering the next appointment with the service, the staff member, the location and the usual gap already filled in. The customer accepts a date or declines. It is not a booking flow. A booking flow asks for four decisions, a service, a person, a date and a time. A rebooking prompt makes all four from the visit that just finished and asks for one tap. That difference is the whole reason it works, because the customer is standing in front of you with their phone already open.
Describe the visit, then ask for the next one
Put the interval on the service, the prompt on the confirmation screen, and the review request on a different week. That is a day of work and it changes how full next month looks.
Start building