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.

Hi Quinn — following up from DTS case 22070584. I'm working on a Windows compatibility runtime (Wine plus a CPU translator) that runs natively on Apple Silicon. 64-bit x86 Windows programs work fine. 32-bit ones don't, because they need address space in the low 4 GB: guest pointers are 32-bit, and some Windows structures sit at fixed addresses like 0x7ffe0000 that programs read directly. On arm64 I can't get anything down there: task_info(TASK_VM_INFO) -> min_address 0x100ea0000 mmap(0x7ffe0000, MAP_FIXED) -> ENOMEM mach_vm_allocate(0x7ffe0000, VM_FLAGS_FIXED) -> KERN_INVALID_ADDRESS There's also nothing below 4 GB to remove: mach_vm_region finds no entry there at all, and mach_vm_deallocate(0, 4 GB) returns KERN_SUCCESS without changing anything. Building with a smaller __PAGEZERO doesn't help either — every size I tried (0x1000, 0x4000, 0x10000, 0x100000, 0x1000000, 0x10000000, 0x80000000) gets SIGKILLed before main, with no crash report. Ad-hoc signing, the hardened runtime and -no_pie made no difference. I did notice /usr/libexec/rosetta/runtime is arm64 with no __PAGEZERO segment at all and __TEXT at vmaddr 0, so the kernel can clearly do this, at least for platform binaries. Is there a supported way for a third-party arm64 process to map below 4 GB — an entitlement, a spawn attribute, something I've missed? If the answer is no, that's fine, I'd just like to know so I can stop looking and plan around it. I have two small test programs that print all of the above if they'd be useful.

We have a group of Macs that mount SMB shares over 10 GbE with jumbo frames (MTU 9000). Since late June, they have been kernel panicking several times a day with the same assertion: panic(cpu N caller ...): assertion failed: m->m_flags & M_PKTHDR, file: .../xnu/bsd/kern/uipc_mbuf.c, line: 4839 @uipc_socket.c:8260 Panicked thread: dlil_input_en0 Last started kext: com.apple.filesystems.smbfs 6.0.1 Environment Clients: Mac Studio (M1 Max and M1 Ultra) and Mac Pro (2019, Intel with T2), using the built-in 10GBASE-T at MTU 9000 macOS 26.5.1 (25F80), 26.6.2 (25G83) and 26.7 (25G229); it panics on all three Servers: Samba-based NAS, SMB 3.1.1, signing on, encryption off Filed as FB24912731 What we've found It still panics with our third-party EDR fully uninstalled. The Mac that panics needs an active SMB session. A Mac left on the network without a share mounted stayed up through several events that took down the others. Panics are often simultaneous across machines: two to six Macs, with different hardware and different macOS builds, within the same minute. It doesn't need sustained heavy throughput. Some panics came within minutes of reconnecting, during light editing. Setting kern.skywalk.flowswitch.rx_agg_tcp_host=0 did not help. The switch and server links stay up, and spanning tree doesn't change during these events. Only the Macs' ports drop. In one server-side capture, the client stopped sending within about 0.2 ms of receiving a READ response made of 8948-byte frames. That fits the panicked thread being dlil_input. Two existing threads look related Kernel panic using Vagrant synced folders via NFS beginning with macOS 15.4 (FB17853906). A DTS reply there said the issue is in kernel mbuf management and that SMB "is very likely to experience a similar panic." Incorrect packet handling in SMBClient MacOS 26, which describes a race in SMBClient under heavy load above about 10 Gbps. Questions Is this the same underlying issue as FB17853906, and is a fix planned for macOS 26? Our 2019 Mac Pros can't move to a later major release. Is there a known workaround, such as a sysctl, an nsmb.conf option, or a change to MTU or offload settings? Is there logging or a diagnostic we can leave enabled to capture more state at panic time? We can't reproduce this on demand, but between several machines we see it multiple times a day. We can provide full panic reports, sysdiagnoses, and packet captures from both client and server sides.

While attempting to read a user’s daily step history spanning backward to the last 7 days, a small but consistent subset of users encounter Error Code 3 with the underlying error description: Error Code 3 "Unable to invalidate interval: no data source available." When this error occurs, we are entirely unable to read their step history. We have received ~10 direct user reports of this within the last couple of weeks.

When I tap on one of the buttons in the ShieldAction extension I want to close the shield and open the parent app instead of the shielded app. Is there any way of doing this using the Screen Time API? class ShieldActionExtension: ShieldActionDelegate {      override func handle(action: ShieldAction, for application: ApplicationToken, completionHandler: @escaping (ShieldActionResponse) -> Void) {     // Handle the action as needed.           let store = ManagedSettingsStore()               switch action {     case .primaryButtonPressed:       //TODO - open parent app       completionHandler(.defer)     case .secondaryButtonPressed:       //remove shield       store.shield.applications?.remove(application)       completionHandler(.defer)         @unknown default:       fatalError()     }   }   }

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

If you submitted a request for a Critical Alert Notifications entitlement and did not receive a response, please resubmit your request.

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.

Starting in iOS 27, opening a tel: URL that contains a call-forwarding MMI code from an app shows a system alert and dials nothing: Malicious Link Blocked: This link was blocked because it contains malware that will forward all of your incoming messages and calls to 1 (XXX) XXX-XXXX. Scammers often provide malicious links that look legitimate via email, text, or chat. On iOS 26 the same call showed the normal call confirmation prompt and the carrier applied the forwarding. Repro (in response to a button tap): UIApplication.shared.open(URL(string: "tel:*21*XXXXXXXXXXX%23")!) Typing *21*XXXXXXXXXXX# into the Phone app's keypad by hand still works on iOS 27, so the capability is still there; only the in-app handoff is blocked. This breaks setup for call-screening and visual-voicemail apps whose onboarding depends on carrier forwarding (*21*, *61*, *67*, *71*, *72). It also blocks the disable codes (##21#, ##004#, *73), so users can't turn forwarding off from inside the app, which works against the user's own safety. The anti-hijack intent makes sense for links arriving from Messages, Mail or Safari. For a user tap inside an installed App Store app, a confirmation sheet ("Forward calls to ...? Allow") seems like the right balance, and disable codes should always be allowed. Filed as FB24843805. Questions: Is this block meant to apply to links opened by an installed app in response to a user tap? Is there a supported API, entitlement or URL form to hand a forwarding code to the Phone app with user confirmation? Our current workaround is to copy the code to the clipboard and ask the user to paste it into the keypad, which is a real drop-off point for our (mostly older) users. If you're affected too, please file your own feedback and reference FB24843805.

My custom filesystem kernel extension stores ACLs as an extended attribute, com.apple.system.Security. Sanboxed apps such as TextEdit, Pages, etc., running as a non-privileged process, fail to save modified contents when permissive ACLs are in use. Running them as a privileged process, does allow for file changes to be saved though. Non-sandboxed apps, such as VSCode, and command line programs are not susceptible to this behaviour. APFS, on the other hand, seems to handle ACLs as an ATTR_CMN_EXTENDED_SECURITY filesystem attribute, rather than as an EA. In this case, sandboxed apps have no trouble accessing the ACL data. I implemented a minimal PoC within my custom kext to verify this. I construct an ACL in memory allowing a given user to write,append,delete file contents, and return it that via vnop_getattr. This allows the file contents to be modified and saved by sandboxed apps. Can you please confirm if my findings are accurate and sandboxed apps fail to read the com.apple.system.Security EA by design? Also, Is it an accurate assumption, that ACLs should be handled either as an EA, or an ATTR_CMN_EXTENDED_SECURITY, but not both? Thanks.

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!

Dear Apple Developer Support, I am developing HushRise, an iPhone alarm application intended to help people in Ukraine manage sleep disrupted by wartime air-raid alerts. Nighttime alerts can force people to interrupt their sleep and seek shelter, sometimes repeatedly. Families must then plan work, school, and other responsibilities around these disruptions. Educational institutions and other services may suspend in-person activities during alerts, making a fixed wake-up time less useful than a wake-up signal that takes the current alert status into account. The purpose of HushRise is to support rest and daily routines under these conditions. It is not an official emergency-warning service and must not replace civil-defence alerts or encourage people to ignore them. The intended behavior is: A user sets a wake-up time and selects their region. At that time, the alarm starts only after a fresh server response confirms that no air-raid alert is active. If an alert is active, the application waits for the reported all-clear. Multiple alarms postponed during the same alert should produce one wake-up signal after the all-clear. A snoozed alarm must also obtain fresh confirmation before starting again. An alarm that has already started may continue until the user stops or snoozes it. We have tested a native AlarmKit integration on a physical iPhone. The system alarm, Lock Screen controls, Apple Watch presentation, and Stop action work. However, without ongoing background audio, iOS suspends our application’s status checks. In one test, an alarm due at 20:09 was not scheduled until the application returned to the foreground at 20:11. Audible background playback helped in experiments, but requiring continuous sound is not appropriate for the intended quiet sleep experience. Could your technical team please advise: What supported architecture should we use for an AlarmKit alarm whose trigger depends on a server event occurring at an unknown time? Can a server notification initiate the necessary validation and alarm scheduling while the iPhone is locked, and what execution guarantees or limitations apply? Is there an entitlement or approval process appropriate to this use case? Would Critical Alerts be applicable, or would another mechanism be more suitable? Which capabilities require Apple Developer Program membership? Our current prototype is installed through a free Personal Team. We understand that an offline device cannot receive new server information and that notification delivery may be delayed. We want to communicate these limitations honestly and build within Apple’s supported APIs. We can provide a minimal reproducible project, sanitized device logs, and a description of our physical-device tests. Thank you for helping us identify a reliable and appropriate approach for people whose sleep and daily lives are affected by the war in Ukraine. Kind regards, HushRise developer

What happens Since installing macOS 27.2 b2 (didn't go through b1, might have been there already), the Contacts app has become almost unusable on my two Macs. Opening a contact or moving to the next one often freezes the app for 8 to 10 seconds, with the spinning wheel. It happens many times in a row while browsing the address book. It comes back no matter what I try: restarting, letting iCloud resync the contacts, deleting and recreating cards. Once, it seemed to go away for a couple of minutes upon restarting, but it returned. Both Macs share the same iCloud account (~690 contacts): a MacBook Pro M4 Pro and a Mac mini M4, both on 27.2 b2 (26B5091g). Reported as FB24928119. Technical details All 18 Contacts_*.spin reports show the main thread blocked in CNCDContactFetcher withLockedContext_fetchPosterData, waiting on a synchronous XPC call to com.apple.contacts.poster.api. That service is postersyncd, which syncs Contact Posters. The kernel kills postersyncd with exceeded mem limit: InactiveHard 20 MB (fatal) at 30–35 MB. launchd relaunches it every ~10 s: 74 kills in 26 h on one Mac, 54 in 24 h on the other. log stream --level debug shows the same sequence on every relaunch: START: Background cleanup → Potential cleanup for missingLocalContactIdentifiers → FetchingContacts → killed within the same second. The cleanup never finishes, so it restarts forever. The poster store (group.com.apple.contacts/ContactsMetadata) is ~85 MB, with blobs of up to 9 MB each. The memory limit stays InactiveHard even while Contacts is frontmost. Moving the poster store aside doesn't help: iCloud rebuilds it in ~25 s. Posters deleted from iOS or iCloud.com get a deletion date but are never purged. Question: has anyone else seen this on 27.2 b2? Is there a way to reset the Contact Posters data stored in iCloud?

What happens Since installing macOS 27.2 b2, the Contacts app has become almost unusable on my two Macs. Opening a contact or moving to the next one often freezes the app for 8 to 10 seconds, with the spinning wheel. It happens many times in a row while browsing the address book. It comes back no matter what I try: restarting, letting iCloud resync the contacts, deleting and recreating cards. Once, it seemed to go away after restarting, but it returned after a couple of minutes into using Contacts again. Both Macs share the same iCloud account (~690 contacts): a MacBook Pro M4 Pro and a Mac mini M4, both on 27.2 b2 (26B5091g). Reported as FB24928119. Technical details All 18 Contacts_*.spin reports show the main thread blocked in CNCDContactFetcher withLockedContext_fetchPosterData, waiting on a synchronous XPC call to com.apple.contacts.poster.api. That service is postersyncd, which syncs Contact Posters. The kernel kills postersyncd with exceeded mem limit: InactiveHard 20 MB (fatal) at 30–35 MB. launchd relaunches it every ~10 s: 74 kills in 26 h on one Mac, 54 in 24 h on the other. log stream --level debug shows the same sequence on every relaunch: START: Background cleanup → Potential cleanup for missingLocalContactIdentifiers → FetchingContacts → killed within the same second. The cleanup never finishes, so it restarts forever. The poster store (group.com.apple.contacts/ContactsMetadata) is ~85 MB, with blobs of up to 9 MB each. The memory limit stays InactiveHard even while Contacts is frontmost. Moving the poster store aside doesn't help: iCloud rebuilds it in ~25 s. Posters deleted from iOS or iCloud.com get a deletion date but are never purged. Question: Has anyone else seen this on 27.2 beta? Is there a way to reset the Contact Posters data stored in iCloud?

Feedback ID: FB24937933 I’m seeing a persistent launch failure across multiple unrelated apps on an iPhone 15 Pro Max. Affected apps include Telegram, Box, LinkedIn, Amazon, Apple Podcasts, Shazam, and others. The behavior is consistent: I launch the app. The app stays on a black or frozen launch screen. After approximately 19–20 seconds, iOS terminates the app. Retrying may occasionally work temporarily, but the problem returns. Crash reports from multiple unrelated apps show essentially the same termination: EXC_CRASH / SIGKILL 0x8BADF00D scene-create watchdog transgression More importantly, the main thread repeatedly shows this pattern: xpc_connection_send_message_with_reply_sync NSXPCCONNECTION_IS_WAITING_FOR_A_SYNCHRONOUS_REPLY -[__NSURLBackgroundSession setupBackgroundSession] -[__NSURLBackgroundSession initWithConfiguration:delegate:delegateQueue:delegateDispatchQueue:] This appears to indicate that the app’s main thread is synchronously waiting for an XPC-backed system service while creating a background NSURLSession, and the response does not arrive before the scene-create watchdog timeout. I first reproduced this on iOS 26.6.2 and the problem still occurs after updating to iOS 27.0 (24A437). Troubleshooting already performed: • Force restart • Network Settings Reset • Background App Refresh disabled • VPN/proxy disabled • Affected apps deleted and reinstalled • iOS updated from 26.6.2 to 27.0 Because the same stack pattern is occurring across multiple unrelated third-party apps, as well as Apple apps such as Podcasts and Shazam, this does not appear to be isolated to a single application. Apple Support has also told me that similar cases have been reported and that the issue may be addressed in a future software update. Has anyone seen a system-level NSURLBackgroundSession / XPC service enter this kind of stuck state across multiple applications? Is there a known issue involving the background URLSession service or related networking daemon that could cause synchronous XPC calls during app launch to block until the watchdog terminates the process? I have submitted the full crash reports through Feedback Assistant under FB24937933.

I tried to compile the latest mDNSResponder (2881.120.11) for linux and discovered that it simply doesn't build: ../mDNSShared/uds_daemon.c: In function ‘resolve_result_callback’: ../mDNSShared/uds_daemon.c:3629:46: error: ‘request_state’ has no member named ‘resolve_awdl’ 3629 | const mDNSBool is_split_awdl_query = (req->resolve_awdl && question->InterfaceID == AWDLInterfaceID); | ^~ ../mDNSShared/uds_daemon.c:3629:89: error: ‘AWDLInterfaceID’ undeclared (first use in this function); did you mean ‘mDNSInterfaceID’? 3629 | const mDNSBool is_split_awdl_query = (req->resolve_awdl && question->InterfaceID == AWDLInterfaceID); | ^~~~~~~~~~~~~~~ This line was introduced in release 2881.60.4 (Jan 5, 2026), and all of the AWDL-related changes made to uds_daemon in that version look like unfinished code: The line shown above which references a non-existent struct field and nowhere-defined identifier/constant. Two functions in uds_daemon.c define a variable mDNSBool has_split_awdl_query = mDNSfalse; which is unused apart from its (unconditionally false) value being logged. The max-size-check for struct request_state in uds_daemon.h is increased but the struct itself wasn't changed (nor does the release introduce any other changes that might indirectly change the size of the struct) This code is common to all supported targets, so that means all four mDNSResponder releases done this year fail to build on all platforms. I'm a bit astonished how this even happens and has gone unnoticed for this long. Unfortunately it's not clear how to properly report this, the github repo has no issue tracker and the feedback assistant doesn't seem to have applicable options for this.

Hello all, Looking for guidance for my app. I run a workout studio and the time frames for classes are all in military time. I have tried extensively to have this turned off and I am just unsure what is left to do. Has anyone dealt with something like this?

We receive live relative-altitude updates from CMAltimeter.startRelativeAltitudeUpdates(to:withHandler:) on iPhone. CMAltitudeData inherits CMLogItem.timestamp, which the documentation describes as the time when the item is valid and as seconds since device boot. We need to determine whether a pressure measurement's event time falls inside an application operation bounded by a supported monotonic clock. Could Apple clarify the supported contract for CMAltitudeData.timestamp on iOS? Does CMAltitudeData.timestamp use the same epoch and rate as mach_absolute_time(), DispatchTime.uptimeNanoseconds, CACurrentMediaTime(), or ProcessInfo.systemUptime? If only some are compatible, which ones? Does it advance or pause during device sleep, device lock, application suspension, and background execution? In particular, are its sleep/suspension semantics guaranteed to match any of the clocks above? Is there a supported API for converting CMLogItem.timestamp to a host CMClock/Mach time, or for sampling “now” in the exact same clock domain used by CMAltitudeData.timestamp? Are the answers contractual across supported iPhone hardware and iOS releases, or are they implementation details that applications should not rely on? If direct comparison is not supported, what Apple-supported clock or conversion mechanism should an application use to compare a CMAltitudeData event time with two application-side monotonic operation boundaries? The question concerns clock semantics only. A minimal reproducer can be supplied if requested, but no application identifier, production data, sensor values, or user data is required to answer it.