Many apps are distributed on the public App Store. Those same apps can also be installed on company managed devices. While user enrolled devices will likely or certainly have an Apple Account on there, that is not the case for supervised devices. The company that manages the device might prohibit the use of Apple Accounts. I'd like to see a capability where the MDM can provision the device with an assurance of an age being met. In the majority of practical purposes, users enrolling devices into an MDM are likely employees due to the nature of MDM. Same for users of supervised devices. An API that lets the MDM tell the app that even though the API returns unavailable (or some new enum), that its okay to proceed because the business is assuming the risk of the age being met to consume some app. I have a feedback I wrote up last December for this FB21340165 Another idea I've played around with would be to have a fail proof way for developers to detect if the app is MDM installed, just on the regular, not related to DeclaredAgeRange API. One could look for managed app configuration via the legacy UserDefaults mechanism, or the new ManagedApp framework--but there is no guarantee that the MDM administrator is actually going to use that feature. If you're deploying an app to your company devices and employee enrolled devices, you can implement app config with a signal to the app, but for B2B apps and other businesses there is no assurance. To be clear, I'm not asking for interpretation of the regional laws as I know the FAQ page directs developers to our internal legal reps, I just want to know how to best use the DeclaredAgeRange API in the context of an MDM deployment.

Unlike almost all other system TCC prompts, the DeclaredAgeRange does not have an API to detect the current status. This makes it hard to determine when it is appropriate to show a permission flow that explains what the app does with the information. I do the workflow during onboarding, and when app features are being accessed. I would like to not just 'pop up' if the user completed onboarding on iOS 18, and then upgraded to 26 (or 27). FB21157742

The DeclaredAgeRange framework's 'actions' are not sendable. This means when the app is in swift 6 mode, the sample code provided in the documentation won't even compile due to the thread isolation. Is there any reason why the action closure in the environment can't be sendable? Otherwise @preconcurrency import for me. FB20959748

I have use cases where I want to specifically query against postal address and other properties that existed on CLPlacemark. With the new address type those are not exposed there. It might be contained in the text, so general string token searching is fine, but my data model saves postal code as an individually queryable component in my Swift Data model. FB16064707 FB20007974 FB20008112

I'd like to know if there is any way for an app to deep link the user to their Apple Account --> Personal Information --> Age Range for Apps screen within settings. I don't have a feedback for this (yet). The idea is simple. If a user denies sharing permission, but the app developer makes the decision to use the API to enforce their own apps terms (i.e. 16+, 18+, etc.) one would throw up a non-dismissible screen and the user is stuck. The best I have come up with is to link to Apple's support page on the Age Range for Apps feature. However, this isn't an ideal user experience and leaves a lot for the user to do. If they really want to use they can change their mind and I want to help reduce that friction. Why does this matter? From my 'non-legal' research and experimentation with this API, I have decided the easiest thing is to just check the age in all regions--use it for checking and evaluating against your apps terms of use. For example, I have a brewery app, while it won't check 21+ through the API, certainly the app is not meant to be used by minors. Aside from a few rough edges in the API, the framework is overall really well thought out. Most people I talk with about this haven't even heard of the new Apple Account setting, and the ones that think they can find it go to privacy and security in the Settings app.

There have been a lot of changes to the DeclaredAgeRange and PermissionKit APIs. I get it, things have to change to align with evolving regional requirements. I was surprised to not see a talk this summer about the frameworks and the new APIs, nor updated sample code. Is this something that can be done? Developers have to juggle a lot of availability checks. It would be great to have a very clear table that describes if OS version this, then API that should be used.

The new MetricKit and StateReporting APIs look great. The names of the Swift-first API conflicts with a lot of what I’ve written to do custom decoding (CrashDiagnostic —> MetricKit.CrashDiagnsotic and MetricKitModels.CrashDiagnostic). Job well done. Very clean API and reminds me of enum cases generated from Swift OpenAPI Generator, good stuff. Since there were no 1:1 labs this year for power and performance, I thought I’d send over my feedback for open discussion on the forums. This post is mostly centered around documentation and clarification. FB23019810 - Multiple metric and diagnostic pipeline design. What is the recommended implementation if I have two destinations that want the exact same domain scope. Two managers? A single manager with multiple async streams? Some API like HealthKit recommend a single HKHealthStore, is there any downside to creating many managers, or conversely, creating many async streams for metrics and diagnostics? FB23019316 - The new sample code shows mxSignpost. Is there any reason why we should not be using OSSignposter backed with a MetricKit OSLog handle? The API is more expressive and can handle wrapping closures P.S. see FB22413384 to hopefully enhance OSSignposter with an async func variant FB23020182 - MetricKit deprecations seem off and availability of the new API is missing from macOS and visionOS too. Can you clarify what the docs should show for deprecation? Can you clarify what the docs should show for availability of the new API? FB23051890 - Regarding StateReporting, I understand there is a sanity limit for how one would slice up the metrics per the video commentary. Too many dimensions the data becomes hard to associate with actual improvements to be made. Is there a limit developers should stay clear of? When using the StateReporting API, what are the practical limits to the number of domains and metadata key/value pairs we can have? FB23051980 - I’m excited and ready to implement StateReporting, in all the places. Is it supported in extensions? Will the resulting state changes be included in MetricReport? Last I asked, MXMetricPayload didn’t capture extension data. Will the resulting state changes be included in DiagnosticReport? I do see MXDiagnosticPayload come through containing extension data, so hopefully yes. FB23051678 - I didn’t catch any session or documentation material about the usage around the volatile metadata in the StateReporting API. The docs state it is a fatalError to change the domain and stable metadata keys, that makes sense if that is how the composite key for uniqueness is being created. By the name volatile I assume it can, well change. What is the usage of the volatile metadata? What limitations exist around it if any? The ReportedState API doesn’t have any properties for volatile, is it meant to be received in reports? FB23051738 - There isn’t a StateReporting area path in Feedback Assistant. For now sending feedbacks to MetricKit team, but it is a different framework. I assume other new frameworks are also missing I haven’t confirmed yet. FB13904761, FB13819435, FB13221143, FB22362800 - I have a handful of feedbacks that were reporting anomalous data with payloads. The routine with most bug feedbacks is to capture a sysdiagnose. Any tips on doing that when the reports are coming in from the field or not being actively monitored on dev and test devices? I know this is unlikely to happen but putting it out there FB9931474 - MetricKit: Add API to trigger sysdiagnose programmatically FB23047674 - Add docs for StateReporting and the Xcode simulate MetricKit menu. What domains should be added to the managers to populate data in the simulated reports? FB23020088 - I dig the new memory diagnostic, I’m hoping to close out this feedback that requested it FB9972410. Based on the language in the session, I am leaning towards it is only for memory limit, not jetsam memory pressure. Can you clarify in the documentation which memory exits it is for? Thanks for making it all the way to the end. If better to split this up in different posts I can try to do that but overlapped with other conference calls at the moment.

I shared a handful of feedbacks regarding MetricKit and StateReporting documentation here: https://developer.apple.com/forums/thread/833079, this post focuses on API design feedback and enhancements. While you’re breaking the interface and the json schema version, there are a few more quality of life improvements that could be made. I’m sharing my feature request feedbacks for the new API here to encourage other devs to write similar feedbacks and share theirs too. So, what would you say is the best way to inspire and ask for new features in MetricKit? #filefeedback FB23023840 - MetricKit: Add 'id' or 'identifier' (UUID string) to the MetricReport and DiagnosticReport Just like an IPS crash file, I’d like each report to have a unique identifier. This will help when performing mass imports of payloads into analysis and visualization tools. FB23023481 - MetricKit: Update environment osVersion.platform to use the same string name values as App Store Connect API --> iPhone OS should be simply 'iOS' This is just a small QOL to keep naming consistent in related fields. One could even share code! FB23024453 - MetricKit: Make MetricReport and DiagnosticReport types conform to Equatable for convenience of comparing decoded reports against each other This is similar to the unique ID concept, but if you don’t want to add an ID or conformance to identifiable, this can be a very useful quick check for all of the type properties being the same or not for report uniqueness. FB23019500 - MetricKit: Update API of MetricReport to not allow a nil environment I know the metadata in the metrics is nullable, and if this is just a wrapper or conversion of that I get it, but, is it possible to make the environment for the MetricReport required? I think it is reasonable for all of the properties except the multiple app versions to detect in the MetricReporter type or what ever internals. The rest of the API change eliminated a whole cohort of nullable types and properties, I think this is the last one! FB23023396 - MetricKit / Xcode: Simulate MetricKit payloads with encodingKeyFormat set to default produces an empty string bundle identifier My first few simulated payloads had an empty string for the bundle identifier. I know that the metadata didn’t expose this property in the old API but the jsonRepresentation did. I don’t know if it is related to how it is computed in that legacy type or just a bug in the Xcode utility. FB23052965 - MetricKit: Create OpenAPI Spec for the JSON encoding representations of MetricReport and DiagnosticReport I will have to update the code in my dev tools app that analyzes and visualizes MetricKit payloads to support the new json format(s). It would be nice if all of this code could be generated using a tool like the Swift OpenAPI Generator. One major advantage is that anyone could create their decoding types fairly easily, and, updating to new versions with new metrics or diagnostic constructs would be a simple code generation effort. FB23019260 - MetricKit / Developer Documentation: Update the new MetricKit sample code to use swift lang version 6 and fix compile errors The days of @preconcurrency import MetricKit are gone! At least for the new types. The sample code still uses Swift 5. Small tweak but good to illustrate the API is fully sendable and ready for structured concurrency. FB19499083 - Add API to designate the ‘source’ of the install —> App Store, TestFlight, Xcode (ad-hoc, mdm, etc.) I use the ‘source’ to determine a priority and routing of metric payloads (soon to be metric/diagnostic reports). I’d like to see as part of the environment property, a designation to where the app came from. Now that the report types are fully codable I could just wrap to enrich it, and that is probably going to be a common workflow, but it would be great if the original type had it from the start. I don’t have a reliable way to distinguish MDM device-enrolled vs MDM user-enrolled, Xcode is easy —> #if DEBUG source = Xcode. FB23053458 - MetricKit / Developer Documentation: Update sample code to capture the async sequences and demonstrate cancellation under a user privacy switch showing privacy-by-design I have always found MetricKit to be an incredibly useful privacy-by-default and private-by-design developer instrumentation tool. The sample code could be updated to show developers they can and should cancel their report tasks if the user wants to not have their data collected. MetricKit is rather incompatible with Open Telemetry, but signposts do easily transfer to spans and traces. Apple’s swift-log, swift-metrics, and swift-distributed-tracing would make for some really interesting integrations with MetricKit as the backing store. No FB numbers yet, I need to think about this one more. Betas are installed, apps updated with reporter sequences, save to files app and hunting for bugs. Evident from the group lab, MetricKit and StateReporting are a significant milestone for app performance and observability. Looking forward to future updates and betas!

The documentation suggests that you can transfer files out of the crash reporting extension but it doesn’t outline if there are any gotchas to watch out for. Are there any limitations to this? Does it have full network access? Are app groups and keychain groups fully supported? Does the extension have a memory footprint limit we should watch out for? What is the lifecycle of the callback, what Is a reasonable amount of time to plan our implementation to do its work and be done within? 10 seconds? 30? And so on.

Apple made it very clear that this year is declarative. The last four years I’ve had several feedbacks open for legacy app config, and the new ManagedApp framework app config. This has been a major blind spot to deploying apps via Apple Business (Essentials). I didn’t see any announcements for support, but to double check, is that coming? FB19980558 (Business Essentials: Add Support for Managed App Configuration (via UserDefaults) and newer Managed App Framework) 2025 FB13398533 (Business Essentials: Add ability to send managed application configuration to an application installed via Apple Small Business Essentials app) 2023 FB21371989 (ManagedApp: Create a swift-configuration ConfigProvider implementation backed with ManagedAppConfigurationProvider)

For apps that display significant points of interest for a specific category, say breweries, or the places the user frequently visits, what is the best category to submit against the entitlement form? These apps are not quite navigation as they invoke Apple Maps, and they’re not for finding “parking” but a different type of map item category. The app would display specific markers for these map items, voice to search, and then link to Apple Maps for directions. This compliments existing iOS apps. I don’t want to encourage phone usage and being voice search and positional awareness to nearby POI that matter to the CarPlay screen.

I have a CloudKit container that I share across several apps. when I look at the App Privacy Report for these apps, it reflects the app connecting to Google storage APIs. While Apple might host with Google, the perception for users is iCloud and Apple. Can something be done about this? FB16410232 (CloudKit: CloudKit requests contacting google upload servers unexpectedly in app privacy report)

In the past I ran into issues where the CloudKit client SDK was not attributing network usage in MetricKit. Since MetricKit got a major update this year I’d like to make sure usage goes here agains the app. I would expect transfer metrics to also count for CKSyncEngine, or the CloudKit config for core/swift data too. Is this assumption correct? FB12673917 (CloudKit / MetricKit: CloudKit queries are not counting towards network transfer metrics in MetricKit - WWDC23 lab, possible missing URLSession 'attributedBundleIdentifier' not being set)

I don’t have a feedback for this yet, but I’d like to see some analytics reports for CloudKit performance. Things to capture stats, performance, failures, etc. lots of the data in the console, but exposed through analytics reports. Related but different, if I had something like a generated OpenAPI client, I’d add instrumentation via client middleware. I could do most of what I’d want to instrument that way, status codes, timeouts, durations, payload sizes, etc. Alternatively, if the CloudKit client API exposed URLSession, or a hook to the delegate / metrics, a lot of what I am interested in could be achieved via session task metrics too. FB13628463 (CloudKit: Expose URLSessionTaskMetrics from CloudKit client)

I’d like the ability to detect a users security role. This makes sense for detecting the roles assigned to named users for enabling workflows within an app. For example, user generated content and “moderators”. Instead of building an unlisted app, I’d prefer to just check permissions against the user. As a workaround, one could create record types with the same “security role” as the moderator actions, but to attempt to fetch a dummy record seems fragile and inefficient. FB9638492 (CloudKit: API to detect provided security role on current user)