I am running into a really weird problem where I can't quite nail down the root cause. Our app used to function properly for background/silent notifications for ios12 and ios13 up until a few weeks ago. So a bit of background information:
We use SNS to send visual/audible and silent background notifications.
We are aware of the apns-push-type header that is required for ios13. SNS automatically handles this new header and our manual testing (i.e. without SNS) have also produced the same results.
The silent notifications (i.e. content-available: 1) always fail on ios13.3 (or higher) but always work on ios12.4 (and below).
In our swift code, we are using :didReceiveRemoteNotification:fetchCompletionHandler for silent notifications. We are also using userNotificationCenter (with willPresent and didReceive). Whenever we send audible/visual notifications, willPresent gets triggered on ios12 and ios13. On ios12, silent notifications trigger didReceiveRemoteNotification:fetchCompletionHandler but nothing with ios13.
During our testing, we successfully sent an empty alert type to trigger a silent notification on ios13 and this works on ios12 as well (this triggers willPresent). This feels like a hack to me because it will likely wakeup the device momentarily and the notification will disappear if the app is running in the background.
In other viewcontrollers, we are observing NotificationCenter for received messages to take appropriate actions.
To me it seems, {"content-available": 1} never works on ios13 and but does on ios12. Also didReceiveRemoteNotification:fetchCompletionHandler never gets called on ios13 but does on ios12. Our intent with silent notifications with (i.e. with content-available:1) is to refresh the details from our service when changes occur when the app is in foreground or background.
Any help would be appreciated.
I was able to resolve this issue. Before I get into the solution, however, I want to mention that I ran into this problem only on iOS13 and with silent notifications. The same code was working with iOS12 with same feature.
Our app has a separate screen for requesting notification permissions when the app is launched first time. At this stage we register the device for notifications. Next time when the app is launched, we don't show this screen anymore. To get it to work on ios13, we had to re-register with APNS in AppDelegate's didFinishLaunchingWithOptions every single time. Again, on iOS12 silent notifications were working without re-registering with APNS but on iOS13 we have to re-register every single time.
I hope this helps anyone else running into this problem.
Related
I'm using local and silent remote notifications in the app I'm working at work. I need to launch some methods according to events received from our servers or from the app itself via silent remote and local notifications respectively. I have no problem with remote notifications with the app in foreground, background or with the notification touched but I can't get the scheduled local notifications to be noticed by AppDelegate if the app is running in background (I mean, without user tapping the banner).
Is this even possible? If yes, which parameter should I add to the notification or what method is supposed to be called when it arrives?
I don't think it's possible to send a local notification that runs silently and starts your app. The normal way to do things like this is Background App Refresh:
https://developer.apple.com/documentation/uikit/app_and_environment/scenes/preparing_your_ui_to_run_in_the_background/updating_your_app_with_background_app_refresh
You have no control of the time. iOS will periodically give you short slices of time
I've been trying to find something about this problem for a few days, but without any useful results. I'm working on a VoIP app for iOS (using an iPhone 4 running iOS 6.0) in Objective-c which uses remote notifications to notify the user about calls when the client is in background.
My issue is quite strange: When the app is in background and the screen is locked, notifications arrive and work perfectly - they ring, and open the app when opened. But when the application is in background, and the screen is unlocked - for example, we're on the home screen - notifications simply fail to appear, not giving any sign that something happened.
Anybody got any ideas where to look around? The app code handles push notifications correctly when they appear, so that shouldn't be an issue. The notifications get out of our server, so I'm starting to think that there is something about the device's settings. The app is set to a "banner" alert style, and its notifications are enabled.
When the app is running in the background, the notification does not appear. You need to catch it in the App Delegate application:didReceiveRemoteNotification:.
Implement this method and put a UIAlert to see when the notification arrives.
I'm seeing something very strange, and I'm hoping someone here can help me. Anytime I close/background my iOS app, the last push notification sent to that app via UrbanAirship pops-up at the top of the screen.
I've setup push notifications for my iOS app using UrbanAirship, and its associated libraries. I'm using the latest library from UA (1.3.3), and I believe I've configured everything correctly. I've gone over the basic documentation multiple times, and I'm not doing anything out of the ordinary that I can tell.
In my AppDelegate, I'm not doing anything with the UA libraries in the functions applicationWillResignActive or applicationDidEnterBackground, so I'm not certain why backgrounding the app would trigger this notification to come up. The documentation doesn't state that anything needs to happen in those functions. In the function applicationWillTerminate, I am correctly calling [UAirship land], but this issue isn't popping up when the app is terminated.
More data: I'm not actually seeing a new notification in the Notification center on my phone. I'm just seeing the message pop-up again, as if it were new.
This issue is perplexing, and if anyone can offer some insight or assistance with it, I'd appreciate it.
My specific requirement is an app that is in the background, being notified that the display is about to go to sleep or that the device has or is about to reach it's idle timeout - and then waking up and executing some (brief) piece of code.
I have found reference to notifications that an app is being put in the background or suspended here:
http://developer.apple.com/library/ios/#DOCUMENTATION/iPhone/Conceptual/iPhoneOSProgrammingGuide/ManagingYourApplicationsFlow/ManagingYourApplicationsFlow.html
And there seems to be a way of detecting on OSX:
http://developer.apple.com/library/mac/#qa/qa1340/_index.html
So, can a background iOS app receive notification that the display is going to sleep and execute just before it does?
No, thats not possible on iOS. I suggest you file a bug report at bugreport.apple.com and explain to them why you need such a feature, although this isn't a guarantee that such a thing will come. But if more people request this feature, the likelier it gets implemented.
I'm wondering if it's possible to make an iphone app give the user an alert in a certain time without being run in the background or using notifications?
I see it happening in an app called iPray Pro. It gives an alert for the prayer time even though it's not running in the background or using notifications. I checked under the Setting-Notifications and the app is not there at all.
How is it done?
Scheduled local notifications will trigger even if the app is closed. iPray probably schedules notifications for a given time which are then triggered by the OS without the app having to be open.
Look for Local Notifications in the iOS documentation. They are like push notifications, but don't require a server. They are quite simple API to use too; make a UILocalNotification and use the scheduleLocalNotification: method on UIApplication to add the notification onto the system.
It will then fire in accordance to the fireDate property of the local notification you scheduled.
Local Notifications require iOS4.0 or later.
It is using Local Notifications, not Remote Notifications.