How long should a waitlist claim window be?

Short enough that the slot still gets filled, long enough that a person at work can answer. The number that matters is not the window, it is the gap between now and the slot. A cancellation for tomorrow afternoon can carry a two hour window. A cancellation for this evening cannot, because a two hour window spends the whole evening. Set the window as a fraction of the notice you have, put the actual deadline time in the message rather than a countdown, and expire it with a scheduled job rather than a check that only runs when somebody opens the app.

Does a waitlist notification count as marketing under Apple's rules?

Apple does not use that split. The word transactional does not appear in the App Review Guidelines at all, so there is no exempt category to claim. 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 via consent language displayed in your app's UI, and you provide a method in the app to opt out. It is a purpose test. A message telling somebody a slot opened, sent because they asked to be told when a slot opened, is neither a promotion nor direct marketing. Add an offer to the same message and it is, and then the consent language and the opt out both apply.

Can a waitlist work if the customer declined notifications?

It has to. Guideline 4.5.4 also says push notifications must not be required for the app to function. Apple's own guide to asking permission explains why that is a practical problem too: the first time your app calls requestAuthorization the system prompts the person and records the answer, and subsequent requests do not prompt them. You get one prompt. Ask it when somebody taps join the waitlist, not on first launch. Collect an email address or a phone number at the same time, and show the queue position, the offer and its deadline on a screen inside the app so the feature still works for somebody who said no.

Should I notify everyone on the waitlist or one at a time?

Notifying everybody fills the slot fastest and costs you the most goodwill, because one person wins and the rest were interrupted for nothing. It also needs a lock on the booking, or two people claim the same slot and you have an overbooking to apologise for. Going one at a time is fair and slow, and it only works if the offer actually expires on time. A reasonable middle: one at a time when the slot is days away, everybody at once when it is tonight and an empty chair costs more than a few annoyed people.

Why do waitlists stop working after a few months?

Because nobody built the closing half. Three things rot. Offers that expire but never move to the next person, because expiry was a check that ran when the app opened. People who booked somewhere else and stayed on the list, so your first in line is unreachable. And requests for dates that have already passed, which make the list longer every week and the top of it useless. All three are one scheduled job: expire offers, remove bookings that happened, and drop requests whose date is gone.

Articles · GuidesUpdated October 2026

A waitlist is not a list. It is a rule about who gets the slot, and how long they have to take it.

Q: Can I charge a deposit to hold a waitlist place?

Yes, and it must not go through in-app purchase. App Review Guideline 3.1.3(e), 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, a class, a court and a table are all consumed outside the app. The wording is must, not may. The exception runs the other way: a paid priority tier that only unlocks something inside your app is covered by 3.1.1 and does need in-app purchase.

A booking waitlist is the people who want a slot that is already taken, plus four rules: what each person is waiting for, what counts as a slot opening, who gets offered it first, and how long they have to say yes before the offer moves on. The fourth rule is the one people skip, and it is the one that decides whether the slot gets filled. Build the first three and you have a list you read at the end of the day and work through by phone.

Two of the rules on this page are not yours to set. Apple's App Review Guidelines put conditions on push notifications used for promotion, and they say push cannot be required for your app to work. And a deposit for an appointment that happens in the real world must not go through in-app purchase. Both are quoted below, word for word, from the guidelines as they read on 14 October 2026.

What follows is what a waitlist has to store, what has to happen in the minute after a cancellation, the three ways to offer the freed slot and what each one costs you, and where the money sits. The short version: the hard part is never the list.

Start here

The short version

Four rules, and the claim window decides the other three.

Write the four down before you write any code. One: what is each person waiting for, exactly. A single slot, any slot on Tuesday, any slot with Dana, a table for four. Two: what counts as a slot opening. A customer cancels, you release a no show, you add a class, somebody moves their appointment. Three: who gets offered it. The person who has waited longest, everybody at once, or one at a time down the list. Four: how long the offer stands. Fifteen minutes, two hours, until the slot starts. Pick a number and put it in the message.

Everything else follows from those four. If people can wait for any slot that day, you store a window and not a slot id, and a cancellation has to be matched against every waiting window. If you offer one at a time, you need a timer and a next in line. If you offer to everybody, you need a lock on the booking so two people cannot claim the same slot, and you need to be comfortable interrupting the people who will lose. There is no neutral choice in that list. Each one trades a filled slot against how fair the thing feels.

What does a waitlist actually have to do?

Five jobs, in order. Capture the request, with enough detail to match it later. Notice that a slot opened. Decide who to offer it to. Send the offer with a deadline inside it. Close the loop, by booking them, by moving to the next person, or by putting the slot back on general sale. Most apps that claim a waitlist have the first one and half of the second.

Noticing is the job that quietly fails, because slots do not only open inside your app. A customer cancels in the app, which is easy. You cancel for them over the phone, which is easy only if your staff screen writes to the same table the app reads. The appointment disappears because a stylist deleted it from her own calendar, which your app never hears about at all unless you wired up calendar sync. If the rota lives in a calendar and the bookings live in a database, your waitlist is only as good as the link between them.

Matching is where the complaints come from. Offer a table for two to somebody waiting for four and they will claim it anyway, then arrive with four. Offer a Thursday to somebody who wrote Tuesday only. Offer a slot that starts in ten minutes to somebody who needs an hour to get across town. Every one of those is a single field you did not collect when they joined: party size, acceptable days, minimum notice. Store the field, or take the phone call.

Closing the loop is dull, so almost nobody builds it. An offer that expires has to really expire, which means a scheduled job, not a check that happens to run when somebody opens the app. A person who books has to come off the list. A request whose date has passed has to come off the list too, or the list grows for ever and the person at the top of it wanted an appointment in March.

Check yours

What your waitlist has to store, and what it does at 9am

Tick what your waitlist has to cope with. Each one is a field you collect when somebody joins, and a rule that runs the moment a slot frees up.

Nothing ticked. A waitlist for one exact slot, one service and one member of staff is a single table and an afternoon of work. Everything above is what turns it into a feature.

Does a waitlist alert count as marketing under Apple's rules?

Apple does not use that split, so the question has a different answer than most people expect. Guideline 4.5.4 of the App Review Guidelines, read on 14 October 2026, reads in full: Push Notifications must not be required for the app to function, and should not be used to send sensitive personal or confidential information. 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's UI, and you provide a method in your app for a user to opt out from receiving such messages. Abuse of these services may result in revocation of your privileges.

The word transactional does not appear anywhere in the guidelines, so there is no exempt category to claim. What 4.5.4 sets out is a purpose test: is this message a promotion or direct marketing? A notification saying a slot has opened, sent to somebody who asked to be told when a slot opened, is neither. It is the thing they asked for. The consent language requirement does not attach to it, and you do not need a second opt in to send it.

It attaches the moment you put something extra in the message. A slot has opened at 3pm is the feature. A slot has opened at 3pm, and have you tried our new colour service, is a promotion sent to a list of people who opted into a waitlist and not into marketing. Now you need the consent language in your own UI and the opt out inside the app, and the opt out has to actually work. The cheap way to stay clean is one notification type per purpose: offers go out on their own, and anything you would describe as a campaign asks for consent separately.

The first clause of 4.5.4 is the one that changes your design. Push must not be required for the app to function. A waitlist whose only expression is a push notification fails that rule, and it fails in the street too, because a notification sent to a phone in a cinema is a notification nobody reads. A screen in the app where somebody can see that they are third in line, with the live offer and its deadline, is not a nice extra. It is the version of the feature that still works when the notification does not.

Apple, App Review Guidelines, guideline 4.5.4, read 14 October 2026

What if they never turned notifications on?

Then your waitlist runs on email, on a text message, or on them opening the app, and you should plan for that from the start, because the permission is not yours to grant. Apple's guide to asking permission describes the flow: you get the shared UNUserNotificationCenter instance and call requestAuthorization with the interaction types your app uses, such as alert, sound and badge. The first time your app makes that request, the system prompts the person to grant or deny it and records the response. Subsequent authorization requests do not prompt the person. You get one prompt, once.

That makes the timing of the ask a product decision rather than a technical one. Asking on first launch, before anybody has a reason to say yes, spends the one prompt on a stranger. Asking the moment somebody taps join the waitlist spends it on a person who has just told you they want to be interrupted. Apple also documents provisional authorization, requested by adding the provisional option, which grants authorization automatically on the first call but delivers quietly: those notifications do not interrupt with a sound or a banner and do not appear on the lock screen, they only show up in the notification centre history until the person keeps or turns off notifications. Quiet is the wrong setting for a fifteen minute claim window.

A yes is not permanent either. The same guide says people can change your app's authorization settings at any time, and can change the types of interaction your app is allowed. Somebody who agreed in March can be sending your offers into a scheduled summary by May. For an offer with a deadline, Apple's UserNotifications reference describes the Time Sensitive interruption level as presenting the notification immediately and breaking through system controls such as Notification Summary and Focus, and says in the same place that the user can turn that ability off. Use it for claim windows and nothing else, and keep the second channel anyway.

Two cheap habits cover the whole gap. Collect an email address or a phone number when somebody joins the list, and tell them which one you will use. And write the deadline into the message as a clock time rather than a countdown, because an offer read forty minutes late should tell a person they have missed it instead of letting them find out at your door.

Apple, asking permission to use notifications, read 14 October 2026

Should you take money to hold a place?

A deposit is the one thing that reliably makes a waitlist offer get answered, and it comes with a rule worth getting right first time. App Review Guideline 3.1.3(e), goods and services outside of the app, read on 14 October 2026: 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, a class, a court and a table are all consumed outside the app. The deposit must not go through in-app purchase. Must, not may.

That is better for your margin than people assume, and the opposite rule sits on the same page. Guideline 3.1.1 says that if you want to unlock features or functionality within your app, you must use in-app purchase. A paid priority tier that exists only inside your app, jump the queue for a monthly fee, is an app feature and not a real world service, so it lands on the in-app purchase side with Apple's cut on top. Read what Apple's commission costs before you price a tier like that, and decide where a waitlist belongs in your app monetisation rather than bolting a fee onto it a year later.

The mechanics worth copying from people who do this every day. Authorise the card rather than charging it, so claiming the slot is a capture and an expired offer is a release. Write the refund rule in the same sentence as the amount, at the moment they join, in words a person could repeat back to you. Take the deposit when they claim a slot and not when they join the list, or you are holding money from people who were never offered anything. And keep the number small enough to be a nudge. The point is an answered notification, not revenue.

One more thing that is a policy question and not a technical one. Decide what a no show on a claimed waitlist slot costs, and decide it before the first one happens. A person who claimed a slot at nine minutes past and never arrived has cost you more than an empty chair, because the next three people on the list were told it was gone. Whatever you charge for that, it has to be the same number you showed them when they claimed it.

Apple, App Review Guidelines, guidelines 3.1.1 and 3.1.3(e), read 14 October 2026

The three ways to offer a freed slot, side by side

The question	First in line	Everybody at once	One at a time, on a timer
Who hears about the freed slot	The person who has waited longest	Everybody on the list at once	One person, then the next, then the next
Fills the slot fastest	No	Yes	No
Needs a claim window with a real deadline	Yes	No	Yes
Two people can claim the same slot	No	Yes	No
Feels fair to the person who waited longest	Yes	No	Yes
Where it goes wrong	The slot sits unclaimed while one window runs down	One winner, and everybody else got interrupted for nothing	Too slow if the window is long and the slot is tonight

Where this lands if a builder generated your app

None of the rules change because an AI wrote the code. You still pick the claim window, you still answer for what the notification says, and on iOS you are the one who presses submit. App Review 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's content. Read on 14 October 2026. So a tool can write the waitlist, and the person whose shop it is signs it off.

Newly is an AI app builder. You describe the app in plain English and it writes a real React Native and Expo project that you own, so the waitlist table and the expiry job are code you can read and change. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, builds a standalone Android APK, and syncs both ways with GitHub. It is $25 a month, with no free tier. It does not submit to the App Store for you, because of the guideline above.

The four rules carry straight across to anything with a fixed capacity. In a gym membership app the capacity is a hard number per class, so one leaver is exactly one offer and the count has to come from the bookings table. The honest limit: no builder can tell you how long your claim window should be, or what a no show costs you. Those two numbers come from your own diary, and everything else on this page is downstream of them.

Questions people ask about booking waitlists

It is a booking app with one extra list: the people who want a slot that is already taken. The list is the easy part. The app also has to know what each person is waiting for, notice when a slot frees up, decide who gets offered it, give them a deadline to claim it, and move on when they do not. Those five jobs are the feature. A list with no deadline and no next in line is a note you read at the end of the day and act on by hand.

Describe the waitlist, then decide the window

Write down the four rules first: what people wait for, what counts as a slot opening, who hears about it, and how long they have. A waitlist built from those four fills chairs. One built from a list and a hope is a phone call you make every evening.

Start building