Have you considered passing in your preference value directly as an initializer parameter to your UIViewRepresentable type? If it needs to change, you can pass a binding. What was the motivation for using a preference value?

I assume when you say stops communicating with the Bluetooth device, you mean the connection was dropped? This is different from the connection continuing to exist and you just stop receiving notifications/indications. When you see your device disconnect, just issue a reconnect and upon connection, go through your gatt discovery procedure again as if it was a fresh connection. Lose all of your characteristic references and start over to be sure.

@mattk-wt sounds like a great feedback to send in. If you create one post your feedback number in here and I'll make a feedback for the same capability and reference your number as I would use it in one of my apps too.

In case it wasn't obvious, your app needs some usage. Make sure that you're using it. You should be getting data periodically when the app runs if you're a subscriber. One of the best ways I have found to 'make sure it continues to work' during internal team TestFlight builds is to show a notification when ever a metric or diagnostic payload has been received. Every morning like clockwork, when I use the app (or a background feature kicks in), I get a metric push notification.

How are you determining if the user has opted into MetricKit reporting? Is the "MetricKit health report" something you have developed or something you're using off the shelf? Are you talking about the "Share with App Developers" option that the user can opt-in from the Settings app? If so, that's not MetricKit. MetricKit, unlike the crash data found in Xcode Organizer and the App Store Connect power performance API, is fully up to you to control. Implement the callback, you should get data.

Have you confirmed via another mechanism that your app is indeed crashing? Off the shelf crash solution, device crash file, test flight crashes, etc. I assume that you are calling your start() method. To check this out: Run your app with Xcode with debugger attached Xcode > Debug > Simulate Metric Payloads Observe your code being invoked (or not). I have noticed that in flavors of Xcode 14, this doesn't work to reliably give diagnostic payloads but seems to have been fixed for my setup in Xcode 15. Once you've verified your code is wired up properly via the Xcode feature, then check your understanding/expectation about WHEN the diagnostics will be delivered to your callback below. If you're expecting the app to crash in the background here is a tip: The MetricKit diagnostic payload callback, according to the MetricKit team via a WWDC session a few years ago, is non-launching. Do you have other features in your app that would normally launch the app in the background? If so, you should expect diagnostics periodically. If not, then you'd get them when your app was launched by the user. If you're expecting the app to crash in the foreground, then for sure, the next time you launch it I would expect to receive the payload.

@joshmooredd TLDR: Start using MXCrashDiagnostics contained within the MXDiagnosticPayload. This has timestamps of crashes. If you're looking for exact timestamps, you might be able to discern some of them by looking at the MXDiagnosticPayload and the resulting MXCrashDiagnostics within. If however, you are just looking for ORDER and relative time, then you can build this out yourself with a few different techniques. Meaning if you just care about timeline and sequence of your events intermixed with exits--check out the following recommendations. Use official Apple API to detect TERMINATIONS (by the user). See: UIApplicationDelegate - applicationWillTerminate You're not guaranteed to get this callback, but when you do, expect it to show up in exit data later on in the metric payload Use a signal handler to inspect uncaught exceptions. Not for the faint of heart. If you're only looking to make breadcrumbs and NOT capture things like call stacks at the time of an uncaught exception, this might be an okay thing to do. Look at ANY of the shelf open source crash reporting solution for examples. BUT, also heed the words of @eskimo here: Implementing your own crash report If you're just worried about order, start looking at the crashes found in the MXDiagnosticPayload. They will contain a timestamp of when the crash occurred and then you can build your timeline. Some of the MXCrashDiagnostic might have easy to map exceptionType, exceptionCode, and bsd signals that you can map to the exit data counts. If you're targeting iOS 17, PID to the rescue. I asked in feedback to add some identifiers to be added to the payloads, and as a response I got PID in the metadata (big thanks MetricKit team!!! FB9616844). IF your events were capturing PID, hint look at ProcessInfo, you could know for certain which crashes were in which run of the app with respect to your events. Then use this info and combine it with suggestion 3. Hope this helps you on your journey to making better apps!

@BringSupersonicsBack What are the other fields of the crash? Have you converted the exception code, type, and signal to the mach exception codes and BSD signals? That might give us some hints--though I expect all types to generate a stack frame. Also, have you noticed any consistency when this happens in terms of either device type or os version? Look at the metadata. This would be helpful to identify if it smells like a bug introduced in X OS version on Y device models. Smells like a bug to me. I'd suggest making a defect with the MetricKit team via Feedback Assistant. I'm building a MetricKit analysis app for iPad and Mac and I'm curious about your findings too as it is a data scenario I haven't considered. The strange thing that I have found in the past is call stack frames, but none of them marked as attributed. - FB12739927

Make sure that you first create an index for the timestamp. Add the queryable index if you plan to use it in your predicate, such as 'created|modified after Tuesday'. Add the sortable index if you plan to use the property as a sort descriptor. Finally, if you're testing in production, make sure that your indices were pushed to production! This is never a fun thing to debug. Been there done that. I'm doing a manual synchronization where I 'fetch modified since last cursor'. Regarding the name of the properties, if you're fetching all properties, you can use the debugger to inspect the system field names.

When you run your CloudKit app via Xcode, on simulator or device, the container being used is 'development'. When ever I detect a change of deployment type (i.e. #if DEBUG), I **** my local core data database and let it rebuild from CloudKit. While you can replicate the data in both development and production containers, it probably won't be 'auto-magic' like you're hoping. When you install the app via TestFlight, can you first delete your local app? I would assume this would get you past the synchronization error you've shared above. Another thing to check is to make sure your schema is deployed. NOTE: Schema can only add fields, so once you deploy to production, you're stuck with them.

@brandonK212, The ActivityViewContext is the context object passed inside the ActivityConfiguration for building your view bodies. The preview for a live activity is very different from previewing a widget. You have to create your attributes set and then request a preview on that instead. Here is a minimally required code snip to get you started. Create custom Attributes Create a widget that uses an ActivityConfiguration of your custom attributes In your preview, instantiate an instance of your attributes and call .preview on it As a note, you need your widget defined as main, or use a widget bundle. I originally missed this and nothing happened. Presumably, under the hood it will lookup which ActivityConfiguration to invoke, and thus which 'View' to finally instantiate for the preview. https://developer.apple.com/documentation/widgetkit/activitypreviewviewkind https://developer.apple.com/documentation/activitykit/activityattributes/previewcontext(_:isstale:viewkind:) P.S. This is brand new with Xcode 14.2 and requires iOS 16.2 :) @available(iOSApplicationExtension 16.1, *) @main struct LocationWidget: Widget {     var body: some WidgetConfiguration {         ActivityConfiguration(for: LocationAttributes.self) { context in             Text("You're at \(context.attributes.name)")         } dynamicIsland: { context in             DynamicIsland {                 DynamicIslandExpandedRegion(.leading) {                     Image(systemName: "mappin.circle")                         .resizable()                         .scaledToFit()                         .frame(width: 32, height: 32)                 }                                  DynamicIslandExpandedRegion(.center) {                     VStack(alignment: .center) {                         Text("You're visiting \(context.attributes.name)")                         HStack {                             Text("\(context.state.location.latitude), \(context.state.location.longitude)")                         }                     }                 }                                  DynamicIslandExpandedRegion(.trailing) {                     HStack {                         Image(systemName: "hand.thumbsup.fill")                             .resizable()                             .scaledToFit()                             .frame(width: 32, height: 32)                                                  Image(systemName: "hand.thumbsdown")                             .resizable()                             .scaledToFit()                             .frame(width: 32, height: 32)                     }                 }                                  DynamicIslandExpandedRegion(.bottom) {                     Text("Enjoy your visit!")                 }             } compactLeading: {                 Text("Compact Leading")             } compactTrailing: {                 Text("Compact Trailing")             } minimal: {                 Text("Minimal")             }         }     } } struct LocationActivityView: View {     var body: some View {         Text("Hello Location")     } } struct LocationAttributes: ActivityAttributes {     struct ContentState: Codable, Hashable {         var location: Location     }          let name: String } struct Location: Codable, Hashable {     let latitude: Double     let longitude: Double } #if DEBUG @available(iOSApplicationExtension 16.2, *) struct LocationActivityView_Previews: PreviewProvider {          static var previews: some View {         Group {             LocationAttributes(name: "London Eye")                 .previewContext(                     LocationAttributes.ContentState(location: Location(latitude: 51.503351, longitude: -0.119623)),                     viewKind: .content                 )                          LocationAttributes(name: "London Eye")                 .previewContext(                     LocationAttributes.ContentState(location: Location(latitude: 51.503351, longitude: -0.119623)),                     viewKind: .dynamicIsland(.expanded)                 )         }     } } #endif I'm getting an error trying to attach the resulting preview screenshot but give it a run and check it out for yourself!

@Khuffie, I'm running into the same error on Xcode 14.1 RC. Below is my feedback in case anyone at Apple is watching :) FB11707419 - WeatherKit: Undocumented error ocurring on simulator when attempting to get current weather conditions

@ricardo.sms, Likely what you're running into is the length of your domain. I have two domains that are identical except one prefixes with "the", "thecxxxxxxxxxxxxe.app" and "cxxxxxxxxxxxxe.app". The visual App Clip Code can only encode so much. I brought this up during WWDC 2021 lab with App Clip team; they know we want more space. What to do for now? #filefeedback for future OS releases and App Clip Code embedded data size. Okay fine, hope for more in the future, but what to do about iOS 14-16? Here is my implementation: Through experimentation, I found that I only have 6 characters to work with when I use my shorter domain (cxxxxxxxxxxxxe.app). The "the" in my domain really restricts me and I wish I could have a fancy short/OG top level domain, but domain squatters make them so expensive... So I'm stuck with cxxxxxxxxxxxxe.app/id/123456 for my clip urls.

@InfogenLabsPvtLtd, when you created your app clip, did you rename the bundle identifier of either the clip or your parent app? I ran into stuff similar to this because I'm OCD about my bundle identifier naming conventions (I changed .Clip to .clip). Do a search in your project for all of your bundle identifiers and look for any inconsistencies including case sensitive differences. Since you blurred out everything, it is quite hard to help or make suggestions.

+1, as a developer building 'experiences for businesses' it is crucial that information for the maps portal be made available to developers so we can teach/aid the external businesses through the process.