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 finished a new app that integrates Apple hosted background asset. I have tested and confirm that the assets are downloaded both locally and with a TestFlight build. App review is not able to access the background assets. I can see that the assets are updated with status "accepted". But app review is running into error "A server with the specified hostname could not be found.". These are Apple Hosted Assets. Did I miss any configuration?

Hi Apple Developer Support / WeatherKit team, I’m seeing WeatherKit fail on a physical iPhone with what appears to be a JWT / permission issue, even though the app appears to be correctly configured and signed with the WeatherKit entitlement. App / project context: App name: Signals Platform: iOS Framework: SwiftUI WeatherKit usage: Native WeatherKit framework, using WeatherService.shared.weather(for:) Purpose: Showing a small morning weather summary inside the app What I have already verified: Active Apple Developer Program membership WeatherKit capability enabled for the App ID in Apple Developer Portal WeatherKit capability enabled in the App Capabilities tab WeatherKit capability added in Xcode Signing & Capabilities Automatic signing enabled Built and tested on a physical iPhone device Location permission is requested and granted The app binary appears to include the WeatherKit entitlement The embedded provisioning profile appears to include the WeatherKit entitlement Issue: WeatherKit still fails at runtime with a JWT / permission-related error. Could you please help verify whether: The WeatherKit entitlement is correctly attached to my App ID and provisioning profile My Team ID / App ID has WeatherKit access fully enabled on Apple’s backend There are any backend propagation delays or stuck entitlement states WeatherDaemon has permission to generate JWTs for this app There is anything else I need to reset or regenerate, such as provisioning profiles, certificates, or App ID capabilities I can provide: Team ID Bundle ID provisioning profile UUID entitlement output from codesign device logs / WeatherKit error logs screenshots of App ID capability settings Thank you.

Hey, I'm building an app that uses App Intents to modify data stored in SwiftData and synced through CloudKit. My expectation is that these changes should eventually be reflected in my app's widgets across all of the user's devices (iPhone, iPad, and Mac). However, I'm struggling to find a reliable way to ensure widgets reload when the underlying data changes as a result of a CloudKit sync. Reloading widgets on the device that modifies the data works reliably. The challenge is ensuring widgets reload on other devices after the updated data has been synced through CloudKit. In practice, this doesn't appear to happen reliably. I do not expect the user to manually open the app on those devices. I'm fine with the system launching my app in the background if that's part of the intended solution. Is there a recommended approach for keeping widgets in sync with SwiftData and CloudKit across devices? More specifically: Can WidgetKit be notified when SwiftData receives updates from CloudKit? Is there any supported way to trigger widget reloads on remote devices after a CloudKit sync? If not, what is the recommended architecture for ensuring widgets stay reasonably up to date when synchronized data changes? Things I've considered and/or tried: Calling sendChanges(_:) on CKSyncEngine from my App Intent to push changes immediately. However, this depends on an active Internet connection and doesn't address the case where changes are made offline and synchronized to CloudKit at a later time. Sending push notifications to the user's devices after an App Intent runs and using WidgetPushHandler to reload widgets. However, this requires confidence that the changes have already been uploaded to CloudKit. As far as I can tell, that's difficult or impossible to guarantee in the general case because of the issue described above. Calling fetchChanges(_:) on CKSyncEngine from the widget's timeline provider to ensure the widget has the latest data. However, the widget first needs some indication that new changes are available in CloudKit. Additionally, widget timeline reloads appear to have fairly strict execution time limits, which makes performing CloudKit synchronization work in that context seem less than ideal. My goal is for a Shortcut run on one device to update data and have widgets on all of the user's devices reflect those changes without requiring the user to manually open the app on each device. Am I thinking about this problem correctly, or is there a recommended pattern I'm missing? I'd appreciate any guidance on the intended WidgetKit + SwiftData + CloudKit integration story for this scenario. Thanks!

I have a weird situation arising in my app where calling BGTaskScheduler.shared.submit(request) seems to fail silently, without raising any of the BGTaskScheduler.Error's. Here's what's happening. A user registers and submits 5 BGContinuedProcessingTask's, with different ID's using the wildcard. When trying to submit the 6th task like this: try bgTask.submit() //submit task isCreatingBGTask = false // toggle ProgressView off dismiss() //Dismiss the sheet The sheet will dismiss, but the device never gives the haptic feedback, and the task is not visible in the notification centre. Having a maximum number of running tasks makes sense, but why isn't it raising the error BGTaskScheduler.Error(.immediateRunIneligible). It also doesn't seem like there's a way to query the tasks that are in progress (at least I couldn't find a way). So for now I'll just track my own tasks manually, and prevent submission at 5 tasks, but I'm wondering what would happen if another app had 2 tasks going, and then my user tries to submit 3 or something like that.

The documentation specifies that when Contacts framework returns unified contacts that each fetched unified contact object (CNContact) has its own unique identifier that’s different from any individual contact’s identifier in the set of linked contacts and that when refetching a unified contact, that this identifier should be used. There is also an analogous identifier within the list of contactRelations, but each of these don't seem to corespondent to the unified contacts. For example, is a new contact (Sheryl Zakroff) is created in the simulator Contacts and their spouse is set to Hank Zakroff. However, the GUID created for the contactRelations identifier does not correlate to the original Hank Zakroff GUID and cannot be searched. Is this a bug or what is the indent of the contactRelations identifier? Here's a debug output of walking the unifiedContacts: Name: Hank Zakroff 2E73EE73-C03F-4D5F-B1E8-44E85A70F170 - Other : (555) 766-4823 - Other : (707) 555-1854 Name: David Taylor E94CD15C-7964-4A9B-8AC4-10D7CFB791FD - Other : 555-610-6679 Name: Sheryl Zakroff DE783BC8-7917-4138-93F6-3AF0FD4CE083 - Other : (707) 555-1854 - Spouse: <CNContactRelation: 0x60000000dd60: name=Hank M. Zakroff> - 534B467D-CA00-46D3-897C-16EEA782C9CF - Looking for ["534B467D-CA00-46D3-897C-16EEA782C9CF"] []

WeatherService fails on every request with: WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" hourly forecast fetch failed: … Code=2 I've verified the entire setup and the error persists, which points to the App ID's WeatherKit token generation not being provisioned on Apple's backend: Team ID: 2LWCLD2636 Bundle ID: com.hoagiecorps.poppit WeatherKit capability and App Service both enabled on the App ID. com.apple.developer.weatherkit entitlement present in the signed binary and the embedded provisioning profile (verified via codesign -d --entitlements). A TestFlight build carrying the entitlement has been processed (VALID). Location authorized (When-In-Use); valid coordinates are obtained — the failure is purely the JWT auth step. Tried: device reboot, VPN off, iCloud Private Relay off, cycling the WeatherKit capability off/on plus regenerating the profile and clean rebuild, and waiting several days. Physical device, iOS 26. Could someone from the WeatherKit team please check the status for Team 2LWCLD2636, Bundle ID com.hoagiecorps.poppit, and enable WeatherKit token generation for this App ID? It looks like a backend entitlement sync is needed. Thanks!

Does anyone have info about the Retention Messaging API. We've requested access to it, but there's no answer.

I have a SwiftData + CloudKit app that is deployed to the Mac App Store. As a diagram my situation looks like: On my Mac, I have installed the App Store version of the App. When developing it I run the app via Xcode, so I can have a debug build running. The initial stable schema was deployed to CloudKit production before the App release. Now, when I change the SwiftData schema again and run the Debug app on my Mac What happens is that: The SwiftData local store is on the latest schema The CloudKit schema for development is automatically updated That’s all good, but if I run the App Store app version of my app. By default, it uses the same SwiftData store for both builds of the app, which are being synced to different CloudKit schemas for development and production at the same time. As a result, I get an unreliable state where I have seen data duplication as a result, or CloudKit syncing just breaks. Also, since I’m developing the app, the changes to the schema in development may not make it to production, so I don’t want to promote those changes to production. So my question: What’s the recommended way to evolve the schema for an app already on the App Store? I haven’t seen any example or session from Apple that tackles this -what I consider common- use case. I tried to have different CloudKit containers for a "Dev" and "Prod" builds, but that wasn’t the solution.

We are developing an IOUserSCSIParallelInterfaceController driver for a legacy controller. After completing init() successfully, no other methods are called before a DriverKit assert failure - .driver.dext) Assertion failed: (notsync || !remote || (msgid == IOService_Start_ID) || queue->OnQueue()), function Invoke, file uioserver.cpp, line 1654. - that leads immediately to "IOPCIDevice::ClientCrashed_Impl() for client " . This appears to be because the framework is attempting a SetPowerState()' during DEXT load, which is delivered off-queue and panics in OSMetaClassBase::Invoke (uioserver.cpp`) before any other dext method runs. Apple Silicon Mac, macOS 26 (DriverKit 25.1 SDK), Xcode 26.x. Expected: The SetPowerState() power-up is delivered on the driver object's dispatch queue (or otherwise handled by the framework), allowing the dext's SetPowerState override to run, ACK via super::SetPowerState(powerFlags, SUPERDISPATCH), and proceed to UserInitializeController. Actual behavior: init() completes (our trace logs init then completed init) Neither Start_Impl nor SetPowerState_Impl ever executes Instead the process fails with the assertion above , IOPCIDevice::ClientCrashed_Impl() reports "client … does not have open session … skipping recovery". The dext crash-loops ("Driver … has crashed N time(s)"). Any suggestions?

Hello, With Core Data, we can use the isConfiguration(withName:compatibleWithStoreMetadata:) method on an NSManagedObjectModel alongside metadata(for:) on NSPersistentStoreCoordinator to check if the on-disk store is up to date or not. Is this the way to do it too with SwiftData or do we have an easier way to check if the on-disk store will need to migrate? I want to inform my users in the UI when the app launches (or from widgets or app intents). Regards, Axel

Hi everyone, I was watching the "Code-along: Add persistence with SwiftData" session and noticed a strange architectural choice at the end. They track model side-effects directly inside a SwiftUI View's initializer like this: init(activity: Activity, isLast: Bool, isEditing: Bool) { activity.token = withContinuousObservation(options: .didSet) { event in // ... side effects here } } This feels like a significant architectural smell. SwiftUI views are transient structures with no guaranteed lifetime—they can be initialized dozens of times a second during standard layout passes. Furthermore, if multiple views display or interact with the same Activity, this tracking work gets duplicated redundantly. I understand this is a workaround because attaching a standard didSet directly to a stored property inside a @Model class doesn't trigger cleanly due to how the macro expands back-end storage. To keep this data-logic in the model layer where it belongs, I came up with an alternative that maps a custom computed property over a real stored attribute using. Here is the pattern: import SwiftUI import SwiftData @Model class Item { // 1. Persist the actual database column under an internal property name private var _title: String // 2. Expose a public computed property to intercept mutations var title: String { get { _title } set { // Updating the backing variable automatically fires the macro's observation hooks _title = newValue updatedAt = .now // Our derived side-effect! } } var updatedAt: Date init(title: String) { self._title = title self.updatedAt = .now } } Why I prefer this over the WWDC approach: Separation of Concerns: The model handles its own data dependencies (updatedAt), meaning the View layer remains purely declarative. Predictable Execution: The mutation logic runs exactly once per write, regardless of how many views are rendering or re-initializing around the object. No Manual Observation Setup: Because _title is a real, macro-backed attribute, SwiftData’s generated access and withMutation hooks are invoked naturally when the computed property reads or writes to it. We don't have to manually manage tokens or observation blocks. What do you all think? Are there any hidden gotchas to manipulating the schema mapping via originalName like this, or is this a vastly superior layout to WWDC's view-bound observation snippet? The downside is now the SQLIte column is _TITLE instead of TITLE. Is there any workaround for that? There doesn't seem to be @Attribute(columnName: "title")

I have one report from a customer, who migrated all data from his old MacBook to a new one. His is on Tahoe 26.5.1 (25F80). Here is my relevant code: + (BOOL)enableLoginItem:(BOOL)enable { NSOperatingSystemVersion osv = NSProcessInfo.processInfo.operatingSystemVersion; if (osv.majorVersion >= 13) { NSError* error; SMAppService* service = [SMAppService loginItemServiceWithIdentifier:MY_HELPER_APP_ID]; if (![service registerAndReturnError:&error] && error) @throw error; return YES; } return SMLoginItemSetEnabled((__bridge CFStringRef)MY_HELPER_APP_ID, enable); } What should I do to re-enable the login helper?

While attempting to read a user’s daily step history spanning backward to the last 7 days, a small but consistent subset of users encounter Error Code 3 with the underlying error description: Error Code 3 "Unable to invalidate interval: no data source available." When this error occurs, we are entirely unable to read their step history. We have received ~10 direct user reports of this within the last couple of weeks.

Hi! Sms reporting is no longer available in iOS beta 26 builds. I can set my app as the SMS/Call Reporting Extensions but the report button is missing for sms messages in the messages app. Xcode 26 beta 7 build the app without errors. This is a breaking change. Same extension was previously broken for calls but has been fixed in beta 7 build, as reported here. It is however still missing for sms messages in the messages app (beta 9 build).

I am continually prompted to sign into an apple account that I haven't used for years and was as far as I remember deleted. When I run a sysdiag and trawl the logs and text files it looks like a calendar issue. 06/08/26 22:41:57.218995 pid=96 handle_set_value: accountsd attempting to set [com.apple.mobile.data_sync]:[Calendars] to [{ AccountNames = ( Live, Hotmail, "hotmail.co.uk", "unusedappleid @ live.co.uk" ); Sources = ( iCloud ); I've raised a bug report for it but wondered if anyone else had encountered the issue.

We're working on in-app provisioning for wallet access passes. When testing the in-app provisioning on a sandbox account, I get an error saying software update required. Please advise.

I'm implementing payment processing with Apple Pay on the web, but I've been stuck right at the final step of the flow: decrypting the payment data sent by Apple. Here is a summary of my implementation: The backend language is Java. The frontend portal requests the session and performs the payment using the endpoints exposed by the backend. I created .p12 files from the .cer files returned by the Apple Developer portal for both certificates (Merchant Identity and Payment Processing) and I'm using them in my backend. The merchant validation works perfectly; the user is able to request a session and proceed to the payment sheet. However, when the frontend sends the encrypted token back to my sale endpoint, the problem begins. My code consistently fails when trying to decrypt the data (inside the paymentData node) throwing a javax.crypto.AEADBadTagException: Tag mismatch! I can confirm that the certificate used by Apple to encrypt the payment data is the correct one. The hash received from the PKPaymentToken (header.publicKeyHash) object exactly matches the hash generated manually on my side from my .p12 file. In the decryption process, I'm using Bouncy Castle only to calculate the Elliptic Curve (ECC) shared secret. For the final AES-GCM decryption, I am using Java's native provider since I already have the bytes of the shared secret calculated. (Originally, I was doing it entirely with BC, but it failed with the exact same error). We have exhaustively verified our cryptographic implementation: We successfully reconstruct the ephemeralPublicKey and compute the ECDH Shared Secret using our Payment Processing Certificate's private key (prime256v1). We perform the Key Derivation Function (KDF) using id-aes256-GCM, PartyU as Apple, and counter 00000001. For PartyV, we have tried calculating the SHA-256 hash of our exact Merchant ID string. We also extracted the exact ASN.1 hex payload from the certificate's extension OID 1.2.840.113635.100.6.32 and used it as PartyV. We have tried generating brand new CSRs and Processing Certificates via OpenSSL directly from the terminal. Despite having the correct ECDH shared secret (and confirming Apple used our public key via the hash), the AES tag validation always fails.et, the AES tag validation always fails. Given that the math seems correct and the public key hashes match, could there be an environment mismatch (Sandbox vs. Production) or a domain validation issue causing Apple to encrypt the payload with a dummy PartyV or scramble the data altogether? Any guidance on this behavior or the exact PartyV expected in this scenario would be highly appreciated.

I'm on a 16" MacBook Pro M4 Max w/ 36 GB RAM Apple Pay had been working with the beta releases with not issues, but after the macOS 26.6 beta update, Apple Pay was deactivated and is showing an error message: Apple Pay has been disabled because the security settings of this Mac were modified I found suggested fixes on the non-beta Apple forums (since this issue has apparently struck past release-versions of macOS), but none of them have worked. Does anyone here have any notions? Thanks!

Since the iOS 18 and Xcode 16, I've been getting some really strange SwiftData errors when passing @Model classes around. The error I'm seeing is the following: SwiftData/BackingData.swift:409: Fatal error: This model instance was destroyed by calling ModelContext.reset and is no longer usable. PersistentIdentifier(id: SwiftData.PersistentIdentifier.ID(url: x-coredata://34EE9059-A7B5-4484-96A0-D10786AC9FB0/TestApp/p2), implementation: SwiftData.PersistentIdentifierImplementation) The same issue also happens when I try to retrieve a model from the ModelContext using its PersistentIdentifier and try to do anything with it. I have no idea what could be causing this. I'm guessing this is just a bug in the iOS 18 Beta, since I couldn't find a single discussion about this on Google, I figured I'd mention it. if someone has a workaround or something, that would be much appreciated.

Native WeatherKit fails for our app on both development and TestFlight distribution builds, with the WeatherKit service enabled. Team ID: YCF2TGZAX8 Bundle ID: org.walktalkmeditate.pilgrim Call: try await WeatherKit.WeatherService.shared.weather(for: location, including: .current) Error (immediate, every call): Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" What we've verified: WeatherKit enabled under BOTH the Capabilities tab AND the App Services tab for this App ID. com.apple.developer.weatherkit entitlement confirmed in the signed binary (codesign -d --entitlements). Fails identically on (a) Xcode-direct development builds and (b) TestFlight distribution builds. Physical device (iPhone SE 3rd gen) signed into iCloud / an Apple Account. Survives app delete + reinstall AND a device reboot, on both build types. GPS/CoreLocation works fine; only WeatherKit auth fails. Not a timeout or rate-limit. First appeared on Xcode 26 beta; never resolved on stable Xcode 26.3 (17C529), iOS 18.x. This matches the pattern in threads 786126, 810137, 811225, and 789900, where the WeatherKit auth backend hasn't registered/synced the bundle ID for JWT issuance even with App Services on, and Apple resolves it server-side. Could someone check the backend WeatherKit registration for org.walktalkmeditate.pilgrim? Happy to provide a sysdiagnose. Will also file a Feedback report and add the FB number here.