Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Hello developers! Thank you for your dedication to creating apps with great performance. We’re excited to kick off another year of partnering with you on improving power and performance in your apps. At WWDC26, check out the following new things in the latest platform SDKs and Xcode 27 beta for performance. You can also join us online for a Power and Performance Group Lab on Tuesday, June 9 at 11 AM Pacific. Meet State Reporting and the new MetricKit State reporting: The new StateReporting framework lets your application express its state to downstream tools like Instruments and MetricKit. Make your telemetry and traces much more useful by adopting this simple API. MetricKit: In the 27 releases, the Swift-first MetricManager API replaces the MXMetricManager API. Combined with State Reporting, the new MetricKit provides more granular metrics to isolate performance problems faster. It also provides a more expressive API that is great to use in Swift, with improved Swift concurrency and Codable support. With this year’s releases, the MXMetricManager API is considered legacy. ▶️ To learn more, watch Meet the new MetricKit. Discover new features in Xcode organizer Metric goals: Xcode organizer now provides a goal metric for Battery Usage, Disk Writes, Hang Rate, Hitches, Memory, and Storage metrics, allowing you to prioritize performance engineering across more areas. Generate recommendations: Quickly resolve the highest impact performance issues in your app by using Generate Recommendations for Crash, Energy, Disk Write, Hang and Launch diagnostics. Insights overview: The new insights overview in Xcode organizer summarizes high-impact performance regressions for metrics and diagnostic reports, helping you plan and prioritize performance engineering work. Storage metrics: Storage metrics are now available in Xcode organizer, allowing you to monitor your app's Documents & Data and App Size across releases and catch regressions in cache usage and bundle size. Hitches metric: The new Hitches metric replaces the Scrolling metric in the organizer and now displays hitches for all animations in your app, giving you a comprehensive view of animation performance. ▶️ To learn more about other advancements in Xcode, watch What’s new in Xcode 27. Improve app responsiveness with Instruments Foundation Models: The Foundation Models instrument is redesigned with a tree view that lets you drill into individual requests, inspecting tool call arguments and results, inference prompts and responses, and token statistics. Use it to understand caching behavior, measure latency, and optimize throughput. System Trace: System calls, VM faults, and thread states are now unified into a single plot, with a new blending algorithm that stays readable even at high density. Once you spot something worth investigating, left/right key navigation lets you follow a thread's activity step by step, and the inspector provides quick actions like pinning the thread that made another thread runnable. System Trace now also draws thread priority and QoS over time, making it easier to identify priority inversions and unexpected QoS degradations that affect responsiveness. Swift Concurrency: New Main Actor and Global Concurrent Executor tracks let you visualize running tasks and executor queue depth over time, making it easier to spot task scheduling delays and actor contention. Tasks are now grouped into collections for faster navigation. Swift Tasks, Actors, and Executors instruments can now surface Call Trees, Flame Graphs, and Top Functions scoped to each entity — so you can pinpoint exactly where concurrency overhead lives. Top Functions: Helper functions and runtime internals can be expensive but hard to spot in a standard call tree. The new aggregation mode in Top Functions surfaces any function's total execution time across the entire call stack, making it easy to identify and prioritize hidden hotspots. Run Comparison: Compare call tree data across builds to identify regressions and performance wins. Results can be explored as an outline, flame graph, or top functions — choose whichever view best fits your workflow. ▶️ To learn more about profiling your app with Instruments, watch “Profile, fix, and verify: Improve app responsiveness with Instruments” ▶️ To learn about Foundation Models optimization, watch “Debug and profile agentic app experiences with Instruments”. If you have any questions about using State Reporting or the new MetricKit, create a post on the forums. For help creating a post, see Tips on writing a forum posts.

We are seeing an intermittent production crash on iOS 27.0 while the system text-editing menu is active. Environment Device: iPhone 15 OS: iOS 27.0 Orientation: Portrait Xcode: [Xcode 26.4] Detail： Fatal Exception: NSInternalInconsistencyException 0 CoreFoundation 0x98190 __exceptionPreprocess 1 libobjc.A.dylib 0xc380 objc_exception_throw 2 Foundation 0x426ae0 -[NSMutableDictionary(NSMutableDictionary) initWithContentsOfFile:] 3 UIKitCore 0xca4e48 BUG_IN_CLIENT_OF_TARGETED_PREVIEW__VIEW_IS_NOT_IN_A_WINDOW 4 UIKitCore 0x66f558 -[UITargetedPreview initWithView:parameters:] 5 UIKitCore 0x1699cb0 -[UIEditMenuInteraction _contextMenuInteraction:configurationForMenuAtLocation:completion:] 6 UIKitCore 0x174cff8 -[UIContextMenuInteraction _interactionShouldBeginAtPoint:completion:] 7 UIKitCore 0x174a48c -[UIContextMenuInteraction _presentMenuAtLocation3D:] 8 UIKitCore 0x16999a8 -[UIEditMenuInteraction _editMenuPresentation:handoffDisplayedMenuWithContext:] 9 UIKitCore 0x15bf75c -[_UIEditMenuContentPresentation _performContextMenuHandoffForMenu:sourceView:] 10 UIKitCore 0x15bf610 -[_UIEditMenuContentPresentation editMenuListViewDidActivateHandoff:source:] 11 UIKitCore 0xd52810 -[_UIEditMenuListView _performHandoffFromSourceView:] 12 UIKitCore 0x5740c4 -[UIApplication sendAction:to:from:forEvent:] 13 UIKitCore 0x573ef4 -[UIControl sendAction:to:forEvent:] 14 UIKitCore 0x5737f8 -[UIControl _sendActionsForEvents:withEvent:] 15 UIKitCore 0x6d1e94 -[UIButton _sendActionsForEvents:withEvent:] 16 UIKitCore 0xd53bb8 -[_UIEditMenuListView _selectItemAtIndexPath:] 17 UIKitCore 0xd53104 -[_UIEditMenuListView _handleSelectionGesture:] 18 UIKitCore 0x5e798c -[UIGestureRecognizerTarget _sendActionWithGestureRecognizer:] 19 UIKitCore 0x5e77fc _UIGestureRecognizerSendTargetActions 20 UIKitCore 0x5e7580 _UIGestureRecognizerSendActions 21 UIKitCore 0xe4b30 -[UIGestureRecognizer _updateGestureForActiveEvents] 22 UIKitCore 0xe4984 -[UIGestureRecognizer gestureNode:didUpdatePhase:] 23 Gestures 0xcdac __swift_memcpy8_8 24 Gestures 0x397acc block_destroy_helper.6 25 Gestures 0xd514 __swift_memcpy8_8 26 Gestures 0xa87c __swift_memcpy8_8 27 Gestures 0x1a608 __swift_closure_destructor.8 28 UIKitCore 0xea41c -[UIGestureEnvironment _updateForEvent:window:] 29 UIKitCore 0xec298 -[UIWindow sendEvent:] 30 UIKitCore 0x5e5874 -[UIApplication sendEvent:] 31 UIKitCore 0xe2bdc __dispatchPreprocessedEventFromEventQueue 32 UIKitCore 0x6ad78 updateCycleEntry 33 UIKitCore 0x69b88 _UIUpdateSequenceRunNext 34 UIKitCore 0x69928 schedulerStepScheduledMainSectionContinue 35 UpdateCycle 0xbc0 UC::DriverCore::continueProcessing() 36 CoreFoundation 0x267cc __CFMachPortPerform 37 CoreFoundation 0x4a24c CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE1_PERFORM_FUNCTION 38 CoreFoundation 0x4a45c __CFRunLoopDoSource1 39 CoreFoundation 0x3a634 __CFRunLoopRun 40 CoreFoundation 0x3b7f4 _CFRunLoopRunSpecificWithOptions 41 GraphicsServices 0xf24 GSEventRunModal 42 UIKitCore 0xba1cc UIApplicationMain 43 flashexpress 0x303948 main + 17 (AppDelegate.swift:17) 44 ??? 0x1810675b8 (缺失)

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?

I'm using the macOS 26 vmnet network API with Virtualization framework (vmnet_network_create + VZVmnetNetworkDeviceAttachment) and giving each VM a stable address with vmnet_network_configuration_add_dhcp_reservation, plus creation-time rules from vmnet_network_configuration_add_port_forwarding_rule. Both work on the network's first run. But if the network's last interface leaves while I still hold the vmnet_network_ref, then the next interface start brings the network back without its reservations or forwarding rules. The subnet and gateway are kept. How it shows up in practice: a VM that is the only guest on its network gets restarted from inside the guest. Virtualization framework removes and re-adds the VM's vmnet interface about 1 s apart, with no delegate callback. That's enough to stop and restart the network, and the guest comes back on a dynamic lease with its forwarded ports refused. Minimal repro, no VM needed: Create a configuration in VMNET_SHARED_MODE with set_ipv4_subnet, one add_dhcp_reservation and one add_port_forwarding_rule, then call vmnet_network_create. vmnet_interface_start_with_network. InternetSharing logs port forwarding enabled …, and /etc/bootptab contains the reservation. vmnet_stop_interface. InternetSharing logs no internal interface left, stopping network → reset to idle, and /etc/bootptab is emptied. vmnet_interface_start_with_network again on the same, still-retained ref. InternetSharing logs has been started with no port forwarding enabled line, and /etc/bootptab is never rewritten. The forwarded port is refused. Control: release the ref, call vmnet_network_create again from the same configuration, and start an interface. The reservation and the rule are both back. Reproduced on macOS 27.0 (26A428) and (with a minimal vmnet only test, no actual VM) on macOS 26.6.2 (25G83). This seems to contradict the documentation for vmnet_network_create: "The lifetime of such reservation is the same as that of vmnet_network_ref." A related issue: vmnet_interface_add_ip_port_forwarding_rule and its remove and get counterparts return VMNET_FAILURE synchronously on an interface started with vmnet_interface_start_with_network. The same calls work on a vmnet_start_interface interface. The add_port_forwarding_rule documentation points to those calls for managing rules after start, so there's no way to put a rule back after the restart. The same "torn down on last detach while the ref lives on" lifecycle is also reported in apple/container#2051 (https://github.com/apple/container/issues/2051), with a different symptom (two networks sharing a bridge, so tearing one down breaks the other's egress). It proposes the same mitigation: an anchor interface held with vmnet_interface_start_with_network. Filed as: FB24895271: reservations and rules discarded when the last interface is removed FB24895264: the runtime forwarding calls fail on network-attached interfaces FB24895282: suggestion for a network state-change callback and a DHCP lease query by MAC Questions: Is losing reservations and rules when the network goes idle intended? Is holding an app-owned interface on the network (via vmnet_interface_start_with_network) so it never reaches zero interfaces a supported workaround, or does it risk other side effects?

We are evaluating a lifecycle architecture for a local macOS application and would appreciate guidance on supported public APIs. Proposed architecture: A normally signed, non-root host application. One embedded XPC service with exactly one intended client. No application-created subprocesses inside the service. No privileged helper, persistent LaunchAgent, exported endpoints, private APIs, or reduced system security. One bounded operation per session. Failed or interrupted operations must not automatically be retried. Initial validation would use synthetic workloads only. Our current evaluation target is macOS 15.6 on Apple silicon, using the macOS 15.5 SDK. Please identify any relevant deployment-version limitations. The XPC overview (https://developer.apple.com/documentation/xpc) describes an embedded service as tied to its client's lifetime. We also understand that xpc_connection_cancel (https://developer.apple.com/documentation/xpc/xpc_connection_cancel(_:)) is asynchronous and non-preemptive; we are not treating connection cancellation as proof of service termination. We need clarification on these points: Client death and service startup Does the documented client-lifetime relationship cover client termination, including SIGKILL, during service startup before the first reply? Does it also cover an already running service that is blocked or stopped with SIGSTOP? Which behavior is guaranteed, and which timing or failure cases are intentionally unspecified? Timeout while the client remains alive What supported public mechanism should a normal application use to terminate its own unresponsive embedded service when an operation exceeds its deadline? We want to avoid PID enumeration, PID-reuse races, broad process-group signaling, and exporting a full task-control port. Is there a supported identity-bound termination mechanism? If not, what architecture does Apple recommend? A stopped or hung client remains alive, so we do not assume client-lifetime coupling handles that separate failure case. Observing termination Which public notification reliably identifies the exit of the particular service instance, as distinct from connection invalidation or a missing reply? Because launchd is the parent, the application cannot simply waitpid the service. Is reaping entirely launchd's responsibility, and what completion claim can the application legitimately make? Identity and required privileges Which public signing requirements, launch constraints, sandbox settings, or entitlements are necessary for this architecture? Please distinguish authentication before accepting work from constraints enforced before service code executes. We do not assume peer authentication also grants termination rights. Restart behavior After interruption, cancellation, client exit, or service failure, under what circumstances can launchd or subsequent XPC activity start a replacement service? What supported pattern prevents accidental resubmission or resumption of the same failed operation? We are not asking for hard real-time guarantees during kernel failure, or claiming that forced termination proves callback completion or explicit memory zeroization. If this combination of requirements is unsupported, identifying that boundary and the smallest supported architectural alternative would be a useful answer. Documentation references or a minimal public sample would be welcome.

The language in the new EULA seems to indicate we can get permission to run more than 2 VMs on a single host. "(iii) except as otherwise provided in writing, signed, or issued by an authorized representative of Apple, to install, use and run up to two (2) additional copies or instances of the Apple Software, or any prior macOS or OS X operating system software or subsequent release of the Apple Software, within virtual operating system environments on each Apple-branded computer you own or control that is already running the Apple Software, for purposes of: (a) software development; (b) testing during software development; (c) using macOS Server; or (d) personal, non-commercial use." This is important because we often have use-cases that require running docker containers and other Virtualization tools along-side of two VMs on the host and obviously cant. What's the steps we can take to get written permission for this? Thank you!

After scouring the XNU kernel source code, I came across restartable ranges [1]. They seem to be a task-level version of the the part of Linux's restartable sequences [2] for user requested synchronization [3] (akin to MEMBARRIER_CMD_RSEQ). Because of their differences, I would like to know more about how they work and what they are used for. From what I have gathered [4], they seem to be closer to RCU [5] that waits for eviction (as opposed to completion). But the fact that they are barely mentioned anywhere (see [4]) in the XNU source code I'd be really happy if you can point me to more information about them and how they compare to rseq (or rcu). What are the XNU devs planning on doing with them? [1] osfmk/kern/restartable.c: https://github.com/apple-oss-distributions/xnu/blob/f6217f8/osfmk/kern/restartable.c [2] https://criu.org/Restartable_Sequences [3] as opposed to (what I think is what makes rseq really cool) automatic eviction on preemption/CPU migration [4] there seems to be very little information online (including this forum) and the only places inside the XNU kernel source trees that aren't tests are in osfmk/kern/{thread,thread,sched_prim}.{c,h}, which doesn't really give much more information. [5] Read-Copy-Update: https://www.kernel.org/doc/html/latest/RCU/whatisRCU.html

I’m looking for clarification on what iOS currently allows third-party apps to do in these areas: Siri integration and background voice activation: Can an iOS app implement a custom voice assistant that responds to a wake phrase such as “Hey Nowa” and performs app tasks through voice commands? Could it listen while the app is terminated or the iPhone is locked, similar to Siri? Call recordings: Is there a supported way for an iOS app to access recordings of phone calls made on the user’s iPhone and make them available within the app? I couldn’t find documentation for an API that provides access to these recordings. SMS access: Is there a supported way for an iOS app to access and fetch all SMS and iMessage conversations stored in the user’s Messages app, so they can be viewed within our app? As far as I understand, iOS may not allow these capabilities for third-party apps, but I’d appreciate clarification. If any are supported, could you please point me to the relevant Apple documentation?

I'm trying to write a NWProtocolFramerImplementation class that will be channeled through a Framer wrapper. There are still some parts I need figuring out. For handleOutput(framer: message: messageLength: isComplete), what do the last two parameters do? Does isComplete refer to the end of the current conversation, or the entire connection? Why would we submit a messageLength if the data size should already be implied within message? If I parse by line breaks, is there a way to indicate if the latest line is the last of the current conversation, either input or output?

I am seeing a repeatable interaction between audio activity or audio-device discovery and a Bluetooth LE HID mouse on a Mac mini M2 Pro. Opening the detailed Sound panel in Control Center, or changing the HDMI audio output, makes the pointer stutter. Opening Apple’s Music.app has also caused a temporary complete loss of the mouse. In the worst cases, the mouse becomes completely unavailable and does not recover without Bluetooth troubleshooting or re-pairing. Configuration Mac mini Mac14,12, Apple M2 Pro, 32 GB RAM macOS Tahoe 26.7 (25G229) Also reproduced on macOS Tahoe 26.1 (25B78) Logitech MX Anywhere 3 Mac over Bluetooth LE VID 0x046D, PID 0xB025 Firmware MPM24.01_0015 Logitech MX Keys M Mac over Bluetooth LE PL4071UH display and audio output over HDMI Logi Options+ installed Trigger Connect the MX Anywhere 3 Mac and MX Keys over Bluetooth. Open Control Center from the menu bar. Open the detailed Sound panel, or change the HDMI audio output. Move the Bluetooth mouse continuously while audio-output discovery is taking place. The issue is intermittent, but it has been reproduced several times on both macOS 26.1 and 26.7. Pointer stuttering can continue after the Sound panel is closed. A later incident occurred when I opened Apple’s Music.app. The Bluetooth mouse became unavailable again, but this time it recovered automatically after approximately ten seconds. The Sony WH-1000XM6 headset was connected over Bluetooth, while the 512 GB USB flash drive was not connected. This shows that the USB drive is not required for a temporary mouse loss and makes concurrent Bluetooth audio activity a more relevant condition to investigate. The additional trigger suggests that the problem may not be limited to the Control Center interface itself and may also be associated with audio-subsystem initialization or audio-device activity. This is an observation, not yet a confirmed causal link. Additional condition in the permanent-loss cases In every incident where the mouse did not recover on its own and became effectively unusable, the following two devices were also present: a Sony WH-1000XM6 wireless headset connected over Bluetooth; a 512 GB SanDisk USB flash drive connected to the Mac. I am reporting this as a correlation, not as a confirmed cause. The headset adds simultaneous Bluetooth audio activity. The USB drive may or may not be relevant depending on its USB mode, activity, shielding, physical location, and possible 2.4 GHz interference. The 512 GB capacity is included only to identify the device. Less severe cursor stuttering has also been observed around Sound-panel discovery; the two devices above are specifically the common condition I recorded during the permanent mouse-loss incidents. Observed result The pointer starts stuttering and raw mouse HID reports develop multi-second gaps. In severe incidents, the Bluetooth mouse stops working entirely. Opening Music.app has also caused a temporary complete loss of the mouse; during that incident the Sony WH-1000XM6 was connected over Bluetooth, the USB flash drive was not connected, and the mouse recovered automatically after approximately ten seconds. Logi Options+ then displays the mouse as inactive. The mouse disappears from the IOHID tree, while the Bluetooth keyboard can remain present. A wired USB mouse remains responsive, so the Mac and pointer rendering are not completely frozen. The failure can persist after the Sound panel is closed. Relevant logs On macOS 26.7, bluetoothd repeatedly recorded the following sequence for the MX Anywhere 3 Mac: MX Anywhere 3 Mac needs low latency current connection parameters: interval 30.00 ms, latency 0 connection changed to: interval 7.50 ms, latency 44 Device "MX Anywhere 3 Mac" is Incompatible LE HID Device "MX Anywhere 3 Mac" does not have _HID_SERVICE_ Connection timed out disconnect result: 307 BLEPaired HIDBadBehavior Central The sequence repeated during automatic reconnection attempts. The mouse later recovered on some occasions, but other incidents required turning Bluetooth off for about 15 seconds, turning it back on, forgetting the mouse, and pairing it again. Instrumented reproduction During a monitored reproduction on macOS 26.1: detailed audio discovery started at +21.333 s; a 2.400 s gap in raw HID reports from the mouse occurred 0.899 s before that event; bluetoothd then reported a HID lag issue for VID 0x046D, PID 0xB025 at +1.897 s; no display-frame gaps were detected; there was no sustained CPU saturation. This indicates that the interruption is already present in the raw HID input stream. It does not appear to be only a cursor animation or WindowServer rendering delay. Expected result Discovering or switching audio outputs should not alter a separate BLE HID mouse connection, cause multi-second HID report gaps, remove _HID_SERVICE_, or disconnect the mouse. Technical points for investigation Could this be a macOS Bluetooth/HID connection-parameter or service-discovery problem triggered by concurrent audio discovery? In particular, why does macOS change the mouse from 30 ms / latency 0 to 7.5 ms / latency 44, then classify it as Incompatible LE HID, lose _HID_SERVICE_, and eventually disconnect it with result 307? Has anyone reproduced the same sequence with a Logitech BLE mouse, a Bluetooth audio headset, or a USB 3 storage device connected? The issue was also submitted through Apple’s public macOS feedback form on 24 September 2026. That form confirmed receipt but did not provide an FB case number. Possibly related report Another Developer Forums report describes a different BLE HID device with Incompatible LE HID and disconnect result 307 on macOS 27. The hardware and trigger are different, but the Bluetooth/HID failure signature may be related: https://developer.apple.com/forums/thread/845857

I'm getting a persistent WeatherKit authentication failure that survives every standard troubleshooting step. Hoping someone from the WeatherKit team can check the backend sync for my Team ID. Team ID: 9CQUMUHB42 Bundle ID: com.martin.MinimalWidgets (app) Bundle ID: com.martin.MinimalWidgets.MinimalWidgetsWidget (widget extension) Error: Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" What I've verified: WeatherKit capability is enabled in Xcode for BOTH the app and widget extension targets WeatherKit is enabled in the App ID configuration for both identifiers in the Developer Portal Confirmed with codesign -d --entitlements :- that com.apple.developer. weatherkit is correctly present and set to true in the signed binaries for both the app and the extension WeatherKit Usage dashboard shows 500,000 calls/month quota, 0 used Cleared the provisioning profile cache at ~/Library/Developer/Xcode/UserData/Provisioning Profiles, ran Download Manual Profiles again Clean Build Folder, deleted the app from device, reinstalled Restarted the test device Waited over 24 hours since first enabling the capability None of the above resolved it — the exact same error persists on every attempt, including today. This looks like a backend entitlement sync issue between the Developer Portal and the WeatherKit auth service rather than a local configuration problem, since the signed entitlements are confirmed correct on my end. Could someone from the WeatherKit team check the sync status for this Team ID / Bundle ID and confirm whether WeatherKit token generation is enabled server-side? Happy to provide any additional diagnostic info (sysdiagnose, device logs, etc.) if needed. Thanks in advance!

We need to retain CarPlay's native A–Z button between the scroll arrows in an audio app. This is core navigation for an album/artist library. We use CPListSection(items:header:sectionIndexTitle:) with single-character labels. The sectionIndexTitle API is still documented and is not deprecated in the Xcode 27 SDK. We need the supported native implementation, not a custom picker. On a parked physical head unit with an iPhone running iOS 27, our app displays populated album rows and section headers but no A–Z. Apple Music displays A–Z on the same head unit. We do not know Apple Music's internal implementation. A standalone, public-API-only reproduction is prepared; its CarPlay scene code is included below. Each tab supplies four A/B/M/Z sections of ten synthetic rows. The variants are initially populated, updated after loading, the full section initializer, and securely archived and decoded sections. No network, authentication or artwork is required. The original app displays functioning native alphabet navigation on the iOS 26.5 CarPlay simulator. The public probe compiles. We cannot run an end-to-end iOS 27 CarPlay simulator session because Device Hub requires a physical device, as confirmed in developer forum thread 834440. Separately, an isolated local diagnostic hosted the native list renderer with CarPlay traits. Both runtimes receive four nonempty index labels and all 40 rows. On iOS 26.5 (23F77), its table data source returns A/B/M/Z. On iOS 27.0 (24A434), the attached UICollectionViewDiffableDataSource returns nil index titles. Both the full initializer and secure archive round-trip preserve titles but produce the same result. This diagnostic is not an end-to-end CarPlay session and does not establish the exact internals on the physical phone. A standard UIKit table supplied with index titles and CarPlay traits still displays the native A–Z button on the same iOS 27 runtime. The control itself still exists; the observed failure is the template-to-index connection. This control experiment is also hosted in a phone window, not a CarPlay session. A standard UIKit collection data source implementing indexTitles(for:) also shows index letters on this runtime; the unmodified template renderer's collection data source returns nil. We have not modified that renderer. Questions: Did iOS 27 move native CPListTemplate alphabet navigation to another API, configuration, or presentation requirement? What is the supported migration? If sectionIndexTitle remains the correct input, is this a known regression in the new list renderer, and what supported correction is available? How should third-party audio apps reproduce Apple Music's native alphabet navigation on iOS 27 without private API or replacing it with a custom control? Please provide a working public-API example or identify the relevant fix/version. Reproduction: use the audio CarPlay entitlement and configure CPTemplateApplicationScene with CarScene as its delegate. This is the scene code from the compiling standalone probe: import CarPlay import UIKit @MainActor func indexedSections() -> [CPListSection] { ["A", "B", "M", "Z"].map { letter in let items = (1...10).map { number in let item = CPListItem(text: "\(letter) Album \(number)", detailText: "Synthetic test entry") item.handler = { _, completion in completion() } return item } return CPListSection(items: items, header: letter, sectionIndexTitle: letter) } } final class CarScene: UIResponder, CPTemplateApplicationSceneDelegate { func templateApplicationScene(_ scene: CPTemplateApplicationScene, didConnect controller: CPInterfaceController) { let ready = CPListTemplate(title: "Ready", sections: indexedSections()) ready.tabTitle = "Ready" ready.tabImage = UIImage(systemName: "list.bullet") let updated = CPListTemplate(title: "Updated", sections: [CPListSection(items: [CPListItem(text: "Loading", detailText: nil)])]) updated.tabTitle = "Updated" updated.tabImage = UIImage(systemName: "arrow.clockwise") let full = CPListTemplate(title: "Full Init", sections: indexedSections().map { CPListSection(items: $0.items, header: $0.header ?? "", headerSubtitle: nil, headerImage: nil, headerButton: nil, sectionIndexTitle: $0.sectionIndexTitle) }) full.tabTitle = "Full Init" full.tabImage = UIImage(systemName: "list.bullet.rectangle") let decoded: CPListTemplate do { let sections = try indexedSections().map { section in let data = try NSKeyedArchiver.archivedData(withRootObject: section, requiringSecureCoding: true) guard let restored = try NSKeyedUnarchiver.unarchivedObject(ofClass: CPListSection.self, from: data) else { throw CocoaError(.coderReadCorrupt) } return restored } decoded = CPListTemplate(title: "Decoded", sections: sections) } catch { decoded = CPListTemplate(title: "Decode failed", sections: [CPListSection(items: [ CPListItem(text: "Section decoding failed", detailText: String(describing: error)) ])]) } decoded.tabTitle = "Decoded" decoded.tabImage = UIImage(systemName: "shippingbox") controller.setRootTemplate(CPTabBarTemplate(templates: [ready, updated, full, decoded]), animated: false) { _, _ in } Task { @MainActor in try? await Task.sleep(for: .seconds(2)) updated.updateSections(indexedSections()) } } }

I’m building an iOS app using MapKit that allows users to create and navigate trails. I need offline map functionality, I was wondering if MapKit supports that. If not I was wondering if MapBox is a viable alternative to MapKit though I would prefer using MapKit. Thanks!

To whomever this may concern, We are investigating a BLE firmware-update compatibility issue affecting a legacy Nordic nRF51 DFU bootloader on a subset of iPads. We are seeking guidance on whether there are known CoreBluetooth or Bluetooth-controller differences across recent iPad hardware that could affect reconnection to Bluetooth LE connectable directed advertisements. Background Our accessory uses a legacy Nordic nRF51 DFU flow: The iPad is connected to the accessory’s normal application firmware. The app requests entry into DFU mode. The accessory disconnects normally. The accessory restarts into its bootloader. The bootloader sends connectable directed advertisements targeted at the iPad that initiated DFU. The iPad is expected to reconnect, after which the firmware transfer begins. Observed behavior On working iPads, the BLE trace shows: Application disconnect → accessory begins connectable directed advertising → iPad sends BLE connection indication → bootloader connection succeeds → DFU begins On affected iPads, the trace shows: Application disconnect → accessory begins the same connectable directed advertising → no connection indication from the iPad → DFU cannot proceed The accessory is advertising to the current resolvable address of the connected iPad. The bootloader starts directed advertising at nearly identical timing in both working and failing traces, approximately 456 ms after disconnect. The initial disconnect is normal in both cases: LL_TERMINATE_IND / Remote User Terminated Connection / reason 0x13 The problem occurs only after the accessory begins directed advertising. It seems like the iPad might be able to receive and listen to directed advertisement, however it seems to be unable to send back a connection indication. Hardware correlation observed so far We observed a correlation with Bluetooth controller vendor information visible in our BLE captures: FORMAT FOR FOLLOWING LINES Result -> Example device -> Observed controller vendor DFU succeeds -> iPad Air, 5th generation -> Broadcom DFU succeeds -> Other tested iPads, including one iPad with an A16-class platform -> Broadcom DFU fails -> One affected iPad with an A16-class platform -> MediaTek We want to be careful not to overstate this result: We have tested only one affected MediaTek-based iPad so far. The model string is MD3Y4LL/A and its current iOS version 26.6.1. The functioning Broadcomm iPads A16 we have tested that did not fail DFU process have model string MD7F4KN/A. The other iPad models we tested DFU on (which were all successful, albeit none of them were MediaTek chips, they were all Broadcomm) were: MRJN2KN/A, MM9C3KN/A, MQ6J3KN/A, MM6T3KN/A (the latter with iOS 26.6.1 as well, suggesting it is not necessarily an iPad OS version issue) We have not found a second MediaTek-based iPad to determine whether the behavior reproduces across that hardware. We initially suspected that recent non-cellular iPads might consistently use MediaTek, but this was disproved by the iPad Air, 5th generation we tested (MM9C3KN/A): it had no cellular connection and used Broadcom, and DFU worked normally. Therefore, we do not conclude that the issue is caused by MediaTek hardware. We only see a correlation worth investigating. What we have ruled out The target firmware image is not involved; failure occurs before any firmware data is transferred. The accessory reaches bootloader mode and sends directed advertisements at the expected time. The iOS Nordic DFU library already calls CoreBluetooth’s normal reconnect API: centralManager.connect(peripheral, options: nil) iOS does not expose an API allowing an app to create or send a raw Link Layer CONNECT_IND; therefore the application cannot directly work around controller-level connection behavior. The affected iPad does not provide a normal scanner/discovery callback for this directed bootloader advertisement, so matching by name or service UUID is not available as an application-layer workaround. Questions . Are there known CoreBluetooth, iPadOS, or Bluetooth-controller differences that can affect handling of BLE connectable directed advertisements, particularly when an accessory directs advertisements to a central using a resolvable private address? . Is there a recommended CoreBluetooth pattern for reconnecting to a known peripheral after it restarts into a legacy bootloader that uses directed advertising? . Does CBCentralManager.connect(_:options:) queue a pending connection request that should be serviced when a matching directed advertisement is received? If so, are there circumstances in which this behavior differs by iPad hardware or controller implementation? . Is there any public diagnostic information, entitlement, or supported API that could help us determine why a pending CoreBluetooth connection request does not result in a connection attempt in this scenario? . Does Apple recommend a specific compatibility approach for legacy BLE DFU bootloaders that use directed advertising, beyond updating the accessory firmware to use ordinary undirected advertising? . We can provide packet captures from both the working and failing cases, including timestamps, directed-advertisement target addresses, and the absence/presence of the subsequent connection indication. Thank you for any guidance on whether this is expected behavior, a known compatibility limitation, or if there is anything we could try on our end to hopefully resolve this issue.

I’m using the new Preview app on an iPhone running iOS 27 with a multi-page PDF that contains selectable text. Apple’s Preview guide says PDF text search is supported: open the PDF, tap Search, type a word/phrase, and use previous/next match arrows. But I cannot find a Search/Find control anywhere. I checked: • The visible top toolbar • The filename dropdown (it only shows Duplicate, Move, Rename, Export, and Print) • The **- - - ** menu • The bottom toolbar Has anyone found the actual Find in PDF control in the current iPhone Preview interface? If it is missing for you too, please include your iPhone model and exact iOS 27 version/build.

On macOS 27.2 beta 1/2 our URL filter never starts: the session loops starting -> stopping. The same build works on macOS 27.0 (26A428). Both our TestFlight and notarized standalone builds fail. Prefilter and PIR registration succeed. The PIR status request then fails: NWPath is satisfied, the connection is configured proxy fail closed, proxy strict fail closed, the proxy fails (event: proxy:children_failed), and the error is NSURLErrorDomain -1009 / POSIX 50 "Network is down" with _NSURLErrorPrivacyProxyFailureKey=true. NEMembershipCheckerErrorDomain Code=3 -> NEAgentURLFilterErrorDomain Code=3; the app sees serverSetupIncomplete. The privacy-proxy allow-list entry is identical on macOS 27.0 and 27.2 beta (com.adguard). Disabling the VPN, rebooting, and recreating the URL filter configuration do not help. Log excerpt: neagent: updatePrefilterWithCompletionHandler - result 1 neagent: <NEPIRChecker> - Register with PIR Server (group <com.adguard.safari.AdGuard> ... PrivacyProxyFailOpen <0> ...) -> completed registration ciphermld: [C3 ...] proxy fail closed, proxy strict fail closed ciphermld: [C3.1.1 ... failed proxy (satisfied (Path is satisfied), interface: en0[802.11], ipv4, dns, uses wifi, flow divert agg: 2, LQM: good)] event: proxy:children_failed ciphermld: queryStatus: NSURLErrorDomain -1009 / POSIX 50 "Network is down", _NSURLErrorPrivacyProxyFailureKey=true, NWPath=satisfied neagent: Failed to startFilter <Error Domain=NEMembershipCheckerErrorDomain Code=3 "(null)"> nesessionmanager: NEURLFilterPlugin(com.adguard.safari.AdGuard[url-filter][inactive]): setStatus:error: - err Error Domain=NEAgentURLFilterErrorDomain Code=3 Filed as FB24933164.

Subject: Hard SMC and Kernel bug on 14" MacBook Pro M5 Pro (Mac17,9) in Build 26B5091g - High Power Mode completely unresponsive Hello CoreOS and Apple Silicon Performance Engineering Teams, I am writing to report a severe, reproducible system-level regression regarding High Power Mode and SMC power distribution on the new 14-inch MacBook Pro with the M5 Pro chip (Model Identifier: Mac17,9), currently running macOS 27.2 Beta 2 (Build 26B5091g). The issue prevents the M5 Pro hardware from scaling its cooling and power envelope correctly, rendering High Power Mode completely broken regardless of the power source (tested with both official 96W and 140W Apple power adapters). Key technical diagnostic findings from my device: Kernel vs UI State Mismatch: Running pmset -g via Terminal returns powermode 2, proving that the kernel registers High Power Mode as active. However, the System Information profile reader (Hardware -> Power) shows a direct conflict: "High Power Mode: No" and "Low Power Mode: Yes" (Режим энергосбережения: Да). Unresponsive SMC & Fan Curves: The cooling hardware remains completely unresponsive to the high-performance toggle. The fans fail to engage the pre-emptive 4500-5000 RPM cooling curve under heavy compute or gaming loads, remaining locked in the silent "Automatic" profile, which causes artificial thermal constraints. Powermetrics Telemetry Anomalies: A raw powermetrics trace captured during this state reveals a severe thread management bug: The P0-Cluster (High-Performance cores) shows a down residency of 98.88%, meaning the heavy performance cores are effectively kept asleep by the OS governor during high-power configuration. Combined Power (CPU + GPU + ANE) drops to a mere 429 mW. The thermal sampler entirely fails to pull hardware RPM telemetry from the SMC fan loops, providing only a generic "Current pressure level: Nominal" string. This profile behavior confirms that the macOS 27.2 power governor layer is suffering from a hard breakdown in SMC communication specific to the J614/Mac17,9 platform. The operating system handles the software flag but fails to pass the physical instruction downstream to the hardware control registers. Please prioritize this issue for the next macOS 27.2 beta cycle to ensure full thermal and compute optimization for the M5 Pro architecture prior to the final public release. I have attached the complete sysdiagnose archive, terminal configuration text files, and raw powermetrics logs. Thank you for your dedication to Apple Silicon optimization. FB24929043

Hi, I’m developing a macOS Finder Sync extension and noticed that NSMenuItem.separator() does not appear to render as a standard separator line when used inside the menu returned from FIFinderSyncController. In a normal AppKit NSMenu, the separator renders as expected. However, when the same kind of menu is returned from the Finder Sync extension, the separator appears as a blank/full-height empty row rather than a thin dividing line. Example: override func menu(for menuKind: FIMenuKind) -> NSMenu { let menu = NSMenu(title: "") menu.addItem(NSMenuItem( title: "First Action", action: #selector(firstAction(_:)), keyEquivalent: "" )) menu.addItem(NSMenuItem.separator()) menu.addItem(NSMenuItem( title: "Second Action", action: #selector(secondAction(_:)), keyEquivalent: "" )) return menu } Expected result: The separator should render as a normal macOS menu separator line between the two menu items. Actual result: In Finder’s context menu, the separator is displayed as blank vertical space / an empty menu row. I understand that Finder Sync menus are rendered by Finder and may not support every NSMenuItem feature. However, NSMenuItem.separator() is a very standard way to visually group menu commands, so I wanted to ask: Is this a known limitation of Finder Sync extension menus? Is there a supported way to display a real separator line in Finder Sync context menus? Should this be filed as a Feedback Assistant issue against Finder Sync / AppKit? I’m trying to avoid fake separators such as disabled menu items with "────" as the title, since that does not feel native and may not behave well with different fonts, accessibility settings, or appearance modes. Thanks!

Hi, Overview I have a SwiftData project which automatically syncs with CloudKit. When I run the app, I see the following error in Xcode logs. Error updating background task request: Error Domain=BGSystemTaskSchedulerErrorDomain Code=3 "(null)" My attempt I can enable Background processing (under Signing & Capabilities > Background modes), but I don't know the BGTaskSchedulerPermittedIdentifiers to add in the Info.plist Questions How can I resolve this? If I should enable background processing, what are the BGTaskSchedulerPermittedIdentifiers to add in Info.plist?

Hi, Problem I have a widget which displays a bright red. When I display the same view inside the app, the red is bright. However when I use the same view on the widget, the color looks a bit dull. Note: Widget Style: Default (Always) It is the same dull red when in focus and when not in focus This happens on iOS (device and simulator) and macOS Questions How can I fix it on the widget? Does widget support Display P3 colors? Any help on this would be much appreciated.

Looking for guidance on how to escalate a PassKit issue that appears to be at the team-account level, after two months of exhausting every client-side variable. SYMPTOM Every .pkpass I sign under team XMJKFS3D66 (Mesh Community AS, Norway) is silently rejected on install with: "Sorry, your Pass cannot be installed to Passbook at this time." The rejection is silent — no user-facing hint at what iOS objects to. WHAT I'VE RULED OUT Reproduced across: 3 separate Pass Type IDs (pass.com.meshcommunity.membership original, .membership after re-issue, brand-new pass.com.meshcommunity.kiosk) 2 independently-issued signing certs on the same identifier 3 iPhone testers on 3 different iOS builds with different Apple IDs Paris Pinkney (WWDR DTS) sent me the standard 6-item team-wide checklist on Aug 5, and I'm verifiably clean on all six: Cert not expired — notBefore 2026-07-08, notAfter 2027-08-07 Cert not revoked — OCSP status "good" from ocsp.apple.com/ocsp03-wwdrg404 WWDR G4 intermediate matches cert issuer OU Program membership active, latest PLA accepted Both Pass Type IDs Active in Portal Team ID XMJKFS3D66 matches everywhere (pass.json.teamIdentifier + cert OU) Also verified: openssl smime -verify -in signature -inform DER -content manifest.json -noverify → "Verification successful" Full chain in signature: Pass Type ID cert → WWDR G4 → Apple Root CA PKCS#7 detached, DER, SHA-256, -noattr CDN serves application/vnd.apple.pkpass THE DEFINITIVE TEST To rule out the last remaining plausible client-side hypothesis (missing primaryFields causing a silent layout rejection, suggested by an independent review), I built a minimal known-good pass: { "formatVersion": 1, "passTypeIdentifier": "pass.com.meshcommunity.kiosk", "teamIdentifier": "XMJKFS3D66", "organizationName": "Mesh Community", "serialNumber": "10001", "description": "Mesh Kiosk Pass", "logoText": "Mesh Community", "foregroundColor": "rgb(255, 255, 255)", "backgroundColor": "rgb(25, 25, 25)", "barcodes": [ { "format": "PKBarcodeFormatQR", "message": "10001", "messageEncoding": "iso-8859-1" } ], "generic": { "primaryFields": [ { "key": "name", "label": "MEMBER", "value": "Test User" } ] } } ASCII-only, no emoji, no hyphenated serial, includes primaryFields, minimal fields Same signing recipe, same G4 chain, verify clean Same 6 standard PNG assets (icon + logo, 1x/2x/3x) Result on a fresh iPhone: identical silent rejection. Same "Sorry, your Pass cannot be installed to Passbook at this time." dialog. At this point every plausible client-side variable has been isolated and eliminated. The block appears to be at team level inside Apple's PassKit backend — invisible from the Developer Portal. WHAT APPLE HAS DONE SO FAR DTS Case-ID: 21008005 — opened 2026-07-13, reproducer.zip attached same day Assigned engineer: Paris Pinkney (WWDR, DTS) since 2026-08-05 Sysdiagnose: filed via Feedback Assistant as FB24516356 on 2026-08-26 (device Serial HWT3HQ2F9F, SEID captured, iOS 23G71, reproduction timestamp 2026-08-13 11:02:15 +0200) with Wallet debug profile installed on the device before reproduction Radio silence since 2026-08-17 — 5 weeks and counting, including no reply to a polite check-in on 2026-09-08 WHAT I'M ASKING Anyone at Apple engineering seeing this: is there a way to accelerate the Case-ID 21008005 / FB24516356 log review? The PassbookUIService / PassKit / PassKitCore entries around the timestamp above would settle this in minutes on your end. Any developer who's hit team-wide PassKit rejection before: what unblocked it? Was it a PLA re-acceptance, a Developer Program Support ticket (separate from DTS), a re-provisioning request, something else? Any way to inspect a team's backend PassKit entitlement state from outside (a Portal page, an endpoint, an xcrun command), so I can either confirm my suspicion or eliminate it myself? Any known-good published .pkpass from a Norwegian-registered (C=NO) Developer Team I can diff against, just to eliminate country-registration as a factor? Working Apple Wallet is a launch-blocker for the Mesh Community Workbar Kiosk rollout — we're currently shipping Google Wallet + QR-in-email as a full fallback and it works everywhere including iPhone, so no user is being turned away. But we'd like to close the Apple Wallet loop, and after 2 months I've run out of things to try from my side. Any pointer welcome. Happy to share the full evidence bundle privately with anyone at Apple who can help. Thanks, Mesh Community AS · Team ID: XMJKFS3D66