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, Overview I am trying to write a unit test case to buy a storekit product. SKTestSession.buyProduct(identifier: options:) throws the error StoreKit.StoreKitError.notEntitled Testcase Code @Test func example() async throws { let session = try SKTestSession(configurationFileNamed: "VehicleStore") session.disableDialogs = true session.clearTransactions() do { let transaction = try await session.buyProduct(identifier: "nonconsumable.car", options: []) print(transaction) } catch { // Throws StoreKit.StoreKitError.notEntitled print("Error: \(error)") } } Storekit configuration file Note In-App purchases capability is added StoreKit configuration file is used in testcase Environment: macOS 26.5.2 (25F84) Xcode 26.6 (17F113)

SKTestSession configurations seem to have been broken starting in Xcode 26.3. The release notes for iOS 26.5 indicate that it was supposed to be fixed there, but I still haven't been able to get it to work. Is there something that has changed recently about how SKTestSession configurations need to be used?

Hi, I want to develop a referral system for my subscribers. If someone suggests my app and his/her friend buy a subscription I want to give the referrer a one-month free subscription or extend the existing subscription to one month for free. Is it possible to do this with offer codes?

Hello, I am developing a cross-platform mobile app that communicates with an external accessory over a serial (UART) link. HARDWARE : The accessory is an optical reading probe that connects to the phone via USB. Inside the cable there is a standard FTDI USB-to-serial chip (similar to common FTDI/CP210x USB-serial adapters). WHAT WORKS On Android, our app: Detects the USB device Opens the serial port Reads and writes raw bytes successfully This wired FTDI path is fully implemented and working. WHAT DOES NOT WORK On iPhone, using the same wired FTDI USB accessory: We connect via Lightning or USB-C adapter The app never sees the FTDI device We cannot find a public iOS API to open a generic USB-serial port MY QUESTION : Is there any supported way for a third-party iOS app to communicate with a generic FTDI USB-serial device over a wired USB connection? Specifically, am I missing: A public Apple framework for USB serial? An Info.plist key or entitlement? A system driver on iOS similar to macOS AppleUSBFTDI (TN2315)? Or is wired USB-serial on iPhone only possible with MFi-certified accessories (External Accessory framework) or another transport such as Bluetooth LE? WHAT I HAVE ALREADY CHECKED External Accessory: seems to require MFi hardware and a registered protocol string. Our FTDI probe is not MFi. TN2315 (AppleUSBFTDI): appears to be macOS only, not iOS. Physical USB connection: cable fits, but no serial API is exposed to the app. ENVIRONMENT Platform: iOS (iPhone) Language: C# / .NET-iOS Need: transparent byte-level serial read/write SUMMARY: Android USB-serial works with our FTDI wired accessory. iOS does not. Am I missing something on iOS, or is generic FTDI USB-serial simply not supported for third-party iPhone apps? Thank you for any guidance.

unable to add sandbox mastercard to iwatch wallet, no issue for amex. slightly difficult and failed but in the end managed to add visa after several manual input sandbox test card. Please take a look at 23315137

The context is partially expressed in an earlier post. In summary: There is an iOS App target that contains minimal code, only to load a Framework explicitly at runtime using dlopen and dlsym, instead of the usual load-time imports in Apple platforms. For iOS app (C++ (primary) and Swift), the entry point is a UIApplicationDelegate conformer class - AppDelegate, marked with @main. But the problem is, the AppDelegate class cannot remain in the App target, which has barely any logic. The App target is a thin loader. The AppDelegate contains some methods such as application(_:didRegisterForRemoteNotificationsWithDeviceToken:) that needs some logical processing, which is not present in the App target. Instead of using dlsym (to hand over to the Framework) for every AppDelegate event that doesn't have a broadcast notification, the thought was to move the AppDelegate class into the Framework, and the entry point in App target is now main.swift. This keeps the Framework clean and minimal with the following steps: Interop to C++ Explicitly loading the MachO binary inside the Framework using dlopen Loading the symbol using dlsym Invoking the Framework entry point Then, the Framework entry point in C++ creates the UIApplication class and the UIApplicationDelegate using UIApplicationMain(_:_:_:_:) method, which doesn't return as it transfers control to the UIApplicationDelegate. This is against the recommended @main entry point, but based on research, @main seems like syntactic sugar to avoid writing boilerplate code. But in my case, which needs to avoid instantiating the UIApplicationDelegate in the App target, using main.swift, even for an iOS app, is the best fit. I understand that main thread has to be returned back to the OS asap for processing user events etc., and the intent is to not execute the entire startup logic of the app in main thread. Wanted to confirm if this approach of using main.swift entry point is valid for iOS, iPadOS and tvOS apps too and in which case, these flows can converge to macOS, which is already using main.swift approach.

Hi There, My app is a legacy project built with Objective C. The host app shared data with the service extension by using NSUserDefaults *userDefault = [[NSUserDefaults alloc] initWithSuiteName:@"group.com.myapp.project"]; and it worked until a customer recently reported a bug (iOS 18.6). After debugging, I found that data sharing from the host app to the service extension was not working correctly. The host app updated a field's value, but the service still used the old or stale value, causing the issue. HostApp saved info 2026-06-01 13:44:07.020 [INFO] (VMP)(ThreadID: 0x10a85c000): "Saved Vomo information { "EXT_AP_IP" = 1c28af0f9d73; "EXT_PING_DND" = 0; "EXT_PING_USER_NAME" = aaa08AA541F8; "EXT_SERIAL_ACK_TIME" = "2026-06-01 20:44:07 +0000"; "EXT_SERIAL_NO" = 689; "EXT_SERVER_NAME" = "10.xxx.xxx.182"; "EXT_VOICE_LOGIN" = 1; }" Service extension read value: 2026-06-01 13:46:09.678 [INFO] (VMP) - (EXTENSION)(ThreadID: 0x1050a41d0): "start Vomo with Server: [10.xxx.xxx.79] and userName [aaa08AA541F8]" I can see the value shared from host app is: 10.xxx.xxx.182, but service extension still took the stale value 10.xxx.xxx.79 First I thought it is synchronized issue, however, apple deprecated those API, CFPreferencesAppSynchronize((__bridge CFStringRef)@"group.com.myexample.project"); How to ensure the shared value successfully delivered to service extension? Thanks.

We are implementing a Transparent Proxy for HTTPS (via TCP and QUIC). The following rules are set in startProxy: settings.includedNetworkRules = [ NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .TCP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "0.0.0.0", port: "443"), prefix: 0, protocol: .UDP), NENetworkRule(destinationNetwork: NWHostEndpoint(hostname: "::", port: "443"), prefix: 0, protocol: .UDP) ] Handling TCP connections seems to work fine. But opening UDP flows from Chrome (or Brave) always fails with Error Domain=NEAppProxyFlowErrorDomain Code=2 "The peer closed the flow" (Doing the same for Firefox works!) BTW: We first create a remote UDP connection (using the Network framework) and when it is in the ready state, we use connection?.currentPath?.localEndpoint as the localEndpoint parameter in the open method of the flow. Is it a known issue that QUIC connections from Chrome cannot be handled by a Transparent Proxy Provider?

Trying to virtualize macOS 27 on a 26.6 host failed at 77% install progress, even with Xcode 27 beta installed. But worked fine on a macOS 27 host. Are there any tricks to use a 26 host? Thanks!

After updating the application following an upgrade from a previous macOS version to macOS Tahoe 26.5.1 (25F80), the sandboxed app immediately crashes on launch. The crash occurs during dyld library initialization, before any application code (including main()) is executed. The crash report identifies that libsystem_secinit.dylib rejects the existing app sandbox container with the following signature: "failed integrity checks for container at /Users/apptest/Library/Containers/77C6DBAA-6E54-4ED4-947C-5C5648BE280B/Data: Invalid argumen" Clearing out the old sandbox container data (e.g., rm -rf ~/Library/Containers/77C6DBAA-6E54-4ED4-947C-5C5648BE280B/Data) resolves the crash. Please help analyze the possible causes of this issue: 1.Could this be a compatibility issue between the new macOS 26.5.1 system and Mac Catalyst apps? 2.Could this be caused by certain APIs used by the app or specific project configuration settings? If so, please provide some relevant hints to help narrow down the scope of analysis. Crash Log excerpt.txt

I have a sandboxed Mac App Store app that uses Apple’s MultipeerConnectivity framework for a local peer-to-peer “mesh” feature. The app advertises itself as a nearby peer and accepts inbound invitations from other nearby devices so users can do local collaboration, chat, shared workspace sync, and multiplayer game sessions. This is local peer-to-peer only; the app is not running a public web server, FTP server, or similar service. When I remove the App Sandbox Incoming Connections entitlement: com.apple.security.network.server nearby peer discovery / inbound connections stop working in the sandboxed Mac build. Is com.apple.security.network.server the correct entitlement for this MultipeerConnectivity use case on macOS, assuming the app clearly exposes this local peer-to-peer feature in the UI?

Title: WeatherKit REST API returns 401 NOT_ENABLED although App ID and WeatherKit key are enabled Body: I am integrating WeatherKit REST API for an iOS app, but every request returns: HTTP 401 {"reason":"NOT_ENABLED"} Configuration summary: The App ID has WeatherKit enabled in App Services. The App ID also has WeatherKit enabled in Capabilities. The WeatherKit key shows WeatherKit enabled in the Keys page. A Service ID has been created. The backend generates an ES256 JWT using the .p8 private key. The decoded JWT header and payload have been verified. I have redacted the actual Team ID, Key ID, Bundle ID, and Service ID here for security reasons. Test A: JWT header.id = TEAM_ID.SERVICE_ID JWT payload.iss = TEAM_ID JWT payload.sub = SERVICE_ID kid = WEATHERKIT_KEY_ID exp - iat = 3600 seconds Result: HTTP 401 {"reason":"NOT_ENABLED"} Test B: JWT header.id = TEAM_ID.BUNDLE_ID JWT payload.iss = TEAM_ID JWT payload.sub = BUNDLE_ID kid = WEATHERKIT_KEY_ID exp - iat = 3600 seconds Result: HTTP 401 {"reason":"NOT_ENABLED"} Since Apple returns NOT_ENABLED instead of INVALID_AUTH_TOKEN, the JWT appears to be structurally accepted, but WeatherKit is not enabled for the authenticated identifier/key combination. Questions: For WeatherKit REST API, should the JWT sub claim use the Service ID or the App Bundle ID? What exactly causes HTTP 401 NOT_ENABLED? Is there any additional WeatherKit REST API enablement required besides enabling WeatherKit on the App ID and creating a WeatherKit key? Could this be an account-side entitlement propagation issue?

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.

I'm debugging the following kernel panic to do with my custom filesystem KEXT: panic(cpu 0 caller 0xfffffe004cae3e24): [kalloc.type.var4.128]: element modified after free (off:96, val:0x00000000ffffffff, sz:128, ptr:0xfffffe2e7c639600) My reading of this is that somewhere in my KEXT I'm holding a reference 0xfffffe2e7c639600 to a 128 byte zone that wrote 0x00000000ffffffff at offset 96 after that particular chunk of memory had been released and zeroed out by the kernel. The panic itself is emitted when my KEXT requests the memory chunk that's been tempered with via the following set of calls. zalloc_uaf_panic() __abortlike static void zalloc_uaf_panic(zone_t z, uintptr_t elem, size_t size) { ... (panic)("[%s%s]: element modified after free " "(off:%d, val:0x%016lx, sz:%d, ptr:%p)%s", zone_heap_name(z), zone_name(z), first_offs, first_bits, esize, (void *)elem, buf); ... } zalloc_validate_element() static void zalloc_validate_element( zone_t zone, vm_offset_t elem, vm_size_t size, zalloc_flags_t flags) { ... if (memcmp_zero_ptr_aligned((void *)elem, size)) { zalloc_uaf_panic(zone, elem, size); } ... } The panic is triggered if memcmp_zero_ptr_aligned(), which is implemented in assembly, detects that an n-sized chunk of memory has been written after being free'd. /* memcmp_zero_ptr_aligned() checks string s of n bytes contains all zeros. * Address and size of the string s must be pointer-aligned. * Return 0 if true, 1 otherwise. Also return 0 if n is 0. */ extern int memcmp_zero_ptr_aligned(const void *s, size_t n); Normally, KASAN would be resorted to to aid with that. The KDK README states that KASAN kernels won't load on Apple Silicon. Attempting to follow the instructions given in the README for Intel-based machines does result in a failure for me on Apple Silicon. I stumbled on the Pishi project. But the custom boot kernel collection that gets created doesn't have any of the KEXTs that were specified to kmutil(8) via the --explicit-only flag, so it can't be instrumented in Ghidra. Which is confirmed as well by running: % kmutil inspect -B boot.kc.kasan boot kernel collection at /Users/user/boot.kc.kasan (AEB8F757-E770-8195-458D-B87CADCAB062): Extension Information: I'd appreciate any pointers on how to tackle UAFs in kernel space.

I'm testing iAP in a sandbox account (as configured in App Store Connect under 'Sandbox Testers'). So the in app purchase works. Cool. But I wanted to retry it. So I cleared the purchase history (both in App Store Connect and on my iPad in the 'Developer' section in Settings). But when I relaunch my app the purchase still validates and my app displays the item as 'unlocked'. Figure the receipt must still be cached so I nuke the app and completely reinstall it but it appears StoreKit is still getting the receipt and it isn't being cleared because my app is displaying it as 'purchased.' Also tried rebooting the iPad. But the sandbox purchase doesn't clear. I just did a sandbox test since it is closer to real life than StoreKit Configuration so I just wanted to do it a few times to make sure all is good but making a burner test account for every purchase is kind of tiresome. Anyone know of a workaround? I might just declare victory and go back to StoreKit Configuration.

We are testing Apple Universal Links for ios.aierchina.com. The domain is ICP-registered and hosted in mainland China. The problem: Apple's CDN always returns “not found” for our AASA file: https://app-site-association.cdn-apple.com/a/v1/ios.aierchina.com What we have verified: The AASA file is correctly served at both /.well-known/apple-app-site-association and /apple-app-site-association Returns HTTP 200, valid JSON, correct Content-Type, no redirects, valid SSL Server response time is under 500ms What works: Adding ?mode=developer to the applinks entry works perfectly Universal Link Diagnostics on device (ios.aierchina.com/uat) correctly resolves to our app bundle What does not work: Production mode fails because the Apple CDN never caches our AASA file Reinstalling the app does not help Server logs show occasional requests from com.apple.swcd, but CDN still returns 404 Questions: Are there known issues with Apple CDN caching AASA files for China-hosted domains? Is there any way to force Apple's CDN to re-crawl our domain? Could the GFW or regional network policies be interfering? What was the fix?

Hi, I recently requested for some entitlements from Apple. In the form that I filled, there was only placeholder for Vendor ID so I put my vendor ID (in decimals). There was no placeholder to specify Device ID. However, in the Description placeholder at the end of the form, I did put the device ID (in decimals). After I got the entitlements, I tried loading my driver to match the device. It does match with only vendor ID but does not match with Vendor and Device ID together. So, now matching has widened little bit more than what we wanted. I was wondering if this is normal or if I did something wrong due to which entitlements was only granted for vendor ID but not for vendor + device Id. Thank you for your time!

Note: This document is specifically focused on what happens after a DEXT has passed its initial code-signing checks. Code-signing issues are dealt with in other posts. Preliminary Guidance: Using and understanding DriverKit basically requires understanding IOKit, something which isn't entirely clear in our documentation. The good news here is that IOKit actually does have fairly good "foundational" documentation in the documentation archive. Here are a few of the documents I'd take a look at: IOKit Fundamentals IOKit Device Driver Design Guidelines Accessing Hardware From Applications Special mention to QA1075: "Making sense of IOKit error codes",, which I happened to notice today and which documents the IOReturn error format (which is a bit weird on first review). Those documents do not cover the full DEXT loading process, but they are the foundation of how all of this actually works. Understanding the IOKitPersonalities Dictionary The first thing to understand here is that the "IOKitPersonalities" is called that because it is in fact a fully valid "IOKitPersonalities" dictionary. That is, what the system actually uses that dictionary "for" is: Perform a standard IOKit match and load cycle in the kernel. The final driver in the kernel then uses the DEXT-specific data to launch and run your DEXT process outside the kernel. So, working through the critical keys in that dictionary: "IOProviderClass"-> This is the in-kernel class that your in-kernel driver loads "on top" of. The IOKit documentation and naming convention uses the term "Nub", but the naming convention is not consistent enough that it applies to all cases. "IOClass"-> This is the in-kernel class that your DEXT attaches to and works through. This is where things can become a bit confused, as some families work by: Routing all activity through the provider reference so that the DEXT-specific class does not matter (PCIDriverKit). Having the DEXT subclass a specific subclass which corresponds to a specific kernel driver (SCSIPeripheralsDriverKit). This distinction is described in the documentation, but it's easy to overlook if you don't understand what's going on. However, compare PCIDriverKit: "When the system loads your custom PCI driver, it passes an IOPCIDevice object as the provider to your driver. Use that object to read and write the configuration and memory of your PCI hardware." Versus SCSIPeripheralsDriverKit: Develop your driver by subclassing IOUserSCSIPeripheralDeviceType00 or IOUserSCSIPeripheralDeviceType05, depending on whether your device works with SCSI Block Commands (SBC) or SCSI Multimedia Commands (SMC), respectively. In your subclass, override all methods the framework declares as pure virtual. The reason these differences exist actually comes from the relationship and interactions between the DEXT families. Case in point, PCIDriverKit doesn't require a specific subclass because it wants SCSIControllerDriverKit DEXTs to be able to directly load "above" it. Note that the common mistake many developers make is leaving "IOUserService" in place when they should have specified a family-specific subclass (case 2 above). This is an undocumented implementation detail, but if there is a mismatch between your DEXT driver ("IOUserSCSIPeripheralDeviceType00") and your kernel driver ("IOUserService"), you end up trying to call unimplemented kernel methods. When a method is "missing" like that, the codegen system ends up handling that by returning kIOReturnUnsupported. One special case here is the "IOUserResources" provider. This class is the DEXT equivalent of "IOResources" in the kernel. In both cases, these classes exist as an attachment point for objects which don't otherwise have a provider. It's specifically used by the sample "Communicating between a DriverKit extension and a client app" to allow that sample to load on all hardware but is not something the vast majority of DEXT will use. Following on from that point, most DEXT should NOT include "IOMatchCategory". Quoting IOKit fundamentals: "Important: Any driver that declares IOResources as the value of its IOProviderClass key must also include in its personality the IOMatchCategory key and a private match category value. This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it. It also prevents the driver from having to compete with all other drivers that need to match on IOResources. The value of the IOMatchCategory property should be identical to the value of the driver's IOClass property, which is the driver’s class name in reverse-DNS notation with underbars instead of dots, such as com_MyCompany_driver_MyDriver." The critical point here is that including IOMatchCategory does this: "This prevents the driver from matching exclusively on the IOResources nub and thereby preventing other drivers from matching on it." The problem here is that this is actually the exceptional case. For a typical DEXT, including IOMatchCategory means that a system driver will load "beside" their DEXT, then open the provider blocking DEXT access and breaking the DEXT. DEXT Launching The key point here is that the entire process above is the standard IOKit loading process used by all KEXT. Once that process finishes, what actually happens next is the DEXT-specific part of this process: IOUserServerName-> This key is the bundle ID of your DEXT, which the system uses to find your DEXT target. IOUserClass-> This is the name of the class the system instantiates after launching your DEXT. Note that this directly mimics how IOKit loading works. Keep in mind that the second, DEXT-specific, half of this process is the first point your actual code becomes relevant. Any issue before that point will ONLY be visible through kernel logging or possibly the IORegistry. __ Kevin Elliott DTS Engineer, CoreOS/Hardware

Environment: iPhone 17 / iPhone 17 Pro (Apple N1 chip) iOS 26.x Xcode 26 Framework: Flutter app with native iOS BLE library (CoreBluetooth) We have a production IoT app that communicates with BLE nodes (Nordic, PIC, EnOcean peripherals) using an advertising/scanning-based protocol — not GATT connections. The app broadcasts commands via CBPeripheralManager (advertising service UUIDs) and receives responses by scanning with CBCentralManager (reading manufacturer data and service UUIDs from advertisement packets). This workflow has been reliable across all iPhone models from iPhone 8 through iPhone 16 Pro Max. On iPhone 17 devices, we are experiencing multiple failures in this workflow. Architecture: Sending commands: We use CBPeripheralManager.startAdvertising() with CBAdvertisementDataServiceUUIDsKey to broadcast a UUID-encoded command to nearby nodes. Receiving responses: We use CBCentralManager.scanForPeripherals(withServices: nil, options: [CBCentralManagerScanOptionAllowDuplicatesKey: true]) and filter responses in centralManager(_:didDiscover:advertisementData:rssi:) by matching CBAdvertisementDataServiceUUIDsKey or CBAdvertisementDataManufacturerDataKey against expected UUID masks. Communication pattern: Advertise a command → stop advertiser → start scanner → wait for matching response → process result. Typical timeout is 1.5 seconds per exchange. Issues observed on iPhone 17: peripheralManagerDidStartAdvertising behaviour change After calling CBPeripheralManager.startAdvertising(:), the delegate callback peripheralManagerDidStartAdvertising(:error:) either fires with errors that did not occur on previous hardware, or advertising does not appear to reach the peripheral nodes at all. The same advertising payload works immediately when tested on iPhone 15/16. Is the N1 chip's Bluetooth 6 stack handling CBAdvertisementDataServiceUUIDsKey advertising differently? Are there new constraints on advertising payload size or format? Scanner returning fewer/no results with withServices: nil Our scanner uses scanForPeripherals(withServices: nil) because we need to read manufacturer data from advertisement packets and filter using a custom UUID mask. On iPhone 17, we observe significantly fewer didDiscover callbacks compared to iPhone 15/16 in the same physical environment, with the same nodes advertising. We understand that passing service UUIDs in withServices: is recommended, but our protocol requires reading raw manufacturer data bytes that aren't associated with a single service UUID — we use mask-based matching (e.g., filter mask 11110000-0000-0000-0000-000000000000 against scan results). Has the N1 chip changed the rate or filtering behaviour of unfiltered BLE scans? Is there a new throttling mechanism? Background scanning stops immediately When the app moves to background, scanning appears to stop entirely on iPhone 17 — even with bluetooth-central in UIBackgroundModes. On iPhone 16, background scanning continued (at reduced intervals) and delivered results for peripherals advertising filtered service UUIDs. Aggressive session termination on app backgrounding Our advertise-then-scan sequences (typically 1.5s round-trip) are being interrupted when the user briefly switches apps. The CBPeripheralManager stops advertising and the CBCentralManager stops scanning, causing timeout errors. This was not observed on previous iPhone models with the same iOS background mode configuration. Questions for Apple: Are there documented changes to CoreBluetooth behaviour on the N1 Bluetooth 6 chip that affect advertising-based (non-GATT) communication patterns? Has the scan response rate for scanForPeripherals(withServices: nil) been intentionally reduced on iPhone 17? Is CBCentralManagerOptionRestoreIdentifierKey now required for reliable background scanning on iPhone 17, or is this a known regression? Are there new advertising payload constraints (size, format, interval) that we should be aware of for the N1 chip? What we've tried: Added NSBluetoothAlwaysUsageDescription and NSBluetoothWhileInUseUsageDescription to Info.plist Confirmed Bluetooth permissions are granted Tested with identical BLE nodes that work on iPhone 15/16 Verified CBManagerState.poweredOn before all operations Any guidance or known workarounds would be greatly appreciated. Happy to provide sysdiagnose logs or a minimal reproducible sample project.

Hello, I would like to report an inconsistency in Apple Maps regarding place names in the Balearic Islands when using Apple Maps in Spanish. Most official place names in the Balearic Islands are displayed correctly. For example, Apple Maps correctly shows names such as Eivissa, and other Balearic municipalities also appear with their official names. However, there are still some incorrect cases, especially: Maó, which is still displayed incorrectly (shown as "Mahón") Sant Francesc de Formentera, shown as "San Francisco Javier" This does not seem consistent, because Apple Maps already respects the official Catalan/Balearic place names in most other cases. Until recently, Ciutadella was also displayed incorrectly, but after months of reporting the issue, it has finally been corrected. This shows that the correction is possible and that the current remaining cases are likely data inconsistencies. Other major platforms such as Google Maps and Tripadvisor already display these names correctly. The official reference sources that should be used are the Instituto Geográfico Nacional (IGN) and the IDEIB / official geographic data of the Balearic Islands. https://www.ign.es/iberpix https://www.tripadvisor.es/Tourism-g642211-Mao_Menorca_Balearic_Islands-Vacations.html https://www.tripadvisor.es/Tourism-g1188767-Sant_Francesc_de_Formentera_Formentera_Balearic_Islands-Vacations.html The expected behavior would be for Apple Maps to use the official place names consistently across the Balearic Islands, including Maó and Sant Francesc de Formentera, just as it already does with Eivissa and other municipalities. Could Apple Maps review its geographic data for the Balearic Islands and align these names with the official sources? Thank you.