If anyone else encounters this issue, using the Appointment ID as the password got me through the door!

Fresh from yesterday w/ iOS 17.2 beta 1: https://developer.apple.com/documentation/JournalingSuggestions?changes=latest_minor https://developer.apple.com/documentation/ios-ipados-release-notes/ios-ipados-17_2-release-notes#Journaling-Suggestions-API I discovered right away with Xcode 15.1 beta 2 that the framework is missing for simulator so time to upgrade some devices and hope some simulator support gets added.

In case you're looking for it and your search provider of choice hasn't indexed the page yet, documentation is available here: TipKit Framework

HealthKit will be available and functional in iPadOS 17! Check the WWDC23 videos and keynote :)

@jonaszbilski The expectation for an iOS device running 14+ (or macOS 12) would be that the diagnostic payload callback also gets invoked. The menu option is "Simulate MetricKit Payloads", payloads being plural. When I was learning the stack trace and other types I was doing so using the Xcode menu option for receiving diagnostics. Since this appears to be a bug, I created a feedback against Xcode here: FB11840182 - "Xcode / MetricKit: Debug > Simulate MetricKit Payloads does not invoke the diagnostics callback as expected". MBP 16 M1 - macOS Version 14.1 (14B47) iPad Air 3rd Gen - iPadOS Version 16.1 (20B79)

@newToThis123, based on your description, it looks like you're writing XCTest and now XCUITests. CoreBluetooth is not implemented on simulator so you'll never see a switch to .poweredOn in that case. Otherwise, if you are running your tests on a device, the test process is not your application and the bluetooth permissions don't carry over, so I don't think you'll get .poweredOn there either. You could attempt to rewrite your unit tests as XCUITests, and put appropriate state machine logic around your connect call to ensure .poweredOn state before sending the connect call. If you want to stick with XCTests (unit tests), or write Bluetooth related tests that can run on simulator, I might suggest abstracting your code a little bit like how it is done in this video and think differently about what you are actually testing. Testing in Xcode

What is your mechanism for recording audio? I'd check the docs and see if they allow starting the recording from background. From experience, you can do a number of items when your app is woken up from CoreBluetooth events, but I've never personally tried to record audio from those events. For what it is worth, good luck getting this through App Review; hopefully the feature is very clear to the users and opt in. Very close to privacy invasion / surveillance, IMHO.

As @darkpaw code shows, widgetURL is the mechanism to wire up to your views and then to handle openURL in your SwiftUI app / views or ApplicationDelegate. Pre iOS 16, widgetURLs only worked on systemMedium and larger items from my recollection. It may have changed with all of the new Lock Screen widgets and support for widget kit on watchOS. See WidgetURL API for more information.

I resolved this by ensuring the application target had the push capability added. After adding, the error went away. I updated my feedback to Apple with sample project and a request for a named swift error type for this error condition. FB11226441

The resume time is the measured time from when the user taps on your app and your app resumes. Think application/scene delegate callbacks and watchdog terminations. Resuming has to be fast but you get either 10 or 20 seconds to do so before iOS will kill you. The exact 'end' of the measurement is unknown, but think of it as a quality of service measurement on the main thread. Is this from a single report or are you seeing many reports like this? If just a single report, treat it as an iOS defect of MetricKit / outlier and capture a sysdiagnose for a feedback assistant report if you can. I had run into something similar where the data didn't look right as was many many magnitudes larger than what I had usually seen and the result was a bug and to file feedback.

MetricKit and Xcode Organizer Metrics are two different things. Data in organizer is 'opt-in' by users and even then will only be delivered if there are enough users such that Apple can anonymize the data. Has your app usage gone down significantly? There are also App Store Connect APIs that you can hit to get performance metrics, you could explore calling that and changing your window for the query to a larger range than what Xcode organizer gives you.

If you're making an apple-to-apple chat app, you might want to look at Multipeer Connectivity. If you want bidirectional communication over BLE you can search for SPP-BLE (Serial Port Profile over BLE). You effectively get a rx and tx channel. Another approach would be that you could have each device connect to each other and they both perform the central and peripheral role just inverted with each other. It all depends on how you want to write your transport protocol.

When you start advertising a new UUID, the old advertisement is implicitly stopped. If your UUIDs are short (16 or 32 bit) you should be able to stuff them both into a single advertisement. iOS shoves so much other stuff in the advertisement packets that you don't get a lot of space. If you want to get two different advertisement UUIDs to appear to your scanner app, you should implement a loop to toggle between the two different forms of advertising. I can't make a recommendation on how frequently to switch between the two advertisement payloads--that'd have to be something you experiment with.

Can you share some sample code related to your CBCentralManager, scan call, connect call, peripheral object property?

Blocked by human body or a few feet is rather surprising to get a disconnect in open air. What is the tx power of your device? Do you have a PCB antenna or a dedicated one? Years and years ago I was able to get an iPhone and iPad to stay connected over BLE several houses away down the street in open air. I think iOS defaults to 0 dbm for tx power when using CBPeripheralManger? It has been a while. Anyways, operating within an arms length should really be something that is stable IMHO if you have relatively high TX and good antenna design. I forget if the NRF series has an antenna built into the housing or allows for external ones. If you have the ability to turn up your tx power, that is one thing you can try. Do you read RSSI from your device often? What does it look like just before disconnect? This can be used to help troubleshoot too. As for what is controlling the disconnect determination, you're looking for the "supervisory timeout" or "supervision timeout". This is probably something you can control from the nordic SDK and have updated during the connection with your iOS device. I thought that iOS set the supervisory timeout to 720 ms by default, so you can only go < 1 second without bidirectional packets before the link is considered lost. However the accessory guideline now talks about having your device set to 2 seconds. Here are some useful links Accessories Accessory Design Guidelines