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.

This is production issue with a user completely stuck: User entered an offer code for 1 year free --> validated under iOS > Apple Account > subscriptions: it correctly shows a 1 year free trial But the transaction is not listed in his Transaction.currentEntitlements() Even after a restore (App.sync()) The Apple Account has always been the same (no mix) This is with the new offer codes introduced in 2026 Also, user wanted to pay the subscription himself in order to unlock the situation, he cannot because of the 'active' offer. Tried giving him another code, but it's refused by the system because there is only one active. Urgent help would be greatly appreciated. func readEntitlements(fromDeferredTransaction: Bool = false) async { var purchasedNonConsumables: [Product] = [] var purchasedSubscriptions: [Product] = [] var purchasedNonRenewableSubscriptions: [Product] = [] var activeSubTransactions: [Transaction] = [] //Iterate through all of the user's purchased products. for await result in Transaction.currentEntitlements { // currentEntitlements is a StoreKit2 useful feature that only gives us the relevant transactions (not the old & expired ones) do { //Check whether the transaction is verified. If it isn’t, catch `failedVerification` error. let transaction = try checkVerified(result) //Check the `productType` of the transaction and get the corresponding product from the store. switch transaction.productType { case .nonConsumable: if let nc = availableNonConsumables.first(where: { $0.id == transaction.productID }) { purchasedNonConsumables.append(nc) } case .nonRenewable: if let nonRenewable = availableNonRenewableSubscriptions.first(where: { $0.id == transaction.productID }) { let currentDate = Date() let expirationDate = Calendar(identifier: .gregorian).date(byAdding: DateComponents(year: 1), to: transaction.purchaseDate)! if currentDate < expirationDate { purchasedNonRenewableSubscriptions.append(nonRenewable) } } case .autoRenewable: if transaction.revocationDate == nil { activeSubTransactions.append(transaction) } if let subscription = availableSubscriptions.first(where: { $0.id == transaction.productID }) { DLog("Found valid entitlement. Subscription with exp date = \(String(describing: transaction.expirationDate))") purchasedSubscriptions.append(subscription) } else { DLog("Entitled to \(transaction.productID) but its Product is not loaded (product fetch failed/incomplete). Access will be granted from the transaction.") } default: break } } catch { print() } } //Update the store information with the purchased products. self.purchasedNonConsumables = purchasedNonConsumables self.purchasedNonRenewableSubscriptions = purchasedNonRenewableSubscriptions //Update the store information with auto-renewable subscription products. self.purchasedSubscriptions = purchasedSubscriptions //Authoritative entitlement transactions (independent of the product fetch succeeding). self.activeSubTransactions = activeSubTransactions subscriptionGroupStatus = try? await availableSubscriptions.first?.subscription?.status.first?.state // Callback IAPManager.shared.updateProStatus(isSureThatUserIsOnline: fromDeferredTransaction) }

Dear All, I am currently developing a high throughput audio system which operates via PCIe tunneled into a USB4 interface. This include a custom FPGA based hardware and custom Audio DriverKit driver. While performing read operation via the hw DMA (that is a Host to Device transfer), I am noticing sparse latency spikes into the read transfers. Specifically, 4KB operations (which I assume including MRd + CpID) take normally from 5us to 40us to be completed, perfectly fine for my case. However, in some rare occasions, they can end up to 400us, which causes me overruns. The measurements have been carried out from the FPGA and they include the overall request and transfer time. While trying to tackle the problem, I'm investigating the possible power saving options and performance constraint methods at my disposal. I currently use these methods to mitigate the problem. ChangePowerState(kIOServicePowerCapabilityOn); SetPowerOverride(true); RequireMaxBusStall(kIOMaxBusStall25usec); CreatePMAssertion(kIOServicePMAssertionCPUBit | kIOServicePMAssertionForceFullWakeupBit, &ivars->PMAssertionID, false); The buffers are currently about 16MB, single segment, 16KB aligned and, of course, "prepared" for DMA. The system run for 3 hours without any overrun, but I'm not still fully convinced about its reliability. May someone provide me some comments on this? Are there profiling tools that I can use? Feel free to request me any required detail. The testing system is a MacBook Pro M2 Pro. Many Thanks and Best Regards Francesco

Hello Applet, I’m experiencing an issue with StoreKit on a TestFlight build. My app uses auto-renewable subscriptions through StoreKit and RevenueCat. Configuration already verified: App installed through TestFlight (not debug). Bundle Identifier: com.ciborgu.vytalai Paid Applications agreement is active. In-App Purchase capability is enabled. Three auto-renewable subscriptions exist in App Store Connect. Product IDs match exactly between App Store Connect, RevenueCat and the application. RevenueCat initializes successfully. A Sandbox test account has been created. Tested on a physical iPhone. Device restarted and app reinstalled from TestFlight. VPN and iCloud Private Relay disabled. When attempting to purchase a subscription, the Apple payment sheet never appears. Our diagnostics indicate that StoreKit does not return any available products for the configured Product IDs, preventing the purchase sheet from opening. Expected Product IDs: vytalai_premium_monthly vytalai_premium_yearly vytalai_premium_yearly_intro Could you please verify if there is any issue with the App Store Connect configuration, StoreKit availability, or the processing state of these subscriptions on Apple’s side? If additional logs or diagnostics are required, I can provide them. Thank you. I have already contacted Apple Developer Support regarding this same issue. Previously, I was advised to schedule a technical support meeting. However, when I requested the meeting, my request was declined because of the subject of my issue, so I was unable to speak with an Apple engineer. Since I have now completed all the recommended troubleshooting and the issue still persists, I would greatly appreciate it if this case could be reviewed by the appropriate technical team or a StoreKit engineer. Thank you for your assistance.

Hi everyone, I’m having an issue where my TestFlight build cannot load auto-renewable subscription products from App Store Connect. The app is built with Flutter and uses StoreKit 2 through an in-app purchase implementation. The same subscription system works correctly on Google Play Billing and returns product details/prices there, but on iOS StoreKit returns no subscription products. I tested this on a real iPhone installed from TestFlight, not from Xcode debug and not using a local StoreKit configuration. The app requests four auto-renewable subscription product IDs. The IDs in code exactly match the product IDs in App Store Connect. The app diagnostics show: Platform: iOS StoreKit mode: StoreKit 2 Store available: true Requested IDs: 4 subscription product IDs Returned IDs: none Missing IDs: all requested product IDs Error source: app_store Error code: storekit_no_response Error message: StoreKit: Failed to get response from platform. Store note: The store accepted the query, but did not return details for these product IDs. Things I have already checked: Product IDs match exactly between Flutter code and App Store Connect Bundle ID matches the App Store Connect app record In-App Purchase capability is enabled Subscriptions are in one subscription group Subscription availability is set for all countries/regions The TestFlight build is installed on a real device Local StoreKit configuration was removed StoreKit reports store availability as true App Store Connect / In-App Purchase keys are configured for backend verification The same product-loading flow works on Google Play The current App Store Connect status for the subscriptions is: Subscriptions: Ready to Submit / Ready for Review Localizations: Prepare for Submission Also, the bank information is not submitted yet. My question is: can StoreKit in TestFlight return subscription product details while the first auto-renewable subscriptions are still only “Ready to Submit” and have not yet been submitted with an app version for review? Or will StoreKit return no products until: The first subscriptions are attached to an app version and submitted for review Subscription localizations are fully prepared/submitted Paid agreements, tax, and banking are fully completed Since StoreKit is available and accepts the product query, but returns zero products, I’m trying to understand whether this is expected App Store Connect behavior or if there is another configuration issue I should check. Thanks.

Our vehicle digital key app uses CBCentralManagerOptionRestoreIdentifierKey and bluetooth-central background mode to maintain BLE connections with cars. We want to confirm: if the app is actively connected to a BLE vehicle peripheral and then terminated by system memory reclamation (not user force-quit), will iOS automatically relaunch the app via Bluetooth State Restoration when the peripheral sends notifications or re-advertises? Also please list all mandatory conditions to trigger such Bluetooth-based background relaunch after system termination, and clarify whether this pure-BLE relaunch channel works independently apart from iBeacon location-triggered cold launch for our terminated app on iOS 26 without AccessorySetupKit. Best regards

My Non-Consumable IAP was rejected with Guideline 3.1.1 and now has status ‘Developer Action Required’. The problem: On the version page in App Store Connect, the ‘In-App Purchases and Subscriptions’ section does not appear at the bottom. I cannot link the IAP to a new version submission. Every time I submit a new binary, Apple approves the app version but rejects the IAP afterward — even though I have no way to attach it to the version in the first place. This seems to be a circular issue: the IAP doesn’t appear on the version page because of its current status, but the only way to fix the status is to submit it with a new version. Has anyone experienced this and found a solution? Any help appreciated!​​​​​​​​​​​​​​​​

Hi, I would like to dipslay resource monitoring graph of CPU, Memory & Network of a running VM with Virtuization Framework. How can i do it with Swift? Is there a way we can do it without the need of guest agents.

We develop a healthcare emergency-alerting app with a native watchOS companion app. We've hit a network routing issue on watchOS that we cannot work around with any public API, and it breaks a safety-critical flow (triggering an emergency alarm from the watch). Environment watchOS 26.5 on Apple Watch SE3, paired with iPhone SE 2nd Gen on iOS 26.5 Watch app deployment target: watchOS 9.0 Plain URLSession (async/await), default configuration plus waitsForConnectivity = false, allowsExpensiveNetworkAccess = true, allowsConstrainedNetworkAccess = true HTTPS to our own backend (valid public TLS certificate, no pinning) Steps to reproduce Pair the watch with the iPhone. Both on the same known Wi-Fi network. On the iPhone: turn OFF Wi-Fi and cellular data. Keep Bluetooth ON. The watch remains connected to its known Wi-Fi network (or would be, if the system brought the radio up). Trigger any HTTPS request from the watch app (foreground). Expected Since the companion iPhone has no internet, the watch should satisfy the request over its own Wi-Fi. Actual The request is routed through the companion link (ipsec1, "companion preference: prefer" in the logs) and fails after the TLS handshake dies inside the tunnel: Error Domain=NSURLErrorDomain Code=-1200 "An SSL error has occurred and a secure connection to the server cannot be made." _kCFStreamErrorDomainKey=3, _kCFStreamErrorCodeKey=-9816 (errSSLClosedNoNotify) The watch never fails over to its own Wi-Fi, no matter how many times we retry or how long we wait. The same request succeeds within seconds if the user disables Bluetooth on the iPhone (watch then joins Wi-Fi directly), or restores the iPhone's internet. What we already tried waitsForConnectivity = true doesn't help; a path exists (the tunnel), it just doesn't work. Fresh URLSession per retry, backoff retries still routed via the tunnel. Per TN3135 we understand low-level networking is not available to a normal app: we prototyped NWConnection with prohibitedInterfaceTypes = [.other], and indeed on device NWPathMonitor stays .unsatisfied even when the watch has working Wi-Fi, exactly as TN3135 describes. So Network framework is not an escape hatch for us, and we are not looking to abuse the audio-streaming/CallKit carve-outs. Questions Is the companion-preferred routing supposed to fail over to the watch's own Wi-Fi when the iPhone is reachable over Bluetooth but has no internet? If yes, on what timescale, and is there anything an app can do to help the system notice the dead path sooner? Is there ANY supported way for a foreground watchOS app to express "do not use the companion link for this request"? We found only the private _companionProxyPreference SPI, which we obviously can't ship. If the answer to both is "no", what is the recommended pattern for safety-critical requests in this state is failing fast and instructing the user to disable iPhone Bluetooth really the intended UX? Related earlier reports of the same behavior: https://developer.apple.com/forums/thread/759321 https://developer.apple.com/forums/thread/107964

I have a DriverKit dext that implements a virtual SCSI HBA (no physical hardware). Because a bare IOUserSCSIParallelInterfaceController has no provider to match, the bundle ships two IOKitPersonalities: Bootstrap — IOClass IOUserService, IOProviderClass IOUserResources, IOResourceMatch IOKit. In Start() it does SetProperties({NvmeOfSCSIHBA: true}) + RegisterService(), publishing itself as a nub. Controller — IOClass IOUserSCSIParallelInterfaceController, IOProviderClass IOUserService, IOPropertyMatch {NvmeOfSCSIHBA: true} — it matches the bootstrap nub. This loads and runs correctly. The problem is upgrades. Activating a higher CFBundleVersion via OSSystemExtensionRequest.activationRequest (in-place replace) always defers the old version's termination to reboot. The new version reaches [activated enabled] but never starts; the old process keeps running until reboot. From sysextd/kernelmanagerd: kernelmanagerd Dext … v15 … is being replaced and cannot be terminated right away sysextd delegate returns Error Domain=OSSystemExtensionErrorDomain Code=101 "…is being replaced", assumes responsibility for old version …, keeping old version 15 sysextd turning the responsibility for termination of …, version 15 over to delegate (with uninstallation at the next reboot) sysextd a category delegate declined to terminate extension with identifier: … sysextd v15 terminating_for_uninstall → terminating_for_upgrade_via_delegate Key observation: this defers even on a fresh boot where the dext was never opened — no app/daemon ever opened the IOUserClient, no I/O, nothing attached beyond the controller↔nub match. So it does not appear to be a "client still holds it open" / busy-state situation; the driver_extension category delegate declines the moment it's a replacement. What I've tried: In-place activationRequest (replace): always defers to reboot (above). deactivationRequest (standalone): the request hangs — no delegate callback at all (waited ~13 min), even with no client open. Disconnecting all clients first (graceful Stop() that cancels its dispatch queues and completes async) does not change the replace deferral. My understanding from the docs/forums is that the normal reboot-free replace relies on the backing device being disconnected/reconnected to quiesce the old dext (thread 677040). My controller matches a persistent IOUserResources-backed nub that never detaches, so there's no equivalent quiesce point. Questions: For a dext whose only provider is a self-published IOUserResources nub (no detachable hardware), is reboot-free replacement structurally impossible — i.e. is the Code=101 "is being replaced" defer inherent to this matching pattern? Is the supported way to live-upgrade such a dext to deactivationRequest → (on .completed) → activationRequest rather than an in-place replace? If so, what makes a deactivationRequest complete in-session vs. defer to reboot for an IOUserResources-matched dext — and what would cause it to hang with no delegate callback? (Daemon's IOUserClient is closed; the controller's Stop() cancels its queues and completes.) Should the dext itself proactively tear down the published nub (e.g. terminate the bootstrap IOService) before/at upgrade so the controller detaches — or does that just re-match the still-staged old personalities and relaunch the old version? Is there a recommended pattern for a virtual (hardwareless) DriverKit HBA that needs in-field, reboot-free version updates, or is reboot genuinely required for this class of dext? Environment: macOS 27 (Tahoe)

I have a DriverKit dext that implements a virtual SCSI HBA (no physical hardware). Because a bare IOUserSCSIParallelInterfaceController has no provider to match, the bundle ships two IOKitPersonalities: Bootstrap — IOClass IOUserService, IOProviderClass IOUserResources, IOResourceMatch IOKit. In Start() it does SetProperties({NvmeOfSCSIHBA: true}) + RegisterService(), publishing itself as a nub. Controller — IOClass IOUserSCSIParallelInterfaceController, IOProviderClass IOUserService, IOPropertyMatch {NvmeOfSCSIHBA: true} — it matches the bootstrap nub. This loads and runs correctly. The problem is upgrades. Activating a higher CFBundleVersion via OSSystemExtensionRequest.activationRequest (in-place replace) always defers the old version's termination to reboot. The new version reaches [activated enabled] but never starts; the old process keeps running until reboot. From sysextd/kernelmanagerd: kernelmanagerd Dext … v15 … is being replaced and cannot be terminated right away sysextd delegate returns Error Domain=OSSystemExtensionErrorDomain Code=101 "…is being replaced", assumes responsibility for old version …, keeping old version 15 sysextd turning the responsibility for termination of …, version 15 over to delegate (with uninstallation at the next reboot) sysextd a category delegate declined to terminate extension with identifier: … sysextd v15 terminating_for_uninstall → terminating_for_upgrade_via_delegate Key observation: this defers even on a fresh boot where the dext was never opened — no app/daemon ever opened the IOUserClient, no I/O, nothing attached beyond the controller↔nub match. So it does not appear to be a "client still holds it open" / busy-state situation; the driver_extension category delegate declines the moment it's a replacement. What I've tried: In-place activationRequest (replace): always defers to reboot (above). deactivationRequest (standalone): the request hangs — no delegate callback at all (waited ~13 min), even with no client open. Disconnecting all clients first (graceful Stop() that cancels its dispatch queues and completes async) does not change the replace deferral. My understanding from the docs/forums is that the normal reboot-free replace relies on the backing device being disconnected/reconnected to quiesce the old dext (thread 677040). My controller matches a persistent IOUserResources-backed nub that never detaches, so there's no equivalent quiesce point. Questions: For a dext whose only provider is a self-published IOUserResources nub (no detachable hardware), is reboot-free replacement structurally impossible — i.e. is the Code=101 "is being replaced" defer inherent to this matching pattern? Is the supported way to live-upgrade such a dext to deactivationRequest → (on .completed) → activationRequest rather than an in-place replace? If so, what makes a deactivationRequest complete in-session vs. defer to reboot for an IOUserResources-matched dext — and what would cause it to hang with no delegate callback? (Daemon's IOUserClient is closed; the controller's Stop() cancels its queues and completes.) Should the dext itself proactively tear down the published nub (e.g. terminate the bootstrap IOService) before/at upgrade so the controller detaches — or does that just re-match the still-staged old personalities and relaunch the old version? Is there a recommended pattern for a virtual (hardwareless) DriverKit HBA that needs in-field, reboot-free version updates, or is reboot genuinely required for this class of dext? Environment: macOS 27 (Tahoe)

We offer an in-app way for customers to request an Apple refund for an auto-renewable subscription using StoreKit2. Everything worked during testing and verification in the Sandbox and TestFlight phases, but now consistently fails in Production. We present the refund sheet on a button press: .refundRequestSheet(for: transactionID, isPresented: $isPresenting) { result in switch result { case .success(let status): // .success / .userCancelled handled here case .failure(let error): // -> .failed for every user } } We log the outcome of all the requests, success and cancel behaves as expected. Since RefundRequestError only has .duplicateRequest .failed and the localizedDescription is generic, we don't know why it is failing. We have already checked that the transaction are for verified, not revoked, non-upgraded and active subscriptions. The issue only happens in Production. Is there any way to get more information about why a refund request fails or what other configuration needs to verified for this to work? Is there an eligibility window or other non-specified limit that might result in these errors?

Hello, I am developing a parental control app using FamilyControls, DeviceActivity, and DeviceActivityReport. My current setup is: The child device requests FamilyControls authorization with .child The parent device requests FamilyControls authorization with .individual The parent app displays reports through a DeviceActivityReportExtension The report filter uses users: .children and devices: .all I would like to clarify two questions: Can a third-party app use the Screen Time API to retrieve or display screen time activity per child or per child device from the parent app? For example: Child A's total screen time today Child A's iPhone screen time today Child A's iPad screen time today At the moment, I can only display an aggregated report using users: .children and devices: .all. I do not see a public API for selecting a specific child or a specific child device. Is this a current limitation of the public Screen Time API, or is there a recommended approach to implement this? Can the Screen Time API report activity data for family members aged 14-17? Specifically, if a family member is between 14 and 17 years old and their device has completed .child authorization, can the parent app still display their Screen Time data using DeviceActivityReport(users: .children)? Or are there restrictions related to Apple ID age, Family Sharing, or Screen Time permissions that prevent third-party apps from retrieving or displaying activity data for users in this age range? My goal is to understand what third-party apps can implement in a compliant way using the public APIs, without attempting to bypass any system limitations. Thank you.

We are developing a DLP agent that uses a NETransparentProxyProvider to perform traffic inspection and modification. Our architecture currently includes: LaunchAgent, which monitors user session activity (login/logout, session activation) Container App, which: installs and activates a System Extension creates and saves the NETransparentProxyManager configuration starts the transparent proxy via startVPNTunnel. We would like to automate the startup of the Transparent Proxy for all users, including newly created users, in a way that is fully supported by macOS. We are looking for official guidance on the correct and supported mechanism for starting a user‑level Network Extension (specifically NETransparentProxyProvider) automatically at user login. Questions: What is the recommended and supported way to automatically start a NETransparentProxyProvider at user login? Are there any constraints or best practices we should follow when designing an automatic startup flow for a Network Extension such as NETransparentProxyProvider? We would appreciate official clarification on the supported deployment patterns for starting a user‑level Transparent Proxy Network Extension automatically in multi‑user enterprise environments.

Related feedback: FB16995719 This is an old one, that has not been solved in iOS 27. This is very annoying since iOS 27 brings new AI stuff to Spotlight, that can't be used because of this bug. Jennifer has acknowledged this bug during a one-on-one session last year (WWDC25) where we carefully reviewed my code. I simply would like that the app documents content to be indexed. It's simple text that I pass to textContent. ------- try await CSSearchableIndex.default().indexAppEntities([entity]) // How the indexing is called ------- @available(iOS 18, *) /// The IndexedEntity struct DocumentEntity: IndexedEntity, Identifiable { static var typeDisplayRepresentation: TypeDisplayRepresentation { TypeDisplayRepresentation(name: LocalizedStringResource("INTENT_DOCUMENT_DISPLAY_REP")) } static let defaultQuery = DocumentQuery() // A unique identifier for each document let id: NSManagedObjectID let title: String? let thumbnailData: Data? // The document's text to be indexed let textContent: String? let pageCount: Int // A display representation for UI purposes. var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "\(title ?? "")", image: thumbnailData == nil ? nil : .init(data: thumbnailData!) // INDEXED successfully through the use of @available(iOS 18, *) struct DocumentEntity: IndexedEntity, Identifiable { static var typeDisplayRepresentation: TypeDisplayRepresentation { TypeDisplayRepresentation(name: LocalizedStringResource("INTENT_DOCUMENT_DISPLAY_REP")) } static let defaultQuery = DocumentQuery() // A unique identifier for each document (for example, your NSManagedObject's objectID). let id: NSManagedObjectID let title: String? let thumbnailData: Data? // The OCR text to be indexed let textContent: String? let pageCount: Int // A display representation for UI purposes. var displayRepresentation: DisplayRepresentation { DisplayRepresentation( title: "\(title ?? "")", image: thumbnailData == nil ? nil : .init(data: thumbnailData!) ) } } ) } } @available(iOS 18, *) extension DocumentEntity { // The attributeSet for Spotlight var attributeSet: CSSearchableItemAttributeSet { let attributeSet = defaultAttributeSet attributeSet.title = title attributeSet.displayName = title // THIS ONE IS INDEXED attributeSet.contentType = UTType.plainText.identifier attributeSet.textContent = textContent // THIS ONE IS **NOT** INDEXED attributeSet.pageCount = NSNumber(integerLiteral: pageCount) // THIS ONE IS INDEXED attributeSet.thumbnailData = thumbnailData attributeSet.creator = Constants.APP_NAME return attributeSet } } Related: https://discussions.apple.com/thread/256061571

Summary We are observing that Wi-Fi Aware data transfer throughput on iPhone is heavily impacted by the device's Wi-Fi association state and by surrounding RF interference. When Wi-Fi is turned off from Control Center, Wi-Fi Aware throughput increases to roughly 2x (or higher) compared to when the device remains associated to a Wi-Fi network. We would like to confirm whether this is expected behavior or a system-level bug. Log Feedback ID: FB23454477 Environment Device: iPhone Feature under test: Wi-Fi Aware (NAN) data path transfer Steps to Reproduce Connect the iPhone to a Wi-Fi network (associate to an AP). Establish a Wi-Fi Aware (NAN) data-path session with a peer device. Start a sustained data transfer and measure the steady-state throughput. Repeat the measurement in two RF conditions: a. Clean RF environment (no other surrounding Wi-Fi/BLE devices nearby). b. Congested / high-interference RF environment. Turn Wi-Fi off from the Control Center pull-down menu (leave the peer/session as before). Repeat the same Wi-Fi Aware transfer and measure throughput again. Observed Behavior Scenario 1 — Wi-Fi connected (associated to an AP) Clean RF environment (Wi-Fi connected, no other surrounding Wi-Fi/BLE devices nearby): Wi-Fi Aware transfer throughput is approximately 20 MB/s. Congested / high-interference RF environment: Wi-Fi Aware transfer throughput drops to approximately 8 MB/s. Reference log: sysdiagnose_2026.06.28_21-05-09+0800_iPhone-OS_iPhone_23F81.tar.gz Scenario 2 — Wi-Fi turned off via Control Center After turning Wi-Fi off from the Control Center pull-down menu, the Wi-Fi Aware transfer throughput increases to 2x or higher compared to Scenario 1. Reference log: sysdiagnose_2026.06.28_21-15-00+0800_iPhone-OS_iPhone_23F81.tar.gz Expected Behavior Wi-Fi Aware throughput should not be significantly constrained by the device's Wi-Fi association state. We expect comparable Wi-Fi Aware performance regardless of whether the device is associated to a Wi-Fi network, since disabling Wi-Fi should not be required to achieve full Wi-Fi Aware data-path throughput. Questions for Apple Is the throughput reduction while associated to a Wi-Fi network expected behavior (e.g., due to time-sharing/channel scheduling between the infrastructure connection and the Wi-Fi Aware data path)? If this is by design, are there recommended APIs, configurations, or best practices to maintain higher Wi-Fi Aware throughput while the device remains connected to Wi-Fi? If this is not expected, we believe this is a system-level bug and would appreciate guidance on a fix or workaround.

'm building a peer-to-peer mesh messaging app using MultipeerConnectivity. The app implements TTL-bounded flooding relay so messages can traverse multiple hops across devices that aren't directly connected to each other. The core limitation I'm hitting: MPC stops browsing and advertising when the app is backgrounded, which means a node can no longer relay messages for the rest of the mesh. For the mesh to be useful in practice, nodes need to stay active as relays even when users switch to other apps. I'm aware of the standard options: . Background task extension (beginBackgroundTask) — only buys ~30 seconds, not a real solution . Push notifications (APNs) — requires a server, defeats the goal of a fully offline/local mesh . CoreBluetooth with state preservation/restoration — genuine background capability, but essentially a full rewrite of the transport layer, and BLE throughput (~100–250 kbps) would hurt larger payloads Before committing to a CoreBluetooth rewrite, I want to make sure I'm not missing anything. specifically questions are: Is there any way to keep an MCNearbyServiceAdvertiser or MCNearbyServiceBrowser running in the background that I'm not aware of? Does MCSession maintain existing connections long enough in the background to be useful for relay (i.e., does it survive past the background task expiry)? Is Network.framework's local network discovery (NWBrowser with Bonjour) any more background-friendly than MPC's browser/advertiser? • Has anyone successfully implemented a hybrid approach — CoreBluetooth for background discovery/signaling + a higher-bandwidth channel (WiFi Direct or Network.framework TCP) negotiated when foregrounded? • Are there any entitlements or capabilities (e.g., AccessorySetupKit, NEAppProxyProvider, or anything in the networking extension family) that could help here that aren't commonly discussed? The relay/routing layer, E2EE, and message dedup all sit above the transport and are transport-agnostic, so the rewrite scope is limited to the discovery and session management layer — but it's still significant. Any experience with this pattern would be very helpful.

I'm building a custom keyboard extension that offers voice dictation. Because keyboard extensions are constrained (memory cap ~30–48 MB, restricted audio session access), I delegate recording to my container app: User in a host app (e.g., Safari) taps the mic in my keyboard extension. The keyboard calls extensionContext.open(URL("myapp://dictation")) to launch the container app. The container app records audio via AVAudioEngine + SFSpeechRecognizer, writes the final transcript to the App Group, and signals completion via a Darwin notification. 4. The user is expected to be returned to the original host app (Safari) automatically so they can keep typing. The problem (step 4): On iOS 26.4 I can no longer identify which app was the host. Every previously-known path returns nil for the keyboard extension's host: parent.value(forKey: "_hostBundleID") → returns the literal string parent.value(forKey: "_hostApplicationBundleIdentifier") → returns NSNull xpc_connection_copy_bundle_id on the underlying XPC connection (via PKService.defaultService.personalities[…]) → returns NULL NSXPCConnection.processBundleIdentifier on extensionContext._extensionHostProxy._connection → returns nil proc_pidpath(hostPID, …) → EPERM from the keyboard sandbox LSApplicationWorkspace.frontmostApplication → selector unavailable from the extension RBSProcessHandle.handleForIdentifier:error: → returns an RBSServiceErrorDomain error Without the host's bundle ID, the container app has no way to call LSApplicationWorkspace.openApplicationWithBundleID: (the technique that worked on iOS 25 and earlier). UIApplication.suspend() correctly sends the container to background, but iOS treats us as a "fresh launch" — it returns the user to the Home Screen instead of Safari, because the container app was launched by an extension, not directly by Safari. KeyboardKit's maintainer reached the same conclusion (issue #1014) and shipped 10.4 without the feature. My questions: Is there a public, App-Store-safe API in iOS 26+ for a custom keyboard extension to identify its host application, or for the container app (launched via the extension's openURL) to identify which app initially hosted the extension that opened it? UIOpenURLContext.options.sourceApplication reports the extension's own container, not the actual host. 2. Is there a public mechanism for "return to source app" when the container app was launched by an extension's openURL? Equivalent to the ← Source affordance iOS shows for normal inter-app openURL, but triggered programmatically by the launched app. 3. Some popular keyboards (e.g., 微信输入法 / WeChat Keyboard) still appear to round-trip through their container app on iOS 26.4 and return the user to the original host — including the iOS ← WeChat back affordance in the host's status bar afterward. What's the recommended approach to achieve this? If it requires a specific scene-activation flow, NSUserActivity pattern, or extension-context configuration, please point at the relevant docs. 4. If there is no public path today, is FB22247647 (or a related radar) the right place to track this? Should developers in this position migrate to in-extension audio capture (which has its own significant constraints in keyboard extensions)? I'd much rather not rely on private APIs. Concrete guidance — or even an acknowledgment of which direction Apple intends — would help thousands of custom-keyboard developers who currently have a degraded voice-input experience on iOS 26.4+. Tested on iPhone 12 Pro Max running iOS 26.4.2 (build 23E261), Xcode 26.x, Swift 5. Thanks!

I have a custom keyboard (UIInputViewController, Full Access). For a dictation feature it opens its containing app to record audio (the keyboard can't use the microphone) and then needs to return the user to the host app they were typing in. That requires knowing the host app. Through iOS 26.3 this worked, because the host bundle id was exposed on the keyboard's input-session connection. On iOS 26.4 / 26.5 it is now nil, and every route I have tried is blocked: UIInputViewController _hostApplicationBundleIdentifier -> nil _hostProcessIdentifier and the host audit token are available, but: RBSProcessHandle handleForAuditToken: / handleForIdentifier: -> "Client not entitled" SecTaskCopySigningIdentifier / SecTaskCopyValueForEntitlement -> nil (sandbox) proc_pidpath -> EPERM UIKeyboardImpl _remoteAppId / _remoteLocalizedAppName -> nil The keyboard arbiter client-change event fires in SpringBoard, not in the extension process However, at least one shipping keyboard still does this on iOS 26.5. I verified in device logs that Yandex Keyboard launches its container app with a URL containing the correct, current host bundle id, and it is live: it reported net.whatsapp.WhatsApp, then net.whatsapp.WhatsAppSMB when the host was WhatsApp Business. So the capability clearly still exists for some apps. Questions: Is there a supported API on iOS 26.4+ for a keyboard extension to identify its host app? If it requires an entitlement, can developers request it, and how? If there is no public path, is the intended approach the system "back to previous app" breadcrumb (manual) plus a containing-app round trip? I have also filed Feedback (FB#######). Thanks.

We are conducting iBeacon compliance testing for our device and would like to clarify two test items from the iBeacon test specification: Regarding Tx power stability verification over time and across different battery capacities: Could you please specify the required test duration and the exact test procedure? Specifically, how long should the Tx power be monitored to verify stability within the 2dB standard deviation requirement, and what battery capacity levels (e.g., 100%, 50%, 20%, low battery threshold) should be tested? Regarding device interoperability with iOS CoreLocation APIs for beacon-based region monitoring and ranging: Could you please provide guidance on the test methodology? Specifically, what test cases, expected behaviors, and pass/fail criteria should we follow to verify correct interoperability with region monitoring (didEnter/didExit) and ranging (didRangeBeacons) APIs? Any official test guidelines or reference documents would be greatly appreciated.

Hi everyone, We're working on a custom USB-C accessory based on an MCU (ARM Cortex-R8, running RT-Thread RTOS) with a Synopsys DWC3 USB Device controller. Our goal is to stream real-time sensor data (~10 Mbps) from the accessory to an iPhone via USB-C. We're planning to configure our MCU as a USB NCM device (following USB-IF NCM v1.0 spec), so the iPhone sees it as a standard Ethernet adapter. We would then run a lightweight TCP/IP stack (lwIP) on the MCU side and communicate with our iOS app via standard BSD Sockets / Network.framework over the virtual network — no gateway, just direct IP-to-IP communication within the local network that the NCM device presents. Questions: Feasibility confirmation: Based on our description, do you see any issues with this approach on iPhones including iPhone 16 and newer models? Our USB controller supports High-Speed (480 Mbps), so NCM throughput should not be a bottleneck. No-gateway concern: We don't plan to implement a DHCP server or gateway on the MCU. We'd use static IP configuration (or Link-Local addressing) for direct socket communication. Is there anything in iOS's network stack that would prevent this — for example, requiring a DHCP-assigned address or a default gateway before allowing socket traffic on the USB Ethernet interface? MFi and long-term viability: We understand this approach doesn't require MFi certification, since NCM is a standard USB-IF class and iOS has built-in Ethernet support. However, we want to make sure this doesn't go against the spirit of the MFi program or Apple's accessory policies. Is there any risk that Apple might restrict or block non-MFi NCM accessories in a future iOS update? We'd rather invest our effort in the right approach from the start. App Store review: Would an iOS app that communicates with our accessory exclusively via standard socket APIs (Network.framework / BSD Sockets) over the USB Ethernet interface face any App Store review issues — assuming it doesn't use any private APIs and doesn't declare MFi support? Any guidance would be greatly appreciated. We want to make sure we're building on a solid foundation.