I'm seeing an issue with NEURLFilterManager on iOS 26.5.2 and wanted to check if anyone else has encountered this. Our URL Filter implementation was working correctly on previous iOS 26.x releases. After updating devices to iOS 26.5.2, the filter no longer starts. The status changes to: Received filter status change: <FilterStatus: 'stopped' errorMessage: 'The operation couldn’t be completed. (NetworkExtension.NEURLFilterManager.Error error 10.)'> What I've verified The same project and implementation worked on earlier iOS versions. The app and extension have the required Network Extension capabilities and entitlements. The extension bundle identifier matches the one configured in NEURLFilterManager. The extension is embedded correctly in the application. I've tried uninstalling/reinstalling the app and rebuilding with the latest Xcode. The issue is reproducible on iOS 26.5.2. The filter never appears to start, and the status immediately changes to stopped with NEURLFilterManager.Error 10. I'm trying to determine: Has anyone else observed this behavior on iOS 26.5.2? Is there any known regression or change in NEURLFilterManager or URL Filter extensions in this release? Does Error 10 indicate a different failure mode on iOS 26.5.2 than on previous releases? If anyone has experienced the same issue or found a workaround, I'd appreciate any guidance. Thanks!

Many times the device totally lost connectivity, WIFI is completely down, no ip was assigned after device wakeup. From system log I can see BPF socket for DHCP was closed and detached right after attached to en0 in DHCP INIT phase, as result even the DHCP server sent back OFFER(I see server sent OFFER back from packet capture), but there is no persistent BPF socket since it is closed reception during the entire INIT phase. It is definitely an OS issue, is it a known issue? Please help understand Why BPF socket was close right after sending DISCOVER? Default 0x0 0 0 kernel: bpf26 attached to en0 by configd:331 2026-03-25 14:06:33.625851+0100 0x31dea Default 0x0 0 0 kernel: bpf26 closed and detached from en0 fcount 0 dcount 0 by configd:331 System log and packet capture attach, please check.

I am the developer of MIDIDeviceManager, an iOS and iPadOS application used by musicians to control external MIDI hardware during live performance. Before enabling any background execution mode, I would like to ask which architecture Apple intends for this type of application. What the application does The app organises the patches of a musician's MIDI instruments into Pads, Scenes and Setlists so they can be recalled during a performance. It sends MIDI to external hardware such as guitar processors, synthesisers and vocal processors, and it also receives incoming MIDI that triggers its own Scenes — typically from a Bluetooth foot controller, a wired MIDI controller, or another app on the same device. Its purpose is to function as the software equivalent of a programmable hardware MIDI controller. It is not a lyrics app or an audio player, and it produces no audio. The problem During a performance, musicians commonly run more than one app. A typical setup is lyrics or chord charts displayed in one app while a Bluetooth foot controller recalls presets on a Line 6 Helix through MIDIDeviceManager. This requires the app to keep receiving and processing incoming CoreMIDI events while another app is frontmost. Once iOS suspends the app, those events are no longer delivered and the foot controller stops working. This affects iPhone as much as iPad. Several of my TestFlight users perform with iPhone alone, where the device sits on a stand and is not touched during a song. What I have observed I tested this directly on an iPhone 17 Pro Max. With two apps running simultaneously, an app legitimately using the audio background mode continued to receive and act on incoming CoreMIDI events from a Bluetooth foot controller while backgrounded. At the same moment, MIDIDeviceManager received nothing once iOS suspended it. This suggests that, under certain circumstances, an app executing under an appropriate background mode may continue receiving CoreMIDI while backgrounded. Background modes considered audio — appears to provide the required behaviour, but my app produces no audio output. I do not wish to declare a background capability that does not accurately describe what the app does. bluetooth-central — does not appear applicable, since Bluetooth MIDI connections are established through CoreMIDI and managed by the system MIDI server rather than by my own Core Bluetooth session. I have not been able to identify any mode intended for continuous MIDI reception, so UIBackgroundModes is currently empty. A previous rejection An earlier submission did declare audio, and was rejected under Guideline 2.5.4 on 7 July 2026 (submission ID eab58179-8177-4d05-9c37-5e1006828a96): "The app declares support for audio in the UIBackgroundModes key in the Info.plist but we are unable to locate any features that require persistent audio. Background audio is intended for use by apps that provide audible content to the user while in the background, such as music player, music creation, or streaming audio apps." That assessment is correct — the app produces no audio, and I removed the key. But the functional requirement remains: the app needs to receive MIDI while another app is frontmost. I am asking here rather than resubmitting, because I would rather understand the intended architecture than guess again. My questions Which background mode, if any, is appropriate for an app whose purpose is to continue receiving and processing incoming CoreMIDI events while another app is frontmost? If background MIDI reception is supported, is CoreMIDI expected to continue delivering incoming MIDI to a backgrounded app, or is there a different recommended architecture for apps of this type? If the answer is that no background mode applies and this capability is not available to apps of this kind, I would very much appreciate knowing that clearly. I can then document the limitation for my users and design accordingly rather than pursue an unsupported approach. My objective is not to find a workaround, but to implement this the way Apple intends professional MIDI applications to work. Thank you.

See crash details here:- https://pastebin.com/i9u5PE4X There's a comprehensive thread here, folks! https://discussions.apple.com/thread/255651156?sortBy=oldest_first Thanks for any thoughts.

Hi all, I recently requested the Tap to Pay on iPhone entitlement for my app and was approved by Apple. The approval email included a link to download the marketing guide and branding toolkit (logos, brand guidelines, UI assets). Unfortunately I didn't download the toolkit at the time, and now when I open the link it says it has expired. A couple of questions: Is there a way to get a fresh download link for the Tap to Pay on iPhone marketing/branding toolkit? Is it available anywhere publicly, or does it have to be re-sent by Apple? To be clear — my understanding is that the entitlement itself is already attached to my account and I do not need to re-request it just to get the toolkit again. Can anyone confirm that re-requesting the entitlement is unnecessary (and not something I should do)? I'd rather not resubmit the entitlement request and risk disrupting an approval I already have. Just trying to recover the branding assets. Has anyone run into this? Should I contact Developer Program Support to have the toolkit link re-sent, or is there a self-serve resource page? Thanks in advance.

I’m looking at the new BGTaskScheduler.submitTaskRequest(_:completionHandler:) API on iOS 27 that replaces the now deprecated submit(_:).* The documentation says: This method asynchronously submits the task request and invokes the completion handler with any errors that occur during submission. It also says: The completion handler may be invoked on a arbitrary queue after an arbitrary amount of delay. Do not call this method from the main thread or performance-critical contexts. I’m confused when it says “Do not call this method from the main thread.” Since the method asynchronously submits the request and reports errors later through the completion handler, I initially read this as a warning not to wait for the completion handler to be called assuming it returns quickly. But it specifically says not to call the method from the main thread, which suggests the initial call itself may perform blocking expensive work before returning (although this is confusingly stated in the same block describing the completion handler behavior). Is the intended usage to create/configure the request on the main thread, then dispatch only submitTaskRequest to a background queue, or is calling that on the main thread actually okay just like the submit(_:) API it replaced? My current code in a synchronous function running on the main thread: BGTaskScheduler.shared.register(forTaskWithIdentifier: id, using: .main) { @Sendable registeredTask in // The background continued processing task has started, use it to update progress... } let request = BGContinuedProcessingTaskRequest(identifier: id, title: title, subtitle: subtitle) request.strategy = .fail // Start the task immediately and fail if it cannot if BGTaskScheduler.supportedResources.contains(.gpu) { request.requiredResources = .gpu } do { try BGTaskScheduler.shared.submit(request) // FIXME: How to migrate to the new API? } catch { // No worries, user will just have to keep the app open until the task completes print("BGTaskScheduler request failed: \(error.localizedDescription)") } *I assume this change was made to address issues like FB21052216 (https://developer.apple.com/forums/thread/807370)

I implemented BGContinuedProcessingTask in my app and it seems to be working well for everyone except one user (so far) who has reached out to report nothing happens when they tap the Start Processing button. They have an iPhone 12 Pro Max running iOS 26.1. Restarting iPhone does not fix it. When they turn off the background processing feature in the app, it works. In that case my code directly calls the function to start processing instead of waiting for it to be invoked in the register block (or submit catch block). Is this a bug that's possible to occur, maybe device specific? Or have I done something wrong in the implementation? func startProcessingTapped(_ sender: UIButton) { if isBackgroundProcessingEnabled { startBackgroundContinuedProcessing() } else { startProcessing(backgroundTask: nil) } } func startBackgroundContinuedProcessing() { BGTaskScheduler.shared.register(forTaskWithIdentifier: taskIdentifier, using: .main) { @Sendable [weak self] task in guard self != nil else { return } startProcessing(backgroundTask: task as? BGContinuedProcessingTask) } let request = BGContinuedProcessingTaskRequest(identifier: taskIdentifier, title: title, subtitle: subtitle) request.strategy = .fail if BGTaskScheduler.supportedResources.contains(.gpu) { request.requiredResources = .gpu } do { try BGTaskScheduler.shared.submit(request) } catch { startProcessing(backgroundTask: nil) } } func startProcessing(backgroundTask: BGContinuedProcessingTask?) { // FIXME: Never called for this user when isBackgroundProcessingEnabled is true }

Hello everyone, I’m experiencing a visual issue when dismissing a sheet on iOS 26. I’m using the same implementation shown in the official Apple documentation. While testing, I noticed that some apps do not exhibit this behavior. However, when running this code on iOS 26, the issue consistently occurs. Issue description: The sheet dismisses abruptly A white screen briefly appears for a few milliseconds and then disappears This results in a noticeable visual glitch and a poor user experience I tested the exact same code on iOS 18, where the sheet dismisses smoothly and behaves as expected, without any visual artifacts. Has anyone else encountered this issue on iOS 26? Is this a known bug, or is there a recommended workaround? Any insights would be greatly appreciated. Thank you.

We are implementing In-App Provisioning functionality for our Bank but there is always 500 Internal Server Error respond by Apple server once we tried to add card to apple wallet. Our code let request = PKAddPaymentPassRequest() request.activationData = try decodeBase64(payload.activationDataText, field: "activationDataText") request.encryptedPassData = try decodeBase64(payload.encryptedDataText, field: "encryptedDataText") request.ephemeralPublicKey = try decodeBase64(payload.ephemeralPublicKeyText, field: "ephemeralPublicKeyText") return request Because of fPanId is not required so we are not pass it to Apple server and that field generated once the card already added to wallet. Please help us investigate the issue, thanks! FeedbackId 24065847 (In-App Provisioning 500 Internel Error)

~5% of our users when downloading the iOS application from the Apple Store for the first time are unable to enrol a Passkey and experience an error saying the application is not associated with [DOMAIN]. The error message thrown by the iOS credentials API is "The operation couldn't be completed. Application with identifier [APPID] is not associated with domain [DOMAIN]" We have raised this via the developer support portal with case id: 102315543678 Question: Why does the AASA file fail to fetch on app install and is there anything that can be done to force the app to fetch the file? Can this bug be looked at urgently as it is impacting security critical functionality? Other Debugging Observations We have confirmed that our AASA file is correctly formatted and hosted on the Apple CDN. Under normal circumstances the association is created on install and Passkey enrolment works as intended. We have observed that when customers uninstall/reinstall the app this often, but not always, resolves the issue. We also know this issue can resolve itself overtime without any intervention. We have ruled out network (e.g VPN) issues and have reproduced the issue across a number of different network configurations. We have ruled out the Keychain provider and have reproduced it across a variety of different providers and combinations of. We observed this across multiple versions of the iOS operating system and iPhone hardware including the latest hardware and iOS version.

Hi all, I'm running 2 macOS VMs on a bare-metal Mac (host is also macOS). I'm seeing inconsistent iMessage sign-in behavior depending on the Apple ID type and whether it's bare metal or virtualized: Managed Apple ID (ABM-issued): signs into iMessage fine on the bare-metal host. Same Managed Apple ID: fails to sign into iMessage inside the VM on the same physical machine. Personal/basic Apple ID: signs in fine in the VM without issue. Has anyone run into this specific combination — MAID working on bare metal but not inside a VM, while a personal ID works fine in both?

We’ve been implementing LiveCallerId using OHTTP and have hit a wall with the production environment. The setup works perfectly in TestFlight, but the release version of the app is consistently being rejected by the Apple OHTTP Relay when trying to tunnel traffic to our gateway. Timeline & Status: Applied via the form in September 2025. Received confirmation in November 2025 that our /.well-known/ohttp-keys endpoint was correctly configured. Since then, we've struggled to get a dialogue with Apple to confirm the final production whitelisting. Technical Observations: Our ohttp-keys endpoint is being polled frequently (every few minutes). Based on the traffic, this is clearly the Apple Relay infrastructure fetching/refreshing the keys, not the devices themselves. This suggests the Relay "sees" our configuration, yet it still refuses to tunnel traffic to our gateway in the production environment. Since everything is functional in TestFlight, our implementation seems correct. It feels like there is a configuration mismatch or a missing "production flip" on the Relay side for our Bundle ID. If anyone from the Apple engineering team could verify the status for this Bundle ID, it would be a huge help. We've been stuck in this "TestFlight-only" state for quite a while now.

We are seeing a reproducible issue on a physical iPhone with Dynamic Island. Steps to reproduce Install and launch version 1 of the app locally. Start background location tracking using CLLocationUpdate.liveUpdates() together with CLBackgroundActivitySession. Move the app to the background. The blue location indicator appears in the Dynamic Island. While tracking is still active, install version 2 over the existing app. Open the updated app. Stop all location tracking: Cancel the CLLocationUpdate task. Call invalidate() on the CLBackgroundActivitySession. Release all references to the session. Move the app to the background again. Expected behavior The blue background location indicator disappears after the location updates and background activity session have been stopped. Actual behavior The blue location indicator remains permanently visible in the Dynamic Island, even though: No location updates are being received. No CLBackgroundActivitySession is retained. Starting and stopping another location session does not remove it. Force-quitting and reopening the app does not remove it. Only restarting the iPhone makes the indicator disappear. The problem occurs when a new build is installed over an existing installation while a background location session is active. Starting and stopping the same session normally within one installed version works as expected. Comparison with Live Activity background location The app also has a separate location feature that uses an active Live Activity to support background location updates without creating a CLBackgroundActivitySession. Installing a new build while that feature is active does not cause the blue location indicator to become stuck. The problem has only been reproduced when a CLBackgroundActivitySession is active during the installation. This suggests that the issue is specifically related to transferring or cleaning up CLBackgroundActivitySession state across an app update, rather than to CLLocationUpdate.liveUpdates() itself. Questions Is this a known issue with CLBackgroundActivitySession or CLLocationUpdate.liveUpdates()? Is there a supported way for the newly installed app process to invalidate or clean up a background location session created by the previous app process?

Hello, I am currently developing a printed data security feature for a cross-platform DLP system. On other platforms, this functionality relies on a cross-platform third-party library. On macOS, this library depends on the Core Graphics and AppKit frameworks. So, such dependency makes it impossible to use the code within a launch daemon, which is where this mechanism needs to run. As an alternative approach, I am considering implementing the necessary functionality inside a CUPS filter. However, I have some doubts regarding the execution context of the CUPS filter process. Is it safe to use AppKit within a CUPS filter? Thank you in advance.

Hello, QQ for the Wi-Fi/Accessories team. Is the expectation that Wi-Fi Aware will work properly when the iPhone has Wi-Fi off either in settings or control center? I am able to reproduce errors where it does not work properly if the Wi-Fi on the phone is turned off. Please let me know best practices Using iPhone 17 pro on iOS 26.6

Hi, As a company, we have several apps in the AppStore that contain AppClips. With the latest iOS18 it works without any problems. With all iOS26 betas so far, however, there is always the problem “ASDErrorDomain- Error 507” and the AppClip cannot be opened. You can easily test this by scanning the following QR code with the system camera: You only ever get this error instead of the option to open the AppClip. As the iOS26 beta phase is already at an advanced stage, we are naturally concerned as to whether the problem will be solved.

I am investigating premature DeviceActivityMonitor.eventDidReachThreshold callbacks on physical devices running iOS 26.x. I have also observed similar overcounting behavior on iOS 18.x. In one repeatable test, an all-activity event configured with a 10-minute threshold fired after approximately 5 minutes of actual unlocked usage. The event was created with: A single completion threshold. includesPastActivity: false. A nonrepeating DeviceActivitySchedule. A unique activity and event identity for each monitoring generation. However, eventDidReachThreshold could still arrive significantly earlier than expected. Defensive mitigation I have been testing a defensive mechanism that treats eventDidReachThreshold only as a wake-up signal, rather than authoritative proof that the configured usage duration has elapsed. When the callback arrives, the monitor extension independently validates the duration against locally persisted timing state. The flow is: Each logical work cycle has a unique cycle identifier and generation number. The app stores a local timing anchor when monitoring begins or resumes. When the threshold callback arrives, the extension verifies: The cycle identifier. The generation number. The activity name. The current application state. The extension calculates a locally trusted elapsed duration. If the local duration has not reached the configured duration: It does not send a notification. It does not apply any user-visible action. It persists only the locally trusted progress. It increments the generation number. It stops the previous monitor. It registers a new event for only the locally remaining duration. Completion is accepted only when the locally calculated duration is due. Delayed callbacks from previous generations are ignored. Simplified pseudocode: override func eventDidReachThreshold( _ event: DeviceActivityEvent.Name, activity: DeviceActivityName ) { let state = loadPersistedState() guard eventMatchesCurrentGeneration( event: event, activity: activity, state: state ) else { // Ignore stale or duplicated callbacks. return } let now = Date() let trustedElapsed = calculateLocallyAccountedElapsed( state: state, now: now ) let tolerance: TimeInterval = 3 if trustedElapsed + tolerance < state.configuredDuration { let remaining = state.configuredDuration - trustedElapsed var nextState = state nextState.confirmedElapsed = trustedElapsed nextState.generation += 1 // Persist the new generation before replacing the monitor. persistAtomically(nextState) center.stopMonitoring([activity]) let nextActivity = makeActivityName( cycleID: nextState.cycleID, generation: nextState.generation ) let completionEvent = DeviceActivityEvent( threshold: normalizedDateComponents(remaining), includesPastActivity: false ) do { try center.startMonitoring( nextActivity, during: makeNonRepeatingSchedule(), events: [ makeCompletionEventName(nextState): completionEvent ] ) } catch { // Persist a recoverable unavailable state. recordMonitoringFailure(error) } return } transitionToCompletedState() scheduleUserNotification() } Durations are normalized before creating the event: func normalizedDateComponents( _ duration: TimeInterval ) -> DateComponents { let seconds = max(1, Int(duration)) return DateComponents( minute: seconds / 60, second: seconds % 60 ) } This avoids using values such as second: 300. Example For a configured duration of 10 minutes: DeviceActivity incorrectly delivers the completion callback after approximately 5 minutes. Local accounting reports only approximately 5 minutes. No notification or other user-visible action is performed. The previous monitor is replaced with a new generation configured for the remaining approximately 5 minutes. Completion is accepted only after the locally trusted timing state is due. This mechanism has so far prevented premature DeviceActivity callbacks from producing premature notifications during my physical-device testing on iOS 26.x. Additional precautions The implementation also uses the following precautions: Only one completion event is registered instead of multiple minute checkpoints. includesPastActivity is explicitly set to false. Every replacement monitor has a new generation identity. Generation state is persisted before the old monitor is replaced. Callbacks from an old cycle, generation, or activity name are ignored. The extension performs only small, bounded state updates. User-visible actions occur only after local validation succeeds. Limitations This is a defensive workaround, not a fix for the underlying DeviceActivity or Screen Time accounting issue. Known limitations include: It cannot prevent iOS from delivering an incorrect callback. If the system never delivers another callback, completion may be delayed or missed. If every new event immediately fires, repeated re-registration may occur. startMonitoring may fail if the system considers the activities too numerous or too tightly scheduled. Local unlocked-time accounting depends on reliable lock and unlock observations. Wall-clock calculations must consider manual system-time changes. The approach cannot correct Screen Time’s internal activity data. For modes that intentionally count locked time, absolute local-notification scheduling may be more reliable and may avoid DeviceActivity thresholds entirely. All processing in this mitigation occurs on-device. It does not require uploading activity tokens, Screen Time data, user identifiers, or diagnostic logs. The implementation uses only public APIs. Questions for Apple Is treating eventDidReachThreshold as a wake-up signal and validating it against locally persisted timing state an acceptable design? Is stopping the current monitor and registering a new generation for only the locally remaining duration from the monitor extension considered a supported recovery pattern? Are there documented or recommended limits, rate controls, or backoff requirements for this type of defensive re-registration? Is there a more reliable supported API for usage-based completion when eventDidReachThreshold fires prematurely on iOS 26? I would appreciate confirmation from Apple engineers or feedback from other developers who have tested a similar approach.

The entitlement documentation page for com.apple.developer.driverkit.family.hid.virtual.device says "To request this entitlement, fill out the request form." I can't find any way to actually request it. In Certificates, Identifiers & Profiles there is no row for that key anywhere — not on an App ID's Capabilities tab, and not under Capability Requests. Capability Requests does list these, with the entitlement key shown in each info tooltip: DriverKit Transport HID — com.apple.developer.driverkit.transport.hid DriverKit Family HID Device — com.apple.developer.driverkit.family.hid.device DriverKit HID EventService — com.apple.developer.driverkit.family.hid.eventservice DriverKit UserClient Access — com.apple.developer.driverkit.userclient-access HID Virtual Device — com.apple.developer.hid.virtual.device So the only virtual-HID entry that exists in the portal is the CoreHID one. What I've built: a DriverKit dext that publishes a software-only HID game controller (no physical bus), so a macOS app can synthesise gamepad input for games that require a real controller. It builds against the DriverKit SDK and is signed. Its entitlements are com.apple.developer.driverkit, .transport.hid and .family.hid.virtual.device. The host-to-dext control channel is a vendor Feature report rather than a custom IOUserClient, so it needs no userclient-access. Questions: Is com.apple.developer.driverkit.family.hid.virtual.device still grantable? If a dext can no longer declare it for distribution, I would rather rebuild on CoreHID's HIDVirtualDevice now than keep building against a key I can't ship. If the DriverKit path is still supported for a virtual HID gamepad, what is the correct complete entitlement group? Karabiner-DriverKit-VirtualHIDDevice ships with com.apple.developer.driverkit + .transport.hid + .family.hid.device + .family.hid.eventservice + com.apple.developer.hid.virtual.device — i.e. a DriverKit dext holding the CoreHID virtual-device entitlement, and no .family.hid.virtual.device at all. Is that the supported shape? If .family.hid.virtual.device has been retired, should its documentation page be updated? Happy to file a Feedback if that's the right route. Not a status request: I do have a Virtual HID request queued and the portal shows it as Submitted, so I'm content to wait. I'd just rather find out now whether it's queued against the right key for what I've built.

UserDefaults store app-related settings, and I am just worried that if an SDK also writes to the UserDefaults, that there could be potentially some key collisions between the host app and the SDK. Is the concern just in my head or does it have merit?

Development environment Xcode 26.0 Beta 6 iOS 26 Simulator macOS 15.6.1 To verify TLS 1.3 session resumption behavior in URLSession, I configured URLSessionConfiguration as follows and sent an HTTP GET request: let config = URLSessionConfiguration.ephemeral config.tlsMinimumSupportedProtocolVersion = .TLSv13 config.tlsMaximumSupportedProtocolVersion = .TLSv13 config.httpMaximumConnectionsPerHost = 1 config.httpAdditionalHeaders = ["Connection": "close"] config.enablesEarlyData = true let session = URLSession(configuration: config, delegate: nil, delegateQueue: nil) let url = URL(string: "https://www.google.com")! var request = URLRequest(url: url) request.assumesHTTP3Capable = true request.httpMethod = "GET" let task = session.dataTask(with: request) { data, response, error in if let error = error { print("Error during URLSession data task: \(error)") return } if let data = data, let responseString = String(data: data, encoding: .utf8) { print("Received data via URLSession: \(responseString)") } else { print("No data received or data is not UTF-8 encoded") } } task.resume() However, after capturing the packets, I found that the ClientHello packet did not include the early_data extension. It seems that enablesEarlyData on URLSessionConfiguration is not being applied. How can I make this work properly?