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.
- Is there a limit developers should stay clear of?
There aren't hard limits. Note however that the more dimensions you include in your states, the larger the space they cover and the more likely you are to fragment your data. More keys also leads to larger data rates.
We recommend trying to limit your state transitions to the cadence of user interaction or less.
- When using the StateReporting API, what are the practical limits to the number of domains and metadata key/value pairs we can have?
Rate limits in the StateReporting framework are applied per-domain as a function of data rate, not key count. Try and reason about the size of your state dictionaries overall, rather than key count. If you have a lot of keys and/or verbose keys/values, you are more likely to have a higher data rate and also will have a harder time bucketing metrics and/or analyzing traces.
MetricKit also limits the number of domains/states that it will aggregate across. The exact semantics here may change so we cannot give hard rules. Overall err in favor of concision to steer clear of current and future limits.
Hopefully this helps.
