I wouldn't be so sure about the app clip getting an update. If the user launched the app clip again, maybe it would get the latest. The language around it staying on your device for 30 days to me feels like it wouldn't auto update. I would create a feedback for this and ask for clarifying documentation in the App Clip Framework or App Store Connect. Out of curiosity, is the update just to get them new features, or is the old version of the app clip no longer compatible with the backend?

Do you plan to setup advanced app clip experiences or use the default one that Apple provides if you don't configure your AASA and associated domains?

I'm seeing something similar when I try to view crash data. https://developer.apple.com/forums/thread/748657

FB13677569 - Xcode Cloud: Failed to archive for visionOS using 'latest relase' 15.3 public with error visionOS 1.1 is not installed

Users on iOS 15 will still be able to download your 'final iOS 15' app version if you let them via last compatible version. You can look at this page and see a screenshot of it in App Store Connect. https://developer.apple.com/help/app-store-connect/manage-your-apps-availability/make-a-version-unavailable-for-download Keep in mind any services or APIs that you integrate with are still subject to availability per those providers.

@andreikrn @atul3189 @dkvijay The conversation I had with a MetricKit engineer during WWDC20 or WWDC21 labs was that the user setting to "Share with App Developers" is not used in MetricKit when deciding to generate a metric or diagnostic payload. If you read the footer carefully, "Share with App Developers" is an Apple thing, Apple is sharing it with developers. MetricKit allows YOU, the developer, directly receive the data and then handle it responsibly. I have been operating under this assumption for years. I just wrote up a feedback requesting a docs update for this. Fingers crossed. FB13618353 - MetricKit / Developer Documentation: Add description to the behavior of MetricKit with respect to "Share with App Developers" setting Before operating under this assumption, please consider giving your users the option to control data collection. #privacy-by-design So now that you've thought about letting users choose to participate in this data collection within a feature or setting in your app, it is easy to validate the assumption that MetricKit is not tied to "Share with app developers". Turn off the "Share with App Developers" setting Create a button that crashes your app. Generate logs or save the payload in your subscriber didReceive callback Install this app on a device via Xcode or TestFlight Ensure you are NOT debugging, as the crash will be caught by Xcode Tap the crash button Relaunch the app, your app SHOULD get a callback Verify that your log is printed or the payload is persisted via your process An alternate path if you don't log or save the MXDiagnosticPayload would be: Set a breakpoint on your didReceive diagnostics method Attach the debugger (run app) on your device with Xcode after the app is crashed Verify during app launch that you didReceive diagnostic callback is invoked. I just verified this with iOS 17.3.x in one of my apps using the alternate path and Xcode 15.2. NOTE: For all of this to work, you should be setting the .addSubscriber method somewhere during app startup--my favorite spot is didFinishLaunching. Even for a SwiftUI application, I still have a UIApplicationDelegateAdaptor and in that implementation I put it in didFinishLaunching. Now a note on privacy and MetricKit data collection. Because the user can't control my app's MetricKit payload collection via the global setting "Share with app developers", I have explicitly put reference to MetricKit metrics and diagnostics in my privacy statement. Furthermore I have given users the option to enable/disable directly within my app. With that having been said, I do make a decision that, if you use a TestFlight build of my app for beta testing, both diagnostics and metrics will be recorded by default to help improve my app--that is after all the whole purpose of TestFlight right? P.S. Don't forget to update your App Privacy Label with respect to this data collection too! I conditionally detect installed from TestFlight and add a disclaimer to the very top of my Privacy Policy. If the user did in fact install a TestFlight build, they will see this in the settings to enable/disable collection. Again, note the disclaimer. My apps don't always crash, but when they do MetricKit is there for me to records it. As an added perk, MetricKit can capture events that other off-the-shelf crash reporters just can't do, so I use MetricKit exclusively to build the most privacy preserving crash reporting solution I can.

You should unit test your logic, not your CBCentralManager itself. Unit testing Core Bluetooth isn't going to yield the results you expect. It is just as you described, unit testing isn't running in an app per-say. Simple fact, you can't initialize many of the Core Bluetooth types, namely CBPeripheral. I'd check out the following video and refactor your code accordingly for testing. https://developer.apple.com/videos/play/wwdc2018/417/

What are you trying to enable the user to do? Most things are not possible to navigate directly into the Settings app. Secret apple sauce. If Bluetooth is off and you want to turn it on AND you're using CoreBluetooth, initialize your manager with the power key. This will trigger a prompt to the user to either enable Bluetooth, or start new connections if that was turned off for the day. self.centralManager = CBCentralManager(delegate: nil, queue: .main, options: [CBCentralManagerOptionShowPowerAlertKey: true])

According to the documentation of the characteristic write options, the write with response SHOULD chop up the message and perform a long write. Core spec 4.0 Part G 4.9.4. https://developer.apple.com/documentation/corebluetooth/cbcharacteristicwritetype I created a feedback for this as I am also encountering the prepareQueueFull unexpectedly. FB13596337 Here are some console logs: Central (iPadOS 17.2) (client) error bluetoothd 21:53:42.361949-0600 com.apple.bluetooth Stack.GATT Received error response 9 for write long value - canceling execution (status=65535) error bluetoothd 21:53:42.421534-0600 com.apple.bluetooth Server.GATT Failed to write long characteristic value at handle 0x001b on device "58B87653-65EE-23CB-2E99-0D70A24D0CE2" - result was 9 error bluetoothd 21:53:42.421727-0600 com.apple.bluetooth Server.GATT Command failed to execute with status 9 error bluetoothd 21:53:42.422360-0600 com.apple.bluetooth Server.GATT Command failed to execute with status 9 Peripheral (macOS 14.2) (server) error bluetoothd 21:54:52.323246-0600 com.apple.bluetooth Server.GATT Refusing Prepare Write Request as it would exceed the maximum amount of data queued (512) for this connection by 135 byte(s) error bluetoothd 21:54:52.323518-0600 com.apple.bluetooth Stack.ATT Failed to write value to attribute handle 0x001B with result 9 (status=65535)

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.