Skip to main content

Apple Push Notification Changes for iOS 11

Push Notification

With the advent of iOS 11, Apple has introduced changes in the way they handle certain kinds of push messages. This was done to improve battery life, but comes at a cost of user experience that is likely to affect your app.

What Apple has done is to implement a service called the “DuetActivitySchedulerDaemon” (DASD). Part of the job of this service is to measure how frequently your app is used. If your app is not used frequently, DASD may delay or discard push messages sent to your app which have the content-available flag set.

On iOS 10, Apple acknowledged a defect where push notifications containing content-available would not be delivered after an app was force-closed and rebooted. Based on what Apple has delivered in iOS 11, we assume this defect will not be fixed.

Until we have engineered solutions to work around this issue, be aware when deploying:
  • silent (data) pushes
  • in-app messages
  • pushes with dynamic categories
  • simple pushes which have more than one associated action (these are implemented with dynamic categories)
  • API pushes you send which include content-available
These messages all make use of the content-available flag and may not be delivered except to those users who use your app frequently (multiple times a day). Simple messages with only one associated action are unaffected by this issue.

We will provide a new WCA SDK for iOS that works around these Apple issues. An ETA for that SDK should be available soon.

For further technical details, see the discussion here:
https://stackoverflow.com/questions/44796613/silent-pushes-not-delivered-to-the-app-on-ios-11/

This issue won’t be seen when your app is connected to the debugger, but will appear in production apps.

Users of Xtify 2.x product who include the “Content Available” flag in their campaigns will also be affected by this Apple decision.



Comments

Popular Posts

What are the Alternatives of device UDID in iOS? - iOS7 / iOS 6 / iOS 5 – Get Device Unique Identifier UDID

Get Device Unique Identifier UDID Following code will help you to get the unique-device-identifier known as UDID. No matter what iOS user is using, you can get the UDID of the current iOS device by following code. - ( NSString *)UDID { NSString *uuidString = nil ; // get os version NSUInteger currentOSVersion = [[[[[UIDevice currentDevice ] systemVersion ] componentsSeparatedByString: @" . " ] objectAtIndex: 0 ] integerValue ]; if (currentOSVersion <= 5 ) { if ([[ NSUserDefaults standardUserDefaults ] valueForKey: @" udid " ]) { uuidString = [[ NSUserDefaults standardDefaults ] valueForKey: @" udid " ]; } else { CFUUIDRef uuidRef = CFUUIDCreate ( kCFAllocatorDefault ); uuidString = ( NSString *) CFBridgingRelease ( CFUUIDCreateString ( NULL ,uuidRef)); CFRelease (uuidRef); [[ NSUserDefaults standardUserDefaults ] setObject: uuidString ForKey: @" udid " ]; [[ NSUserDefaults standardUserDefaults ] synchro...

Xcode & Instruments: Measuring Launch time, CPU Usage, Memory Leaks, Energy Impact and Frame Rate

When you’re developing applications for modern mobile devices, it’s vital that you consider the performance footprint that it has on older devices and in less than ideal network conditions. Fortunately Apple provides several powerful tools that enable Engineers to measure, investigate and understand the different performance characteristics of an application running on an iOS device. Recently I spent some time with these tools working to better understand the performance characteristics of an eCommerce application and finding ways that we can optimise the experience for our users. We realised that applications that are increasingly performance intensive, consume excessive amounts of memory, drain battery life and feel uncomfortably slow are less likely to retain users. With the release of iOS 12.0 it’s easier than ever for users to find applications that are consuming the most of their device’s finite amount of resources. Users can now make informed decisions abou...

An introduction to Size Classes for Xcode 8

Introduction to Size Classes for Xcode In iOS 8, Apple introduced  size classes , a way to describe any device in any orientation. Size classes rely heavily on auto layout. Until iOS 8, you could escape auto layout. IN iOS8, Apple changed several UIKit classes to depend on size classes. Modal views, popovers, split views, and image assets directly use size classes to determine how to display an image. Identical code to present a popover on an iPad  causes a iPhone to present a modal view. Different Size Classes There are two sizes for size classes:  compact , and  regular . Sometime you’ll hear about any.  Any  is the generic size that works with anything. The default Xcode layout, is  width:any height:any . This layout is for all cases. The Horizontal and vertical dimensions are called  traits , and can be accessed in code from an instance of  UITraitCollection . The  compact  size descr...