Overview

Hi Devs, I'm working with WatchOS for the first time and am having a frustrating time with Xcode to Watch, to say the least. I have a Series 9 dev watch and Xcode does not reliably connect to it. Spending 15-20 min per build/run attempt just trying to get xcode to find and connect to the watch. It WILL sometimes recognize and allow a build to run, the issue is I can't tell any reliable way to establish the connection. It drops after every build and leaves me at square zero. Current solution is some amount of force quitting, reconnecting iPhone to USBC, disconnecting watch to wifi and back on. Devices Window usually reads: Previous preparation error: A connection to this device could not be established.; Timed out while attempting to establish tunnel using negotiated network parameters - swapping to some attempting to connect state that never (reliably resolves). Is this why no one builds for WatchOS? Hoping someone has pro tips on this.

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

On this talk: Bring an LLM provider to the Foundation Models framework URL: https://developer.apple.com/videos/play/wwdc2026/339/ on the coding examples a very peculiar framework is shown: import MLXFoundationModels However I am not able to find it nowhere, there is even a code section with this framework as part of an example. Where is this framework, there are no BETA branches on the MLX framework either. Thanks!

Hello everyone, I recently enrolled in the Apple Developer Program as an Individual developer, and my enrollment is still being processed. My enrollment was submitted on June 17, 2026, and I currently have an open support case (102921992970) with Apple Developer Support. Unlike some payment-related issues discussed here, I have not been charged yet, and no payment has been processed from my card. My enrollment simply remains in a pending/processing state. At the moment, I have not received any requests for additional information or documentation. My support case remains open, but I have not yet received an update regarding the status of the review. I wanted to ask if anyone else has experienced a similar delay recently. How long did your enrollment take to be approved? Were you contacted for additional verification? Is it normal for enrollment review to take more than a few business days before payment is processed? Any insights or experiences would be greatly appreciated. Thank you. Kind regards, Famous Macaulay

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.

In Xcode project > Build Settings > Swift Compiler - Concurrency. When we have those settings : Approachable Concurrency - Yes Default Actor Isolation - MainActor A sendable struct without @Actor annotation will be stuck to @MainActor. But if we have a sendable struct, by principle, it should be used across Actors. To remediate the situation, we had to prefix the struct with nonisolated keyword. The setting "Default Actor Isolation - MainActor" should not add @MainActor to Sendables. Problem describe in : FB23264607

Transitions inside ScreenTime Report is not working if phone locked when app is opened. It is starts working only after terminate and open the app.

Hello, I'm looking for advice because my app update appears to be stuck in "Waiting for Review." Submission date: June 11, 2026 Status: Waiting for Review (it has never changed to "In Review") Type: Update to an existing app (not a new app) This update does not introduce: new subscriptions or paywalls, new payment methods, major changes to the app's business model. I've already: Submitted an App Review Support request. Submitted an Expedited Review Request. Waited for a response, but I haven't received any reply. I've also verified that there are no outstanding agreements or obvious issues in App Store Connect. Has anyone experienced a similar situation recently? If so: Did your submission eventually move into review on its own? Did you have to withdraw and resubmit? Is there another way to contact the App Review team when support requests receive no response? If an Apple staff member sees this, I'd appreciate it if you could check whether my submission or support case may be stuck. Thank you.

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 paid the enrollment tax with a debit card from my business parter. My account still not enrolled at development program. I have 2 tickets at apple support since 06/23 and nothing was done. Any suggestions?

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)

Hi, I added two new auto-renewable subscriptions to an existing subscription group: 50GB Monthly 50GB Yearly The other subscriptions in the same group (200GB and 500GB monthly/yearly) have already been approved. However, these two new subscriptions have remained "In Review" for over 3 days without any updates. Is this normal, or could the review be stuck? Has anyone experienced the same issue? Thanks!

I'm trying out Xcode 12 (beta) and encountered an issue with TextField when viewing it in a live Preview. Although the view is interactive (scrolling vertically seems to be OK) and a cursor appears in the TextField view when it is clicked on, keyboard input is ignored. The same code works as expected in Xcode 11.5. Simulator in both 11.5 and 12 exhibits expected behaviour. Is this a bug? I know there is an issue with interactivity in Preview with multiple views inside PreviewProvider but I'd assumed this is if you'd added multiple Views to the same body of this struct.

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?

AI agentic coding is great, but it drifts away from the good practices and good code. Sometimes I am writing code while thinking what exactly to write, exploring the architecture solution, the data flow, not the technology, so making a prompt is not the best use case. I am doing iOS development in VSCode since preview version of Copilot launched, the auto-completions that AI provides IS the greatest tool a developer can have Please 🙏 prioritize the unimaginable good auto-completion that only Apple can provide, so that we can auto-complete function implementation, class implementation, multiple lines of comments in a fraction of a second

Hi, I am working on integrating In-App Purchases (IAP) into a React Native app using the Expo managed environment. I would appreciate guidance on the complete implementation steps for setting up and handling IAP in this context. Specifically, I am looking for: How to configure In-App Purchases in App Store Connect (product IDs, pricing, etc.) Which libraries or Expo modules are recommended for IAP in a managed Expo workflow (e.g., expo-in-app-purchases or react-native-iap)? Step-by-step integration guide — installing the library, adding necessary permissions/entitlements, and any required app.json / app.config.js configuration. How to fetch available products, initiate a purchase, and handle purchase callbacks/receipts in code. Server-side receipt validation — best practices and recommended approach. Handling edge cases such as purchase restoration, subscription renewals, and failed transactions. Any sandbox testing setup required for testing IAP before going live. Any official documentation, sample code, or recommended resources for React Native Expo managed workflow would be greatly appreciated. Thank you!

Hello, Our app has been in "Waiting for Review" status for more than a week, and our previous submission also took over a week to be reviewed. This delay is affecting our planned release schedule. App details: App name: Nhật Luân Kiếm App ID: 6777269196 We'd really appreciate any guidance on the current review timeline, or whether there is anything on our side we can do to help move the review forward. We're happy to provide any additional information if needed. Thank you very much for your time and support. Best regards.