@kenny9309 there are a few good feedbacks here IMHO. Add thermal state to MetricKit metadata, low power mode is already there. This won't get you historical mind you, but it is a start. Add historical process info data as a new MetricKit metric. Instead of the thermal state at the time of metric capture (metadata), we could ask for historical changes or time spent in condition. Instead of a timeline, closer to existing MetricKit APIs perhaps a histogram of duration spent in thermal state (while app was running in foreground or background) If you want more data, just opt-in always. Add signposts and hook them with MetricKit. If you're only interested in receiving those payloads when you're in thermal state, then use that as your condition before starting a signpost metric. Might as well just record them always.

I assume you're using this collection of APIs. The name is 'review' not 'rating' so that is the gap. Make a feedback, reference mine in it. I would want this capability too. https://developer.apple.com/documentation/appstoreconnectapi/customer-reviews FB21900768 - App Store Connect API: Make a collection of APIs for retrieving app ratings - or enrich the review API to allow fetching ratings without requring the user to have left a review for deeper user sentiment analysis

@zhaotaotao have you looked at any of the AnalyticsReports available via the App Store Connect API? One of the crash reports analytics might be a good way to determine differences in Xcode Organizer vs MetricKit vs App Store Connect Metrics data. https://developer.apple.com/documentation/analytics-reports/app-crashes @Technology Evangelist could you comment on if the same under-reporting and fixed issue in 26 would also muddy the App Store Connect crashes analytics reports with over reporting?

@ErikMonroe I assume you're asking as related to SB2420 in Texas. DeclaredAgeRange has a forums tag. If my assumption is correct, take a look at this property: https://developer.apple.com/documentation/declaredagerange/agerangeservice/iseligibleforagefeatures Stay away from the MetricKit regionFormat property of the MXMetadata dictionary. The user can download an app on the US App Store and then travel to another region.

Good things come to those who wait. I don't get as many signpost metrics as I would expect. To understand your ask better, are you wanting the signpost interval data, or just the fact that the signpost event start and stop happened with basic things like timestamps? If the later, I'd just make an extension or a macro to emit the signpost + a structured log statement via SwiftLog.Logger or os.Logger APIs. Best of both worlds. If you're trying to get men stats and other data in the interval data, I'd start looking at Instruments as your go-to tool. If you want to see that the system is capturing your signposts via MetricKit API, fire up Instruments and watch for them. That having been said, I made a new feedback because I would find this useful too in a certain context. FB21900624 - MetricKit: Update Xcode to include a mode to generate a metric payload with user contributed data - aka signpost metrics The ask in my feedback is user / developer generated data only, which is currently limited to signposts, and potentially extended launch metrics since technically the developer opts into that one too. This is important because I would rather have just my data, than nothing at all due to all of the other system components that would be required generate a full payload.

@naftaly I submitted a somewhat relevant feedback a few years ago. FB9616844 - MetricKit: MXDiagnostic, MXDiagnosticPayload and MXMetricPayload should have 'identifier' properties I mostly wanted a unique identifier built-in because IPS files have them and then I wouldn't need to decorate the MetricKit payloads myself and it would be just built in. If you want to correlate runtime data you captured against a payload, your best bet is to do this with diagnostics since those are truly the PID at time of diagnostic--well at least I assume. I've never bothered to check. This could easily be tested by crashing and check the PID in the IPS crash file against that identified in the MXDiagnosticPayload metadata. The metadata is required in the diagnostic payload but it isn't in the metrics payload. While I have not in practice seen the metrics metadata object to be empty in a metric payload, you're right that you can't do much for variation over time. The API just simply doesn't have a way to represent that. My understanding is that it is the metadata at the time of reporting. If you're truly interested in the low power mode value over time, I would capture this in your app and then enrich your metric kit payload over time. I think it is unreasonable to expect the system to give you details when your app is background and not executed. You could listen to this while your app is running and record. Exploring creating signpost events would also be an option, though I would do the signpost event, not signpost interval for low power mode changes. https://developer.apple.com/documentation/foundation/processinfo/islowpowermodeenabled I have never concerned myself with the PID in the MXMetricPayload's metadata because as you pointed out, it can change over time. What is less likely to change is the TestFlight status. For that, I have done a bit of investigation and I'm waiting on a feedback. To answer your questions, you can, at the time a metric payload is delivered, check the system properties, PID, thermal state, etc., and just compare. In the case of TestFlight, the property seems just busted. FB15701498 - MetricKit / TestFlight: Production Issue - MXMetricManager not generating metric payloads as expected with iOS 18 This is another example where I capture information and enrich the MetricKit payload json when I ship off device. This is another example of 'value at time of payload'. I'm not tracking if the user was installing app store, Xcode, and TestFlight builds throughout a period of time--but my same advice about low power mode above could be taken if I truly was. StoreKit2 has a nice AppStore.Environment property that I switched from reading the sandbox receipt.

@Joeljiangjiang, what @eskimo said. Here is my feedback as a reference. Please make one and if you're willing share your ask here so I can update mine too. In short, I want both a diagnostic, and some new properties associated with that memory pressure diagnostic. FB9972410 (MetricKit: Capture memory usage at time of jetsam and report as diagnostic) April 2022 While the memory metric is insightful combined with the exit metrics, it would be even more powerful to know the memory footprint at the time of jetsam pressure exit. This would allow one to look at the memory footprint and really evaluate if it is worth investigating, or if the footprint is so low and just the system was memory hungry because of some foreground app. For example, if the average suspend memory was 38 mb, but there was one instance of 150 mb, it would be good to see that one getting jetsam'd but the others not. Then we know we have an outlier and something wasn't released upon transition to background and it is time well spent to fix

I would check out any of the HealthKit WWDC talks. There is a 'user entered' metadata key, but that relies on the app to use that flag when the user saves a workout. You can't edit samples. You can only create new ones, or delete data from your app. Hard to answer, are you trying to sync the data with a backend or just present changes locally to the user? There are version metadata keys that will be mutated by Apple. Again, up to the third party developer to do the right thing. This one is fairly obvious if you check the docs or watch some old videos. Checkout the route builder and route query types. Ask for workout route permissions and you can query any route against workouts. Do note you can have more than one route per workout. As to will route data exist? That depends on the app that saved the workout. Apple does this for outdoor workouts. Aside from 'delete all records of all apps', you app should be able to do almost everything that Apple Fitness and Apple Health allow. When deleting data, you can only delete data that you created. This is there to prevent an app with a bug that wipes out the users whole health database. https://developer.apple.com/videos/all-videos/?topic=health%20%26%20fitness

@brianindeed Use PermissionKit and the new significant change topic to notify 'the App Store' of your change. My understanding is that this will trigger the parental consent flows. Check out this video, I assume the behavior is identical across the two different topic types: https://developer.apple.com/videos/play/wwdc2025/293

I don't think that Apple will give developers options to modify this one due to its sensitivity. Additionally, this permission is attached to the user's Apple Account, not their device. Out of curiosity, what would you want to put here? In my onboarding I'm doing a permission priming experience before I make the request.

@DTS Engineer Tested with Xcode 26.2 downloaded from the App Store, against iPhone 17 Pro running 26.1 (23B85) Xcode Version 26.2 (17C52) So this property wasn't tested. I haven't touched PermissionKit yet so I wasn't actively testing this, however my wrapper library code still fails for this property too and causes a runtime crash due to symbol not found. AgeRangeService.ParentalControls.significantAppChangeApprovalRequired 55C0A89C-7970-4C69-B5D3-1E6873C6EF2B-diagnostic.json Here is some offending code, assumes iOS 26 minimum target: extension ParentalControls { public init(activeParentalControls: AgeRangeService.ParentalControls) { var value: Int = 0 if activeParentalControls.contains(.communicationLimits) { value |= ParentalControls.communicationLimits.rawValue } if activeParentalControls.contains(.significantAppChangeApprovalRequired) { value |= ParentalControls.significantAppChangeApprovalRequired.rawValue } self.rawValue = value } }

Please familiarize yourself with the Developer News page. https://developer.apple.com/news/ As of today, Apple has posted two articles about this topic: New requirements for apps available in Texas Next steps for apps distributed in Texas I'd highly encourage watching these WWDC25 videos a few times to catch all the details: Deliver age-appropriate experiences in your app - WWDC25 Enhance child safety with PermissionKit - WWDC25

This is not legal advice, nor a statement from Apple. I will share what I'm going to do in my apps and recommend to others. How I interpret 121.056 (B) (1) is basically, use the signals when they're available. If they're not available, you can't use them. You can't do the impossible. So if you have an app update that supports iOS 26, implement it there, and < 26 you simply can't. As a developer, it is impossible to use the age signals provided by the App Store if they don't exist. If you're not comfortable with this approach, file feedback asking for support on devices < 26. Hypothetically, if Apple were to add support to, say iOS 18, it would still be something like iOS 18.8.x or higher. I am closely following the OS Usage page and waiting for an update to show the adoption of 26. https://developer.apple.com/support/app-store/ For my specific usage, I'm moving my apps to 26+ for my updates. However, I have apps that include watch extensions, and an Apple Vision Pro target. This presents its own challenges. I posted quite extensively about the framework being unavailable on several Apple platforms. You can read more about those gaps here: https://developer.apple.com/forums/thread/808139

Regarding feedback FB20954846 for App Clip support, I got a message from Apple saying it is fixed. I can now compile, and code sign for an App Clip using the DeclaredAgeRange API. Great. Now that I can get past the compiler failure I'm running up against a new issue. When installed via TestFlight, an App Clip throws that the age range is unavailable. In the console app it looks like the App Clip is still prohibited from calling the system functionality: default PerformanceOrganizer AppClip 18:36:39.200071-0600 (501) Failed to fetch persona: got error from remote proxy: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction.} error PerformanceOrganizer AppClip 18:36:39.200108-0600 (501) personaAttributesForPersonaType for type:0 failed with error Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction." UserInfo={NSDebugDescription=The connection to service named com.apple.mobile.usermanagerd.xpc was invalidated: Connection init failed at lookup with error 159 - Sandbox restriction.} For good measure, the same behavior happens for both installed via Xcode as well as TestFlight. Tested on iOS 26.1 public. Feedback updated with more details. For the other developers out there trying to add Age Assurance to your App Clips, are you running into the same issues?

While l can't speak to the consequences of changing your Apple Account's age setting, changing the age setting will clear all statuses. This is based on my testing with iOS 26.1 and 26.2 beta 3. This might be as designed, but might also be unexpected. I submitted a feedback related to permission management as it is what I would describe as a one-way trip right now. FB21024854 - DeclaredAgeRange / Age Range for Apps: Cannot manage or even view age range for apps in Settings > Apps > AppName as described in learn more in main Age Range for Apps screen Please see the attached screenshots. In the age range for apps “learn more” it clearly directs the user that they can manage a per-app level age range sharing election in the apps settings. This is simply not true. When I go to my apps settings, there is nothing there for age range. Additionally, I cannot even edit the sharing status from the main menu under the Apple account screen. I have a separate feedback for that already. Something is broken or not implemented.