I've got an iOS app with lots of extensions, some of them complex and doing a lot of stuff. After a bug I'd like to be able to use OSLogStore to get a holistic picture of logging for the app and its extensions and send that to a debugging server to retrospectively view logs for the app and its extensions. The constructor is OSLogStore.init(scope: OSLogStore.Scope), however scope only has one value .currentProcessIdentifier. Implying if that is called from within the app it can only get access to logging for its process only. I tried it out to confirm this is the case - if I log something in an extension (using Logger), then run the app with code like this:  let logStore = try! OSLogStore(scope: .currentProcessIdentifier)  let oneHourAgo = logStore.position(date: Date().addingTimeInterval(-3600)) let allEntries = try! logStore.getEntries(at: oneHourAgo)       for entry in allEntries { look at the content of the entry Then none of the entries are from the extension. Is there anyway from within the app I can access logging made within an extension?

I'm running an app with the com.apple.developer.usernotifications.filtering entitlement and the filtering works fine with iOS 15. However I tried running it on an older phone / OS (iPhone 8 / iOS 13.1.2) and it does not work. Is this entitlement not supported with iOS 13.1.2? If so, what is the earliest iOS version that supports it? The handset logged this: The OS displayed: default 07:55:58.800825-0800 NotificationServiceExtension   Mutated notification request will not visibly alert the user, will deliver original content If the app is run on iOS 15, it says : default 07:20:27.251600-0800  SpringBoard        Mutated notification request will not visibly alert the user, will supress original content

I'm working on an out-sourced application for a company and when a version of it built using ids and provisioning profiles from my Apple account it runs without problems. However when it is built and run using the company's ids and provisioning profiles I am seeing an issue with it. What is happening is when a notification service extension uses a call extension then the OS logs: doQueryCallExtensionStatusWithDispatchGroup() COMPLETED WITH ERROR: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.CallKit.CallDirectory was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo= NSDebugDescription=The connection to service named com.apple.CallKit.CallDirectory was invalidated: failed at lookup with error 159 - Sandbox restriction. I noticed that in the company's provising profile for the notification service extension the app identier prefix is different from the team identifer. In my own provisioning profile the app identifier prefix and team identifer are the same. Could it be the case that this difference in identifiers within the provisioning profile is leading to the sandbox error message? Attached is the notification service extension provisioning profle provided to me by the company (converted to a .plist for readability)

We have an app which gets sent APNSs by the server and use a Notification Service Extension to intercept them. In my observations I've never seen throttling applied on the device to these pushes (unlike app directed push where its easy to observe happening if you let the batter run low for example). The Apple documentation says it may perform server side throttling, but when, how often, under what circumstances? If the app has 30 million users and the server sends them 10m or 100 pushes per day will it get throttled? Does anybody have any have any documented or observed info on this.

It an app receives a Voip push, but has to terminate the call, then if this happens a few times the OS is terminating the app (Message from debugger: Terminated due to signal 9) and then it stops delivering future pushes to the app.i.e. with code let endCallAction = CXEndCallAction(call: callUUID) let transation = CXTransaction(action: endCallAction) self.callController.request(transation) { (error) in } provider.reportNewIncomingCall(with: callUUID, update: callUpdate) { error in Model.priorityLog("GRUNT reportNewIncomingCall completion error \(String(describing: error))") completion() }

I wrote a notification content extension which with 10.1 was working perfectly and reliably - it was getting called 100% of the time, as it should, and eveything was great and working as it should.But now with 10.2 I just cannot get the bugger to work at all - the extension just isn't being called by the OS (actually it was called once out of about 30 attempts and on that one occasion the UNNotificationExtensionDefaultContentHidden YES flag was ignored, which it didn't use to be with 10.1)Anybody else having problem with content extensions with 10.2, but if not is there some trick or tweak or change you applied to get them to work?