Overview

Hello, I have an app that is using iOS 26 Network Framework APIs. It is using QUIC, TLS 1.3 and Bonjour. For TLS I am using a PKCS#12 identity. All works well and as expected if the devices (iPhone with no cellular, iPhone with cellular, and iPad no cellular) are all on the same wifi network. If I turn off my router (ie no more wifi network) and leave on the wifi toggle on the iOS devices - only the non cellular iPhone and iPad are able to discovery and connect to each other. My iPhone with cellular is not able to. By sharing my logs with Cursor AI it was determined that the connection between the two problematic peers (iPad with no cellular and iPhone with cellular) never even makes it to the TLS step because I never see the logs where I print out the certs I compare. I tried doing "builder.requiredInterfaceType(.wifi)" but doing that blocked the two non cellular devices from working. I also tried "builder.prohibitedInterfaceTypes([.cellular])" but that also did not work. Is AWDL on it's way out? Should I focus my energy on Wi-Fi Aware? Regards, Captadoh

Hi, We applied for Tap to Pay on iPhone entitlement and were approved, but on distribution support it's only showing Development. We can build and debug Tap to Pay on development, but unable to build release. We opened ticket with Apple support but they were saying it was configured correctly. I attached screenshot of our developer account entitlement for Tap to Pay. It clearly said Development only.

In the video ”Create Icons with Icon Composer”, the presenter mentions that Apple has created a layer-to-SVG script for Illustrator that‘s available for download: Once the artwork is in a good place, next we want to export the layers as SVGs. For every tool, this can look a bit different. For those using Illustrator, we've created a layer to SVG script that will automate this for you, which you can download. Exporting out the canvas size ensures everything drops right into position in Icon Composer. Here‘s the link to the mention: https://developer.apple.com/videos/play/wwdc2025/361/?time=377 I can’t find any place to get this script, and my designer is very interested in using it to import our Illustrator icon into Icon Composer. Can someone point me to it?

I have a VoIP app, now try to implement the new method which support the "PKVoIPPushMetadata" in iOS 26.4. Code as below: /// iOS 26.4+ (SDK with `PKVoIPPushMetadata`): prefer this path for VoIP per Apple; completion is `@Sendable` on supported SDKs. @available(iOS 26.4, *) func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingVoIPPushWith payload: PKPushPayload, metadata: PKVoIPPushMetadata, withCompletionHandler completion: @escaping @Sendable () -> Void) { print("willtest: didReceiveIncomingVoIPPushWith: metadata=\(metadata)") handleVoIPPush(payload: payload, metadataMustReport: metadata.mustReport, completion: completion) } func pushRegistry(_ registry: PKPushRegistry, didReceiveIncomingPushWith payload: PKPushPayload, for type: PKPushType, completion: @escaping () -> Void) { print("willtest: didReceiveIncomingPushWith: PKPushType=\(type)") handleVoIPPush(payload: payload, metadataMustReport: nil, completion: completion) } But the voip push only goes to the old method on my iOS26.4 device(iPhone17). And it will go to the new method after I delete the old method. So how can I use this method in my app? I must support iOS16+ versions.

I’m seeing a crash when running XCTest on iOS 15.2 Simulators with Xcode 26.4. The test bundle never starts. xctest crashes before establishing the XCTest connection. This appears to be a regression from Xcode 26.2. The same test flow worked with Xcode 26.2, but crashes with Xcode 26.4. This does not appear to be caused by my app or package code. I can reproduce it with a minimal Swift Package that only imports Foundation and has one XCTest case using URLRequest.httpMethod. Environment: Xcode with failure: 26.4 Xcode that worked: 26.2 macOS: 26.2 Destinations tested: iPhone SE (2nd generation), iOS 15.2 Simulator iPad mini (6th generation), iOS 15.2 Simulator Test command: xcodebuild test Swift Package deployment target: iOS 15.2 Swift tools version: 6.1 Minimal reproduction package: Package.swift // swift-tools-version:6.1 import PackageDescription let package = Package( name: "FoundationOnlyRepro", platforms: [.iOS("15.2")], products: [ .library( name: "FoundationOnlyRepro", targets: ["FoundationOnlyRepro"] ) ], targets: [ .target(name: "FoundationOnlyRepro"), .testTarget( name: "FoundationOnlyReproTests", dependencies: ["FoundationOnlyRepro"] ) ], swiftLanguageModes: [.v6] ) Sources/FoundationOnlyRepro/FoundationOnlyRepro.swift import Foundation public struct FoundationOnlyRepro { public init() {} public func makeRequest() -> URLRequest { var request = URLRequest(url: URL(string: "https://example.invalid")!) request.httpMethod = "GET" return request } } Tests/FoundationOnlyReproTests/FoundationOnlyReproTests.swift import XCTest import Foundation @testable import FoundationOnlyRepro final class FoundationOnlyReproTests: XCTestCase { func testURLRequestHTTPMethod() { let request = FoundationOnlyRepro().makeRequest() XCTAssertEqual(request.httpMethod, "GET") } } Command used: xcodebuild test \ -scheme FoundationOnlyRepro \ -destination 'platform=iOS Simulator,name=iPhone SE (2nd generation),OS=15.2' \ -derivedDataPath /tmp/rdp-dd \ -quiet The same kind of crash also occurs when using an iPad mini (6th generation) iOS 15.2 Simulator destination. Result: Testing failed: xctest (...) encountered an error (Early unexpected exit, operation never finished bootstrapping - no restart will be attempted. (Underlying Error: Test crashed with signal abrt before establishing connection.)) ** TEST FAILED ** The diagnostic stderr shows: dyld[28688]: Symbol not found: _$s10Foundation10URLRequestV10httpMethodSSSgvs Referenced from: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/Library/PrivateFrameworks/ResultDataPublisher.framework/ ResultDataPublisher Expected in: /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 15.2.simruntime/Contents/Resources/RuntimeRoot/System/Library/Frameworks/Foundation.framework/Foundation Demangling the missing symbol: xcrun swift-demangle '_$s10Foundation10URLRequestV10httpMethodSSSgvs' Output: Foundation.URLRequest.httpMethod.setter : Swift.String? I also checked the iOS 15.2 simulator runtime. The symbol appears to exist in: /Library/Developer/CoreSimulator/Profiles/Runtimes/iOS 15.2.simruntime/Contents/Resources/RuntimeRoot/usr/lib/swift/libswiftFoundation.dylib but ResultDataPublisher.framework appears to be resolving it from: .../System/Library/Frameworks/Foundation.framework/Foundation This suggests the crash is in Xcode’s XCTest/result publishing infrastructure, not in the app/test bundle. Questions: Is Xcode 26.4 + iOS 15.2 Simulator + xcodebuild test expected to be supported? Is there a supported workaround to disable or avoid ResultDataPublisher.framework for command-line XCTest runs?

I recently noticed a UX inconsistency while using the battery charge limit feature on my MacBook with a MagSafe charger. With the optimized charging feature, users can set a custom maximum charging limit (for example, 95%) to improve battery health. However, the MagSafe LED indicator continues to show the charging state (amber) even after the device reaches this user-defined limit. Previously, the LED would turn green when charging reached 100%, clearly indicating a “fully charged” state. But now, when charging stops at a user-defined limit, there is no clear visual feedback that charging has effectively completed based on the user’s preference. This creates confusion, as the LED suggests that charging is still ongoing even though the system has stopped charging at the configured limit. A possible approach to improve this could be to treat the user-defined limit as an effective “fully charged” state during charging. For example: if is_charging: if battery_percentage < user_defined_limit: LED = AMBER else: LED = GREEN This would align the physical LED indicator with the system’s charging behavior and improve clarity for users without requiring hardware changes. Has anyone else observed this behavior, or is there any existing workaround?

Our app PrepAiro: Crack UPSC IAS 2026 (Account: 6741750813) has been caught in a rejection/resubmission loop since April 12, now over 10 days. Timeline: April 12: First rejection received Cycles 1–6: Each rejection addressed per reviewer feedback, resubmitted promptly April 18: Status moved to "Waiting for Review" , no movement since We submitted an expedited review request through Apple Support due to the urgency. This release contains critical bug fixes actively impacting users, but there has been no response or update. We understand review timelines can vary, but 6 full cycles over 10 days with no resolution, and a 6-day stall after the last submission, is unusual. Each resubmission addressed the specific feedback provided, yet the cycle continues. Has anyone experienced similar extended holds recently? And is there any additional channel or escalation path beyond the expedited review request to get clarity on what's causing this? Any guidance from Apple or fellow developers would be appreciated.

Hello, my Apple Developer Program enrollment has been pending for 5 days - I am not able to reach support cause the don't answer phone. I have completed all steps and payment - have my invoice. . Could you help somehow?

Platform: macOS 26.3.1, M5 Pro MacBook Pro Framework: CoreWLAN Affected applications: NetViews, Air Tool 2, and our own tooling — appears to be specific to the new Wi-Fi 7 hardware Hardware Card Type: chip id: 0x11 api 1.2 firmware [Rev 72.11.260 N1B1 devFused=0] phy [17.1.17.0], core80211 [324.10.260 N1_silicon_b] Firmware: Jan 27 2026 21:18:32 version XBS_BUILD_TAG GIT_DESCRIBE FWID chip id: 0x11 api 1.2 firmware [Rev 72.11.260 N1B1 devFused=0] phy [17.1.17.0], core80211 [324.10.260 N1_silicon_b] Driver: IO80211_driverkit-1540.16 "IO80211_driverkit-1540.16" Jan 27 2026 Background Both issues described below were working correctly on macOS 26 with previous-generation hardware. The regression is specific to the Wi-Fi 7 card shipping in the M5 Pro MacBook Pro. This is not an OS regression — it is a hardware/driver/firmware compatibility issue with the new card under macOS 26. Issue 1: disassociate() + tcpdump/Wireshark -I no longer enters monitor mode Previously, the standard approach of calling disassociate() and then launching tcpdump -i en0 -I or Wireshark -i en0 -I -k would successfully put the interface into monitor mode. On the M5 Pro Wi-Fi 7 card, this no longer works. The capture tool launches but the interface either stays in station mode or enters mode 0 - where there is no connection, but still not able to be a monitor radio. This is the primary regression affecting third-party wireless tools. Issue 2: setWLANChannel reports success but the radio only retunes once As a workaround for Issue 1, we use the built-in Wireless Diagnostics → Sniffer tool to establish monitor mode (which works fairly reliably on this hardware). Once the interface is in monitor mode via that path, we attempt to change the channel using setWLANChannel: let iface = CWWiFiClient.shared().interface(withName: "en0")! let target = iface.supportedWLANChannels()! .first { $0.channelNumber == 6 && $0.channelWidth == .width20MHz }! try iface.setWLANChannel(target) The first call succeeds (eg: channel 48 -> 6) the radio actually tunes to the requested channel and Wireshark captures frames there. Any subsequent call (eg: channel 48 -> 6 -> 1) shows the same apparent success - no error thrown, wlanChannel() updates to reflect the new channel - but the radio does not retune. Wireshark continues capturing on the first changed channel. We have tested with disassociate() and interface power cycling between attempts — neither resets the ability to retune the radio. What we have ruled out Timing: delays between calls make no difference Competing processes holding the interface wlanChannel() returning a stale cache value — it updates correctly, but diverges from actual hardware state after the first channel change Key data point: Wireless Diagnostics Sniffer works The built-in Wireless Diagnostics → Sniffer tool successfully puts the interface into monitor mode on this hardware. This confirms the card and driver are capable - the issue is that the capability is no longer reachable via CoreWLAN or via tcpdump/Wireshark's -I flag. Wireless Diagnostics Sniffer does not support live channel changes, so it cannot serve as a full workaround. The questions Is there a supported path for third-party apps to enter monitor mode on the new Wi-Fi 7 hardware on macOS 26? What is the correct mechanism for changing channels while in monitor mode - is setWLANChannel expected to retune the radio on subsequent calls, or is there a different API intended for this? The fact that Wireless Diagnostics accomplishes both (albeit, not live) confirms the hardware and driver are fully capable - we are looking for the sanctioned equivalent for third-party tools.

Hello, I'm posting again because my situation has not improved despite previous outreach. My app (ID: 6756186616, iOS 1.3.0) was submitted on March 15, 2026 — over 6 weeks ago. After about 4 weeks in "Waiting for Review," it moved to "In Review" on April 14, 2026. It has now been stuck in "In Review" for two full weeks with no further updates. I opened a Developer Support case (#20000111565861) earlier in the process and was told my submission was being investigated, but I have not received any follow-up communication since. Given Apple's stated review timelines, a 6+ week review with two weeks of silence during the active In Review phase is a serious blocker for an independent developer. I would really appreciate: Any clarity on whether something specific in my submission is causing this delay Whether there is an escalation path beyond Developer Support Whether anyone else has experienced similar timelines recently and how they were resolved Thank you for your time.

Hi Apple team, Could you please let us know the estimated timeline for approval of our OHTTP relay request? We’d appreciate any updates on the current status or next steps from your side. My request number is GZ8425KHD9. Thanks in advance.

Has anyone seen Managed Background Assets get stuck before any download progress is reported on iPadOS 26.3 / TestFlight? We are using Apple-hosted managed asset packs for a large on-demand model download. The app can resolve the asset pack metadata: we can show the asset pack’s download size in the UI, so AssetPackManager.assetPack(withID:) appears to work. But when we call ensureLocalAvailability(of:), the UI stays at 0% indefinitely. We also do not receive any useful terminal state from statusUpdates(forAssetPackWithID:): no .began, .downloading, .failed, or .finished. The app remains responsive. The issue also appears persistent on the affected device/account. Reinstalling the app does not help, reinstalling TestFlight does not help, logging out and back in does not help, and restarting the device does not help. After each attempt, the app can still resolve the asset pack metadata/download size, but the actual download remains stuck before any progress or failure status is delivered. The suspicious part of the device log is that the managed helper starts normally, fetches/installs the manifest from TestFlight, but repeatedly fails to create its helper directory inside the app container: OurApp Initializing the asset-pack manager… OurApp Creating a proxy object for the helper service… OurApp activating connection ... name=com.apple.backgroundassets.managed.helper.service kernel Sandbox: no system container path found for ID "com.apple.backgroundassets.managed.helper.service" Managed Background Assets Helper Service Starting the Managed Background Assets Helper Service… Managed Background Assets Helper Service Configuring the directory suffix… Managed Background Assets Helper Service The directory suffix was successfully configured. Managed Background Assets Helper Service The extension token "<...>" was consumed. kernel Sandbox: Managed Background Assets Helper(...) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service Managed Background Assets Helper Service mkdir: path=/private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service/ mode= -rwx------: [1: Operation not permitted] After that, manifest fetching still seems to work: OurApp The asset-pack manager has been initialized. OurApp The system download-manager delegate has been assigned to the download manager. OurApp The app was installed for internal beta testing; checking for updates automatically… OurApp Refreshing the manifest… Managed Background Assets Helper Service The app with the bundle ID "..." is configured to use Apple hosting. Managed Background Assets Helper Service Asking the TestFlight extension via the App Store Daemon for the URL request... Managed Background Assets Helper Service Fetching the download manifest ... from TestFlight… Managed Background Assets Helper Service Installing a manifest at ".../Library/Application Support/.../Manifest.json"... But during/after manifest install, the same mkdir failure appears again: Managed Background Assets Helper Service Installing a manifest at ".../Manifest.json"... Managed Background Assets Helper Service mkdir: path=/private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service/ mode= -rwx------: [1: Operation not permitted] kernel duplicate reports for Sandbox: Managed Background Assets Helper(...) deny(1) file-write-create /private/var/mobile/Containers/Data/Application/.../tmp/com.apple.backgroundassets.managed.helper.service So the behavior seems to be: TestFlight/internal beta install Apple-hosted managed asset pack Manifest fetch succeeds Asset pack metadata resolves, including download size Actual local availability request never starts reporting progress No visible Background Assets failure reaches the app Logs show repeated sandbox file-write-create denial for the Managed Background Assets Helper trying to create /tmp/com.apple.backgroundassets.managed.helper.service inside the app container Reinstalling the app/TestFlight, logging out and back in, and restarting the device do not clear the stuck state On devices with 26.4, the issue doesn’t seem to exist Has anyone else seen this on iOS/iPadOS/macOS versions before 26.4? Is this a known issue in the Managed Background Assets helper/runtime? I noticed 26.4 added more local status APIs for asset packs, so I’m wondering whether this area changed in 26.4. Any hints on whether the sandbox denial is expected/noisy, or whether it could explain ensureLocalAvailability(of:) never progressing, would be appreciated.

I’m trying to use MTL4FXTemporalDenoisedScaler, and I’m seeing a crash during initialization even with a very simple sample app. I created a minimal sample here: https://github.com/tatsuya-ogawa/MetalFXInitExample The exception is: NSException: "-[AGXG16XFamilyHeap baseObject]: unrecognized selector sent to instance ..." What I found is: • This works: descriptor.makeTemporalDenoisedScaler(device: device) • This crashes: descriptor.makeTemporalDenoisedScaler(device: device, compiler: metal4Compiler) So the issue seems to happen only with the Metal4FX version. For testing, I’m using an iPhone 15 Pro. According to the Metal Feature Set Tables, MetalFX denoised upscaling should be supported on Apple9 and later, so I believe the device itself should meet the requirements. Reference: https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf Has anyone seen this before, or knows what might be causing it? I’d appreciate any advice. Thanks.

Description Xcode 26.4.1 crashes immediately on launch with a code signature error. The issue exists on macOS 26.4.1 and persists after upgrading to macOS 26.5 (25F5058e) and attempting 26.6 beta. Crash Details: Exception Type: EXC_BAD_ACCESS (SIGKILL (Code Signature Invalid)) Termination Reason: Namespace CODESIGNING, Code 2, Invalid Page Key symbols: dyld3::MachOFile::trieWalk, dyld4::JustInTimeLoader::applyFixups, dyld4::Loader::forEachBindTarget All Steps Tried (All Failed): Fresh reinstall from Mac App Store and .xip from Developer website Multiple sudo xattr -cr + sudo codesign --force --deep --strict --options=runtime --sign - Deleted all Xcode caches, DerivedData, and preferences Tested in a brand new user account (same crash) Downgraded Xcode to older versions macOS remains on 26.4.1 (issue existed here) and upgraded to 26.5 / attempted 26.6 beta — still same crash Refreshed Apple Worldwide Developer Relations certificates Multiple restarts The crash report is identical every time. System Information Model: MacBook Pro (M1 Pro, MacBookPro18,1) macOS: 26.5 (25F5058e) — issue started after upgrade from 26.4.1 Xcode: 26.4.1 (24909.0.3) SIP: Enabled Developer Mode: Enabled Additional Notes Other applications launch normally. This appears to be a system-level compatibility issue introduced in macOS 26.5's stricter code signing validation on mapped files / chained fixups. Request Is there a known workaround? Is Apple preparing a fix in a future macOS 26.5 patch or Xcode update? What additional information would help? Thank you!

I want to address the missing or incomplete DirectX calls from D3DMetal and Game Porting Toolkit 3. These missing calls have in part caused issue with our porting process and we are reconsidering. Missing or Incomplete Calls DXGI_FEATURE_PRESENT_ALLOW_TEARING — IDXGIFactory5::CheckFeatureSupport — this calls has to do with how VSync is handled and some modern games require it to initialize. Currently D3DMetal return 0 maybe by design but most likely because it’s not integrated. Adding a stub that returns 1 can fix this. I’m my use case I simply Noped the check and forced it to continue. D3D12_FEATURE_D3D12_OPTIONS2.DepthBoundsTestSupported — this call is also not present. Which causes games to not initialize rendering. Thankfully this was fixed by once again skipping the check. But this is essential for water rendering. This could be one reason currently water is not rendering in our game. IDXGIOutput6::GetDesc1().ColorSpace — returns DXGI_COLOR_SPACE_RGB_FULL_G22_NONE_P709 (SDR) on external HDR compatible displays. We were able to fix this by forcing HDR to be enabled. It should return HDR support. These calls may exist but they need to be updated to return the correct values. Specifically for depth bound test you can reference MoltenVK which sets it up on top of Metal since it’s not a native feature. The water issue could be also an issue with how the shaders are compiled. But I’m unable to check because of the closed source nature of GPTK and its debuggers. What is a better way we can debug our game to see why the water isn’t rendering. Does D3DMetal have some debug options or something similar? Feedback Number FB22330617 - Missing DirectX Calls for Tearing and Depth Bound Test in D3DMetal and GPTK 3 We hope these issues are resolved quickly because we were thinking of a simultaneous release with our Windows version, but we can't ship with such large bugs.

Hi there, I’m curious to understand how the system determines which language to use for an app. The system is currently set to en-IN (English - India). My app supports the following languages: en (the default development language) en-GB (United Kingdom) en-IE (Ireland) en-US (United States) When I run the app, the Bundle.main.preferredLanguages returns [„en-GB“, „en“], which causes the app to be set to en-GB. However, when the app doesn’t support the preferred system language, I would expect it to default to the en language. Surprisingly, this is not the case. This behavior is precisely described in Technical Note TN2418. Unfortunately, there’s no explanation provided. Is this behavior related to the CLDR Linguistic Distance? I also attempted to replace the default development language en with en-001 (English - world), but it had no effect.

I have a app that has both mobile and watch versions. Recently some testers report that the watch app could not be launched if the put the app in the background and then resume. And if they kill the app and try to launch again, there is no any response when tapping the app icon. I managed to export some system logs by installing a sysdiagnose profile, and this info looks suspicious

I was selected as one of the winners for the recent Swift Student Challenge, and I was wondering if we will get more information regarding the delivery of the AirPods Max 2 and the certificate? Were these already delivered? I haven't received any email about this, so I wanted to ask here.

Excited for AlarmKit! I have found two concerns that I cannot find answers for though. The volume of my alarms seems to be very quite relative to the full volume capability of the device. For example, if I turn the volume all the way up and play the audio file, the sound is very loud. However then, if I set the alarm using alarm kit with the same audio, the track played during the alerting phase is not that loud. I am afraid that it will not be loud enough in real life. Will there be future support to set the volume level of the alarm to maximum settings? When I press the volume buttons (with the app open) during an active alarm, the audio stops, but the alarm manager does not clear these events. The alarm manager does clear the alarm event if the alarm is stopped through a live activity.

It appears that hidesBottomBarWhenPushed no longer works in iOS 26 Beta 1. Is it supposed to work, is it going away or is there a alternate behavior we should be using?