The idea: a button can’t grant a permission

Add an Enable Push Notifications or Enable Location Services button to a MAM app, and it’s natural to assume the button turns the permission on. It doesn’t — and it can’t. Notifications and location aren’t your app’s to grant; the operating system owns them. The most any app is ever allowed to do is ask, and even that ask is tightly rationed by Apple and Google.

So depending on where the user happens to be in the permission lifecycle, these buttons do one of two things:

• If the OS has never asked the user yet, the button can trigger the one-shot OS permission prompt — the native “Allow / Don’t Allow” dialog.
• If the user has already answered (especially if they declined), the app has lost its chance to ask again. From there, the only useful thing the button can do is deep-link the user into the device’s Settings screen for that permission, so they can flip it by hand.

That second behavior is the one that catches admins off guard. You tap “Enable Notifications” expecting a yes/no prompt, and instead the phone’s Settings app opens. That’s not a bug — it’s the only door the OS leaves open once the permission’s already been decided. This article walks through why MAM’s permission buttons are built around that constraint, and what the user actually sees on each platform.

Both buttons come from mam-main‘s content-class system. In code they are the open_notifications class (admin label Enable Push Notifications, vc_type open_preferences) and the open_location_services class (admin label Enable Location Services, vc_type open_location_preferences). Both are deliberately settings-light — their content-type forms report “No settings required” — because it’s the OS calling the shots here, not anything you configure on the WordPress side.

Why “deep-link to Settings” instead of “grant”

Three hard constraints shape these buttons, and none of them are MAM’s choice — they’re platform rules MAM has to live inside.

1. The OS permission prompt is one-shot

When an app asks for notifications or location, the operating system shows its native dialog exactly once (per permission, per install — there are minor per-OS nuances). Once the user taps “Don’t Allow,” the app has lost the legal right to re-trigger that dialog. Call the request API again and nothing happens — the OS just hands back the answer it already has on file.

That’s the single most important fact about permission UX to carry with you. After a decline, the only way the user can change their mind is to walk into the device Settings app and flip the permission for your app by hand. A button that “asks again” would be a button that visibly does nothing. A button that takes the user straight to the right Settings screen, on the other hand, actually gets something done — so that’s what these buttons are wired to do.

2. The app can’t read the user’s mind about why

Apple and Google both review apps for why they’re requesting a sensitive permission, and a vague justification gets a build rejected. That’s why MAM splits the “explain it” step from the “ask it” step. Your custom rationale — the copy that tells the user why the app wants location or notifications — is yours to write. The actual OS prompt, by contrast, shows a canonical dialog the platform controls. (For location on iOS, the string inside that dialog comes from the publish-time permission text, stored as ios_app_gps_message, configured under Mobile App Manager → Publish Your App. More on this in “Where the OS prompt text comes from” below.)

3. There’s nothing for the admin to configure

Because the OS owns the outcome, there’s no meaningful per-button setting to expose. Both classes return “No settings required” from their content-type form. You place the button, give it a label and styling like any other nav button, and the runtime behavior is fixed from there: trigger the prompt if it’s still available, otherwise open Settings. That’s why you won’t find a “grant permission” toggle anywhere in the button’s configuration — there’s nothing the server could do to honor it even if it were there.

What the user sees, per OS

Both buttons aim at the same outcome, but the native experience diverges by platform. Think of the descriptions below as the shape of the experience rather than a pixel-precise guarantee — the exact destination screen is controlled by the OS version.

iOS

• First time, permission undecided: tapping the button can surface the native iOS permission alert (“”App” Would Like to Send You Notifications” / “Allow “App” to use your location?”). For location, the message line is the text you set as the GPS usage string at publish time.
• Already decided (declined or previously granted): iOS won’t re-show the alert. Instead, the button deep-links into Settings → [your app], the per-app screen where Notifications and Location toggles live. The user flips the switch there and returns to the app.
• iOS keeps each app’s permission toggles on a single dedicated page, so both the notifications button and the location button tend to land the user on that same per-app settings page.

Android

• First time, permission undecided: Android 6 (Marshmallow) and later use runtime permission prompts, so the button can trigger the native runtime dialog. On very old Android versions (pre-6), permissions were granted at install time, so there’s effectively nothing left to prompt — the permission’s already on.
• Already decided / “Don’t ask again”: Android routes the user to the system App info / App settings screen (or the notification-channel settings for notifications), where the permission can be toggled manually. Notifications in particular are organized into channels on modern Android, so the deep-link may land on a notifications-settings page rather than a single Allow/Deny switch.
• Android’s permission model has shifted across OS versions, so the precise destination varies more here than it does on iOS. What stays constant: the button gets the user to the place where they can change the setting, since the app can’t change it for them.

Here’s the practical takeaway for an admin testing the app: don’t be alarmed when the button opens a system Settings screen instead of an in-app dialog. On a device that’s already answered the permission prompt, that is the correct, expected behavior.

Where the OS prompt text comes from

This is a common source of confusion, so it’s worth being precise about which copy lives where.

• Your rationale screen copy (when you use a separate rationale/gating screen ahead of the button) is yours, written in the app builder. It sets expectations before the OS gets involved.
• The OS prompt’s own text is platform-controlled. On iOS, the location usage string is the publish-time value ios_app_gps_message, set under Mobile App Manager → Publish Your App. Apple displays that string inside its native location dialog, so it needs to clearly justify the request, or the build risks rejection on review.
• The Settings screen the button deep-links to is entirely the OS’s own UI. Nothing in MAM styles or labels it.

A useful rule of thumb: your rationale copy and the OS usage string should say the same thing, each in its own words. One sets up the ask; the other is the ask.

Note on the Notifications button’s history

The notifications content class (open_notifications) is the permission/settings button described in this article — its in-code purpose is to open the device’s notification settings so the user can enable push. Worth flagging: some older reference material describes an “Open Notifications” button as an in-app notification center (a history list of received notifications) instead. These are two different features that happen to share a similar name. If you want to show the user a history of notifications they’ve received, that’s the notification-center feature; if you want to help the user turn push on, that’s the Enable Push Notifications permission button covered here. When in doubt, let behavior be the tiebreaker: a permission button deep-links to OS Settings, while a notification center renders a list inside the app.

How this connects to the rest of the app

• Geofilters / location features. The Enable Location button (and any rationale screen ahead of it) is how a user unlocks the GPS path that geofilters can use. Geofilters still work with no permission at all — the user can pick a city manually — so think of this button as enhancing location features rather than gating them. See the geofilters concept article.
• Push notifications. Enabling notifications is what lets your dispatched push messages actually reach the device. The button itself doesn’t configure push credentials or message routing — it only helps the user opt the device in. See the notifications concept articles for how messages are sent.
• Publishing. The iOS permission strings (e.g. the GPS usage message) get set at publish time, not on the button. See the publish-your-app reference.

Where to go next

• To understand how granted location feeds content filtering, see How geofilters and location work: city picker, radius, content filtering.
• To understand how push messages are dispatched once a device is opted in, see the notifications dispatch concept article.
• For the per-class details, see the App Settings reference entries for the Enable Location and Enable Push Notifications content classes.
• For where the iOS usage strings are configured, see the Publish Your App reference.