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.

I have an app with a Widget Extension. Both the main app and the widget extension link against the same Swift Package, which contains a localization bundle (String Catalog) used by SwiftUI views inside the package. To make the package's views follow the app's configured language (rather than the system language), I set CFBundleAllowMixedLocalizations to NO in the Info.plist of each target (main app and widget extension). Behavior in the main app: This works as expected. If the app only supports Korean, the package's views display Korean text even when the system language is set to English. Behavior in the widget: The same views (from the same package) display English instead of Korean, even though the widget extension has the identical CFBundleAllowMixedLocalizations = NO setting and the widget's view code lives entirely in the package — not in the widget extension target itself. Question: As far as I understand, widgets are supposed to follow the host app's language setting. Given that both targets have the same Info.plist configuration, why would the widget extension resolve localized strings differently from the main app for code in the same package? Is this expected behavior for widget extensions specifically, or a bug? Is there a recommended workaround to force a widget extension (and by extension, the Swift Package code it runs) to use the app's language instead of the system language?

Hi, On visionOS 27 simulator accessoryRectangular widget shows completely blank with no text. The same widget shows up correctly on iOS 27 simulator. What I have tried: I have checked the timeline provider and they all seem to be generating timeline entries. supportedFamilies include accessoryRectangular I have even hard coded the content in the view for the widget yet only accessoryRectangular for visionOS 27 shows up blank. Isolated problem The same widget shows up correctly on iOS 27 simulator. The problem is only with visionOS 27. Environment: macOS: 26.6.1 (25G76) Xcode: 27.0 beta 5 (27A5237l) Simulator: visionOS 27.0 Questions What am I missing? How can I resolve it? Is this a known issue? Has anyone gotten accessoryRectangular widget showing up on visionOS 27 simulator? Any help on this would be much appreciated.

I have a multi-platform app 1 (visionOS, macOS, tvOS) on the app stores. I am trying to add an iOS version but it got rejected. I have been trying to get another visionOS app 2 accepted but that was also rejected. After app 1 was rejected I retried the other app 1 versions and had some issue downloading Background Assets . After reinstalling the app 1 versions from their App Stores they worked as expected. The other app 2 was working for me via TestFlight but each time I submitted a new version of the app it was rejected with a black screen image, indicative of a downloading issue. I may need to do some coding work on app 2 but the behavior of accepted app 1 versions has me asking if others have seen issues with Background Asset downloads. This seems to be a relatively new technology so maybe stiill a work in progress.

We're evaluating Apple-hosted Background Assets for an app distributed on App Store and would like to understand the security model behind it before adopting it. So far the public documentation only mentions the HTTPS requirement for asset transport. We'd appreciate any additional documentation or guidance covering: How asset downloads are authenticated (e.g., is access tied to the app's entitlement/provisioning, or is there a separate token/credential mechanism?) How access to specific assets is controlled/scoped Where Apple-hosted assets are physically/logically hosted (e.g., is this CDN-backed, and is there any control or visibility over hosting region?) Any other security considerations typically associated with cloud-hosted content (encryption in transit and at rest, integrity verification, etc.) Is there a more detailed security/architecture document beyond the public developer documentation, or can someone from the team point us in the right direction?

Container ID: iCloud.com.bluecrestcreative.HouseholdWizard (and a brand-new test container, iCloud.com.bluecrestcreative.HouseholdWizard2 — see below) Calling persistentContainer.share(_:to:) on an NSPersistentCloudKitContainer never successfully completes against the Production CloudKit environment. The identical code works fine against Development. What I've ruled out so far, each with a real test: Stale local state — wiped the local Core Data store entirely and retried from empty. Same failure, new share/zone UUID each time. Container-specific corruption — created a brand-new CloudKit container under the same team (never used before, zero history) and pointed the app at it instead. Same failure. Permissions — confirmed full "Edit Production" access in Container Permissions for my account. Entitlements mismatch — verified identical entitlements between a working Development build and the failing Production build (only the environment key differs). Daemon/session staleness — rebooted the Mac, retried. Same failure. CloudKit Dashboard schema — "Deploy Schema Changes to Production" shows zero pending changes even after a successful share in Development, so the cloudkit.share system type doesn't appear to be tracked by the normal schema-deploy mechanism. The specific error captured from the original container (Xcode 26.6, macOS): NSCloudKitMirroringDelegate _requestAbortedNotInitialized: Never successfully initialized and cannot execute request due to error: CKError "Partial Failure" (2/1011); "Failed to modify some records"; partial errors: { cloudkit.zoneshare:(com.apple.coredata.cloudkit.share.:defaultOwner) = CKError "Invalid Arguments" (12/2006); server message = "Cannot create new type cloudkit.share in production schema" } On the brand-new test container, the failure mode was slightly different (an initial CKError Code=5 / notAuthenticated during user-identity fetch, then CKShare.url simply never populates, indefinitely), but the end result is identical: sharing never actually completes. Has anyone seen this, or know what's needed to make CKShare record creation work against Production for a container? Already have a DTS incident open (Case-ID 21466535) but wanted to ask here in parallel since code-level questions get routed here anyway.

So how can I still login

Hello everyone, I need help about ASK. AccessorySetupKit: removeAccessory confirmation dialog displayed in English while device, app and ASK picker are localized in French. Area: AccessorySetupKit / Bluetooth Type: Incorrect/Unexpected Behavior iOS version: iOS 26.6 When calling ASAccessorySession.removeAccessory(_:completionHandler:), the system confirmation dialog ("Remove paired accessory? "MyAppXXX" is attempting to remove MyDevice.") is displayed in English, even though: The device language is French Locale.current.identifier = fr_FR The app's effective localization resolves to French Bundle.main.preferredLocalizations = ["fr"] The app bundle declares French Bundle.main.localizations = ["en", "es", "it", "fr", "nl"] developmentLocalization = "en" All other AccessorySetupKit UI is correctly localized: the ASK picker shown by showPicker(for:) and the pairing dialogs appear in French as expected. Only the remove-accessory confirmation dialog falls back to English. Issue is already open with Apple feedback Assistant: FB24306024 And also by Apple technical support 21587044 Thank you

When using AccessorySetupKit to remove accessories, a pop-up window appears when calling removeAccessory. However, the text in the pop-up window does not change according to my iPhone's language settings and remains only in English. Has anyone encountered this issue? Does Apple have any plans to address this compatibility issue?

I’m trying to request an NFC PassKit Certificate through https://developer.apple.com/contact/passkit/. After clicking Send, the completed form is POSTed successfully and receives 200 OK, but the server returns the original form instead of a confirmation page. The page’s passkit.js then clears all fields, and Developer Support confirmed that my earlier submission was never received. Has anyone else encountered this behavior or found another way to submit the NFC PassKit Certificate request?

On iOS 26.4, I set a Screen Time passcode. However, when I go to Settings > Apps > [Our App] and turn off Screen Time Access for the app, the system asks for Face ID instead of the Screen Time passcode. As a result, Screen Time access can be disabled without entering the Screen Time passcode. Steps to Reproduce 1. Set a Screen Time passcode on iOS 26.4. 2. Open Settings > Apps > [Our App]. 3. Turn off Screen Time Access for the app. Expected Result The system should require the Screen Time passcode before allowing Screen Time access to be disabled. Actual Result The system asks for Face ID instead of the Screen Time passcode, and Screen Time access is disabled.

I’m building an app that contributes to a crowdsourced earthquake early warning network: the device reports anomalous accelerometer readings, a server correlates them across nearby devices, and users farther from the epicenter get a warning seconds ahead. Detection has to continue while the app isn’t in the foreground. I’ve ruled out the obvious paths — CMMotionManager stops on suspension, CMPedometer and CMMotionActivityManager only return historical data, BGTaskScheduler is too infrequent, and CMSensorRecorder is watchOS-only. I’ve also read thread 765258, where DTS confirmed there’s no background capability for accelerometer data and that repurposing another one risks rejection under 2.5.4, so I’m not looking for a workaround. Is there any supported way to do this on iOS, for instance restricted to when the device is stationary and charging? Or is this outside what the platform currently allows? Thanks.

I'm seeing IAPError(code: storekit_no_response, source: app_store, message: "StoreKit: Failed to get response from platform.") when calling queryProductDetails() (via Flutter's in_app_purchase/in_app_purchase_storekit plugin) for all 6 of my app's In-App Purchase products. This happens consistently on a real device (iOS 18.7.9), including after a full device restart. I've followed the entire TN3186 checklist: Paid Apps Agreement: Active Banking: Active Tax Forms: Active Bundle ID matches App Store Connect and Certificates/Identifiers/Profiles In-App Purchase capability is enabled on the App ID All 6 product identifiers match exactly and are attached to the app version under review Pricing is set for all territories on all products None of this resolves the error. This also caused an App Store review rejection citing "In-app purchase products... could not be found in the submitted binary" for the same reason. Bundle ID: com.playadda.playadda Product IDs affected: gems_pack_100, gems_pack_500, gems_pack_1200, premium_monthly, battle_pass_s1, starter_pack Has anyone found a resolution to this specific error beyond the standard TN3186 checklist?

My app has been stuck in “Waiting for Review” status since August 6th, over a week now. I’ve submitted multiple expedited review requests and haven’t received any response or update on any of them. This delay is holding up my launch and affecting my ability to plan around it. I understand expedited review isn’t guaranteed, but getting no reply at all, even a decline, makes it hard to know whether the request was seen or if something else is holding up the review. Could someone look into my case and let me know what’s going on? Best regards, App Name: Ratiō - AI Calorie Tracker Apple ID: 6790632661

Transaction.finish() doesn't clear a transaction on iOS 27 beta 5 — worked correctly through beta 4 — every repeat purchase after the first replays the same transaction with no confirmation sheet and no charge. StoreKit.Transaction.finish() does not clear a transaction on iOS 27 beta 5. The transaction remains in Transaction.unfinished indefinitely, and every subsequent Product.purchase() call for that product returns the same stale transaction instead of starting a new purchase — with no confirmation sheet, no charge, and no way for the app to tell it apart from a genuine purchase. Because the replayed result is .success carrying a VerificationResult that verifies normally, an app has no supported signal that nothing was bought. The only distinguishing traits are that the id and purchaseDate are unchanged and the call returns in ~10ms instead of making a server round-trip. Consequence: a consumable product can be purchased exactly once per device. Every later attempt silently no-ops while appearing to succeed. Steps to Reproduce On a device running iOS 27 beta 5, sign in to a newly created Sandbox Apple Account (Settings → Apps → App Store → Sandbox Account) with no prior purchase history. Install and launch a development build of an app offering a consumable IAP. Confirm Transaction.unfinished is empty. Purchase the consumable. The confirmation sheet appears and the purchase completes normally. await transaction.finish() on the returned transaction. Enumerate Transaction.unfinished again. Purchase the same consumable a second time. Expected Results Step 6: Transaction.unfinished is empty — the transaction was finished. Step 7: a confirmation sheet appears and a new transaction is created, with a new id and a current purchaseDate. Actual Results Step 6: the just-finished transaction is still listed in Transaction.unfinished. Step 7: no confirmation sheet appears. purchase() returns .success in ~0.01s carrying the same transaction — identical id and identical purchaseDate — and nothing is charged. This repeats indefinitely. Re-fetching the transaction from Transaction.unfinished and calling finish() on that instance does not clear it either, so there is no app-side way to drain the queue. Diagnostic Log Virgin sandbox account, empty queue, three consecutive taps on one product: unfinished before tip.small: [] purchase() returned after 18.10s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 --- await transaction.finish() --- unfinished after finishing 2000001221113013: [small#2000001221113013] unfinished before tip.small: [small#2000001221113013] purchase() returned after 0.01s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 unfinished before tip.small: [small#2000001221113013] purchase() returned after 0.01s tip.small: id=2000001221113013 purchaseDate=2026-08-13 22:36:26 +0000 The first call is a genuine purchase (18s round-trip, sheet shown). The transaction survives its own finish(). Calls two and three are replays of it. Notes Not reproducible against a local .storekit configuration in the Simulator, which always presents the confirmation sheet. Requires Apple's sandbox. Also reproduces on a TestFlight build billed to a real Apple ID, where it is worse: TestFlight purchase history cannot be reset, so the affected products stay permanently stuck for that account. It survives deleting and reinstalling the app, and a device reboot. Possibly the same underlying issue as the unanswered report at https://developer.apple.com/forums/thread/808648 (iOS 26/18, Nov 2025). Configuration Device: iPhone 16 Pro Max OS: iOS 27 beta 5 Products: consumable in-app purchases API: StoreKit 2 (Product.purchase(), Transaction.finish(), Transaction.unfinished)

Hi all, we are building a custom controller for ATDECC, which is a layer 2 protocol standardized by IEEE in 1722.1. Our controller can work on multiple network interfaces at the same time . It uses the interface's MAC address to identify, on which interface a certain AVB / ATDECC device was discovered. It then sends replies for this device only to this interface. This controller worked fine up to and including macOS 26, but when running the same code on macOS 27, we cannot get the MAC addresses for the local interfaces anymore, but we receive 02:00:00:00:00:00 for each of them. This seems to indicate that the MAC address was redacted (looks like the same MAC address, that is being returned since iOS 11 due to privacy reason). Is this a bug or is macOS going to redact the MAC addresses also in the final release? If MAC addresses are being redacted, would it help to request access to the new entitlement called com.apple.developer.networking.topology-observation? I attached a little code snippet, that returns actual MAC addresses on macOS 26, but redacted ones on macOS 27. Build with clang++ -std=c++23 -o ifprobe ifprobe.cpp and then run it with ./ifprobe. ifprobe.cpp

I am experiencing a StoreKit issue on iOS 27 Beta with eFootball™ 11.0.0 (jp.konami.pesactionmobile). After an in-app purchase, the app becomes stuck on an infinite loading screen during login. If I manage to log in, the in-game Shop also remains stuck loading. I investigated the issue using macOS Console and found that StoreKit repeatedly attempts to finish the same production transaction every approximately 2–3 seconds. The relevant logs are: Starting request FinishTransactionRequest(...) Failed to encode request parameters NSCocoaErrorDomain Code=3840 Error finishing transaction: StoreKitServiceError StoreKitInternalError.requestEncodeFailed The same transaction is repeatedly passed to FinishTransactionRequest, but the finish operation never succeeds. What I have confirmed The purchase itself was confirmed by Apple Support as successfully completed. The transaction is a Production transaction with the JPN storefront. Reinstalling eFootball does not resolve the issue. Restarting the iPhone does not resolve the issue. Signing out and back into "Media & Purchases" with the affected Apple Account does not resolve the issue. Network requests from the app itself are succeeding with HTTP 200 responses. The issue occurs when StoreKit attempts to finish the transaction. Most importantly, if I sign out of the affected Apple Account under Media & Purchases and sign in with a different Apple Account on the same iPhone, eFootball immediately works normally again — both login and the Shop load successfully. If I switch back to the original Apple Account, the issue returns. Steps to reproduce Use the affected Apple Account for Media & Purchases. Launch eFootball. Attempt to log in. The app remains stuck loading. Observe Console logs from storekitd. The same transaction repeatedly triggers FinishTransactionRequest. Each attempt fails with StoreKitInternalError.requestEncodeFailed. Expected behavior StoreKit should successfully finish the completed transaction, remove it from the unfinished transaction queue, and allow the app to continue normally. Actual behavior FinishTransactionRequest repeatedly fails with requestEncodeFailed, causing the same transaction to be processed indefinitely and preventing normal use of the app. Has anyone encountered the same behavior on iOS 27 Beta? Is this a known StoreKit issue, or is there any way to safely clear/finish the affected production transaction without restoring the device to the current public iOS release?

I see online theres list of urls app can use to deeplink to Apple apps: https://github.com/bhagyas/app-urls#references-and-additional-resources are these acceptable by Apple? Apps just want to redirect the user so they can take some appropriate action.