TestFlight sends automatic e-mail notifications to beta testers, with the subject "AppName 1.2.3 (123) for iOS is now available to test." etc. At the bottom of these messages is an "Unsubscribe" link, which is a mailto: link that sends an e-mail to the app's support contact address with of the form mailto:developer?subject=Unsubscribe from TestFlight&body=tester wants to stop receiving TestFlight emails about AppName Unfortunately, app developers cannot manage an individual testers' notification settings. This creates a frustrating support loop where the developer has to reply directing the tester to disable e-mail notifications for themselves within the TestFlight app. Am I missing something? (Also reported to Apple as FB19806347)

The developer downloads page now lists an Xcode 26.1 which was released on 11th Dec (the original Xcode 26.1 was posted on 3rd Nov). Strangely, this new Xcode 26.1 has a CFBundleShortVersionString of 26.1.1, and a DTXcodeBuild of 17B55 % ls -ln total 4413136 -rw-r--r--@ 1 503 20 2259523057 16 Dec 19:01 Xcode_26.1_Apple_silicon.xip % xip --expand Xcode_26.1_Apple_silicon.xip xip: signing certificate was "Software Update" (validation not attempted) xip: expanded items from "/Users/me/Downloads/temp/Xcode_26.1_Apple_silicon.xip" % plutil -p Xcode.app/Contents/Info.plist | grep CFBundleShort "CFBundleShortVersionString" => "26.1.1" % plutil -p Xcode.app/Contents/Info.plist | grep DTXcodeBuild "DTXcodeBuild" => "17B55" 17B55 does correspond to the original Xcode 26.1 final release. The Xcode 26.1.1 release that was previously posted had a DTXcodeBuild of 17B100, though. The pairing of 26.1.1 and 17B55 looks new and probably a packaging error?

We have been getting several reports in the past 2 weeks of APNs notifications being either heavily delayed or not delivered at all. We have two apps, one of which has a Notification Service Extension and one of which does not. We have had users of both reporting sporadic notification problems. Looking at the sysdiagnose logs from one example, it looks like the notification was actually processed by our notification extension in a timely fashion, but was not displayed to the user. An example event we investigated it the following (now perhaps a little long in the tooth): 2025-10-31T14:32:54 apnsId=EE3E002D-26DE-B4F5-5E9B-5E0C1E1B6B3D We think we have correlated this with device logs: default 2025-10-31 10:32:54.472054 -0400 [EDE9521D-8A65-4588-8AE8-D3D78B9E5EA5] Received replacement content for notification request 859D-ABC7 [ hasContent: 1 attachments: 0 ] However there is no other reference until the app was launched about 1.5 minutes later: default 2025-10-31 10:34:26.875327 -0400 [..] Got 1 delivered notifications [ hasCompletionHandler: 1 ] When trying to reproduce, when I saw notifications bannered, the trace I saw was "Got 0 delivered notifications". What's the significance of "Got 1 delivered notifications" in this case? Historically, SpringBoard logs have shown detailed trace about the handling of notifications (which was very useful in narrowing down the slowness of notifications due to Apple Intelligence, reported on our side as FB16253547, which doesn't seem to have been triaged but it looks like was resolved around iOS 18.2.1 or iOS 18.3); however it seems that now sysdiagnoses are only containing <1 minute of trace from SpringBoard. Is there any way to extend the trace from SpringBoard that is included in sysdiagnoses? I see there was also https://developer.apple.com/forums/thread/806367 around the same time we started receiving reports. However I think my hypothesis is that this is a client-side issue, and notifications are being delivered to devices, just not presented correctly. Will try and collect a bit more data and file some Feedbacks and provide them here, but wanted to also flag here in case there are any others experiencing similar.