Push Notifications for a Fitness App: Permissions and Payload

A fitness app's notification budget is decided before anyone writes a message. On both platforms the user makes one call about whether your app may interrupt them, and on Android every new install starts on the wrong side of that call. Earning the permission is a design problem; deserving it is a content problem. Teams that solve only one end up either holding a permission with nothing worth sending, or writing good messages with nobody left to send them to.

Android: POST_NOTIFICATIONS is a runtime permission#

Google's documentation states that "Android 13 (API level 33) and higher supports a runtime permission for sending non-exempt (including Foreground Services (FGS)) notifications from an app: POST_NOTIFICATIONS." That parenthetical matters for fitness specifically, because the persistent notification a foreground-service workout tracker relies on sits inside the scope of the permission rather than outside it.

For new installs, Google documents that "if a user installs your app on a device that runs Android 13 or higher, your app's notifications are off by default. Your app must wait to send notifications until after you request the new permission and the user grants that permission to your app." Nothing is delivered until the prompt is answered yes.

For device upgrades the rule is different, and it is the source of most of the confusion on this topic. Google states that "the system automatically pre-grants the permission to all eligible apps when the user upgrades their device to Android 13 or higher," where eligible means the app "must have an existing notification channel and not have its notifications explicitly disabled by the user on a device that runs 12L or lower."

Denial is the case to design around. Google's wording is blunt: "if the user selects the don't allow option, your app can't send notifications unless it qualifies for an exemption. All notification channels are blocked, except for a few specific roles." Not the channel the message came from. All of them.

Our judgement, not Google's: because of the pre-grant asymmetry, aggregate notification metrics from an established Android app describe two populations glued together. Long-tenured users who were carried through a device upgrade never saw a prompt; everyone installed since had to say yes on purpose. If you are trying to learn whether your prompt works, segment by whether the user was ever prompted at all, or you are measuring device-upgrade history instead.

iOS: authorization options, one of which does not prompt#

Apple's UNAuthorizationOptions describes what you are asking for, not merely whether you are asking. The documented options include badge ("the ability to update the app's badge"), sound, alert, carPlay, criticalAlert, providesAppNotificationSettings ("an option indicating the system should display a button for in-app notification settings"), and provisional ("the ability to post noninterrupting notifications provisionally to the Notification Center").

Two of those deserve more attention than they usually get. providesAppNotificationSettings asks the system to surface a button back into your own in-app notification controls, which is only worth requesting if you have built controls worth returning to. And provisional authorization does not require an explicit permission prompt: notifications arrive quietly in Notification Center, and the user can later promote them to full delivery or turn them off. That is the mechanism, and it is all we will assert — what provisional does to your opt-in numbers depends entirely on your app and your messages, and anyone quoting you a figure for it is describing a different product.

What a fitness app actually has worth sending#

The useful test is whether the message could have been written before this particular user existed. If it could, it is re-engagement spam in a tracksuit: "ready to crush it today", "your goals are waiting", "we miss you".

Three things a fitness app genuinely knows that a generic app does not:

A workout the user started and abandoned. There is a specific session, a specific point where it stopped, and a real question to put in front of them: finish it, save the partial, or discard it.

A streak or goal state that is about to change. This is the most abused message in the category and it needs real discipline, which is why it gets its own treatment in notification fatigue and opt-out.

A result that arrived from somewhere else. A watch, a chest strap or a connected provider synced a workout the user completed away from your app. Telling somebody their run has landed is information, not a nag.

Everything on that list has a timestamp, a subject and a next action. That is the whole difference between a notification and an interruption.

Permission timing is a design decision, not a default#

You can prompt at first launch, at the first moment the app has something real to deliver, or when the user reaches into a feature that visibly needs notifications — a rest timer, a scheduled plan, a shared challenge.

Our position, offered as judgement: prompt at the point where the reason is already on screen and self-evident, not on a launch screen where the only available argument is that you would like to send them things. On Android that matters more, because a denial is not a soft no — it takes every channel with it, including ones for features the user has not discovered yet.

In practice you get one meaningful ask, so treat the choice of moment with the same rigor you would give a pricing change: instrument which prompt point a user saw, which segment they were in, and what happened afterward.

The surfaces that survive a no#

A blocked notification permission does not silence your app everywhere. Widgets and watch complications render without it and are covered in widgets and complications. On iOS, Live Activities are a separate surface with their own model. On Wear OS the picture is less forgiving: an ongoing activity is paired with an ongoing notification, so the Android permission story follows you onto the watch.

Verify every platform behavior above against the current developer documentation before you build on it. Permission rules are exactly the kind of thing that changes at an API level boundary, and the failure mode is a silent install rather than a build error.