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.

Hello, I submitted a Network Extension URL Filter (Oblivious HTTP) configuration in CloudKit Console almost a week ago. It still says In Review / Waiting for Approval and I haven't heard anything back since the submission notice. I wanted to check whether anything is missing on my end. Just in case, the configuration ID is 60802ed4-abfa-4b20-a64e-0d35230f478a. The app is an open-source ad and tracker blocker from the developers of an existing content blocker with a large user base. On iPhone and iPad its system-wide blocking runs entirely through the URL filter. Until the configuration is approved the iOS app can't block anything at all, and our testers are left with a Mac-only product in the meantime. Because lookups go through Apple's relay to our own PIR server, we never learn which sites anyone visits. All four endpoints have been live since the day I submitted and the TXT records are in place. Every database we build also includes the www.apple.com/url-filter-test validation entry. Is there anything else I need to provide, or a rough timeline I should expect? Thank you in advance!

Hi! We have an app that highly depends on CoreBluetooth including scanning for peripherals with an advertised serviceUUID. Our app sets the CBCentralManagerScanOptionAllowDuplicatesKey flag to true while scanning. Receiving continuous discovery events about nearby devices is key to measure the RSSI before connecting. Updating some of our test devices to watchOS 27 we noticed that our app is broken. To analyze further we created a simple app to compare behavior between watchOS 26 and 27, and the difference is clear. On the 27 device it behaves like the flag is ignored and we only receive a couple of callbacks to centralManager(_:didDiscover:advertisementData:rssi:) then it stops. We could not find any documentation declaring this as a new restriction or something regarding that has changed. Is this a bug, or is there a way to get the old behavior on the new OS? The example app used for testing is available here: https://github.com/levente-gulyas-skidata/WatchBLEExperiments (Change the serviceUUID for testing if needed) Thank you, Levi

What we're doing During time-limited sales, our app shows a countdown Live Activity on the Lock Screen. It's started locally when the user opens the app (no push, no pushType, no push tokens), and its end is scheduled for the sale's start/end time: let activity = try Activity<SaleAttributes>.request(attributes: attributes, contentState: .init()) await activity.end(using: .init(), dismissalPolicy: .after(saleEndDate))The sale time is the same for every user, so the Live Activity ends at the same second on every device. What we expected At saleEndDate, the system removes the Live Activity from the Lock Screen, and nothing else happens. What actually happens If the app isn't running at that moment (the user left it earlier and didn't swipe it away), the system removes the Live Activity and then launches our app in the background: 01:18:59.995 SpringBoard [BundleID: com.example.app] finished, removing from the list... 01:19:00.019 liveactivitiesd Sending request to open "com.example.app" 01:19:00.023 SpringBoard Received trusted open application request … from <… com.apple.liveactivitiesd …> 01:19:00.069 SpringBoard Bootstrapping app<com.example.app> with intent backgroundThe app receives a normal application(_:didFinishLaunchingWithOptions:) with applicationState == .background and empty launchOptions. No other app delegate callback follows. Our app can't tell this apart from any other launch, so it runs its full startup: it builds the home screen and calls our backend APIs. Because this happens on a large number of devices in the same second, our backend gets a sharp burst of traffic exactly at sale start and sale end, from users who never opened the app. What we've checked App still running in the background at the end time: no new launch. App swiped away by the user before the end time: no launch. Live Activity removed by the user before the end time: no launch at the end time. Steps to reproduce Open the app; it starts a Live Activity with its end scheduled 15 minutes ahead. Leave the app with the Home gesture (don't swipe it away) and lock the device. Wait until the system terminates the app process. At the scheduled end time, the Live Activity is removed and the app is launched in the background (log above). Environment iPhone 15, iOS 26.6 (23G71) UIKit app, UIApplicationDelegate lifecycle (no scenes) NSSupportsLiveActivities = YES; UIBackgroundModes = [processing, remote-notification] Questions Why does the system launch the app when a Live Activity reaches its scheduled end? Is this intended? Can we avoid it? Is there a supported way to end a Live Activity at a scheduled time without the system launching the app? If not, how should we handle it? Is there a way to know at launch that it was caused by the Live Activity ending, or what's the recommended way to avoid running the full startup (UI and network calls) for this launch?

I’m testing the first in-app purchase for an iOS app. It is a non-renewing subscription that grants 12 months of access. On November 9, a physical iPhone running our TestFlight build reproduced the same issue twice in the China mainland Sandbox storefront. Setup checked at the time The annual product was Ready to Submit in App Store Connect, with China mainland availability, a CNY 98 price, and a Simplified Chinese localization. The annual product identifier matched the identifier requested by the app. The explicit Bundle ID matched App Store Connect and had In-App Purchase enabled. The Paid Apps Agreement was active, and banking and tax records were in place. We used a mainland-China Sandbox tester and called the native StoreKit 2 Product.products(for:) API. The request included the configured annual product and an old monthly identifier that has no corresponding product in App Store Connect. Steps and results Install the app from TestFlight on a physical iPhone and open the purchase screen in Sandbox. Refresh the available products. We expect the annual product and its localized price to appear. Product.products(for:) completes with an empty array. Device logs show an HTTP 200 response from the China mainland Sandbox catalog followed by Ignoring empty product response. After the 600-second cache lifetime, the query received a different server correlation key and still returned no products. This occurs during product lookup, before any purchase call. TN3186 says that Sandbox testing can take place before submission for review. Has anyone reproduced this specifically with a non-renewing subscription? Is there another way to verify Sandbox catalog visibility for the configured annual product or diagnose why it is omitted? An annual-only StoreKit query would be a useful follow-up test. We can share the exact app and product identifiers, request correlation keys, and device diagnostics with Apple through Feedback Assistant.

Summary Recent macOS release observed intermittent system-wide DNS failures after sleep/wake on multiple devices running Global Secure Access (GSA) with NETransparentProxyProvider. Previously successful DNS lookups time out after wake across applications, including browsers and GSA. Two captures contain failure-time evidence of the mDNSResponder resolver queue predominantly waiting in close()/kernel. Other captures show similar DNS failures, but a shared root cause has not been established. Call chain, from thread entry to kernel wait: start_wqthread + 8 _pthread_wqthread + 292 _dispatch_workloop_worker_thread + 720 _dispatch_root_queue_drain_deferred_wlh + 284 _dispatch_lane_invoke + 392 _dispatch_lane_serial_drain + 332 _dispatch_source_invoke + 920 _dispatch_source_cancel_callout + 208 _dispatch_continuation_pop + 596 _dispatch_client_callout + 16 close + 8 fleh_synchronous + 72 sleh_synchronous (sleh.c:1610) unix_syscall (systemcalls.c:181) fp_close_and_unlock_with_action (kern_descrip.c:1874) fg_drop (kern_descrip.c:287) soclose (uipc_socket.c:1345) soclose_locked (uipc_socket.c:1138) cfil_sock_close_wait (content_filter.c:5743) soflow_db_apply (socket_flows.c; line unavailable) cfil_filters_udp_attached_per_flow (content_filter.c:6675) _sleep (kern_synch.c:213) lck_mtx_sleep_deadline (locks.c:1583) thread_block_reason (sched_prim.c:4060) thread_invoke (sched_prim.c:3443) Steps to reproduce The issue is intermittent. These steps describe the observed sequence, not a deterministic minimal reproduction. Run the GSA client using NETransparentProxyProvider. The affected configurations also have Microsoft Defender network extensions active. Verify that a system DNS lookup succeeds for a known hostname. Allow the Mac to sleep, including maintenance DarkWake cycles. Wake the Mac and repeat system DNS lookups or use applications requiring hostname resolution. Observe repeated approximately 30-second lookup timeouts, sometimes longer. Observed results November 5, 2026 - UTC+05:30 capture User-reported impact: Recurrence of the same sleep/wake connectivity symptoms. OS: macOS 27.2 (26B123). Incident window: 20:38-20:41 IST / 15:08-15:11 UTC. The same Chrome client/name A lookup succeeds earlier in 12.984 ms but times out after wake in 29,999.705 ms. The DNS service/server route changed, so this is not a controlled identical-network comparison. The resolver records 1,007 timeout callbacks during the incident window, across browsers, Teams, GSA, Defender and other processes. The failure-time spindump at 20:40:21.009-20:40:31.013 IST shows the original mDNSResponder PID 78534 with 715/715 resolver-queue samples under dispatch-source cancellation → close() → kernel → lck_mtx_sleep_deadline. Source: spindump.txt:75998-76093. This establishes a sampled wait, not a permanent deadlock or proof of the same root cause as November 2. The file descriptor and kernel/filter wait owner remain unidentified. A later matching Chrome lookup returns an address at 20:43:18.191816 IST on the same resolver PID, without a recorded resolver restart. This establishes some recovery, not that every application or tunnel recovered. November 2, 2026 - UTC-08:00 capture User-reported impact: No network upon wake. This eventually resolves without a reboot, after approximately 5 to 15 minutes of waiting. OS: macOS 27.2 (26B123). Incident window: 09:40-09:45 PST / 17:40-17:45 UTC. The same Edge A lookup succeeds before sleep in 19.346 ms but times out after wake in 29,999.826 ms. The resolver records 1,403 timeout callbacks during the incident window. The failure-time spindump shows 770/777 resolver-queue samples under dispatch-source cancellation → close() → kernel; 769 include lck_mtx_sleep_deadline. This establishes a dominant sampled wait, not a permanent deadlock. The file descriptor and kernel/filter wait owner remain unidentified. November 3, 2026 - UTC-08:00 capture (Mihai) Evidence: mihai_gsa_error.tar.gz The following example records a failure resolving GSA’s own control-plane endpoint, whose DNS lookup is not intercepted by the GSA tunnel. Times in these excerpts are local (UTC-08:00). GSA error [2026-11-03 10:13:58.463] Network connection to the Global Secure Access Edge could not be established StreamId: ControlStream Hostname: <tenant>.auth.client.globalsecureaccess.microsoft.com:443 Error: hostname lookup error: Address lookup failed os_error: nodename nor servname provided, or not known syscall: getaddrinfo mDNSResponder records 10:13:19.663661 [R125367->DupQ50990->Q38408] Duplicate question <private> dn:04wpeA (Addr) 10:13:58.468519 [R125367] DNSServiceQueryRecord STOP -- name hash: dn:04wpeA, duration: 39s 10:13:59.078847 [R125340] QueryRecordOpCallback: Question <private> dn:04wpeA (Addr) timing out, InterfaceID 0x0 Additional observations The original resolver records 11 timeout callbacks across GSA, Defender, Spotify and the system time service. A GSA A-query returns a positive result in 1.282 ms earlier (cache-compatible, not a cold upstream baseline), then the same client/name/qtype/flags times out after 41.865784 wall-clock seconds; that interval includes sleep. The DNS service/server set changes, so this is not a controlled same-network comparison. At 09:40 PST the Wi-Fi interface becomes inactive and loses its IPv4 address, followed by no-dns-service results. The first native lookup errors precede this link loss; it does not explain the entire case. Four GSA A/AAAA timeout transactions have matching late UDP replies. For one A-query, the reply is logged 25.095999 seconds after its matching send and 7.197434 seconds after the API timeout, during shutdown. 48 acceptable UDP response records appear within 1.467 ms. The location of the delay is not identified.

We're seeing a crash from a user on iOS 27.2 that we can't reproduce locally. The crash shows swift_unexpectedError on the main thread with no application frames between the concurrency runtime and the crash. Our app binary hasn't changed since summer 2025 but this user started experiencing the crash for the first time about a week ago. Thread 0 (crashed): Thread 0 Crashed (com.apple.main-thread): 0 libswiftCore.dylib _assertionFailure(_:_:file:line:flags:) 1 libswiftCore.dylib swift_unexpectedError 2 libswift_Concurrency.dylib swift::runJobInEstablishedExecutorContext(...) 3 libswift_Concurrency.dylib swift_job_runImpl(...) 4 libdispatch.dylib _dispatch_main_queue_drain 5 libdispatch.dylib _dispatch_main_queue_callback_4CF 6 CoreFoundation __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ ... (standard UIApplicationMain run loop)The crash occurs 0.45 seconds after launch. The only other active thread at the time of the crash is Thread 6, which shows TipKit driving SwiftData/CoreData work: Thread 6: Thread 6 name: Dispatch queue: NSManagedObjectContext 0x110f99500 0 CoreFoundation CFBasicHashGetPtrIndex 1 CoreFoundation CFBasicHashCreate 2 CoreFoundation CFDictionaryCreateMutable 3 CoreData _PFCMT_SetValue 4 CoreData -[NSManagedObjectContext _retainedObjectWithID:optionalHandler:withInlineStorage:] 5 CoreData -[NSManagedObjectContext objectWithID:] 6 SwiftData (SwiftData + 373080) 7 SwiftData (SwiftData + 281172) 8 SwiftData (SwiftData + 359244) 9 SwiftData (SwiftData + 355724) 10 SwiftData (SwiftData + 359208) 11 CoreData thunk for @callee_guaranteed () -> (@out A, @error @owned Error) 12 CoreData partial apply for thunk for @callee_guaranteed () -> (@out A, @error @owned Error) 13 CoreData NSManagedObjectContext._rethrowsHelper_performAndWait(...) 14 CoreData thunk for @callee_guaranteed @Sendable () -> () 15 CoreData thunk for @escaping @callee_guaranteed @Sendable () -> () 16 CoreData developerSubmittedBlockToNSManagedObjectContextPerform 17 libdispatch.dylib _dispatch_client_callout 18 libdispatch.dylib _dispatch_lane_barrier_sync_invoke_and_complete 19 CoreData -[NSManagedObjectContext performBlockAndWait:] 20 CoreData NSManagedObjectContext.performAndWait(_:) 21 SwiftData (SwiftData + 258584) 22 SwiftData (SwiftData + 257920) 23 SwiftData (SwiftData + 326480) 24 SwiftData (SwiftData + 259564) 25 SwiftData (SwiftData + 56292) 26 SwiftData (SwiftData + 385736) 27 TipKitCore (TipKitCore + 202216) 28 TipKitCore (TipKitCore + 128232) 29 TipKitCore (TipKitCore + 124104) 30 TipKitCore (TipKitCore + 130048) 31 TipKitCore (TipKitCore + 241553) 32 TipKitCore (TipKitCore + 152365) 33 TipKitCore (TipKitCore + 134441) 34 TipKitCore (TipKitCore + 152629) 35 TipKitCore (TipKitCore + 134233) 36 TipKitCore (TipKitCore + 134441) 37 TipKitCore (TipKitCore + 138237) 38 TipKitCore (TipKitCore + 134233) 39 libswift_Concurrency completeTask(swift::AsyncContext*, swift::SwiftError*)All other threads are idle. Context: We call try? Tips.configure([.displayFrequency(.hourly)]) early in our startup sequence. The try? should swallow any error from configure itself, but I'm not sure if TipKit spawns its own internal async tasks. Our app uses UIKit (not SwiftUI App lifecycle). We do not use SwiftData directly — any SwiftData/CoreData frames come from system frameworks. The binary hasn't changed since summer 2025, so this appears to be an OS-level regression on iOS 27.x. We cannot reproduce locally. Questions: Is there a way to get async backtraces in crash reports from the field, or is this only possible under the debugger? If TipKit spawns an internal Task that throws into a non-throwing context, would that produce exactly this crash pattern — swift_unexpectedError on the main thread with no third-party frames? Are there known issues with TipKit's internal SwiftData tasks crashing on iOS 27.x? Any guidance on narrowing this down without a local repro would be appreciated.

I'm developing a private macOS application on an Apple-silicon Mac mini running macOS Golden Gate 27.2. I'm evaluating a system LaunchDaemon running under a dedicated, non-administrator identity that cannot log in interactively. A separate desktop application would communicate with the daemon through authenticated local IPC. Before implementing this architecture, I would like to establish the officially supported approach. My main question: What is the Apple-supported method for creating and maintaining a dedicated, non-administrator, non-interactive service identity for a system LaunchDaemon on macOS 27.2? In particular: Is there a documented procedure for creating, restricting, disabling, recovering and eventually removing this identity? Are dscl, sysadminctl or another account-management mechanism supported for this purpose? Can a LaunchDaemon run under this identity without an interactive user login, including when registered through SMAppService? Are there any secure-token, FileVault, volume-ownership or keychain restrictions that would affect this design? If a dedicated non-login service identity is not a supported architecture, what alternative does Apple recommend? I'd particularly appreciate links to official Apple documentation or guidance from Apple engineers. Thank you.

What supported behaviour, if any, may applications rely on for inherited RLIMIT_AS when launching a process on macOS on Apple silicon using posix_spawn and subsequent exec transitions? An older published XNU header defines RLIMIT_AS: XNU resource.h (immutable revision) I am looking for the documented support and virtual-address-space accounting scope, including exclusions. For a finite limit already set in the launching process, does any documented guarantee cover the new process from its first executable or dynamic-loader mapping and across later exec transitions, or does the limit take effect at a later stage? If the limit cannot be applied, does launch abort before any target user code executes, what failure is reported, and can mappings occur before that failure? An explicit statement that this guarantee is not provided would also be helpful. My question concerns virtual address space, rather than resident memory or a language runtime's heap. A successful setter or getrlimit readback by itself does not answer when the limit takes effect. If an answer relies on published XNU code, what public release/build record would be needed to relate an immutable source revision to a released macOS build on Apple silicon, and what limits apply to that correspondence? I am asking about the supported public interface and publicly available documentation/source, without requesting private implementation details. A link to an existing answer or the documented boundary would be appreciated.

I have a device with iOS 27.2 beta, and I am getting crashes when I do comparison between two Date objects in swift. This doesn't happen on other devices : iOS 27.2 release, and other iOS versions, only on the device with beta version

Hello, I am preparing an existing macOS screenshot utility for distribution through the Mac App Store. The app stores captured PNG files under its temporary directory: FileManager.default.temporaryDirectory .appendingPathComponent("ShelfDragPoC/Captures", isDirectory: true) A context-menu "Edit" action passes the original PNG URL to Preview using NSWorkspace. The app does not create an editing copy. Relevant code: import AppKit @MainActor func openInPreview(_ url: URL) { guard let previewURL = NSWorkspace.shared.urlForApplication( withBundleIdentifier: "com.apple.Preview" ) else { return } let configuration = NSWorkspace.OpenConfiguration() configuration.activates = true NSWorkspace.shared.open( [url], withApplicationAt: previewURL, configuration: configuration ) { _, _ in } } The app monitors the original PNG URL for file changes and refreshes its thumbnail when changes are detected. Observed behavior: In the existing non-sandboxed app, rotating an image in Preview updates the original PNG and the thumbnail without requiring Command-S. In the sandboxed validation app, Preview opens the image, but editing results in a separate copy. When closing the edited document, Preview displays a message indicating that the original document will not be changed. The original PNG and the app's thumbnail are not updated. The Preview launch code and file watcher are unchanged between the non-sandboxed and sandboxed versions. The sandboxed app has these entitlements: com.apple.security.app-sandbox com.apple.security.files.user-selected.read-write com.apple.security.files.bookmarks.app-scope The app-scoped bookmark is used for a separate Desktop export feature. The PNG opened in Preview remains in the app's sandbox container. My question: Is there a supported public API that allows a sandboxed Mac App Store app to open its own container-resident PNG in Preview with the permissions required for in-place editing and normal automatic saving? Ideally, the user would only need to select "Edit" once, without an additional file-selection dialog or an explicit Save command. We want to preserve the original PNG URL, keep App Sandbox enabled, and avoid automatically exporting temporary images to the Desktop. If this workflow is not supported, what is Apple's recommended approach? Thank you.

I have a Java Swing application that is bundled into an app bundle using jpackage. The app basically launches a newer version of itself, when there is a new version downloaded in the users installation directory. I have noticed a regression or change in behavior with how LocalNetwork privacy works now. Previously, we would launch our Java application using the .app bundle. This is a launcher that checks for updates and will launch another JVM instance using any new jars it downloads when updating. So, it is closing the original process and spawning a new process using the downloaded jar. The new process is where the app connects to a server on the Local Network. This new process cannot access the Local Network even when the entry in privacy and security is enabled for the parent process. I have changed the behavior of my launcher application so that it keeps the process alive after launching the client application. When doing this, Local Network access works. So, my question is: is it required for the parent process to be running in order for a child process to have Local Network access? In previous macOS versions, this was not an issue, so something has changed with Local Network security across all the latest versions 26 and 27.

We would like to minimise the amount of code exposed in the product we have developed and an obvious option is to configure our build setting to use the All Symbols for Strip Style. Some investigation with an AI tool reports there are possible problems doing so. ContentFilter: non-global → all — risky. The NetworkExtension and XPC subsystems load your bundle and look up classes by name through the ObjC runtime, which uses __objc_classlist and friends (not the Mach-O symbol table), so in principle all works. In practice it occasionally breaks bundle loading in edge cases. If you try this, test specifically that systemextensionsctl activates the bundle and the filter actually traps packets. Is it safe to use All Symbols with a content filter or do we need to accept Non-Global symbols? Thanks, Dave

We have an internet app that uses BLE COC to synchronize the call audio of Android devices to the iPhone side microphone. All of this functions normally, but if two conditions are met: upgrading to IOS27; Connect iPhone to headphones. So the up and down latency of our BLE COC data will be significant and increase proportionally with time. Through the analysis of the air interface logs, it can be seen that the number of retries for COC data on the air interface has significantly increased, and the interval between the other two packets is very large (far greater than the 30 millisecond conn interval). I would like to ask if Apple has adjusted the scheduling strategy of the Bluetooth controller on iOS 27, and how can we adapt to this situation? The attachment is a screenshot of the air interface log. The packet circled in the picture is sent from iPhone to Android, with an interval of 300+ms. It can be inferred that the iPhone protocol stack and Bluetooth controller have already squeezed a large amount of data, and our business bitrate is not high, only about 10K per second

Hello, We are looking for information about the capacity limits for requests sent directly to the App Store through the StoreKit SDK when clients make in-app purchases. In our expected usage, we anticipate a peak request volume of approximately 30 transactions per second (TPS) through this communication path. Does anyone know if Apple imposes any rate limits or maximum request processing limits on requests sent directly to the App Store via the StoreKit SDK? If such limits exist, it would be helpful if you could share any details about the applicable thresholds. Thank you!

The Problem When a user toggles radio buttons or checkboxes in a PDF using Preview, the widgets disappear following subsequent interactions after the file is saved and reopened. This renders the form fields unusable. Steps to Reproduce the Problem Open a PDF with radio buttons or checkboxes in Preview. Toggle a radio button or checkbox. Save and close the file. Re-open the PDF in Preview. Toggle the same button again. The button (and any others with the same field name) will disappear. Expected Results Toggling a radio button or checkbox should update the field value without causing the button (or related buttons) to disappear. This behavior is consistent with previous versions of PDFKit. What is Happening In Preview, interacting with radio buttons and checkboxes correctly updates their appearance as expected. Saving the PDF, however, causes the appearance dictionary to reference a new N entry that is a single appearance stream unassociated with any state. The annotation's AS entry is not updated. The original N entry remains but is no longer referenced. Subsequent interactions fail to update the visual presentation because the appearance stream is missing. Impact on User Experience Radio buttons and checkboxes may disappear and become unusable when toggled. PDF documents become irreparably altered after a button is toggled and the file is saved. PDF file size significantly increases when the file is saved. Users may believe they have successfully completed a form, only for the data to become inaccessible or invisible to recipients. Forms may need to be completely restarted or recreated from scratch if the original becomes unusable. The corrupted PDF structure might cause the file to render incorrectly or crash in third-party PDF viewers. Affected Apps/OSs Tested with Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). This problem also affects PDFKit on iOS 27.0 and iPadOS 27.0. Feedback/bug report: FB24866826 Related Sample Output Original PDF File Checkbox widget annotation (6 0 obj), its appearance dictionary (17 0 obj), and normal appearance dictionary (18 0 obj). Button is not checked. 6 0 obj << /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /F 4 /Subtype /Widget /DA (/.AppleSystemUIFont 13 Tf 0 g) /MK 16 0 R /C [ 0 ] /AP 17 0 R /V /Off /M (D:20260919225320Z00'00') /AS /Off /FT /Btn /Type /Annot /Ff 0 >> endobj 17 0 obj << /N 18 0 R >> endobj 18 0 obj << /Yes 20 0 R /Off 22 0 R >> endobj PDF File after Save Checkbox widget annotation object (6 0 obj), its new appearance dictionary object (8 0 obj), a new normal appearance stream object (20 0 obj), and the original appearance stream dictionary (now 21 0 obj). File saved after user checked button. 6 0 obj << /Ff 0 /Type /Annot /AS /Off /AP 8 0 R /MK 9 0 R /C [ 0 ] /FT /Btn /M (D:20260919225320Z00'00') /DA (/.AppleSystemUIFont 13 Tf 0 g) /Subtype /Widget /F 4 /Border [ 0 0 0 ] /Rect [ 90 390 110 410 ] /T (button1) /V (Yes) >> endobj 8 0 obj << /N 20 0 R >> endobj 20 0 obj << /Filter /FlateDecode /Resources << /ColorSpace << /CS1 [ /ICCBased 29 0 R ] /CS2 [ /ICCBased 30 0 R ] >> >> /BBox [ 0 0 20 20 ] /Type /XObject /Subtype /Form /Length 123 >> stream x UéA ¬0 Ô}≈|†≈nà¢úÛÇ* —SA =}Ïr(»ñµ≤w◊€YËà’|ÙÎŒç'óRï∂#SäÏÌü∞¢S‰Ì§ôRÌX }–É•åY Éçˆ BŒ H " *â´8™ˆZø6z⁄ÿ ”ú6ɀ੠"∫t˘‹;'¬ endstream endobj 21 0 obj << /Off 22 0 R /Yes 23 0 R >> endobj Note: No object references 21 0 obj in the PDF.

The Problem On opening a PDF document in the Preview app, PDF widget annotations appear pixelated/rasterized. This problem exists with button, text, and choice widget subtypes. The pixelation becomes more apparent when zoomed in. Expected Results PDF widgets should appear sharp and smooth, without pixelation. In previous versions of the Preview app, widgets appear vector-based as expected. Impact on User Experience PDF widgets appear pixelated and inconsistent with text content in the same PDF document. Widgets do not look like elements of an interactive form but, instead, resemble low-quality embedded images. Affected Apps/OSs: Preview 11.0 (1147), as well as other apps that use PDFKit, on macOS Golden Gate 27.0 (26A428). A similar problem appears to affect PDFKit on iOS 27.0 and iPadOS 27.0 as well. Feedback/bug report: FB24843022

Subject: StoreKit 2 – AppStore.sync() fails with StoreKitError.unknown (code 2) in TestFlight Hello Apple Developer forum We are investigating a reproducible issue with StoreKit 2's AppStore.sync() in our iOS application, Elins Nystan. Environment App: Elins Nystan Bundle Identifier: poworg.ElinsNystan-2 TestFlight version: 1.43 (build 8) Device: iPhone 16 Date: November 10, 2026 Environment: TestFlight / App Store sandbox StoreKit: StoreKit 2 Problem The app correctly recognizes an existing subscription and grants Premium access to the account associated with the original purchase. Premium remains active after restarting the application, and subscription-dependent functionality works correctly. However, when the user selects “Restore Purchases,” the app calls AppStore.sync(). An Apple account authentication dialog appears and the user enters their password. After approximately 26 seconds, AppStore.sync() throws an error. Captured device logs All timestamps below are UTC: 2026-11-10 21:33:10 — restore.started 2026-11-10 21:33:10 — restore.syncStarted 2026-11-10 21:33:36 — restore.syncFailed Error details: Domain: StoreKit.StoreKitError Code: 2 Classification: unknownThe three log events share the same operation identifier. The app reports that Restore could not be completed due to an unknown error. Additional observations Premium was active before Restore. Previous testing confirmed that Premium remained active after a failed Restore. No corresponding backend reconciliation request was observed during an earlier Restore failure. No confirmed application-side cancellation or overlapping Restore request has been identified. AppStore.sync() has been part of the Restore implementation since December 2025. We have not identified a source-code regression that explains the StoreKit error. We have not verified a previously successful Restore under equivalent TestFlight conditions. We are not attempting to change subscription ownership or bypass purchase verification. Questions What conditions can cause AppStore.sync() to throw StoreKitError.unknown (code 2) in TestFlight? Could this be related to the sandbox Apple Account, authentication, or an existing subscription with multiple renewal transactions? Are there additional StoreKit or system diagnostics that would help identify the underlying cause? Is there a recommended way to recover from this error while preserving the existing verified subscription entitlement? Is this a known TestFlight/sandbox issue, or should we investigate a specific application configuration? We can provide redacted device logs and additional technical details if required. Thank you for your assistance.

Our Apple Pay merchant domain verification appears to have expired or been revoked without any notification. We discovered the issue only after Apple Pay on the Web stopped working and we saw errors during the merchant session call. Is there a way to determine: When the merchant domain verification became invalid? What event caused it to expire or be revoked? Whether Apple provides notifications when the verification status changes? Whether there is an API or recommended monitoring method to proactively check merchant domain verification status? We would like to understand how this is controlled so we can detect the issue before it impacts Apple Pay on the Web.

We are investigating a severe BLE extended-advertising discovery issue on an iPhone 17 running iOS 27.2 (24B119). The phone fails to discover our peripherals approximately 90–95% of the time, based on our testing estimate. On rare occasions discovery succeeds, and the peripheral can then be connected. We have filed FB25463740, with diagnostic captures and a comparison of successful and failing behavior. Earlier iOS behavior Extended-advertising discovery and connection worked without issues in our previous iOS 26 testing. Failures became apparent with iOS 27, with behavior varying by iPhone model. We do not have a verified iOS 26 baseline for this particular iPhone 17, so we are treating an OS regression as a possibility rather than a confirmed cause. Test configuration Affected phone: iPhone 17, iOS 27.2 (24B119). Working comparison: iPhone 16, also running iOS 27.2 (24B119). Advertising: extended advertising with a 1M primary PHY, 2M secondary PHY, and 31-byte advertising data. Scanning: nRF Connect in the foreground, without a service UUID filter. Both phones were near the same powered-on peripherals, with advertising configuration unchanged during the comparison. Observed behavior The iPhone 16 discovers the extended-advertising peripherals. The iPhone 17 usually does not, even while discovering other nearby BLE devices. Switching the peripherals to legacy advertising provides reliable discovery on the tested iPhone 17. When extended-advertising discovery does succeed, connection works. The issue reproduces in nRF Connect as well as our application. What the captures show During failing foreground scans, the iPhone 17 receives thousands of legacy advertising reports, but neither target peripheral appears in its HCI packet log. A later capture contains rare successful extended-advertising receptions from both peripherals. These reports contain the same 31-byte payloads received by the working iPhone 16 and identify the secondary PHY as 2M. That capture also records a successful connection using 2M in both directions. Successful and failing scans occur on the same iPhone 17 with identical checked scan-start command sequences. The commands complete successfully. This does not establish that all internal controller state is identical. Wi-Fi disconnection preceded one successful period, but repeating that action did not reproduce success. We have not established Wi-Fi coexistence or primary-to-auxiliary timing as the cause. Questions Has anyone observed similar extended-advertising discovery failures on iPhone 17 or other models running iOS 27? If so, which phone models, iOS builds, peripheral chipsets, and advertising PHYs are involved? Does legacy advertising remain reliable? Are there any known issues or supported workarounds for this behavior? For Apple engineering, FB25463740 includes captures covering both successful and failing periods that may help distinguish reception, auxiliary-channel scheduling, and reporting/filtering problems.

I've just bumped into a weird problem. I've created a pretty simple and perfectly working event trigger with a non-trivial predicate which is just an AND of two characteristic-value ones. Then I've renamed it in the Home application, and it stopped working. A dump suggests the cause is a broken predicate, for it looks now rather differently — one of those two characteristic-value predicates seems broken (details below). Is that possible? Could please someone check whether the problem is really a Home ugly bug, or whether I do something wrong at my side? Versions are macOS 27.0.1 (26A434) Home 11.0 (1241.1.7.4.3) I would gladly post a bugreport, but at this moment I am far from being sure I do not overlook something of importance myself. Thanks! My code — for clarity stripped of all the error checking and reporting — looks like this: HMHome *home=...; HMCharacteristic *knihovna=..., *stul=..., *sklenik=...; // light chars, found by names HMActionSet *switchOff=...; // trivial switch-off for another light, found by name HMEventTrigger *trigger=...; // found by name if exists if (trigger) { // if found, the predicate is logged out and that's all NSLog(@"=== predicate found: %@", trigger.predicate); return; } // otherwise, the trigger and predicate are created this way: HMCharacteristicEvent *evt=[[HMCharacteristicEvent alloc] initWithCharacteristic:sklenik triggerValue:@1]; NSPredicate *p1=[HMEventTrigger predicateForEvaluatingTriggerWithCharacteristic:knihovna relatedBy:NSEqualToPredicateOperatorType toValue:@1]; NSPredicate *p2=[HMEventTrigger predicateForEvaluatingTriggerWithCharacteristic:stul relatedBy:NSEqualToPredicateOperatorType toValue:@1]; NSPredicate *p=[[NSCompoundPredicate alloc] initWithType:NSAndPredicateType subpredicates:@[p1, p2]]; NSLog(@"=== predicate created: %@", p); HMEventTrigger *et=[[HMEventTrigger alloc] initWithName:@"TEST-ONLY" events:@[evt] predicate:p]; [home addTrigger:et completionHandler:^(NSError *error) { if (!error) [et addActionSet:switchOff completionHandler:^(NSError *error) { if (!error) [et enable:YES completionHandler:^(NSError *error) { if (!error) NSLog(@"=== success!"); }]; }]; }];As already mentioned, the trigger works perfectly (is trivial enough, would be weird if not). When created and also later, when found by name, the predicate looks like this: === predicate found: (characteristic == <HMCharacteristic, Unique ID: 7444CCCE-1C1B-5234-8CAE-01DA4D811B8B, Type: 00000025, Instance ID: 9> AND characteristicValue == 1) AND (characteristic == <HMCharacteristic, Unique ID: 2E046807-9127-565F-B9CB-10BC0F2EE6D2, Type: 00000025, Instance ID: 9> AND characteristicValue == 1)Then, I just go to the Home application and rename the trigger, nothing else. It immediately stops working properly, and from that moment on, the predicate looks like this — note the difference: === predicate found: characteristic == <HMCharacteristic, Unique ID: 2E046807-9127-565F-B9CB-10BC0F2EE6D2, Type: 00000025, Instance ID: 9> AND (characteristic == <HMCharacteristic, Unique ID: 7444CCCE-1C1B-5234-8CAE-01DA4D811B8B, Type: 00000025, Instance ID: 9> AND characteristicValue == 1)