API enhancement suggestions for MetricKit and StateReporting

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!