Overview

I’m trying to diagnose an APNs provider authentication issue that began after APNs had previously been working. Summary: My iOS app can register for remote notifications and successfully sends its device token to my server. The app has the Push Notifications capability enabled in Xcode, the Bundle ID has Push Notifications enabled in Certificates, Identifiers & Profiles, and the APNs key is active in the Apple Developer portal. However, every server-side APNs send attempt now fails with: HTTP 403 {"reason":"InvalidProviderToken"} This happens against both sandbox and production APNs endpoints. App / account details: Bundle ID / apns-topic: app.terrasignal Team ID: 837F2XGDX Current APNs Key ID: HNW7XPK2H3 APNs key type: Apple Push Notifications service (APNs) Key configuration: Team scoped, Sandbox & Production Xcode signing team: David Buck / Team ID 837F2XGDX Push Notifications capability is enabled in Xcode Device token environment tested: sandbox Server clock verified against Apple/date header and matches UTC What works: iOS app launches successfully Push permission is granted Device token is generated Device registers with my server successfully Server stores the token as sandbox for bundle app.terrasignal What fails: Server-to-APNs provider authentication Direct HTTP/2 APNs request fails before notification delivery Failure reason is always InvalidProviderToken I tested three separate APNs keys: 34T746MWFV T9N75GU2AV HNW7XPK2H3 Each key was downloaded from the Developer portal, uploaded to the server, verified as a valid .p8 private key, and used with its matching Key ID. All produce the same InvalidProviderToken result. I also bypassed my APNs library and tested direct HTTP/2 + JOSE JWT signing. The direct APNs test also fails with the same response: HTTP status: 403 Response body: {"reason":"InvalidProviderToken"} Example direct APNs test details: Host: api.sandbox.push.apple.com Path: /3/device/ apns-topic: app.terrasignal apns-push-type: alert apns-priority: 10 JWT header: {"alg":"ES256","kid":"HNW7XPK2H3"} JWT payload includes iss: 837F2XGDX and current iat Key imports successfully with jose importPKCS8 JWT is generated successfully APNs rejects it with InvalidProviderToken I also tried production endpoint with the same result: Host: api.push.apple.com HTTP 403 {"reason":"InvalidProviderToken"} Things verified: System clock is correct Docker/server UTC time matches Apple Date header Bundle ID topic is app.terrasignal APNs key exists in the Apple Developer portal APNs service is enabled on the key Key is configured for Sandbox & Production Push Notifications capability is enabled for the app Xcode signing uses the same team The .p8 file is not empty or malformed The key imports successfully via jose/importPKCS8 The issue occurs before APNs evaluates the device token, because authentication fails first Question: What Apple-side account/key/app configuration state can cause multiple active APNs auth keys for the same team to return InvalidProviderToken, even when: the key is active, APNs is enabled, the Team ID matches, the Bundle ID topic matches, the server clock is correct, and a direct HTTP/2 APNs request with manually generated ES256 JWT also fails? Is there a way to force-refresh, repair, or re-sync APNs provider authentication for a Developer account / Bundle ID / APNs key?

I have created a SwiftData iOS app from Paul Hudson's Hacking With Swift series in order to troubleshoot some SwiftData issues I am having in a separate app. I have raised > FB22925785 I have gone back to basics to try and problem solve so I have used the first part of an app of Paul's from [https://www.hackingwithswift.com/quick-start/swiftdata/defining-a-data-model-with-swiftdata] The App is very simple and only contains the following import SwiftData import SwiftUI @main struct iTour_from_scratchApp: App { var body: some Scene { WindowGroup { ContentView() .modelContainer(for: Destination.self) } } } The data is import SwiftData @Model class Destination { var name: String var details: String var date: Date var priority: Int init(name: String, details: String, date: Date, priority: Int) { self.name = name self.details = details self.date = date self.priority = priority } } The view is import SwiftUI struct ContentView: View { var body: some View { VStack { Image(systemName: "globe") .imageScale(.large) .foregroundStyle(.tint) Text("Hello, world!") } .padding() } } #Preview { ContentView() } When I try to run this, I am getting 889 lines of CoreData errors appearing in the Console and they start with CoreData: error: Failed to stat path '/Users/chrissantavy/Library/Developer/CoreSimulator/Devices/913BFD87-5FD8-47B9-AD0C-81238E74E89E/data/Containers/Data/Application/29586FDF-F08D-48E8-AF58-FD7BD5A30525/Library/Application Support/default.store', errno 2 / No such file or directory. CoreData: error: Executing as effective user 501 CoreData: error: Executing as effective user 501 CoreData: error: Sandbox access to file-write-create denied CoreData: error: Sandbox access to file-write-create denied CoreData: error: Failed to statfs file; errno 2 / No such file or directory. CoreData: error: Failed to statfs file; errno 2 / No such file or directory. CoreData: error: Information for file system CoreData: error: Information for file system CoreData: error: --------------------------- CoreData: error: --------------------------- CoreData: error: File system type: 0 CoreData: error: File system type: 0 CoreData: error: File system flags: 0 CoreData: error: File system flags: 0 CoreData: error: Total data blocks: 0 CoreData: error: Total data blocks: 0 CoreData: error: Free data blocks: 0 CoreData: error: Free data blocks: 0 CoreData: error: Free blocks for nonsuperuser: 0 CoreData: error: Free blocks for nonsuperuser: 0 CoreData: error: Total i-nodes: 0 CoreData: error: Total i-nodes: 0 CoreData: error: File system ID: 0, 0 CoreData: error: File system ID: 0, 0 CoreData: error: Free i-nodes: 0 CoreData: error: Free i-nodes: 0 CoreData: error: Owner UID: 0 CoreData: error: Owner UID: 0 CoreData: error: Filesystem type name: CoreData: error: Filesystem type name: CoreData: error: Mount on name: CoreData: error: Mount on name: CoreData: error: Mount from name: CoreData: error: Mount from name: CoreData: error: Failed to stat path '/Users/chrissantavy/Library/Developer/CoreSimulator/Devices/913BFD87-5FD8-47B9-AD0C-81238E74E89E/data/Containers/Data/Application/29586FDF-F08D-48E8-AF58-FD7BD5A30525/Library/Application Support', errno 2 / No such file or directory. CoreData: error: Failed to stat path '/Users/chrissantavy/Library/Developer/CoreSimulator/Devices/913BFD87-5FD8-47B9-AD0C-81238E74E89E/data/Containers/Data/Application/29586FDF-F08D-48E8-AF58-FD7BD5A30525/Library/Application Support', errno 2 / No such file or directory. CoreData: error: Executing as effective user 501 The full list of errors is attached iTour from scratch Part-1 errors.txt

Nothing changed on my end, Pro subscription still active, but Xcode 26.5 (17F42) simply does not want to log into Codex anymore. It opens the OAuth flow and after finishing and closing the window, it still says "Not Signed In". Codex login works everywhere else, including the Codex app. What to do?

My app is for a client that facilitates construction draws for construction companies. The app is stuck in a rejection loop for this reason: Guideline 3.2.1(viii) - Business - Other Business Model Issues - Acceptable Issue Description The app still provides loan services but does not meet all the requirements for apps providing these services. See below for additional information. These requirements give App Store users confidence that apps offering financial services are qualified to provide these services and will responsibly manage their data. Next Steps It would be appropriate to take the following steps to resolve this issue: The app facilitates loan or credit applications but you have not provided loan or business license documentation that demonstrates the app is authorized to provide these services. The client does not lend to consumers, nor individuals, and the client operates in states that do not require a lending license (including NMLS) to provide financing (such as construction draws) to construction companies. What documentation would app store review accept? I've tried written explanations in response to no avail.

I updated my OS to Tahoe 26.5 several days ago. Now, I'm developing a new macOS application under it. What I notice about it is that it can take the application at several seconds to select a file or a folder with NSSavePanel, NSOpenPanel and .fileImporter. First, I thought it's just my application. But it's not. Preview acts the same. First, a progress wheel keeps rolling several seconds. Then it will disappear, and you won't be able to select a folder for another several seconds. Why do they make it more difficult to use every time they release a new OS version? Why don't Reviewers notice when they test it? Wait for 10 seconds or more just to select a file or a folder? It's disappointing. I wish I could go back to macOS 15.7.

Hoping this might peak someones interest regarding proxy authorisation handling specifically during a device's SetupAssistant phase. Our problem in this instance relies with the AuthBroker's handling of proxy authorisation challenges. With Apple's devices proxy auth is handled through AuthBroker which will make subsequent calls to GSS/ keychain if applicable to handle proxy Auth with CFNetwork. Whilst this process functions quite well in the large part it's functionality around prompt suppression causes issues during the setupAssistant phase. To avoid prompt fatigue AuthBroker Agent has a flag for a given proxy authorisation host (combination of host + port) that's responsible for reporting if a system prompt has been raised in the past. If it has AuthBroker will suppress prompting for the active session. This creates a problem with SetupAssistant in that AuthBroker agent is not allowed to raise system prompts in this state. As a result it instaed triggers a default not now handling: default 2026-04-27 20:34:43.565424 -0700 AuthBrokerAgent [0x100a7ee60] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[119].0x100a7ee60 default 2026-04-27 20:34:43.565608 -0700 AuthBrokerAgent [0x100a80350] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[158].0x100a80350 default 2026-04-27 20:34:43.565924 -0700 AuthBrokerAgent Fetching proxy credential for query <private> default 2026-04-27 20:34:43.566135 -0700 AuthBrokerAgent Request <private> 0x65a873860 default 2026-04-27 20:34:43.567245 -0700 AuthBrokerAgent Not internal release, disabling SIRL default 2026-04-27 20:34:43.576369 -0700 AuthBrokerAgent CFNetwork Diagnostics [3:1] 20:34:43.575 { CopyDefaultCredential: (null) Store: shared credential storage 0x100a7d320, session 0xad7010040, persistent 0x100a7d3e0 Space: https://someproxy.example.com:3128/, NTLM (Hash 774a6617a1f9d1ae) Result: null } [3:1] default 2026-04-27 20:34:43.576451 -0700 AuthBrokerAgent Prompting user 0x65a873860 default 2026-04-27 20:34:43.578299 -0700 AuthBrokerAgent Cache loaded with 6300 pre-cached in CacheData and 69 items in CacheExtra. default 2026-04-27 20:34:43.606794 -0700 AuthBrokerAgent User selected alternate response, won't prompt again 0x65a873860 default 2026-04-27 20:34:43.606820 -0700 AuthBrokerAgent Not sending a credential 0x65a873860 default 2026-04-27 20:34:43.606829 -0700 AuthBrokerAgent Fetching proxy credential complete result (null) This flows onto Authbroker requests executed after setupAssistant and prevents the device from prompting until an effective restart: default 2026-04-28 13:37:46.710956 +1000 Setup Buddy exiting... default 2026-04-28 13:38:06.658658 +1000 AuthBrokerAgent [0xad6864000] activating connection: mach=false listener=false peer=true name=com.apple.cfnetwork.AuthBrokerAgent.peer[278].0xad6864000 default 2026-04-28 13:38:06.659238 +1000 AuthBrokerAgent Fetching proxy credential for query <private> default 2026-04-28 13:38:06.661957 +1000 AuthBrokerAgent Request <private> 0xa4eccc760 default 2026-04-28 13:38:06.662597 +1000 AuthBrokerAgent SecSecurityClientGet new thread! default 2026-04-28 13:38:06.813050 +1000 AuthBrokerAgent CFNetwork Diagnostics [3:7] 13:38:06.809 { CopyDefaultCredential: (null) Store: shared credential storage 0x100a7d320, session 0xad7010040, persistent 0x100a7d3e0 Space: https://someproxy.example.com:3128/, NTLM (Hash 774a6617a1f9d1ae) Result: null } [3:7] default 2026-04-28 13:38:06.813088 +1000 AuthBrokerAgent Will not prompt since user previously dismissed prompt 0xa4eccc760 default 2026-04-28 13:38:06.813091 +1000 AuthBrokerAgent Not sending a credential 0xa4eccc760 default 2026-04-28 13:38:06.814867 +1000 AuthBrokerAgent Fetching proxy credential complete result (null) Is there any chance to get this handling updated so that SetupAssistant reset AuthBroker's prompting state on conclusion to allow for system prompt exposure to the user without requiring a device restart.

I’m seeing a Bluetooth call audio routing issue on a new iPhone 17 Pro running iOS 26.5.1, build 23F81. Bluetooth media audio works normally. Music and video audio stay on Bluetooth headphones without issues. The problem appears only when the device switches into call audio / HFP mode. Tested with multiple earbuds: Samsung, OPPO, Huawei and CMF Buds Pro 2. The behavior is similar with all of them. There are no other Bluetooth devices connected. Call Audio Routing is already set to Bluetooth Headset in Accessibility settings. The issue affects cellular calls, FaceTime Audio, Telegram and Signal. In some cases the earbuds seem to switch into call mode, but the call audio route falls back to the iPhone receiver or speaker instead of staying on the Bluetooth headset. After the call ends, Bluetooth media audio returns normally. I captured a sysdiagnose right after reproducing the issue. Relevant observations from the logs: Device: iPhone18,2 iOS: 26.5.1 Build: 23F81 Sysdiagnose time: 2026-06-03 11:22:03 +0300 In Bluetooth/CoreCapture/bluetooth_status.txt, Bluetooth was ON 3 paired devices were present 1 device was connected Connected device at the time: CMF Buds Pro 2 So the headset was not simply disconnected from the phone. In the powerlog, before the call the audio route was HeadphonesBT for media playback. Around the FaceTime Audio test, HeadsetBT / PhoneCall appeared, but then the route moved to ReceiverAndMicrophone / Speaker instead of staying on HeadsetBT. During a later cellular call, the active PhoneCall route was also ReceiverAndMicrophone rather than HeadsetBT. After the call ended, the route returned to HeadphonesBT for media playback. This looks like the Bluetooth connection remains alive, but call audio / HFP routing fails. The same sysdiagnose also contains CentauriFirmwareEvent entries under crashes_and_spins from the previous day. They show: subsystem = BT host-reason = firmware crash BTMAIN panic faulting_task = link_manager_thread LMAC_5G watchdog expired SCAN watchdog expired These firmware crash events do not happen at the exact same timestamp as the call test, so I’m not claiming that every call directly crashes Bluetooth firmware. But the sysdiagnose shows both incorrect Bluetooth call audio routing and separate BT firmware crash events. Has anyone seen similar behavior on iPhone 17 / iOS 26 with Bluetooth HFP call audio? Could this be a known iOS 26 / Apple N1 / Bluetooth firmware issue, or does it look more like a hardware defect of this particular device?

Hello, I’m trying to clarify whether the new Age Range / Age Assurance Setup Assistant pane can be skipped on macOS when using a standard MDM Device Enrollment flow, not Automated Device Enrollment. Environment: Platform: macOS Tahoe 26.5.1 Enrollment type: MDM Device Enrollment, not ADE / DEP MDM: Microsoft Intune Profile deployment channel: Device profile Payload type: com.apple.SetupAssistant.managed Key used: SkipSetupItems Skip items tested: AgeAssurance AgeBasedSafetySettings The configuration profile installs successfully on the Mac as a device profile. I can confirm that the com.apple.SetupAssistant.managed payload is present on the device and includes the tested SkipSetupItems values. However, the Age Range / age-related Setup Assistant pane is still shown to the user. Example payload content: <dict> <key>PayloadType</key> <string>com.apple.SetupAssistant.managed</string> <key>PayloadIdentifier</key> <string>com.example.setupassistant.managed</string> <key>PayloadUUID</key> <string>REDACTED-UUID</string> <key>PayloadVersion</key> <integer>1</integer> <key>PayloadDisplayName</key> <string>Managed Setup Assistant</string> <key>SkipSetupItems</key> <array> <string>AgeAssurance</string> <string>AgeBasedSafetySettings</string> </array> </dict> What I expected: When the com.apple.SetupAssistant.managed payload is installed as a device-level profile and includes the relevant age-related skip keys, the Age Range / Age Assurance pane should be skipped during Setup Assistant, or Apple documentation should state clearly that this pane can only be skipped in ADE. What actually happens: The profile installs, but the Age Range / age-related Setup Assistant pane still appears to the user on macOS 26.5.1. Documentation ambiguity: Apple’s Setup Assistant payload documentation says: The supported payload identifier is com.apple.SetupAssistant.managed Supported operating systems/channels include macOS device and macOS user Supported enrollment methods include User Enrollment, Device Enrollment, and Automated Device Enrollment SkipSetupItems is a list of Setup Assistant panes that can be skipped Apple’s macOS Tahoe 26 enterprise notes say: “The new Age Range setup pane is automatically skipped for devices using Automated Device Enrollment.” That wording clearly mentions ADE, but I have not found documentation that explicitly states whether the Age Range pane is intentionally unsupported for non-ADE macOS MDM enrollment, or whether there is a separate skip key required for macOS. Third-party MDM/tooling documentation appears to reference the following newer skip keys: AgeAssurance AgeBasedSafetySettings However, it is unclear whether those keys are supported on macOS, iOS/iPadOS only, ADE only, or all MDM enrollment methods. Questions: Are AgeAssurance and AgeBasedSafetySettings valid SkipSetupItems values on macOS 26.5.1? If yes, are they supported only during Automated Device Enrollment, or should they also work with standard MDM Device Enrollment? If these keys are iOS/iPadOS-only, what is the correct macOS skip item for the Age Range / age-related Setup Assistant pane? Is the Age Range pane intentionally only auto-skipped in ADE on macOS? Should Apple’s public Device Management / SkipKeys documentation be updated to list the correct key names, supported platforms, minimum OS versions, and enrollment requirements? This is important for Mac deployments where devices are enrolled into MDM but are not assigned through Apple Business Manager / Automated Device Enrollment. At the moment, it is difficult to determine whether the behavior is expected, unsupported, or a bug in macOS / Setup Assistant / MDM profile handling. Thanks.

Hi all, Our app has been waiting for review for over two weeks with no movement and no response to the support ticket we raised. App name: Winedrops Apple ID: 6450928882 Originally submitted: 19 May 2026 Resubmitted: 26 May 2026 Current status: Waiting for Review (never moved to "In Review") The app is a UK wine subscription service — nothing in the categories that usually draw longer scrutiny. We've raised a ticket with Developer Support but haven't had a reply. We're not asking for special treatment, just a status check or any indication of whether something is holding it up. If anyone from App Review sees this, we'd be grateful for a look. And if other developers are seeing similar waits this week, it'd help to know it's a backlog rather than a flag on our account. Thanks.

Hi guys, we are trying to implement In-App Provisioning for our banking application. After some iterations of determining responsibilities for providing data, we managed to gather all info required, but the process is failing. When user tries to provision a card, the Provisioning UI flow stops after selecting a device to provision the card on. It presents an alert: "Could Not Add Card", and offers just "Set Up Later". Further investigation (Console.app) shows that PassbookUIService has an error saying: [qv4t2XcQQ1G+AWP9HINjFQ] ProvisioningOperationComposer: Step 'eligibility' failed with error <PKProvisioningError: severity: 'terminal'; internalDebugDescriptions: '( "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > Also, when filtering Console output by my SEID, I can see that the request is failing with HTTP 500 code: default 15:09:22.599860+0200 PassbookUIService Response: https://pr-pod10-smp-device.apple.com:443/broker/v4/devices/???/cards 500 Time profile: 0.274013 seconds { Server = "Apple" Content-Type = "text/html" X-Content-Type-Options = "nosniff" Strict-Transport-Security = "max-age=31536000; includeSubdomains" Date = "Wed, 03 Jun 2026 13:09:22 GMT" X-Frame-Options = "SAMEORIGIN" X-XSS-Protection = "1; mode=block" Cross-Origin-Opener-Policy = "same-origin" Content-Length = "170" Connection = "close" } <html> <head><title>500 Internal Server Error</title></head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>Apple</center> </body> </html> I've submitted a Feedback assistant with the guidelines found here. Feedback ID: FB22924636 (In-App Provisioning failing) Would appreciate if anyone has some pointers as to what to focus on to resolve this issue. Thank you!

Requesting com.apple.managed-keychain Entitlement for Enterprise S/MIME Cert Visibility Platform: iOS | Distribution: MDM (Microsoft Intune) | Not App Store We are developing an internal enterprise iOS app (EMS Assist, com.company.supportcompanion) for Company deployed exclusively to Intune-managed devices. Our requirement: Read S/MIME certificates pushed to the device via Intune SCEP profiles to: Confirm cert presence in the MDM-managed keychain Read expiry date (kSecAttrNotValidAfter) to warn users before expiry Distinguish between missing, expired, and valid cert states What we have tried: Standard SecItemCopyMatching query — returns only app-installed certs, not MDM-pushed certs Graph API (deviceConfigurationStates) — confirms profile compliance but does not expose actual cert expiry or keychain presence Our understanding: com.apple.managed-keychain is required for an app to access MDM-managed keychain items on supervised devices, combined with a matching keychain-access-groups entitlement and the cert profile configured as "always available" in MDM. Questions: Is com.apple.managed-keychain the correct entitlement for this use case? Does it apply to SCEP/PKCS-issued certificates specifically, or only other MDM keychain items? Has anyone successfully accessed Intune-pushed S/MIME certs from an iOS app using this entitlement? Any guidance from the community or Apple engineers would be appreciated.

Hello App Review Team, I wanted to follow up because my app, BitzaHugs, is still showing as Waiting for Review, and I was informed that my case was expedited and in active review. I addressed all previously cited rejection issues and resubmitted the app, but I am still waiting for the review to move forward. App Name: BitzaHugs Support Case #: 102903001544 Current Status: Waiting for Review Expedited Review: Requested again / currently active I completely understand that review times can vary, but because my app has already gone through multiple rejection cycles, the issues have been resolved, and my intended launch date has passed, I would greatly appreciate any update or escalation if possible. Please let me know if there is anything else needed from my side to help move the review forward. Thank you again for your time and assistance, Amanda Benavidez

Hi, I'm the Account Holder and I can't renew our membership because the "Renew Membership" button is missing everywhere, the Apple Developer website, the Developer app on Mac, and the Developer app on iPhone. App Store Connect only shows the message telling me to renew on developer.apple.com, where no button appears. The contact form also returns "There was a problem processing your request," so I haven't been able to reach support through normal channels. I believe I know the cause. Last year, on Apple's advice, I renewed via the in-app subscription route, which tied the membership to an App Store subscription on a personal Apple ID. I cancelled that subscription immediately afterward, because the membership needs to be billed to our company, not a personal account. My working theory is that the account is still flagged to renew via that (now-cancelled, non-existent) in-app subscription, which is why the web Renew Membership button never reappears. What I need: please reset the account's renewal method off the cancelled in-app subscription so the standard Renew Membership button returns and I can renew on the web as the Account Holder, billed to our company. Two related points for whoever picks this up: Our membership expires June 7, so this is time-sensitive. We're a company and need the renewal billed to the company Account Holder Apple ID with a proper invoice, not a personal App Store receipt, so the in-app subscription route is not an option for us this time. Happy to provide the Team ID and account details privately. Is this something that can be reset on your end, and is there anything I should do in the meantime? Thanks.

I have a developer subscription with my username@workemail dot com and I'm trying to get an Enterprise Developer account with my .appleaccount.com address and it has been pending for a few weeks. I can't send in a support as it default to my work email and it won't take it.

My app has been stuck in "Waiting for Review" for at least a week since my submission. Normally it only takes 2-3 days to be reviewed but since I submitted my app last week, the status stuck at "Waiting for Review" without any feedbacks or comments. I feel very helpless now, I don't know if I should revert my submission and do it again, but I have concerns that it will only reset my time for waiting... Is it just me or my other fellow developers are facing similar issue? Is there any channel from Apple where we can get support or help from? Thank you in advance!

Actual Result: After showPicker(for:), the system AccessorySetupUI RemoteAlert brings up a remote keyboard. User taps are dispatched to AccessorySetupUI’s UIRemoteKeyboardWindow instead of the picker content window. App-side endEditing(true) / resignFirstResponder cannot dismiss it because the keyboard belongs to the system AccessorySetupUI remote scene. Key Evidence: 19:51:54.066: App window snapshot before showPicker has no UITextEffectsWindow. 19:51:54.009968: ASAccessorySession ### showPickerWithDisplayItems 19:51:54.013299: AccessorySetupUI showPickerWithOverrideBundleID 19:51:54.051591: AccessorySetupUI reports remote keyboard onscreen, frame {{0, 623}, {440, 333}} 19:51:54.095643: display layout shows com.apple.AccessorySetupUI foreground and com.osmo.tech obscured. 19:51:56.207/19:51:56.305: touch events are sent to and logged as KeyboardTouch touch down/up. Questions for Apple: Is AccessorySetupKit picker expected to show a keyboard when no text input is focused? Is it a system bug that UIRemoteKeyboardWindow covers/intercepts the “Find Accessories” action? Is there any public API for a third-party app to dismiss the keyboard inside AccessorySetupUI RemoteAlert? If this is expected behavior, what is the recommended workaround or required picker/display item configuration?

I've read Quinn's response on thread 827096 about Developer ID notarization submissions held for "in-depth analysis" on new teams. That guidance fits the general shape of what I'm seeing, but I'm posting a separate thread because (a) my situation does not involve an app transfer — these are the first-ever notarizations under a newly activated team, and (b) I've passed the "usually clears in a day or two" expectation and want to ask a few specific questions that thread didn't cover. Setup macOS app distributed outside the App Store Rust universal binary (aarch64-apple-darwin + x86_64-apple-darwin, merged via lipo) Binary signed with Developer ID Application, hardened runtime (--options runtime) and Secure Timestamp (--timestamp) .pkg built via pkgbuild + productsign with Developer ID Installer Team was activated 2026-05-29 — these are our first notarizations under the account, no prior submission history Submissions Submission A — submitted 2026-05-29T19:18:02Z, currently 100+ hours In Progress Submission B — submitted 2026-06-01, currently 30+ hours In Progress, identical polling behavior (Submission IDs available to DTS on request — happy to share via DM or via the Apple Developer Support case we have open on the same issue.) I submitted B specifically to test whether A was a one-off stuck queue entry. Both stalling identically rules that out and points at a team-level condition rather than a per-submission issue. xcrun notarytool log returns Submission log is not yet available or submissionId does not exist for both — same as the OP's experience on 827096. Local verification — every check in TN2206 passes $ pkgutil --check-signature .pkg Status: signed by a developer certificate issued by Apple for distribution Signed with a trusted timestamp on: 2026-05-29 19:15:36 +0000 Certificate Chain: Developer ID Installer: () Developer ID Certification Authority Apple Root CA $ codesign --verify --strict --verbose=2 valid on disk satisfies its Designated Requirement $ codesign --display --verbose=4 | grep -E '^(Authority|Timestamp|Runtime|TeamIdentifier)=' Authority=Developer ID Application: () Authority=Developer ID Certification Authority Authority=Apple Root CA Timestamp=May 29, 2026 at 12:13:40 PM TeamIdentifier= Runtime Version=26.5.0 xcrun notarytool history returns successfully and lists both submissions, so authentication and connectivity to the notary service are healthy. Developer System Status has shown the Developer ID Notary Service as "Available" throughout. Questions for DTS (Quinn or whoever picks this up) Quinn's 827096 reply describes "in-depth analysis" for new teams clearing in a day or two. Is there a known long-tail beyond that window, and is there anything a team can do to flag itself as ready for processing rather than waiting passively? Does resubmitting (as I did with submission B) extend, restart, or sit independently from the review of submission A? Is the review-completion clock driven by the team's activation date, the first submission, or the cumulative submission history? In other words, does each new submission help the team's signal, or does the system wait for the first to fully clear before evaluating subsequent ones? If we hit the 1-week mark Quinn referenced as the escalation tripwire without resolution, what's the recommended channel — a follow-up reply here, a new thread, Feedback Assistant, or another route? We also have an open Apple Developer Support case on this, currently silent for 4 days. Working that channel in parallel. Thanks in advance for any guidance — and thanks to Quinn for the public visibility he's given this pattern on 827096; it's the most useful documentation on it I've been able to find.

I have an iOS app (SwiftUI) that includes recurring subscriptions. To allow users to manage their subscriptions I have implemented manageSubscriptionsSheet according to apple documentation. When I published the app last year for iOS17 and iOS18 this was working well. Now I have gotten a user report that this features yields No connection error instead of the abonnements on iOS26. I have tested on my iPad running iOS 26 as well as on the simulator with iOS 26 and 18. In all cases I get the error. I can press Retry in the dialog and am prompted for AppStore credentials After entering them, again the same error. I can not find a single hint on why and how to fix it. Best wishes, Volker

wifip2pd leaks file descriptors during repeated Wi-Fi Aware NDP cycles → EMFILE → Wi-Fi Aware permanently broken Summary Under repeated Wi-Fi Aware (NAN) datapath connect/teardown cycles, wifip2pd leaks file descriptors until it hits the per-process limit (EMFILE, "Too many open files"). After that, wifip2pd can no longer create the socket needed to configure the nan0 interface, so updating the nan0 IPv6 link-local address fails with Apple80211Error Bad file descriptor. From the app's side, the NDP datapath is established but the NetworkConnection never gets a local IPv6 address and stays stuck in .preparing. The condition does not self-heal and is not cleared by restarting the app — only a reboot (or wifip2pd restart) recovers Wi-Fi Aware. Configuration iPhone 16 Pro Max, iOS 26.5 Network framework (new Swift NetworkConnection / NetworkBrowser Wi-Fi Aware API) System component: wifip2pd Where the problem is The leak and the failure are entirely inside wifip2pd (the per-process descriptor table fills up). The chain is: fd leak in wifip2pd → EMFILE ("Too many open files", errno 24) → socket() fails → cannot set nan0 IPv6 link-local address (Apple80211 ioctl on invalid fd → EBADF) → app NWConnection NWPath = satisfied but localEndpoint = nil → NetworkConnection stuck in .preparing, times out Abnormal console logs (the evidence) The smoking-gun lines from the unified log / Console (process wifip2pd): wifip2pd <Error> Failed to create socket: Too many open files wifip2pd <Error> Failed to update nan0 IPv6 address to [fe80::30c1:22ff:fe97:fefb] (from [fe80::e8a0:9bff:fe25:4d5c]) because <Apple80211Error Bad file descriptor> wifip2pd <Error> nw_path_shared_necp_fd necp_open failed [24: Too many open files] # errno 24 = EMFILE wifip2pd(Network) <Error> File descriptor is bad, could not create socket Counts over one ~11.5-minute failing capture: wifip2pd "Too many open files": 45 occurrences (a healthy capture has 0). nan0 IPv6 address update: 2 success / 13 fail (the 2 successes are before exhaustion; everything after fails with "Bad file descriptor"). Healthy device, for contrast — the IPv6 update succeeds on every NAN MAC rotation, and the app connection then works: wifip2pd Successfully updated nan0 IPv6 address to [fe80::f4c4:14ff:fe28:784a] # → app NWPath: status=satisfied, local=fe80::f4c4:14ff:fe28:784a%nan0 → NetworkConnection .ready Two facts that localize the bug: The leak is in wifip2pd, not the app. wifip2pd is one persistent daemon (constant pid) whose fd count only grows; the client app was restarted multiple times during the test and that did not release the descriptors. All "Too many open files" lines are emitted by wifip2pd. The NDP datapath itself still succeeds — only socket/interface-address configuration fails: kernel nan0: handleDataPathEstablished: NAN-DP Data path ESTABLISHED ... encrypt 1, EstDPs 1 wifip2pd #### Data Confirmed With Peer: ... port: 9004 Application-layer symptom (developer-facing) The same client code works before exhaustion and fails after: Before: NetworkConnection<UDP> reaches .ready; NWPath.localEndpoint = fe80::…%nan0. After: NetworkConnection<UDP> stays .preparing; every onPathUpdate reports status=satisfied, interfaces=["nan0"], local=nil; it times out and retries forever. The decisive developer-visible signal is NWPath.status == .satisfied together with localEndpoint == nil on nan0. Correlating timestamps confirms the contradiction: the console shows Data Confirmed With Peer ... port 9004 ~9–10 s before the app's NetworkConnection gives up, while the matching nan0 IPv6 update fails with "Bad file descriptor". The datapath is up at L2, but the connection is unusable because no local address was ever assigned. Steps to Reproduce Pair an iPhone with a Wi-Fi Aware peer that publishes a datapath service (_media-sync._udp, paired device, NCS-SK-CCM-128). Repeatedly establish and tear down the NDP datapath. In our case the peer device repeatedly powers off/on; each cycle forces a fresh browse + re-pair + NDP establish (the peer's NAN MAC is randomized each boot). Loop this; wifip2pd is never restarted, so the leak accumulates (failure appeared by ~the 9th iteration). Expected vs Actual Expected: wifip2pd releases the descriptors of each completed/torn-down browse/subscribe/datapath session; fd count stays bounded; nan0 IPv6 updates keep succeeding; NetworkConnection reaches .ready. Actual: wifip2pd fd count grows until EMFILE; nan0 IPv6 update then fails permanently; NetworkConnection is stuck .preparing for the rest of the wifip2pd process lifetime. Impact Any app using Wi-Fi Aware NDP datapaths under frequent connect/teardown eventually loses all Wi-Fi Aware connectivity. The failure is sticky for the wifip2pd lifetime and is invisible to / unrecoverable by the client app. Workaround Reboot the device (resets wifip2pd). The client can only slow the leak (fewer reconnects, prompt release of NetworkConnection), not prevent it, since the descriptors leak inside wifip2pd. To confirm / fix A sysdiagnose captured during the reproduction should show wifip2pd's open-fd count growing monotonically per connect/teardown cycle (which descriptor type leaks per browse/subscribe/datapath). Repro signature to grep in the logs: wifip2pd emitting Failed to create socket: Too many open files, necp_open failed [24: Too many open files], and Failed to update nan0 IPv6 address ... Apple80211Error Bad file descriptor.

I’m encountering a persistent issue with my Network Extension (specifically NEFilterDataProvider) and would really appreciate any insights. The extension generally works as expected, but after some time — especially after sleep/wake cycles or network changes — a global network outage occurs. During this state, no network traffic works: pings fail, browsers can’t load pages, etc. As soon as I stop the extension (by disabling it in System Preferences), the network immediately recovers. If I re-enable it, the outage returns instantly. I’ve also noticed that once this happens, the extension stops receiving callbacks like handleNewFlow(), and reinstalling the app or restarting the extension doesn’t help. The only thing that resolves the issue is rebooting the system. After reboot, the extension works fine again — until the problem reoccurs later. I asked AI about this behavior, and it suggested the possibility that the kernel might have marked the extension as untrusted, causing the system to intentionally block all network traffic as a safety mechanism. Has anyone experienced similar behavior with NEFilterDataProvider? Could there be a way to detect or prevent this state without rebooting? Is there any logging or diagnostic data I should collect when it happens again? Any guidance or pointers would be greatly appreciated. Thanks in advance!