I would check out this video that is very useful in this space. https://developer.apple.com/videos/play/wwdc2021/10181

I'll second this request FB13634596 - App Clips: Add support for App Clips on Apple Vision Pro - already in workflow for prescription lenses so add for third party apps The decoder is already there! There can't be that much more work ..... :) In seriousness, App Clips for AVP opens the door to many different domains. $3500 for a device, $15 ticket to a museum, free App Clip, as an example. The price is right for the clip, hardware will hopefully eventually come down.

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.