IOS 10 crashes caused by Local Notification

Hey Andre,

we have a very similar use case and randomly see the exact same behaviour. We rewrote the notification scheduling and cancelation logic to be iOS UserNotifications framework conform, but still having the issue.

Canceling:

UNUserNotificationCenter *center = [UNUserNotificationCenter currentNotificationCenter];

[center getNotificationSettingsWithCompletionHandler:^(UNNotificationSettings * _Nonnull settings) {

if(settings) {

if([settings authorizationStatus] == UNAuthorizationStatusAuthorized) {

UNUserNotificationCenter *center = [UNUserNotificationCenter currentNotificationCenter];

[center removePendingNotificationRequestsWithIdentifiers:@[notificationTypeName]];

}

}

}];

Scheduling:

if (SYSTEM_VERSION_GREATER_THAN_OR_EQUAL_TO(@"10.0")) {

UNCalendarNotificationTrigger *trigger = [UNCalendarNotificationTrigger triggerWithDateMatchingComponents:dateComps repeats:NO];

UNMutableNotificationContent *content = [[UNMutableNotificationContent alloc] init];

content.body = alertBody;

content.sound = [UNNotificationSound soundNamed:soundName];

UNNotificationRequest *request = [UNNotificationRequest requestWithIdentifier:[userInfo objectForKey:@"type"] content:content trigger:trigger];

UNUserNotificationCenter *center = [UNUserNotificationCenter currentNotificationCenter];

[center getNotificationSettingsWithCompletionHandler:^(UNNotificationSettings * _Nonnull settings) {

if(settings) {

if([settings authorizationStatus] == UNAuthorizationStatusAuthorized) {

[center addNotificationRequest:request withCompletionHandler:^(NSError * _Nullable error) {

if (error) {

PLog(@"Problem while scheduling local Notification! %@", [error localizedDescription]);

}

}];

} else {

PLog(@"Notification access not granted");

}

}

}];

} else { iOS 9 code }

Thanks

Andreas

Hi Andre,

I ran into a similar issue with UNNotificationRequest that causes the device to get a black screen and spinning wheel. The error I had was if the identifier of the request was an empty and non-nil string.

identifier = ""

Creating and adding the request doesn't cause the crash; it happens when the device tries to deliver the notification to the user. The log also outputs two lines: "XPC connection interrupted" and "[Common] Terminating since there is no system app."

You might want to try running your app in the simulator. Doing so presented a crash report automatically for me. I could also find it later in Console.app.

I have submitted a bug report to Apple.

Edit: This is still present on iOS 10.0.2 and Xcode 8.0.

Hope this helps,

Patrick

Hello,

Any update on this case?

Couldn't find any workaround to solve this issue.

Crashes on both UILocalNotification and UNNotificationRequest

Hi Andre,

I ran into similat situation when trying to scheule mulpile UILocalNofication where "SpringBoard" would hike up the memory and eventualy crash and restart the phone.

Instead of scheduling multiple notification in a loop try adding them to an array and then schedule the reminder using NSArray<UILocalNotification *> *scheduledLocalNotifications property.

NSArray *arrayOfNotifications = [self.notificationScheduler scheduledLocalNotifications];

NSMutableArray *scheduleNotificationsList = [NSMutableArray array];

for (ReminderInstance *instance in [self getAllInstances]) {

[scheduleNotificationsList addObject:[instance asLocalNotification]];

}

}

[UIApplication sharedApplication].scheduledLocalNotifications = [scheduleNotificationsList arrayByAddingObjectsFromArray:arrayOfNotifications];

Same thing with unscheduling the notifications do not use cancelLocalNotification:.

Hope this will resolve the issue.

Thanks

Alwin

Hi,

I found a temporarely workaround for this issue.

When I'm scheduling less notifications (30), I'm not having the Springboard crash.

I hope Apple will fix it soon, but in the meanwhile, this workaround really improves the situation.

Rotem

I think you are seeing the same issue that is reported here: https://forums.developer.apple.com/message/196460#196460

Scheduling notifications using the iOS 10 framework and UNCalendarNotificationTrigger is incredibly slow. Each notification that is scheduled takes progressively longer for the completion handler to be called (I've seen over 5 seconds to schedule 64 notifications). Repeatedly scheduling notifications just keeps adding work to the queue and everything backs up more and more. Eventually Springboard will crash. The problem also occurs if the app schedules lots of notifications then is sent to the background. The app can't respond to the completion handlers being called and about a minute later Springboard crashes.

In my own Pomodoro timer app I need to schedule notifications each time the user restarts or skips the timer forward. If the user does this repeatedly in quick succession the app repeated cancels all notifications and reshedules 64 notifications. The work keeps backing up and the completion handlers get called later and later until it just crashes Springboard.

I was able to work around this issue by having my own NSOperationQueue (with 1 worker thread) where I synchronously queued up all my iOS 10 UserNotification framework related work (i.e. cancelling all notifications and scheduling new ones). Each time I wanted to cancel and re-schedule, I would call cancelAllOperations on that queue to flush out any operations that hadn't started yet (which helps avoid the ever-increasing backlog).

I also tried to ensure my app would run for 20s after going into the background by putting this code into applicationDidEnterBackground:

    UIBackgroundTaskIdentifier identifer = [application beginBackgroundTaskWithExpirationHandler:^{
        // nothing
    }];

    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, 20.0 * NSEC_PER_SEC), dispatch_get_main_queue(), ^{
        [application endBackgroundTask:identifer];
    });

And, just to be even safer, I broke my 64 notifications up into groups of 16 and scheduled each group with a separate operation on my NSOperationQueue, so that when I did cancelAllOperations, I was able to cancel more work. Only the group that was currently being scheduled (i.e. the operation that was running) would need to complete before my new work would execute on the queue. This helped reduce the worst-case latency in cancelling and re-scheduling the notifications.

I submitted bug report 29551302 with a test project that clearly showed the ever-increasing delays in calling the completion handlers. Using UNTimeIntervalNotificationTrigger instead of UNCalendarNotificationTrigger was quicker, but each successive added notification would take longer for the callback handler to be called. In other testing I found UNCalendarNotificationTrigger didn't deliver the notifications precisely on time, which is why I had moved to using calendar notifications in the first place.