Introduction

Checking whether push notifications are "enabled" on iOS really means checking notification authorization, and sometimes also checking whether the app has successfully registered with APNs. The API changed between iOS 9 and iOS 10, so compatibility code needs to use different system calls depending on the OS version.

Clarify What You Mean by "Enabled"

There are several states that developers often collapse into one Boolean:

• the user has never been asked
• the user denied notification permission
• the user granted permission
• the app is authorized but not currently registered for remote notifications

If your UI or support flow only asks "enabled or disabled," that may be enough. But for real troubleshooting, authorization and remote registration are separate checks.

iOS 10 and Later

Starting with iOS 10, use UNUserNotificationCenter to inspect authorization settings.

1import UIKit
2import UserNotifications
3
4func checkNotificationAuthorizationIOS10(completion: @escaping (Bool) -> Void) {
5    UNUserNotificationCenter.current().getNotificationSettings { settings in
6        let enabled =
7            settings.authorizationStatus == .authorized ||
8            settings.authorizationStatus == .provisional
9        completion(enabled)
10    }
11}

This tells you whether the system considers the app authorized for notifications.

If you need more detail, inspect the full settings object rather than compressing it immediately to one Boolean. That object can show whether alert, badge, and sound settings are individually allowed.

iOS 9 Path

Before iOS 10, the older UIUserNotificationSettings API is used.

1import UIKit
2
3func checkNotificationAuthorizationIOS9(application: UIApplication) -> Bool {
4    guard let settings = application.currentUserNotificationSettings else {
5        return false
6    }
7    return settings.types != []
8}

This is the compatibility path for legacy code. If you still maintain an app that supports iOS 9, keep the branch isolated in one helper rather than scattering old API checks through multiple view controllers.

A Unified Helper

Wrap the version split once.

1import UIKit
2import UserNotifications
3
4func notificationsEnabled(application: UIApplication, completion: @escaping (Bool) -> Void) {
5    if #available(iOS 10.0, *) {
6        UNUserNotificationCenter.current().getNotificationSettings { settings in
7            let enabled =
8                settings.authorizationStatus == .authorized ||
9                settings.authorizationStatus == .provisional
10            completion(enabled)
11        }
12    } else {
13        let enabled = application.currentUserNotificationSettings?.types != []
14        completion(enabled)
15    }
16}

That keeps the rest of the app clean and makes migration easier later.

Authorization Is Not the Same as APNs Registration

A user can authorize notifications, but the app may still fail to receive remote pushes if it never registered or if registration failed.

For remote notifications, the app still needs:

UIApplication.shared.registerForRemoteNotifications()

So a fuller diagnostic flow may combine:

• notification authorization status
• whether a device token was received successfully

If you only check authorization, you may misdiagnose APNs registration failures.

Guide the User to Settings When Needed

If notifications are disabled, the app can send the user to the app settings page.

1import UIKit
2
3func openAppSettings() {
4    guard let url = URL(string: UIApplication.openSettingsURLString) else {
5        return
6    }
7    UIApplication.shared.open(url)
8}

This is useful after a denial, because the permission prompt does not keep reappearing automatically in the same way after the user already made a choice.

Refresh State at the Right Time

Notification settings can change while the app is in the background. If the user visits Settings and comes back, your cached flag may be stale.

A good pattern is to refresh notification state when the app returns to the foreground or when the relevant settings screen appears.

That avoids UI bugs where the app continues showing "disabled" even after the user re-enabled notifications.

Common Pitfalls

• Treating notification authorization and APNs registration as the same thing.
• Using only the iOS 10 API path while still claiming iOS 9 compatibility.
• Checking notification state only once at launch and never refreshing it.
• Collapsing detailed system settings into one Boolean when the app really needs a richer state model.
• Forgetting to provide a path back to Settings after the user denies permission.

Summary

• On iOS 10 and later, use UNUserNotificationCenter.getNotificationSettings.
• On iOS 9, use currentUserNotificationSettings.
• Authorization status and APNs registration status are related but not identical.
• Put compatibility logic in one helper instead of scattering version checks.
• Refresh state when the app returns from Settings or foreground transitions.