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)

App Store Connect returns the following message when the NSExtensionPointIdentifier key in the Info.plist of a Device Activity Monitor extension contains an invalid value: ITMS-90349: Invalid Info.plist value - The value of the NSExtensionPointIdentifier key, <value>, in the Info.plist of ".../PlugIns/...appex" is invalid. To resolve this issue, set NSExtensionPointIdentifier to com.apple.deviceactivity.monitor-extension. The expected Info.plist structure for a Device Activity Monitor extension is: <plist version="1.0"> <dict> <key>NSExtension</key> <dict> <key>NSExtensionPointIdentifier</key> <string>com.apple.deviceactivity.monitor-extension</string> <key>NSExtensionPrincipalClass</key> <string>$(PRODUCT_MODULE_NAME).DeviceActivityMonitorExtension</string> </dict> </dict> </plist> After you apply this fix, build and archive your app, then re-upload to App Store Connect to confirm the error is resolved.

Hello, I have an app for a research study that has been approved and authorized to use SensorKit. All my permissions, entitlements and authorizations are in order, but I still can't get any data. The didFetchResult is not being called even though didCompleteFetch is called. I have waited for over 24 hours, but it still returns no samples. Please, I would appreciate any help on this issue. Thank you func sensorReader( _ reader: SRSensorReader, fetchingRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject> ) { receivedResultsInCurrentFetch = true print("✅ SensorKit fetch result received for: \(sensorKey)") AppLogger.shared.log("SensorKit fetch result received for \(sensorKey)") if let sample = result.sample as? T { print("✅ SensorKit sample matched expected type for \(sensorKey): \(T.self)") AppLogger.shared.log("SensorKit sample matched expected type for \(sensorKey): \(T.self)") processSample(sample) } else { print("❌ SensorKit sample did not match expected type for \(sensorKey): \(T.self)") AppLogger.shared.log("SensorKit sample did not match expected type for \(sensorKey): \(T.self)") } } func sensorReader(_ reader: SRSensorReader, didCompleteFetch request: SRFetchRequest) { if receivedResultsInCurrentFetch, let lastRequestedUpperBound { session.setSensorKitLastFetchTime(lastRequestedUpperBound, for: sensorKey) print("✅ SensorKit fetch completed with samples for \(sensorKey). Checkpoint updated.") } else { print("⚠️ SensorKit fetch completed for \(sensorKey) with no samples.") AppLogger.shared.log("SensorKit fetch completed for \(sensorKey) with no samples. Keeping previous checkpoint so delayed SensorKit data is not skipped.") } isFetchInFlight = false completePendingFetches(success: true) print("✅ SensorKit fetch completed for: \(sensorKey)") AppLogger.shared.log("Fetch request completed for sensor type: \(T.self)") }

We tried to fetch the recorded PPG data using SensorKit with the following code, however the didFetchResult callback method is never called. let ppgReader = SRSensorReader(sensor: .photoplethysmogram) let request = SRFetchRequest() let nowDate = Date() let toDate = nowDate.addingTimeInterval(-25 * 60 * 60) let fromDate = toDate.addingTimeInterval(-24 * 60 * 60) request.from = SRAbsoluteTime.fromCFAbsoluteTime(_cf: fromDate.timeIntervalSinceReferenceDate) request.to = SRAbsoluteTime.fromCFAbsoluteTime(_cf: toDate.timeIntervalSinceReferenceDate) ppgReader.delegate = self; ppgReader.fetch(request) The delegate called the didComplete successfully: func sensorReader(_ reader: SRSensorReader, didCompleteFetch fetchRequest: SRFetchRequest) But never called the didFetchResult func sensorReader(_ reader: SRSensorReader, fetching fetchRequest: SRFetchRequest, didFetchResult result: SRFetchResult<AnyObject>) -> Bool Any ideas why ? (I am wearing the watch for couple days and ensure it has the data for the time period I am querying) One thing I notice is when Apple granted us the entitlement, it uses Uppercase for ECG and PPG, however the document use Lowercases in the plist https://developer.apple.com/documentation/sensorkit/srsensor/photoplethysmogram Dose it matter ?

Hello, We are currently evaluating ways to reduce the app size of the my App. The app contains approximately 200~250 MB of bundled static resources, and we are considering converting these resources into On-Demand Resources（ODR） in order to reduce the initial download and installation size of the app. However, we noticed that ODR is currently marked by Apple as a Legacy Technology. Since we would like these resources to continue being hosted and distributed through Apple CDN / App Store infrastructure, the first alternative we considered is Managed Background Assets, rather than regular Background Assets. We understand that regular Background Assets are available on iOS 16 and later, but they mainly address background download scheduling for apps. What we are specifically looking for is the resource hosting and distribution capability, similar to ODR, where assets can be hosted and delivered through Apple’s infrastructure. This is why we are considering Managed Background Assets. However, my App currently supports devices starting from iOS 14, while the key capabilities of Managed Background Assets require newer iOS versions. As a result, this solution cannot fully cover users who are still on older iOS versions, such as iOS 14 through iOS 18. Given this background, we would like to ask Apple the following questions: Does Apple have any plan to discontinue ODR-related services in the future, especially the App Store-hosted ODR asset download service? If the ODR service is changed or discontinued in the future, would it affect already released App Store apps that rely on ODR asset downloads on older iOS versions? For apps that still need to support iOS 14 and later, while also relying on Apple CDN / App Store infrastructure for resource hosting and distribution, does Apple still recommend using ODR? For apps that cannot immediately raise their minimum supported iOS version to the version required by Managed Background Assets, is there a recommended transition strategy? If ODR services are discontinued in the future, will Apple provide an alternative resource distribution solution that supports older iOS versions, or would developers need to build and maintain their own resource hosting and download system? We would like to better understand the long-term availability and potential risks of using ODR on older iOS versions, so that we can make an appropriate decision for future app size reduction and asset delivery in the App. Thank you.

I typically avoid NSMetadataQuery because I always found the API to be a bit peculiar but for this feature I'm working on I'm not sure it is worth the effort to implement this functionality in my own way. Plus it seems pretty fast. What I find strange is I set the operationQueue to get notifications off the main thread. But also when I set the queue the system yells at me anytime I make a change to NSMetadataQuery that alters the query. So I found this recommendation (requirement) in the documentation : NSMetadataQuery *query = // Initialize and set up a query [query.operationQueue addOperationWithBlock:^{ [query startQuery]; }]; I find this API design to be odd, but maybe I'm just weird. So there are a bunch of properties that can be changed while the query is already running (predicate etc.) and they implicitly stop/start the query and it seems all these calls need to be routed through the query.operationQueue like above? For example if I change the predicate while the query is already started it seems I have to: [query.operationQueue addOperationWithBlock:^{ query.predicate = predicate; }]; The query already knows its operationQueue. Why does the caller have to plumb these calls through the operation queue manually? -stopQuery does not result in an error/warning when called off the operationQueue but is doing so safe? Or do I have to do: [query.operationQueue addOperationWithBlock:^{ [query stopQuery]; }]; Really what I was expecting was to provide a queue for the notification callbacks. I wasn't expecting to manually have to confine the query to its own queue.

I just updated my testing device OS to iOS 26.5 and was trying to validate if our sdk is working fine or not and we found Call blocking is not at working for this update. I already seen some of the post regarding call blocking will not work if call to the expected block number is initiated from testing device. So just to clarify that is not the case in our findings.