Introduction

Local notifications are scheduled by the app on the device itself rather than sent by a server. They are useful for reminders, timers, and offline workflows, but the exact implementation differs between iOS and Android.

Creating a local notification on iOS

On modern iOS, the standard API is UserNotifications. The basic flow is:

• ask for permission
• build notification content
• define a trigger
• schedule the request

1import UserNotifications
2
3let center = UNUserNotificationCenter.current()
4
5center.requestAuthorization(options: [.alert, .sound, .badge]) { granted, error in
6    guard granted, error == nil else { return }
7
8    let content = UNMutableNotificationContent()
9    content.title = "Reminder"
10    content.body = "Your focus session is complete."
11    content.sound = .default
12
13    let trigger = UNTimeIntervalNotificationTrigger(timeInterval: 10, repeats: false)
14    let request = UNNotificationRequest(identifier: "focus-reminder", content: content, trigger: trigger)
15
16    center.add(request)
17}

That schedules a notification to fire ten seconds later.

Handling foreground behavior on iOS

If the app is open when the notification fires, you may want to decide whether it is shown as a banner or handled silently. For that, implement the notification center delegate.

1import UserNotifications
2
3final class NotificationDelegate: NSObject, UNUserNotificationCenterDelegate {
4    func userNotificationCenter(
5        _ center: UNUserNotificationCenter,
6        willPresent notification: UNNotification,
7        withCompletionHandler completionHandler: @escaping (UNNotificationPresentationOptions) -> Void
8    ) {
9        completionHandler([.banner, .sound])
10    }
11}

Without this, foreground presentation may not behave the way you expect during testing.

Creating a local notification on Android

On Android, a local notification is usually created with NotificationCompat, and on Android 8.0 or newer you must create a notification channel first.

1val channel = NotificationChannel(
2    "reminders",
3    "Reminders",
4    NotificationManager.IMPORTANCE_DEFAULT
5)
6
7val manager = getSystemService(NotificationManager::class.java)
8manager.createNotificationChannel(channel)

Then build and show the notification:

1val notification = NotificationCompat.Builder(this, "reminders")
2    .setSmallIcon(R.drawable.ic_notification)
3    .setContentTitle("Reminder")
4    .setContentText("Your focus session is complete.")
5    .setPriority(NotificationCompat.PRIORITY_DEFAULT)
6    .build()
7
8NotificationManagerCompat.from(this).notify(1001, notification)

For delayed delivery, Android apps often combine this with AlarmManager or WorkManager.

Choosing the trigger mechanism

The notification object itself is only part of the solution. You also need to decide what event should cause it.

Common trigger patterns:

• time-based reminder
• calendar date reminder
• background work completion
• location or app-specific milestone

On iOS, UNTimeIntervalNotificationTrigger and UNCalendarNotificationTrigger are the usual building blocks. On Android, scheduling often depends on whether the work must run exactly at a time or can be deferred a little.

Keep notification content meaningful

A technically correct notification can still be a bad product decision. Titles and bodies should be specific, timely, and worth interrupting the user for. Local notifications are easy to overuse, and once users start disabling them, the feature loses value.

Also avoid putting sensitive data directly in the visible notification content unless that is intentional.

Test the full lifecycle

It is worth testing more than just "did the banner appear once". Verify permission denial, repeated scheduling, app foreground behavior, and what happens when the user taps the notification. A lot of notification bugs are not scheduling bugs at all. They are navigation, timing, or permission-state bugs that only appear outside the happy path.

Common Pitfalls

• Forgetting to request notification permission on iOS before scheduling.
• Expecting Android notifications to appear on newer versions without creating a notification channel.
• Testing only when the app is foregrounded and not verifying background behavior.
• Scheduling notifications correctly but using vague or low-value content.
• Assuming local notifications behave identically across iOS and Android.

Summary

• Local notifications are created on-device and do not require a push server.
• On iOS, use UserNotifications with content, a trigger, and a request.
• On Android, use NotificationCompat and create a channel on Android 8.0 or newer.
• Scheduling and display behavior are separate concerns from notification content.
• The technical setup matters, but the usefulness of the notification matters just as much.