On the new iOS 27 Beta, after updating- the Transactions messages are moved to trash and cannot be recovered

I wrote a python script called MXSymbolicate (https://github.com/OliveTreeBible/MXSymbolicate) to symbolicate the crash reports produced by the old version of MetricKit. The new MetricKit in the '27 releases appears to be basically the same data but in type-safe form, with the addition of state tracking. Notably, the new CrashReportExtension API seems to include the ability to symbolicate a crash stack on-device, but it looks like the CallStackTree type is still just binary names and frame offsets and such - no symbol names. Should I keep symbolicating crash reports from the new MetricKit APIs the same way I did the old ones? Or is the expectation that I should use the CrashReportExtension system for symbolicated crashes, and use the MetricKit crash reports for other purposes, like state tracking?

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

I am writing a QuickLook extension using Swift (specifically QLPreviewingController). Extensions can be opened from both the previewer (pressing Space with a file selected) and Get Info. How do I reliably detect which mode my extension is being started from? The problem is that when it's in the Get Info window, it forces a fixed width (but not height). If I set the size statically based on that width, then when it launches in its own window (via Space), you can't resize the preview window. What am I missing? It seems like I should be getting more context about where I'm being inserted so I can lay out accordingly? Does anyone have any suggestions or have faced this problem before?

Hi! I'm using AccessorySetupKit with CoreBluetooth state restoration. My understanding is that using AccessorySetupKit is a now pre-requisite to enabling the state restoration/preservation apis, so I went that route — and pairing, handoff, and restoration on search discovery or connection completion seem to be working Where I'm stuck: my accessory is poll-based. I read it by writing a request and reading the response. Then I send a new request. the BLE accessory never pushes data on its own. Since restoration only seems to wake my app on an inbound BLE event, if the app gets terminated mid-session while the connection's still healthy, nothing wakes the app and polling just quietly stops. Is there a recommended way to handle this for a request/response device? Thanks!

Hi there, we deploy upwards of 12-15 accessories (containing BLE) at a time, in a single system instal. Can AccessorySetupKit be used to streamline the pairing process for all of these accessories at once, so that the user isn't required to step through the process for each individual accessory?

Hi there, we deploy upwards of 12-15 hardware accessories containing BLE at a time, in a single system instal. Can AccessorySetupKit be used to streamline the pairing process for all of these accessories at once, so that the user isn't required to step through the process of pairing with each individual accessory?

I forget which extension type it is, but there is one that can discover the devices in a sandbox. Xcode 26 shows me Media Device Discovery, Xcode 27 doesn't. It could be a different one. Which ever one it is, do you know off hand if the new StateReporting framework would report performance and usage privately to MetricKit? I know that some frameworks report data to Apple's analytics reports, I'd potentially want to capture some performance metrics and app state changes that are happening in supporting extensions.

Hello, Currently we have the sample project from WWDC2024 as an example on how to do it as a live example but only as a simulated project on the Accessory end. The example is good but being implemented a rich platform like iOS or iPadOS, the rich stack of APIs are provided. Embedded devices such as the ESP32/RaspberryPI do not have this rich API stack, such as CoreBluetooth and so on, so a mirror stack of API/functions must be implemented to give the equal experience. Are there any examples or design/technical guidelines for the Accessory end to implement AccessorySetupKit on embedded devices. (Like a list of technical requirements or checklist of functions/implementations/services we can go through on a ESP32/RapberryPI) to ensure that the Accessory has all the needed code/technical implementations with AccessorySetupKit for both Bluetooth and WiFi support, especially on the Bluetooth end. Best to have an ESP32 project, implemented in Embedded Swift but at least a checklist (of items/situations/error handling) to confirm that it works.

Like in the case that two products are advertising with the same company identifier, both matching a single display item passed in when displaying the accessory picker. Would it be expected for two items to show in the accessory picker, one for each advertising product?

What would you recommend to teams that want to act as both a central and peripheral role? I want to use the ASK permission model for Central mode, but doing so I can't build connections to Apple Watch and Apple Vision Pro that don't support peripheral mode forcing the iPhone to do that.

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 am seeing a reproducible App Switcher rendering artifact with ManagedSettingsUI shield customization. When a Screen Time shield is customized with ShieldConfiguration.backgroundColor, the shield appears with an uncropped rectangular background layer in the iOS App Switcher. Square corners become visible around the shield card/background layer. This disappears when backgroundColor is nil, and reappears as soon as any UIColor is provided. I also observed the same behavior in another Screen Time app that customizes its shield background, so this does not appear to be specific to my app. Minimal repro: Create an iOS app using FamilyControls, ManagedSettings, and ManagedSettingsUI. Add a ShieldConfigurationDataSource extension. Return a ShieldConfiguration with backgroundColor set to any UIColor. Shield an app and open the shielded app. Open the iOS App Switcher. Example: return ShieldConfiguration( backgroundBlurStyle: .regular, backgroundColor: UIColor(red: 246/255, green: 238/255, blue: 227/255, alpha: 1) ) Expected: The shield background should be clipped consistently with the App Switcher card/screen corner mask. Actual: The shield background appears as a full rectangular layer in the App Switcher, exposing square corners. Control tests: backgroundColor = nil: no square-corner artifact. backgroundColor = UIColor(...): square-corner artifact appears. The issue occurs regardless of backgroundBlurStyle, including nil, .regular, and .systemUltraThinMaterialLight. I filed this through Feedback Assistant as well. Has anyone found a workaround that still allows a custom shield background color?

We're trying to implement proper age range verification in our app. However, one of my colleagues while testing AgeRangeService.shared.requestAgeRange got strange results and got stuck in this state. I wonder if this is a known bug and how can we deal with it. How many people may be affected? When he changed his birth date to be 17 years old the AgeRangeService.shared.requestAgeRange returned age range 13-15. When he changed back to his original birth date (1994) he still gets 13-15. He tried uninstalling the app, rebooting the system, nothing works. One thing that is different for his account than e.g. mine is that he's ageRangeDeclaration says .confirmed while mine is .selfDeclared. I read in the docs that "The system may override your age gates based on the local regulations of the person’s geographic location." but why on Earth would it think he's underage if he has this account for a really long time and is 30+?

am seeing a persistent WeatherKit JWT generation failure with: WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 I already reviewed the related forum discussion where DTS noted that the WeatherKit App Service must be enabled separately from the WeatherKit capability on the App ID. I have confirmed that both are enabled. Confirmed configuration Team ID: FYGW4LHN42 Diagnostic app bundle ID: com.elilindenDinematch.AppleServiceDiagnostics Device: physical iPhone iOS version: 26.5 App version: 1.0 (1) I created a fresh diagnostic app specifically to isolate this from my main app. The issue reproduces in the clean diagnostic app. I have confirmed: WeatherKit is checked under the App ID capabilities. WeatherKit is enabled under Certificates, Identifiers & Profiles → Services. The Services page shows WeatherKit with “Manage your WeatherKit usage,” a “View” button, and “100% of calls available.” A fresh provisioning profile was generated. The embedded provisioning profile is present in the app. The embedded provisioning profile includes WeatherKit. The app is running on a physical iPhone, not only the simulator. Location services are enabled and authorized. The diagnostic app logs show the provisioning profile is found and includes WeatherKit: profile=FOUND appID=FYGW4LHN42.com.elilindenDinematch.AppleServiceDiagnostics team=FYGW4LHN42 WeatherKit=YES Location authorization also looks valid: servicesEnabled=true authorization=authorizedWhenInUse accuracy=fullAccuracy Failure When the app calls WeatherKit, JWT generation fails: Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" Then WeatherKit fails with: WeatherKit error[0] domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors code=2 description=The operation couldn’t be completed. (WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors error 2.) Relevant excerpt: AppleDiag 2026-06-08T20:20:17.448Z App bundle=com.elilindenDinematch.AppleServiceDiagnostics version=1.0(1) AppleDiag 2026-06-08T20:20:17.448Z Device iOS=26.5 model=iPhone name=iPhone AppleDiag 2026-06-08T20:20:17.455Z PROFILE profile=FOUND name=iOS Team Provisioning Profile: com.elilindenDinematch.AppleServiceDiagnostics uuid=f42899e3-029a-4e85-b6ac-0aa515fc0028 appID=FYGW4LHN42.com.elilindenDinematch.AppleServiceDiagnostics team=FYGW4LHN42 WeatherKit=YES AppleDiag 2026-06-08T20:20:31.882Z BEGIN WeatherKit AppleDiag 2026-06-08T20:20:31.884Z WEATHERKIT start lat=40.7128 lon=-74.006 Failed to generate jwt token for: com.apple.weatherkit.authservice with error: Error Domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 "(null)" AppleDiag 2026-06-08T20:20:34.652Z WEATHERKIT failed elapsedMs=2764 AppleDiag 2026-06-08T20:20:34.655Z WeatherKit error[0] domain=WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors code=2 description=The operation couldn’t be completed. (WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors error 2.) AppleDiag 2026-06-08T20:20:34.655Z WeatherKit error[0] userInfo=empty Because this happens in a clean diagnostic app, with WeatherKit enabled both on the App ID and under Services, and with the embedded provisioning profile confirming WeatherKit=YES, this does not appear to be an app-specific code issue or a missing App ID capability issue. Has anyone else seen WDSJWTAuthenticatorServiceListener.Errors Code=2 after confirming both the WeatherKit App ID capability and the separate WeatherKit App Service are enabled? Could someone from Apple/DTS check whether WeatherKit JWT minting is correctly enabled on the backend for Team ID FYGW4LHN42 and bundle ID com.elilindenDinematch.AppleServiceDiagnostics?

The Implementing age assurance and permissions sample code is available for download. The sample demonstrates how to create a significant change flow to inform people about important updates in your app and request age-related permissions. It supports iOS 26.5 or later.

Environment: iOS 18.7.8, CallKit + PushKit VoIP. On VoIP push we call reportNewIncomingCall and show the system CallKit UI. Goal: When the user declines from the CallKit UI, send a single HTTPS POST to our backend in realtime, across all app states. Problem: Foreground and backgrounded states work. When the app is terminated (system-evicted or user-force-quit), the push launches the app, CallKit shows, and we receive CXEndCallAction — but the network request doesn't reliably leave the device. The process is suspended/terminated moments after the action returns. Tried: URLSession.shared dataTask inside CXEndCallAction — frozen with the app; resumes only on next foreground launch. beginBackgroundTask(withName:) around the request — insufficient when terminated. Background URLSession (.background, isDiscretionary = false, sessionSendsLaunchEvents = true, uploadTask(fromFile:), body staged in Caches, held briefly with a task assertion). Reliable when backgrounded; still unreliable/delayed when terminated, especially after force-quit. Questions: Is reliable, near-realtime client network delivery from a terminated, PushKit-launched app possible, or is this an inherent platform constraint? If it's a constraint, is the recommended pattern to treat the decline as best-effort and make the server authoritative (e.g., ring timeout)? Any official references? Does force-quit vs. system termination change background-execution / background-URLSession guarantees, and is there a supported approach for force-quit specifically? Any API we missed (e.g., a sanctioned way to extend runtime during CXEndCallAction, or background-URLSession scheduling guarantees for VoIP) that makes this realtime-reliable?

Hi, I’m building an iOS app that uses FamilyControls to let users block distracting apps during study sessions. Everything works fine in Debug on a real device: the authorization request succeeds and app blocking works correctly. The problem is when I try to create an Archive for App Store Connect. Xcode gives me this error: “Provisioning profile ‘iOS Team Store Provisioning Profile: com.(ID)’ doesn’t include the com.apple.developer.family-controls entitlement.” I also get a warning saying that my bundle identifier is using the development-only version of the Family Controls capability and that I should request access to the distribution version. I’ve already added the Family Controls capability, enabled the required entitlements, and I’m using automatic signing. I also tried enabling the capability for my App ID in the Apple Developer portal, but it either doesn’t save or the distribution profile still doesn’t include the entitlement. Does the Family Controls distribution entitlement require approval from Apple before it can be used in an App Store build? If so, where do I request it? Has anyone successfully published an app using FamilyControls and run into this issue? Thanks.

Hello, I am the developer of Kiddowall, a B2C parental control app for iOS. I submitted a request for the com.apple.developer.family-controls entitlement on June 2, 2026 (support case #102905280650), and also followed up via an existing case #102905007339. Apple support indicated a 48-hour (2 business days) response time when the case was created. We are now past that window with no update on entitlement status. Request details: Team ID: 5499VUQ6PC Bundle ID: com.kiddowall.child App Bundle ID (parent): com.kiddowall.parent — Kiddowall — Parental Control (BDC, France) Entitlement requested: com.apple.developer.family-controls Support case: #102905280650 Current status: Submitted (no update in 4 days) Context: Kiddowall is a B2C parental control application for French families. Without the FamilyControls entitlement, we cannot implement proper on-device content filtering or screen time management without requiring MDM supervision — which is not viable for a consumer app (it requires factory reset via Apple Configurator 2 or ABM/DEP enrollment). FamilyControls is the only Apple-approved path to build a real parental control app for B2C without supervision. We are committed to full compliance with Screen Time API guidelines. Can anyone from Apple staff confirm the status of case #102905280650, or advise on next steps to expedite this request? Thank you. — Franck MAUDET (Kiddowall)