If you create a CallKit extension with Xcode 15 beta, then add some logging to the template code that gets created and run it on an iOS 17.3 beta phone the logging clearly shows that the OS is running the extension twice when the user turns on the extension in Settings. Run it on any device with < iOS 17 and its only invoked once, as it should be. However, not only does the OS run it twice, but based on the logging the two invocations are in parallel, not serial, suggesting two CallDirectoryHandler instances are being created and run simultaneously.

If there is the following code for a notification service extension var countOfInvocations = 0 public class NotificationService: UNNotificationServiceExtension { public override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -&gt; Void) { NSLog("Push count: \(countOfInvocations)") countOfInvocations = countOfInvocations + 1 Then if pushes are sent to the handset it can be observed in the console log that the value of countOfInvocations keeps increasing, meaning the NotificationService class is getting instantiated and destroyed within the same process. However at what point does that process get torn down by the OS? It seems to be kept alive for about 10 minutes or so. Is there a way the extension can detect its the same or a new process?

I've got a complex app extension and I'd like to be able to combine the logging from the app and the extension into a single file (for extraction/uploading etc.) I experimented adding the following code to both the app and the extension i.e. using the same subsystem for both app and extension logging. let subsystem = "mySubsystem" let logger = Logger(subsystem: subsystem, category: "main") logger.info("Log from within extension") // the version in the app says Log from within app do { let logStore = try OSLogStore(scope: .currentProcessIdentifier) let oneHourAgo = logStore.position(date: Date().addingTimeInterval(-3600)) let allEntries = try logStore.getEntries(at: oneHourAgo) let filtered = allEntries .compactMap { $0 as? OSLogEntryLog } .filter { $0.subsystem == subsystem } } The filtered content only contains logging from either the app or the extension. I suppose the issue might be the use of .currentProcessIdentifier as the scope, however that's the only scope that is defined. Is what is being attempted here possible? Is there any way to write to and extract a unified log for an app and app extension? If not, how about adding it, surely this would be something useful for people to be able to do

In WWDC 2016 Session 230 (https://wwdctogether.com/wwdc2016/230) they show the incoming Voip call screen (at time 02.59) with an image covering the entire call screen. How is that achieved?

I've been successfully using CXProvider.reportNewIncomingVoIPPushPayload() as follows: a (non VoIP) push is sent to the handset this is intercepted by a notification service extension the extension calls CXProvider.reportNewIncomingVoIPPushPayload() (the extension has the required com.apple.developer.usernotifications.filtering entitlement) this results in the app delegate's implementation of PKPushRegistryDelegate:didReceiveIncomingPushWithPayload getting called (the app is launched if terminated) This all works as expected, in particular when the app is terminated it still works. However its suddenly stopped working since my phone got updated to iOS 16.6 (I can't remember exactly what was on it previously, 16.5 or 16.4). Now with iOS 16.6 the behavior is that PKPushRegistryDelegate:didReceiveIncomingPushWithPayload() only gets called if the app is not terminated. If the app is terminated then calling CXProvider.reportNewIncomingVoIPPushPayload() results in the app getting launched and didFinishLaunchingWithOptions() getting called BUT didReceiveIncomingPushWithPayload() is not called when launching from a terminated state. As a consequence of didReceiveIncomingPushWithPayload() not getting called, the app isn't calling reportNewIncomingCallWithUUID() and so after a few runs the OS stops launching the app entirely saying: "Application will not be launched because it failed to report an incoming call too many times". When didFinishLaunchingWithOptions() is called the launchOptions are nil, i.e. there is no way to distinguish the app from being launched as a consequence of reportNewIncomingVoIPPushPayload()(*) being called and therefore it is not possible to call reportNewIncomingCallWithUUID(). So this feature is totally broken apparently from previous behavior. Any comment? TIA (*)Well actually, the extension could write a flag to a shared group and the app read that on launch, but what a hack, and should be unnecessary.

Our app has some Crashlytics & Localytics reporting to collect metrics for diagnostic and info gathering. One thing I'm noticing recently is that if a user has version m of the app installed and updates to version m+1, then for some users, the app has detected and reported that the push token obtained with version m+1 is different from that of version m (for the same handset). That's fine - if the app has detected the change to the token it can send the new one to the server so the server can update. But my question is - if the user didn't explicitly launch the app and thus present the app with the chance to send the new token to the server, then what will happen to the pushes sent by the server using the old token? Presumably they won't get delivered if the token has changed, but if the user has no need to launch the app then they're never going to receive any pushes from the server until they do launch the app. However there's not necessarily any reason why a user should repeatedly launch an app once it's been set up (depending upon what it does and how it delivers info to the user and how the user interacts with it, there's no reason why a user should have to launch the app after initial installation and launch). If so then this seems like a gap in the design of push notifications? If they can change on the same handset, or another scenario is the user backs up their device to iCloud and then restores to a different handset, then in that case the push tokens will have definitely changed, yet any apps using push don't get the chance to send the new token to the server until the user launches the app, meanwhile all pushes from the server will be dropped.

My goal is to try and get a unified logging system set up where logging from an iOS app and its extensions (primarily a notification service extension) get written into one central repository. So I was planning on setting up CocoaLumberjack in the app and the extension to use the same file path/name, adding the group capability to the app and the extensions and specifying the shared group directory as the file path. By default, for an app, CocoaLumberjack writes its files to: var/mobile/Containers/Data/Application/05464D4A-20F6-4E1F-9DBC-3109C053A1E8/Library/Caches/Logs/ On a Mac using an application such as iExplorer the above file and be located and viewed and copied etc. For an extension, it writes them to: /var/mobile/Containers/Data/PluginKitPlugin/5542F5EA-EB3A-4728-B33E-4E57C1B7B3B4/Library/Caches/Logs/ Now if I configure Cocoalumberjack to instead write the logger file to the shared group directory, then that will be at: /private/var/mobile/Containers/Shared/AppGroup/6CD5AF2C-54C9-46EF-B831-997B1DD6664F/ However its not possible using iExplorer to access this location. Using a Mac connected to the iPhone, is there an app or tool etc., that will enable me to locate the log file if it's created in the above AppGroup location?

If I turn on (my company supplied VPN access) and then attempt to build with Xcode then that has the consequence that all the dev/distribution certificates in the keychain turn red and say "certificate is not trusted". Turning off VPN doesn't reset them back and of course re-attempting to build will fail. However if I reboot my MacBook, then the keychain is back in a good state again. However as I work remotely I constantly have to flick VPN on and off throughout the day, and having to reboot endlessly is a pain. Is there something I can do to reset the Keychain's certs to a good state without having to reboot? (and without having to delete them all and re-add them all back to the keychain).

I'm trying to report a crash report. Originally it was about 30,000 characters so I hoped it down until it was < 7000. But when I try and post I get a message saying the post is empty and the character could is negative. Tried multiple times, just can't post.

I'm occasionally getting a crash (on iOS) after a hang and termination by the OS. While reproducing it and watching the Mac console I don't see any obvious cause of the issue. There shouldn't be anything synchronous and long running in the main thread. Verbose logging is turned on, is it possible too much logging is causing this (its using NSLog for the console and also echoing logging to Crashlytics.log())? If so why is it not deterministic in its reproducibility? Here's a crash stack: > Exception Type: EXC_CRASH (SIGKILL) Exception Codes: 0x0000000000000000, 0x0000000000000000 Termination Reason: FRONTBOARD 2343432205 <RBSTerminateContext| domain:10 code:0x8BADF00D explanation:[application<com.appname>:3315] failed to terminate gracefully after 5.0s ProcessVisibility: Unknown ProcessState: Running WatchdogEvent: process-exit WatchdogVisibility: Background WatchdogCPUStatistics: ( "Elapsed total CPU time (seconds): 4.260 (user 2.150, system 2.110), 11% CPU", "Elapsed application CPU time (seconds): 0.022, 0% CPU" ) reportType:CrashLog maxTerminationResistance:Interactive> Triggered by Thread: 0 Thread 0 name: Dispatch queue: com.apple.main-thread Thread 0 Crashed: 0 libsystem_kernel.dylib 0x1dd27b7dc __ulock_wait + 8 1 libsystem_platform.dylib 0x1fe05efb0 _os_unfair_lock_lock_slow + 176 2 CoreFoundation 0x19e3a6648 _logToStderr + 148 3 CoreFoundation 0x19e421500 __CFLogCString + 84 4 CoreFoundation 0x19e34fc8c _CFLogvEx2Predicate + 344 5 CoreFoundation 0x19e35e548 _CFLogvEx3 + 252 6 Foundation 0x1986195c0 _NSLogv + 124 7 Foundation 0x198617f58 NSLog + 56 8 AppName 0x1042dd480 +[Logger trace:] + 70784 (Logger.m:48) 9 AppName 0x104311ae4 CallExtensionManager.appBecameActive() + 285412 (<compiler-generated>:0) 10 AppName 0x104312004 @objc CallExtensionManager.appBecameActive() + 286724 (<compiler-generated>:0) 11 CoreFoundation 0x19e2f2590 __CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER__ + 148 12 CoreFoundation 0x19e396828 ___CFXRegistrationPost_block_invoke + 88 13 CoreFoundation 0x19e3798b8 _CFXRegistrationPost + 440 14 CoreFoundation 0x19e306afc _CFXNotificationPost + 700 15 Foundation 0x1985d1d18 -[NSNotificationCenter postNotificationName:object:userInfo:] + 92 16 UIKitCore 0x1a05b61e8 -[UIApplication _stopDeactivatingForReason:] + 1236 17 UIKitCore 0x1a05b5c98 -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:] + 280 18 UIKitCore 0x1a05b5a84 -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 620 19 UIKitCore 0x1a05b5634 -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:] + 252 20 UIKitCore 0x1a05b5500 __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke + 148 21 UIKitCore 0x1a0ca2a68 +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:fromCurrentState:actions:completion:] + 736 22 UIKitCore 0x1a0d41074 _UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion + 224 23 UIKitCore 0x1a0462c70 -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] + 316 24 UIKitCore 0x1a08d41ac __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke.223 + 556 25 UIKitCore 0x1a0533c60 -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 216 26 UIKitCore 0x1a0533ad0 -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244 27 UIKitCore 0x1a0533910 -[UIApplicationSceneClientAgent scene:handleEvent:withCompletion:] + 336 28 FrontBoardServices 0x1b4340ac8 -[FBSScene updater:didUpdateSettings:withDiff:transitionContext:completion:] + 420 29 FrontBoardServices 0x1b4340904 __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke_2 + 152 30 FrontBoardServices 0x1b4344120 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168 31 FrontBoardServices 0x1b434403c __94-[FBSWorkspaceScenesClient _queue_updateScene:withSettings:diff:transitionContext:completion:]_block_invoke + 344 32 libdispatch.dylib 0x1a578beac _dispatch_client_callout + 20 33 libdispatch.dylib 0x1a578f91c _dispatch_block_invoke_direct + 264 34 FrontBoardServices 0x1b434e24c __FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK__ + 52 35 FrontBoardServices 0x1b434dde8 -[FBSSerialQueue _targetQueue_performNextIfPossible] + 220 36 FrontBoardServices 0x1b4350694 -[FBSSerialQueue _performNextFromRunLoopSource] + 28 37 CoreFoundation 0x19e38e128 __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ + 28 38 CoreFoundation 0x19e39a7b4 __CFRunLoopDoSource0 + 176 39 CoreFoundation 0x19e31f648 __CFRunLoopDoSources0 + 340 40 CoreFoundation 0x19e3350d4 __CFRunLoopRun + 828 41 CoreFoundation 0x19e33a3ec CFRunLoopRunSpecific + 612 42 GraphicsServices 0x1d985035c GSEventRunModal + 164 43 UIKitCore 0x1a06c6f58 -[UIApplication _run] + 888 44 UIKitCore 0x1a06c6bbc UIApplicationMain + 340 45 AppName 0x1042dfbf0 main + 80880 (main.m:7) 46 dyld 0x1bd86cdec start + 2220 Can't get the stack trace for Thread 0 to display nicely

Looking at some tutorials on how to create a swift package (for iOS) they all start by creating a package within Xcode and then showing what files Xcode auto-generated. However with Xcode 15.1 there's lots of stuff mentioned in tutorials which isn't getting created, for example the readme file, the licenses file, a documentation directory and contents. Why is it not creating them? How to add them manually then? Because File/New doesn't have the option to create a Readme.md file for example.

I created a message filter extension, then edited only a few lines from the template source code (for example to return something in the capabilities query). However no matter what I do, I just cannot get the app to appear in the Settings app - when I turn on "Filter Unknown Senders" there's nothing that appears to select my app. I've tried rebuilding, deleting/reinstalling the app, restarting the phone, it just won't appear. But then I switched to another phone, and with this phone, when I turn on "Filter Unknown Senders" my app does appear and can be selected and enabled. But I still cannot get this to happen on the first phone. Why does the exact same app, exact same build of the app to be precise, appear on one phone but not the other? The phone it works on has iOS 17.2.1 and the phone it doesn't work on has iOS 17.1.1

I have a hang log, too large to copy past all of it here. It showing [NSNotificationCenter postNotificationName:object:userInfo:] in the stack. Does that mean there was a hang attempting to post a notification? How could that cause a hang, once the app posts a notification its out of its hands and in the hands of the OS. Or is that a red herring? How do I attach the full .ips file? When trying to add it via the Add File option, its grey and not selectable, if I change the extension .txt it says its too large to attach. Also how to format this? Copy/pasting it looks fine, but after hitting the save button all the formatting is lost. Formatting it as quote or code block also looses it all. Event: Timed Out Runloop Hang Duration: 9.99s Duration Sampled: 3.57s Steps: 344 (10ms sampling interval) Report threshold: 2s `Heaviest stack for the main thread of the target process: 344 start + 2240 (dyld + 24012) [0x1d8996dcc] 344 ??? (CallFilter + 69812) [0x10006d0b4] 344 UIApplicationMain + 340 (UIKitCore + 2276456) [0x1b8080c68] 344 -[UIApplication _run] + 888 (UIKitCore + 2278956) [0x1b808162c] 344 GSEventRunModal + 164 (GraphicsServices + 13560) [0x1f91de4f8] 344 CFRunLoopRunSpecific + 608 (CoreFoundation + 210040) [0x1b5c5d478] 344 __CFRunLoopRun + 828 (CoreFoundation + 211096) [0x1b5c5d898] 344 __CFRunLoopDoSources0 + 340 (CoreFoundation + 215996) [0x1b5c5ebbc] 344 __CFRunLoopDoSource0 + 176 (CoreFoundation + 222120) [0x1b5c603a8] 344 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 (CoreFoundation + 225580) [0x1b5c6112c] 344 -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] + 28 (FrontBoardServices + 41848) [0x1ce0c4378] 344 -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] + 240 (FrontBoardServices + 42144) [0x1ce0c44a0] 344 FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK + 52 (FrontBoardServices + 42272) [0x1ce0c4520] 344 _dispatch_block_invoke_direct + 284 (libdispatch.dylib + 32072) [0x1bdc24d48] 344 _dispatch_client_callout + 20 (libdispatch.dylib + 17152) [0x1bdc21300] 344 __92-[FBSWorkspaceScenesClient createSceneWithIdentity:parameters:transitionContext:completion:]_block_invoke + 352 (FrontBoardServices + 106380) [0x1ce0d3f8c] 344 -[FBSWorkspace _calloutQueue_executeCalloutFromSource:withBlock:] + 168 (FrontBoardServices + 57756) [0x1ce0c819c] 344 __92-[FBSWorkspaceScenesClient createSceneWithIdentity:parameters:transitionContext:completion:]_block_invoke.108 + 280 (FrontBoardServices + 62832) [0x1ce0c9570] 344 -[FBSScene _callOutQueue_didCreateWithTransitionContext:completion:] + 324 (FrontBoardServices + 63188) [0x1ce0c96d4] 344 -[UIApplicationSceneClientAgent scene:didInitializeWithEvent:completion:] + 288 (UIKitCore + 2422752) [0x1b80a47e0] 344 -[UIApplication workspace:didCreateScene:withTransitionContext:completion:] + 508 (UIKitCore + 2423368) [0x1b80a4a48] 344 -[UIScene scene:didUpdateWithDiff:transitionContext:completion:] + 244 (UIKitCore + 1274564) [0x1b7f8c2c4] 344 -[UIScene _emitSceneSettingsUpdateResponseForCompletion:afterSceneUpdateWork:] + 216 (UIKitCore + 1274964) [0x1b7f8c454] 344 __64-[UIScene scene:didUpdateWithDiff:transitionContext:completion:]_block_invoke.225 + 612 (UIKitCore + 4964520) [0x1b83110a8] 344 -[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:] + 316 (UIKitCore + 1278672) [0x1b7f8d2d0] 344 _UISceneSettingsDiffActionPerformChangesWithTransitionContextAndCompletion + 224 (UIKitCore + 1279520) [0x1b7f8d620] 344 +[BSAnimationSettings(UIKit) tryAnimatingWithSettings:fromCurrentState:actions:completion:] + 736 (UIKitCore + 1281432) [0x1b7f8dd98] 344 __186-[_UIWindowSceneFBSSceneTransitionContextDrivenLifecycleSettingsDiffAction _performActionsForUIScene:withUpdatedFBSScene:settingsDiff:fromSettings:transitionContext:lifecycleActionType:]_block_invoke + 148 (UIKitCore + 1281680) [0x1b7f8de90] 344 -[_UISceneLifecycleMultiplexer uiScene:transitionedFromState:withTransitionContext:] + 248 (UIKitCore + 1281984) [0x1b7f8dfc0] 344 -[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:] + 608 (UIKitCore + 1283672) [0x1b7f8e658] 344 -[_UISceneLifecycleMultiplexer _performBlock:withApplicationOfDeactivationReasons:fromReasons:] + 332 (UIKitCore + 1289296) [0x1b7f8fc50] 344 __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke + 216 (UIKitCore + 2175308) [0x1b806814c] 344 _UIScenePerformActionsWithLifecycleActionMask + 112 (UIKitCore + 1621112) [0x1b7fe0c78] 344 __101-[_UISceneLifecycleMultiplexer _evalTransitionToSettings:fromSettings:forceExit:withTransitionStore:]_block_invoke_2 + 108 (UIKitCore + 1621280) [0x1b7fe0d20] 344 -[UIApplication _stopDeactivatingForReason:] + 1240 (UIKitCore + 1623808) [0x1b7fe1700] 344 -[NSNotificationCenter postNotificationName:object:userInfo:] + 92 (Foundation + 173988) [0x1b4bee7a4] 344 _CFXNotificationPost + 724 (CoreFoundation + 188728) [0x1b5c58138] 344 _CFXRegistrationPost + 440 (CoreFoundation + 191464) [0x1b5c58be8] 344 ___CFXRegistrationPost_block_invoke + 88 (CoreFoundation + 191648) [0x1b5c58ca0] 344 CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER + 148 (CoreFoundation + 193240) [0x1b5c592d8] Thread 0x403e DispatchQueue "com.apple.main-thread"(1) 344 samples (1-344) priority 47 (base 47) 344 start + 2240 (dyld + 24012) [0x1d8996dcc] 344 ??? (CallFilter + 69812) [0x10006d0b4] 344 UIApplicationMain + 340 (UIKitCore + 2276456) [0x1b8080c68] 344 -[UIApplication _run] + 888 (UIKitCore + 2278956) [0x1b808162c] 344 GSEventRunModal + 164 (GraphicsServices + 13560) [0x1f91de4f8] 344 CFRunLoopRunSpecific + 608 (CoreFoundation + 210040) [0x1b5c5d478] 344 __CFRunLoopRun + 828 (CoreFoundation + 211096) [0x1b5c5d898] 344 __CFRunLoopDoSources0 + 340 (CoreFoundation + 215996) [0x1b5c5ebbc] 344 __CFRunLoopDoSource0 + 176 (CoreFoundation + 222120) [0x1b5c603a8] 344 CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION + 28 (CoreFoundation + 225580) [0x1b5c6112c] 344 -[FBSMainRunLoopSerialQueue _performNextFromRunLoopSource] + 28 (FrontBoardServices + 41848) [0x1ce0c4378] 344 -[FBSMainRunLoopSerialQueue _targetQueue_performNextIfPossible] + 240 (FrontBoardServices + 42144) [0x1ce0c44a0] 344 FBSSERIALQUEUE_IS_CALLING_OUT_TO_A_BLOCK + 52 (FrontBoardServices + 42272) [0x1ce0c4520] 344 _dispatch_block_invoke_direct + 284 (libdispatch.dylib + 32072) [0x1bdc24d48]

An app is hanging randomly on app launch, after looking into it, it appears it's hanging on a call to UNUserNotificationCenter.current() calls. I say this because there's logging and the sometimes the last line logged is prior to a call to UNUserNotificationCenter() I have a hang log (.ips file) rom the iPhone and at the bottom it says this. I presume blockingThreadInfo is talking about the thread being blocked, and it identifies the topBlockingProcess as user notifications. "blockingThreadInfo" : { "topBlockingProcess" : "usernotificationsd", The following is the code, why would this code cause a hang? The problem occurs when there's lots of notifications that have been posted i.e. something like 100. [[NSNotificationCenter defaultCenter] addObserver:self selector:@selector(appBecameActive) name: UIApplicationDidBecomeActiveNotification object:nil]; @objc func appBecameActive() { method1() method2() } @objc func method1() { UNUserNotificationCenter.current().getDeliveredNotifications { notifications in if SettingsManager.isProductionFinalBuild() == false { // Log notification center contents for notification in notifications { let title = notification.request.content.title let targetId = notification.request.content.targetContentIdentifier let threadId = notification.request.content.threadIdentifier let categoryIdentifer = notification.request.content.categoryIdentifier let identifier = notification.request.identifier let info = notification.request.content.userInfo Logger.trace("Previously delivered notification: title: \(title) identifier: \(identifier) threadId: \(threadId) category: \(categoryIdentifer) target id: \(String(describing: targetId)) userInfo: \(info)") } let matchchingNotifications = notifications.filter({ $0.request.identifier == kMdnAccountNotFoundNotificationIdentifier }) UNUserNotificationCenter.current().removeDeliveredNotifications(withIdentifiers: [kMdnAccountNotFoundNotificationIdentifier]) } } func method2() { UNUserNotificationCenter.current().removePendingNotificationRequests(withIdentifiers: [Constants.kWhatsNewNotificationIdentifier]) UNUserNotificationCenter.current().removeDeliveredNotifications(withIdentifiers: [Constants.kWhatsNewNotificationIdentifier]) }

I've installed the same developer certificate onto three different Macs. When viewed in the keychain (or in Xcode) on one Mac it says its revoked, on another it says its not trusted, but on a third there's no issue reported. How could there be a difference between the three Macs? (Both Macs have the date/time set to be the same). Can 3rd party software, VPNs etc. interfere in this at all?