Can my app detect Do Not Disturb or Focus and hold a notification?

Treat it as no, and the fix does not live there anyway. What iOS exposes to your app is its own notification settings, and two entries matter here: one says whether the system treats your notifications as time sensitive, the other whether it schedules them. Both were read on 14 October 2026. They describe your app's permissions, not whether a Focus is active right now, and you can read them but not change them. Android works the same way in spirit: Google says a person can change a channel's importance in system settings at any time, and that from Android 8.0 they can override Do Not Disturb channel by channel. So send at a reasonable local hour and let their settings do what they chose.

Which iOS notification level breaks through Focus?

Time sensitive. Apple's reference for the interruption levels, read on 14 October 2026, describes the time sensitive level as similar to active but able to break through system controls such as notification summary and Focus, and adds that the user can turn off the ability for time sensitive notification interruptions. Active, which Apple names as the default, is documented as not breaking through system notification controls. Passive adds the notification to the list without lighting up the screen or playing a sound. Critical is a separate case: it presents even when Do Not Disturb is active and bypasses the mute switch to play a sound, and Apple's page for it says plainly that the level requires an approved entitlement.

Do I need Apple's permission to send time sensitive notifications?

Apple's page for the time sensitive level, read on 14 October 2026, names no entitlement and no approval step. What it names is the off switch: the user can turn off time sensitive interruptions. Critical alerts are the opposite case. That level's page says it requires an approved entitlement, and Apple's entitlement reference describes critical alerts as an entitlement that permits an app to receive critical alert notifications, then points you at a request form to ask for it. So plan for critical alerts as a request to Apple with a reason attached, and plan for time sensitive as something you can send and the person can take away.

How do quiet hours work on Android?

Through channels, and the decision happens earlier than on iOS. Google documents that from Android 8.0 every notification must be assigned to a channel or it does not appear, that the channel is where importance is set, and that everything posted to a channel therefore behaves the same way. The importance levels run from urgent, which makes a sound and appears as a heads up notification, down through high, medium and low. Do Not Disturb itself arrived in Android 5.0 and silences sound and vibration for all notifications while still showing them in the system UI, with total silence, alarms only and priority only as its three levels. From Android 8.0 a person can let one kind through by overriding Do Not Disturb channel by channel. Read on 14 October 2026. The design consequence: give reminders, billing and offers separate channels, because Google's own guide to creating channels says the behaviours are fixed once the channel exists.

Should a booking reminder be scheduled on the device or sent from a server?

From a server, for anything a customer can move. A notification scheduled on the device fires with the phone offline and needs nothing running, which suits a fixed recurring time. The cost is that it is already sitting on the phone, so changing or cancelling it needs your app to run again. A server send stays under your control until the second it goes out, which is what you want when a booking is cancelled at 18:00 for a 09:00 appointment. Whichever you pick, one rule saves most of the support tickets: cancelling a booking cancels its reminders in the same step, not in a nightly job.

Articles · GuidesUpdated October 2026

Quiet hours are two systems, and your app only owns one of them.

Q: What time should a booking reminder go out?

In the customer's local time, computed from a stored time zone identifier rather than a saved offset, and clamped into your window rather than dropped. A 24 hour reminder for a 09:00 appointment lands at 09:00 the day before and needs no special handling. A two hour reminder for a 07:00 appointment lands at 05:00, so move it to the evening before and change the wording, because tomorrow at 07:00 reads correctly at 20:00 and in two hours does not. One confirmation and one reminder cover a single appointment. Add a second only if your no show rate says it earns its place.

Quiet hours for notifications means two things that get mixed up. The first is a send window you build: a rule in your own scheduler that stops a booking reminder firing at 03:00 in the customer's city. The second is the set of controls on the phone, Do Not Disturb, the other Focus modes, the notification summary, which the person owns and your app cannot switch off. You build the first one. For the second you get exactly one lever, and on iOS it is the interruption level on each notification while on Android it is which channel you posted to. Every API name and piece of wording below was read on 14 October 2026.

What follows is where each control actually lives, which level Apple documents as breaking through Focus and what using it costs you, how to pick a send time that survives time zones, and the mapping from the things a booking app really sends to the level each one deserves.

Start here

The short version

Your scheduler decides 03:00. The phone decides the sound.

Two sentences cover most of this. If a notification arrives at an hour that annoys somebody, that is almost always your scheduler and not their settings. If a notification arrives silently, or turns up hours later in a batch, that is almost always their settings and not your code.

So the work splits cleanly. The send window is yours: store the customer's time zone when they book, compute the send time in that zone, and clamp anything that falls inside the window to the edge of it rather than dropping it. The delivery style is theirs: both platforms let a person silence, batch or filter what you send, and neither lets your app undo that.

What both platforms do give you is a way to say how urgent one message is. They then decide what that earns. Spending that urgency on an offer is how an app loses it for the reminder that actually mattered.

What do quiet hours mean inside an app?

The first system is your own send window. It is a rule in whatever schedules your messages: do not deliver between these two local hours. Nothing on the phone does this for you. If you send a reminder at 03:00 in the customer's city, it arrives at 03:00, and the only reason it might not make a sound is that the person happened to have Do Not Disturb switched on that night.

The second system is the phone's own controls, and they are older and broader than most people building a first app expect. Google documents Do Not Disturb as arriving in Android 5.0, silencing sound and vibration for all notifications while still showing them in the system UI, with three levels: total silence, alarms only, and priority only. On iOS the same job is spread across Do Not Disturb, the other Focus modes, and the scheduled summary, which holds notifications back and delivers them in batches at times the person picked.

The lever you get differs by platform, and this is the part worth learning once. On iOS urgency is a property of each notification, so the same app can send a quiet one and an urgent one a minute apart. On Android urgency belongs to the channel. Google says every notification must be assigned to a channel from Android 8.0 or it does not appear, that the channel is where you set importance, and that everything posted to the same channel therefore behaves the same way. The system settings call channels categories, which is worth knowing when you write your own help text.

That turns the Android design question into something you answer before you build: how many channels does this app need? A booking app wants at least three. Appointment reminders, account and billing, and offers. Split that way, a customer can mute your marketing without muting the reminder that stops them missing an appointment. Put everything on one channel and their only option is to switch you off entirely. If you are still deciding features with a booking app builder, settle it early, because Google's guide to creating channels says the behaviours are fixed once a channel exists and the person controls them from then on.

Google, about notifications on Android, read 14 October 2026

Pick one

What are you about to send?

The level and the channel are platform decisions. The hour is yours. These are the usual answers for a booking or service app, not a ruling.

Booking confirmed, seconds after they tap

iOS level: Active, the default level

Android channel: Reminders channel, high importance

When it goes: Now. It answers something they just did, so the window does not apply. If they booked at 02:00 they are awake.

Every row here assumes the send time is computed in the customer's time zone, not yours.

Which notifications are allowed through Focus and Do Not Disturb?

On iOS it comes down to one property, and Apple's documentation is precise about it. The interruption levels are passive, active, time sensitive and critical, and each gets a sentence in the reference. Passive adds the notification to the list without lighting up the screen or playing a sound. Active presents it immediately, lights up the screen and can play a sound, and Apple adds that active is the default level and that active notifications will not break through system notification controls. Time sensitive is the one that does: Apple describes it as similar to active but able to break through system controls such as notification summary and Focus, and says the user can turn off the ability for time sensitive notification interruptions.

Read that last sentence twice, because it decides your design. Time sensitive is a request, not a guarantee. The person can switch it off, and once they have, it is off for everything you send and not just the message that annoyed them. That is the real price of spending it on a marketing push: you do not lose one notification, you lose the setting.

Critical is not a stronger version of time sensitive. It is a different thing with a gate in front of it. Apple's page says the level presents the notification immediately, bypasses the mute switch to play a sound, always presents even when Do Not Disturb is active, and requires an approved entitlement. Apple's entitlement reference describes critical alerts as an entitlement that permits an app to receive critical alert notifications, and points you at a request form to ask for it. If your app wakes a sleeping person because a medical device stopped reporting, that is a conversation worth having with Apple. A 07:00 haircut is not.

Android answers the same question from the other end. Google says that from Android 8.0 people can allow notifications through for app specific categories by overriding Do Not Disturb channel by channel, and uses a payment app with separate withdrawal and deposit channels as its example. Google also says that to configure your notifications for these settings you must set a system wide category on them. Your app does not assert urgency past Do Not Disturb. You give the person a channel narrow enough to be worth letting through, and they decide. The delivery mechanics underneath all of this, tokens, payloads, and what happens when the app is closed, sit in push notifications.

Apple, the time sensitive interruption level, read 14 October 2026

How do you schedule a reminder so it lands inside the window?

Start by noticing what the platform documentation does not cover. Nothing in Apple's interruption level reference says anything about when a notification is sent. The levels describe how one is presented once it has arrived. Scheduled notification delivery is entirely yours, which is why every quiet hours bug traces back to your own code.

Three rules cover the timing. First, store a time zone identifier and not an offset, on the thing the reminder belongs to. A booking at a salon in Lisbon is a Lisbon booking whether the customer is in Lisbon or Dallas when the phone buzzes. An offset you saved in March is wrong in November, and the phone's own zone is the wrong answer for an appointment somebody has to physically attend.

Second, compute the send time and then clamp it. A 24 hour reminder for a 09:00 appointment lands at 09:00 the day before, which is fine. A two hour reminder for a 07:00 appointment lands at 05:00, which is inside everyone's quiet hours. The tempting fix is to drop it. Do not: a missed reminder is a missed appointment, and a missed appointment is the only reason the reminder exists. Move it to the edge of the window, the evening before, and rewrite the sentence so it still makes sense. Tomorrow at 07:00 reads correctly at 20:00. In two hours does not.

Third, decide where the reminder is scheduled from, because the trade is real. A notification scheduled on the device needs no server and fires with the phone offline, which suits recurring things at a fixed time. The cost is that it is already sitting on the phone, so you cannot change or cancel it from your side without the app running again. A notification sent from a server stays under your control until the second it goes out, which is what you want the moment a booking is cancelled at 18:00 for a 09:00 appointment. For anything customers move, server side wins.

Then one rule that outranks all of the above, because it causes more complaints than bad timing ever will: cancelling a booking cancels its reminders, in the same step, before anything else happens. Not in a nightly cleanup job. A customer who cancels and then gets reminded has learned that your app does not know what it is doing, and no send window repairs that. The same goes for a rescheduled appointment: move the booking, delete the old reminder, create the new one, all together or not at all.

Apple, the time sensitive interruption level, read 14 October 2026

What should a booking app send, and at what level?

Sort everything you send into three buckets and most of the decisions make themselves. Bucket one: things that answer an action the person just took. A booking confirmation, a payment receipt, a cancellation they asked for. These go out immediately, at the default level, and the window does not apply to them. Nobody books a table at 02:00 and then resents the confirmation at 02:00. If they did it, they are awake.

Bucket two: things with a deadline the person did not choose. A waitlist slot that expires in fifteen minutes. A class starting in an hour that they are signed up for. Tonight's shift changing for a member of staff. This is the only bucket with a real claim on time sensitive, and the test is one question: is this worthless an hour from now? If waiting until morning costs the person nothing, it is not time sensitive, whatever your open rates say.

Bucket three: everything else. Reminders, offers, news, points. These go inside the window, at the default level on iOS, on a channel the person can mute on Android. Double points this weekend is a passive notification at best. If you run a loyalty card app alongside the booking side, keep the two on separate channels, because a customer who mutes your offers is not asking to miss their next appointment.

Billing sits awkwardly across two buckets, so it is worth calling out. A declined card on a membership feels urgent to you and is not urgent at 02:00 to anybody. Send it inside the window, at the default level, with a link that fixes it in two taps. Where that message even comes from depends on which payment layer to use, because a store subscription and a card you charge yourself fail in different places, and only one of them tells your own server first.

The last decision is frequency, and the honest number is lower than it feels. For a single appointment, a confirmation and one reminder cover it. Add a second reminder only if your no show rate says you need it, and send it at a different time of day rather than closer to the appointment. Three notifications for one haircut is how an app gets muted, and a muted app has no quiet hours problem at all, because it has no notifications.

Google, about notifications on Android, read 14 October 2026

The same quiet hours, owned by different people

The question	iOS	Android	Same on both
Where the person sets quiet hours	Do Not Disturb, the other Focus modes, and the scheduled summary	Do Not Disturb, with total silence, alarms only or priority only	No
Where your app says how urgent it is	On each notification, as its interruption level	On the channel, once, for everything posted to it	No
Can the next notification use a different level	Yes	Only by posting it to a different channel	No
Can the person let one kind through	Yes	Yes	Yes
Can your app turn their quiet hours off	No	No	Yes
Who decides a notification arrives at 03:00	Your scheduler	Your scheduler	Yes

Where this lands if a builder generated your app

Nothing about quiet hours changes because an agent wrote the code. The window is still a rule in your scheduler, the levels are still the platform's, and the person still owns the off switch.

Newly is an AI app builder. You describe an app in plain English and it writes a real React Native and Expo project you own. It uploads iOS builds to TestFlight, publishes to Google Play internal testing, builds a standalone Android APK, and keeps a two way GitHub sync so you can read and change what it wrote. It is $25 a month, with no free tier. It does not submit to the App Store for you, because Apple requires the content owner to submit.

The pieces you need are already in the framework that project uses. Expo's notification documentation, read on 14 October 2026, puts an interruption level on the notification content for iOS with the same four values Apple documents, keeps Android behaviour on a channel you create by name and importance, says you can modify only that channel's name and description afterwards, and schedules a notification for a given date. So ask in those terms. Three channels. A send window in the customer's time zone. Reminders cancelled with the booking.

The honest limit: a generated app will happily send a reminder at 03:00 if that is what the arithmetic works out to. Quiet hours are a decision, not a feature, and nothing reads that decision off your description unless you make it part of the description.

Questions people ask about quiet hours

Two separate things that get mixed up. The first is a send window in your own code: a rule that stops your app delivering between, say, 21:00 and 08:00 in the customer's local time. No platform does this for you, so a reminder that lands at 03:00 is your scheduler, not their settings. The second is the set of controls the person owns on their phone: Do Not Disturb and the other Focus modes and the scheduled summary on iOS, and Do Not Disturb with its total silence, alarms only and priority only levels on Android. You build the first. You cannot switch off the second, and the person can change it at any time.

Describe the app, and describe the hours

Name the channels, name the window, and name what cancels a reminder. Those three sentences are the difference between an app people keep notifications on for and an app they mute in week two.

Start building