Introduction

In iOS 8, Apple changed local notification behavior so apps had to ask the user for notification permission explicitly. Before that change, many apps scheduled local notifications without a separate authorization step. If you are maintaining legacy iOS 8 code, the important part is registering notification settings before scheduling alerts and responding to the authorization callback correctly.

Why iOS 8 Changed The Flow

Apple moved notification control toward explicit user consent. That means local notifications and remote notification presentation settings became part of app-level authorization instead of silent default behavior.

In iOS 8-era UIKit, the main API involved UIUserNotificationSettings and application registration methods.

Basic Permission Request

The normal pattern was to build settings and register them during app startup or at a user-meaningful moment.

1import UIKit
2
3@UIApplicationMain
4class AppDelegate: UIResponder, UIApplicationDelegate {
5    var window: UIWindow?
6
7    func application(
8        _ application: UIApplication,
9        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
10    ) -> Bool {
11        let settings = UIUserNotificationSettings(
12            types: [.alert, .badge, .sound],
13            categories: nil
14        )
15        application.registerUserNotificationSettings(settings)
16        return true
17    }
18}

That triggers the system permission prompt when appropriate.

Handling The Registration Callback

Once the user responds, your app receives the registered settings callback.

1func application(
2    _ application: UIApplication,
3    didRegister notificationSettings: UIUserNotificationSettings
4) {
5    if notificationSettings.types.isEmpty {
6        print("User denied notification permissions")
7    } else {
8        print("Notification permissions granted")
9    }
10}

This is the place to branch behavior, not when you first construct the settings object.

Scheduling A Local Notification

After permission exists, scheduling was done with UILocalNotification.

1func scheduleReminder() {
2    let notification = UILocalNotification()
3    notification.fireDate = Date(timeIntervalSinceNow: 60)
4    notification.alertBody = "Time to check your reminder"
5    notification.soundName = UILocalNotificationDefaultSoundName
6    UIApplication.shared.scheduleLocalNotification(notification)
7}

In iOS 8, asking for permission and scheduling the local notification were separate responsibilities.

Ask At The Right Time

Technically you can ask on launch, but product-wise that is not always the best moment. Permission prompts work better when users understand why the app needs them. For reminder apps, ask near the moment the user creates a reminder. For messaging apps, ask after onboarding explains the benefit.

Legacy API or not, that design principle still matters.

Important Modern Context

These APIs are now deprecated. Modern code uses UserNotifications and UNUserNotificationCenter. If you are building new software, do not start with UILocalNotification.

But if you maintain iOS 8 compatibility, legacy registration flow may still appear in old branches and migration projects.

Permission State Handling

Do not assume a prompt will always appear. If the user already responded previously, registration may simply return current settings. Your app should handle all cases:

• granted,
• denied,
• partially allowed depending on alert, badge, or sound settings.

That is why checking the returned types matters more than assuming a fresh prompt.

Common Pitfalls

• Scheduling local notifications before registering user notification settings.
• Asking for notification permission on first launch with no user context.
• Assuming the permission prompt appears every time registration code runs.
• Using deprecated UILocalNotification APIs for new development instead of modern notification frameworks.
• Forgetting to handle the denied-permission path in app behavior.

Summary

• In iOS 8, local notifications required explicit user notification registration.
• Use UIUserNotificationSettings and register with the application object first.
• Check the callback result instead of assuming authorization was granted.
• Schedule UILocalNotification only after permission flow is in place.
• For new code, prefer modern notification APIs and treat this flow as legacy maintenance knowledge.