Team-scoped keys introduce the ability to restrict your token authentication keys to either development or production environments. Topic-specific keys in addition to environment isolation allow you to associate each key with a specific Bundle ID streamlining key management. For detailed instructions on accessing these features, read our updated documentation on establishing a token-based connection to APNs.

Hello developers! Thank you for your dedication to creating apps with great performance. We’re excited to kick off another year of partnering with you on improving power and performance in your apps. At WWDC26, check out the following new things in the latest platform SDKs and Xcode 27 beta for performance. You can also join us online for a Power and Performance Group Lab on Tuesday, June 9 at 11 AM Pacific. Meet State Reporting and the new MetricKit State reporting: The new StateReporting framework lets your application express its state to downstream tools like Instruments and MetricKit. Make your telemetry and traces much more useful by adopting this simple API. MetricKit: In the 27 releases, the Swift-first MetricManager API replaces the MXMetricManager API. Combined with State Reporting, the new MetricKit provides more granular metrics to isolate performance problems faster. It also provides a more expressive API that is great to use in Swift, with improved Swift concurrency and Codable support. With this year’s releases, the MXMetricManager API is considered legacy. ▶️ To learn more, watch Meet the new MetricKit. Discover new features in Xcode organizer Metric goals: Xcode organizer now provides a goal metric for Battery Usage, Disk Writes, Hang Rate, Hitches, Memory, and Storage metrics, allowing you to prioritize performance engineering across more areas. Generate recommendations: Quickly resolve the highest impact performance issues in your app by using Generate Recommendations for Crash, Energy, Disk Write, Hang and Launch diagnostics. Insights overview: The new insights overview in Xcode organizer summarizes high-impact performance regressions for metrics and diagnostic reports, helping you plan and prioritize performance engineering work. Storage metrics: Storage metrics are now available in Xcode organizer, allowing you to monitor your app's Documents & Data and App Size across releases and catch regressions in cache usage and bundle size. Hitches metric: The new Hitches metric replaces the Scrolling metric in the organizer and now displays hitches for all animations in your app, giving you a comprehensive view of animation performance. ▶️ To learn more about other advancements in Xcode, watch What’s new in Xcode 27. Improve app responsiveness with Instruments Foundation Models: The Foundation Models instrument is redesigned with a tree view that lets you drill into individual requests, inspecting tool call arguments and results, inference prompts and responses, and token statistics. Use it to understand caching behavior, measure latency, and optimize throughput. System Trace: System calls, VM faults, and thread states are now unified into a single plot, with a new blending algorithm that stays readable even at high density. Once you spot something worth investigating, left/right key navigation lets you follow a thread's activity step by step, and the inspector provides quick actions like pinning the thread that made another thread runnable. System Trace now also draws thread priority and QoS over time, making it easier to identify priority inversions and unexpected QoS degradations that affect responsiveness. Swift Concurrency: New Main Actor and Global Concurrent Executor tracks let you visualize running tasks and executor queue depth over time, making it easier to spot task scheduling delays and actor contention. Tasks are now grouped into collections for faster navigation. Swift Tasks, Actors, and Executors instruments can now surface Call Trees, Flame Graphs, and Top Functions scoped to each entity — so you can pinpoint exactly where concurrency overhead lives. Top Functions: Helper functions and runtime internals can be expensive but hard to spot in a standard call tree. The new aggregation mode in Top Functions surfaces any function's total execution time across the entire call stack, making it easy to identify and prioritize hidden hotspots. Run Comparison: Compare call tree data across builds to identify regressions and performance wins. Results can be explored as an outline, flame graph, or top functions — choose whichever view best fits your workflow. ▶️ To learn more about profiling your app with Instruments, watch “Profile, fix, and verify: Improve app responsiveness with Instruments” ▶️ To learn about Foundation Models optimization, watch “Debug and profile agentic app experiences with Instruments”. If you have any questions about using State Reporting or the new MetricKit, create a post on the forums. For help creating a post, see Tips on writing a forum posts.

Hi, I see that with mac os 27 we have diskimagekit https://developer.apple.com/documentation/DiskImageKit the stacked disk image gives us the possibility of creating incremental snapshots which is wonderful addition to the virtualization framework. But is there a way to merge back stacked image to base image? Thanks & Regards

One thing I wanted to confirm, suppose i submit one request to onboard OHTTP relay for one organisation app and it gets approved, so can I re submit the request with different bundle ID for other organisation and same PIR server, same OHTTP server ? Or do we need different domain name ?

Hi, does SwiftData supports aggregate functions through NSExpression for operations like SUM, AVG, MIN, and MAX?

I created an App using PeerNetworking to connect two iOS-Devices without existing wifi-infrastructure. In general the solution works fine but when there are many other smart devices nearby connection gets unstable and breaks, devices have to be closer together or dont connect at all. In "Lab"-conditions everything works fine. What could I do to get the connection more stable and reliable?

I have a few products that want to integrate with the Wallet, but want to display very specific domain information. Since there isn't a 1:1 lab for wallet this year I'll vaguely post my feedback here. FB21642083 - Allow developers to add domain type cards to wallet and passes Happy to have further discussion in Feedback.

When entering the following command in macOS 27 beta: lvbojie@Mac ~ % netstat -I nan0 1 Name Mtu Network Address Ipkts Ierrs Opkts Oerrs Coll nan0* 1500 <Link#25> 66:31:00:4c:3c:b5 0 0 41 0 0 nan0* 1500 fe80::6431: fe80:19::6431:ff: 0 - 41 - - liushicong@Mac ~ % netstat -I nan0 1 The nan0 network interface is displayed. Does this indicate that macOS will support Wi-Fi Aware in the near future?

Overview I have a view B contains @Query for cars, now this @Query predicate depends on an input which is passed from view A. Current approach I am creating @Query in the init of view B by using _cars. Questions Now how can I compose @Query based on input from view A? Is my approach correct? In my approach Query will be created every time init gets called Or is there a better approach?

Previously, we used NSUserActivity to enable invoking specific in-app features from the Shortcuts app. This worked as expected up to iOS 17, but it no longer works on iOS 18 and later. We’ve confirmed that the same functionality can be achieved by using App Intents as an alternative. Question. Is the change in iOS 18—where NSUserActivity-based Shortcuts integration no longer works (or is restricted)—an intentional behavior change? If so, could you point us to any relevant documentation or release notes describing this change? We’ve tried to find information ourselves but haven’t found any clear references. Request. In cases like this where an OS update impacts existing implementations, it would be very helpful if such changes were clearly documented in release notes or API change logs in advance.

Hi folks! I’ve been paying attention to FSKit for moment to develop a network file system designed for source control-use cases (à la Eden or Google’s CITC). The design goal is support instant clones, even of massive repositories, by lazily fetching files as needed. Based on this thread, it seems like macOS 27 has added some of the requisite APIs needed to support inode invalidation for network/shared file systems like the cache coherency APIs. For example, I’m thinking that for this file system, I’d want to bypass the kernel’s own caching and have my file system be entirely responsible for it, as it‘d have a better understanding/picture of what is up-to-date and what isn’t and there won’t need to be multiple layers of cache invalidation/coherency. Am I correctly reading the intent of these new APIs?

Dear Apple Developer Support, I am developing and maintaining an iOS application. In iOS 26, we understand that setting UIDesignRequiresCompatibility to true in the Info.plist file allows an app to opt out of the Liquid Glass design. However, we also understand that during WWDC25 Platforms State of the Union, Apple stated: "We intend this option to be removed in the next major release." We would appreciate clarification on the following points. Questions Should the phrase "next major release" be interpreted as iOS 27? Is it currently Apple's plan to make UIDesignRequiresCompatibility unavailable or remove it in iOS 27? Or is the statement above only an intended direction, with the actual removal schedule still subject to change? If there is any publicly shareable information regarding the future availability or deprecation timeline of UIDesignRequiresCompatibility, could you please provide it? Background We develop and maintain a business application that contains a large number of custom screens and UI components. Adapting the entire application to the Liquid Glass design system will require significant design review, implementation effort, and testing. As a result, the future availability of UIDesignRequiresCompatibility is a critical factor in our development planning and resource allocation. For this reason, we would greatly appreciate any guidance you can provide regarding Apple's current plans for this compatibility option. Thank you for your time and assistance. Best regards, Toshiyuki

iCloud KeySyc is a privacy-focused feature that securely syncs a user’s personalized keyboard learning across all Apple devices through iCloud. Today, when users upgrade to a new iPhone or begin using a new iPad or Mac, the keyboard often loses much of the personalization it has developed over time. Users must re-teach autocorrect, rebuild custom vocabulary, and wait for the keyboard to relearn their typing habits. iCloud KeySync would allow users to move seamlessly between devices while keeping the keyboard experience familiar from day one. Problem Statement Apple’s keyboard becomes more useful over time as it learns: Frequently used words and phrases Personal slang and abbreviations Emoji preferences Autocorrect adjustments Writing patterns and typing habits When users switch devices, much of this personalization is lost or takes time to rebuild. This creates friction during device upgrades and reduces the feeling of continuity within the Apple ecosystem. Proposed Solution iCloud KeySync securely synchronizes keyboard personalization data across Apple devices. The feature would: Learn and store personalized keyboard behavior on-device. Encrypt and sync personalization data through iCloud. Restore keyboard preferences automatically when signing into a new device. Keep keyboard learning consistent across iPhone, iPad, and Mac. Key Features Personalized Vocabulary Sync Synchronizes user-added words, nicknames, slang, and frequently used phrases. Emoji Preference Sync Maintains commonly used emoji patterns across devices. Autocorrect Learning Sync Preserves learned corrections and accepted custom spellings. Typing Behavior Continuity Allows devices to share keyboard learning so users receive familiar suggestions regardless of which Apple device they use. User Controls Enable or disable iCloud KeySync. Reset keyboard learning at any time. View privacy information and storage usage. Privacy and Security Privacy should remain the foundation of the feature. All keyboard learning occurs on-device. Personalization data is end-to-end encrypted. Raw message content is never uploaded. Users retain full control over synchronization settings. Security protections match the standards used by iCloud Keychain. User Benefits New devices feel familiar immediately. Less time correcting autocorrect mistakes. Faster onboarding after device upgrades. Consistent typing experience across the Apple ecosystem. Improved customer satisfaction and retention. Example User Scenario A user upgrades from an older iPhone to a new iPhone. After signing into iCloud and restoring their device, the keyboard immediately recognizes their commonly used phrases, preferred emoji, custom words, and learned typing patterns. The new device feels personalized from the first message typed, without requiring weeks of retraining Business Value Improves the upgrade experience. Strengthens ecosystem continuity. Reinforces Apple’s privacy-first approach to AI and machine learning. Creates a subtle but meaningful quality-of-life improvement for millions of users. Switch phones. Keep your vibe.

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

I have a product that currently communicates to a piece of proprietary Medical hardware via USB. We have a driver created with USBDriverKit that is a hard requirement for this product to function. Currently, we are delivering an iPadOS application that utilizes the driver. Our next step is to create an SDK that includes all of the Frameworks and the driver utilized by the application. Since the driver is a system extension that lives in the application, how do we bundle it with our SDK and make it available for use by third-parties?

Dear Screen Time Team! The current 6 MB memory limit for the DeviceActivityMonitor extension no longer reflects the reality of modern iOS devices or the complexity of apps built on top of the Screen Time framework. When Screen Time APIs were introduced with iOS 15, hardware constraints were very different. Since then, iPhone performance and available RAM have increased significantly…but the extension memory limit has remained unchanged. My name is Frederik Riedel, and I’m the developer of the screen time app “one sec.” Our app relies heavily on FamilyControls, ManagedSettings, and DeviceActivity to provide real-time interventions that help users reduce social media usage. In practice, the 6 MB limit has become a critical bottleneck: The DeviceActivityMonitor extension frequently crashes due to memory pressure, often unpredictably. Even highly optimized implementations struggle to stay within this constraint when using Swift and multiple ManagedSettings stores. The limit makes it disproportionately difficult to build stable, maintainable, and scalable architectures on top of these frameworks. This is not just an edge case…it directly impacts reliability in production apps that depend on Screen Time APIs for core functionality. Modern system integrations like Screen Time are incredibly powerful, but they also require a reasonable amount of memory headroom to function reliably. The current limit forces developers into fragile workarounds and undermines the robustness of apps that aim to improve users’ digital wellbeing. We would greatly appreciate if you could revisit and update this restriction to better align with today’s device capabilities and developer needs. Thank you for your continued work on Screen Time and for supporting developers building meaningful experiences on top of it. Feedback: FB22279215 Best regards, Frederik Riedel (one sec app)

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?

I am implementing device authentication for a macOS app. Our iOS app uses App Attest, but App Attest is not available on macOS, so we are evaluating StoreKit's AppTransaction plus AppStore.deviceVerificationID as the macOS equivalent signal. The issue: in a macOS app installed through TestFlight, AppStore.deviceVerificationID is available, but AppTransaction.shared throws StoreKitError code=2. I reproduced this in a focused standalone macOS test app with no backend and no custom dependencies. Environment: Platform: macOS Distribution: TestFlight App Store Connect app ID: 6769568350 Bundle ID: com.soundcity.AppTransactionProbe App version: 1.0 Build: 1 Observed output from the TestFlight-installed app: Bundle ID: com.soundcity.AppTransactionProbe App version: 1.0 Build: 1 deviceVerificationID available: true deviceVerificationID prefix: CA91ED5D... AppTransaction.shared threw error: StoreKitError; domain=StoreKit.StoreKitError; code=2 The relevant code path is essentially: import StoreKit let deviceVerificationID = try? AppStore.deviceVerificationID let appTransaction = try await AppTransaction.shared In the TestFlight-installed build: AppStore.deviceVerificationID succeeds. AppTransaction.shared throws StoreKitError code=2. Questions: Is AppTransaction.shared expected to work for macOS apps distributed through TestFlight? If yes, what does StoreKitError code=2 indicate in this context, and what setup might be missing? If no, is there an Apple-supported way to obtain an AppTransaction JWS, or equivalent signed App Store/TestFlight app-install assertion, for macOS TestFlight builds? For macOS apps that need a device-bound trust signal comparable to iOS App Attest, is AppStore.deviceVerificationID intended to be used without AppTransaction.shared, or should these APIs be used together? I have a focused Xcode test project that demonstrates the issue and can share it if helpful.

I guess this is in parts a multiplatform / SwiftData / WidgetKit and SwiftUI question. my usual problem is I start an app and then quickly find myself wanting to add widgets / controls / AppIntents and expand across multiple targets. for example I start with an iOS only target and expand to watchOS, iPadOS and visionOS. But since this targets and the apps I want to build are very distinct, I don’t find myself using the multiplatform target but instead a target per platform. This (at least from my understanding) then also comes with the benefit that I can add a WidgetKit extension and all targets use it. now this is the base idea, but here come the many questions I have had issues finding a clear answer and guidance on over the last years. When sharing SwiftUI views and business logic for DRY, whats the actual best way to do that? A „core“ swift package, or a library? what are the implications of choosing one over the other? I understand that widgets are separately scoped and sandboxed from my main app, but since I use SwiftData in the main app I‘ll have to use app groups so that both can have the same data store. Now; using query in widgets is no problem and is intuitive enough, but the ModelContext has to come from somewhere and be initialized somewhere Where? + additionally, talking about appintents for example when having a control or interactive widget, they also need to share the same context to have an immediate response and update all accordingly (so app, widgets and intents all need to have the same) but how do I actually do that when everything is sandboxed? I recently discovered the @Dependecy macro in I think it was an app intents talk, but it’s usage was skipped over and I couldn’t find documentation explaining what I need to do here to get this actually working. i think the two above are my main questions and I hope I could give enough context to see where I fall short of understanding the architects involved. so for big multiplatform apps where I want to adopt as many system features as possible what’s the best „separation“ or project structure here? see, for example the default Apple Notes app would really interest me how they handle it, or Journal for that matter, since it targets so many platforms and has native features, how is the project structured at the top level? (Obv just an example of what scope I am looking for here) sample code often falls short of what I need, or maybe then again I haven’t found the right one yet. thanks for reading to this point and I am grateful every input, perspective and suggestion I can get here, since it will apply to all my projects

Regarding significant locations, how long does it take for an iOS device to learn locations? We've done some testing and when we turned on stolen device protection and try to turn it off, it activated the security delay with significant locations on.

With the recent introduction of the unified asset pipeline and Icon Composer, managing cross-platform icon designs has become incredibly efficient. However, there is still a significant platform disparity when it comes to maintaining visual consistency and brand uniformity across paired devices. On iOS, we can dynamically change the app icon at runtime using the setAlternateIconName API. Currently, watchOS completely lacks an equivalent mechanism. If a user selects an alternative icon inside an iOS companion app, the paired Apple Watch app icon remains locked to the default primary asset. This creates a disjointed experience and directly impacts user recognition. The watchOS home screen relies entirely on instant visual cues. If a user changes their iPhone icon to a custom colorway, they instinctively look for that same colorway on their wrist. Leaving the watch icon unchanged makes it harder to quickly locate the app. I have submitted an enhancement request via Feedback Assistant to bring alternate app icon support to watchOS, ideally through an automatic system-level sync within the unified .icon pipeline, or via a native watchOS runtime API. If your app utilizes alternate icons and you would like to see this cross-device continuity brought to watchOS, please consider filing your own duplicate request to help bring visibility to this gap. Filed Feedback: FB23080617

When attached app to debugger with real device, the OS seems to kill the app if the Callkit interface isn't emitted by the app at background within 5s. Do you have any tip in debugging?