Post not yet marked as solved
Please file a Feedback Report as soon as possible, and include a sysdiagnose.
It would be best if you can create the sysdiagnose as soon after installing iOS 16 beta as possible.
Post not yet marked as solved
TOPIC="com.myapp.location-query"
You are sending a location query to an app with a bundle id "com.myapp"
Unless that is indeed your app's bundle id, you will not be able to send any pushes to it.
Post not yet marked as solved
There exists an API that you can use to request the system to extend your background time up to 30 seconds: https://developer.apple.com/documentation/uikit/uiapplication/1623031-beginbackgroundtaskwithexpiratio
It is not possible to extend background activity beyond this for apps which have been suspended in the background and woken up by region monitoring events.
Post not yet marked as solved
The behavior you are seeing is expected, and it is due to content-available (aka "background" or "silent") push notifications being throttled when being delivered to apps that are in the background.
content-available push notifications are never guaranteed to be delivered to the app every single time.
Although you may expect up to several content-available push notifications per hour across all apps on a device, it is entirely possible and appropriate that you may receive none at all.
The WWDC 2020 video "Background execution demystified" (https://developer.apple.com/videos/play/wwdc2020/10063/) explains the factors that effect background runtime.
If the only reason you want this is to get the user's location you will want to look at creating a Location Push Service Extension as described here: https://developer.apple.com/documentation/corelocation/cllocationmanager/creating_a_location_push_service_extension
You will need to apply for an entitlement to be able to use this facility here: https://developer.apple.com/contact/request/location-push-service-extension/
Post not yet marked as solved
The sample code is there. https://developer.apple.com/documentation/corebluetooth/using_core_bluetooth_classic
Please make sure there are no typos or extra characters in the URL you are using.
apns-expiration:300 means the notification expires at 5 minutes past midnight on 1/1/1970 UTC
The value you need to use is the Unix Time in seconds for when you want the notification to expire.
This was a temporary issue with the APNs Sandbox. It has now been fixed as of June 13, 2022 12:00 noon PDT.
You should be able to receive tokens now barring any local network issues on the device side that may have been the root cause in the first place.
Post not yet marked as solved
No, the device is required to be authorized by the user for ANCS access. There is no way around this requirement.
Post not yet marked as solved
When an app is deleted from a device, its listing in Settings will reset, and when it is reinstalled, the Location setting will not be there by default. For the location setting to appear the app needs to instantiate a location manager and use it first.
It is possible that your code is flowing differently for a TestFlight/Release build and not instantiating/authorizing/using CoreLocation APIs as it does in a debug/Xcode build.
You may want to have a look at https://developer.apple.com/documentation/xcode/testing-a-release-build
The problems covered are those which are frequently missed during development and can therefore surface in TestFlight, App Review, customer environments or distribution app testing.
APNs does not distinguish multiple tokens generated using different keys contemporarily vs. the same key being used for the same TeamID.
If you are using multiple keys for simultaneously, for example for use by multiple push providers, you need to find a way to avoid generating multiple tokens for the same TeamID.
It is not clear why you are using multiple keys, but here are a number of additional points to be careful about depending on your use case:
1- APNs expects developers to use the same authentication token for as close to one hour as possible. A good logic would be to generate a new token if the existing one is older than an hour.
2- If you are using multiple keys on the same server, generating tokens on the same connection you will receive this error as well. You need to use separate connections, even from the same physical server.
3- Authentication tokens for more than one team on the same connection is not supported. If the push server is shared by multiple apps using multiple keys, instead of using the same connection pool to send the push requests you should isolate the connection pool for each app.
Post not yet marked as solved
Along with this change in iOS 15, background notifications are throttled and delivered sparingly based on various criteria.
Delivery of background pushes to an app has never been guaranteed, and an app should not be designed in a way that depends on delivery of every background push.
You can expect a very few amount of background notifications to be delivered across all apps per hour, and it is entirely possible and appropriate that none would be delivered at all.
Post not yet marked as solved
Yes, this was a known issue on the early builds of iOS 15. This has been since resolved, and both APIs should be working as designed in the current versions of iOS 15.
Post not yet marked as solved
IOBluetooth is not, and never been thread safe. Everything needs to be handled in the main thread.
Post not yet marked as solved
There are too many moving parts to start guessing what might be wrong, remotely here. Your best bet is going to be to start looking at the Console log and see what might be happening when you send the location push. You would want to filter the output with your bundle id to avoid all the other unrelated log entries. There should be some indication as to what might be happening.
Now that you have fixed the problems with actually sending the push (getting 200), you would want to make sure it is not one of the following issues (not an exhaustive list):
malformed push payload. You would get a 200 but it would fail on the device
using the incorrect (but valid) apns-topic and token. If you also have implemented regular or VoIP notifications in your app, for instance, make sure the correct token is being used.
system not able to launch the extension. Usually due to incorrect project configuration
extension crashing at launch.
extension crashing later while processing. Do you have logging at the point of entry?
location permissions issue
extension not finishing in a timely manner, or using too much memory and being killed
What I would suggest is to add ample os_log() statements to the extension, and then observe what is going on in the Console log.
You will likely see something that will help further pinpoint the problem.
Post not yet marked as solved
There is no need to send silent notifications, nor there is a need for any entitlements.
You can do what you want to do (decrypt a message) , in the Notification Service Extension as discussed at https://developer.apple.com/documentation/usernotifications/unnotificationserviceextension.
The Notification Service Extension will be executed for every visible push notification. So, it will serve your needs to replace the sent encrypted content into a human readable content, as long as the user has not disabled the visibility of your notifications through various settings (in which case the whole process is moot).
