Post not yet marked as solved
Hi Andre. I consulted with the HealthKit team.
Please file an enhancement request regarding storing the location of the swim workout.
The stroke style should be recognized by HealthKit automatically, but if this is not working, please file a bug report.
Please also file an enhancement request regarding swim workouts that don't have any arm movements.
I hope this information is helpful to you.
Post not yet marked as solved
Because iOS 14 and the aligned macOS/watchOS/tvOS releases use Apple's CDN to access the AASA file, this file needs to be available on the public internet without authentication.
An alternative is to use managed mode, which is mentioned in the Associated Domains Entitlement documentation. - https://developer.apple.com/documentation/bundleresources/entitlements/com_apple_developer_associated-domains. managed mode will cause the device to download the AASA file directly from the associated domain, and this domain could be behind a VPN, although I have not tested that scenario. It is possible that some kind of certificate-based client authentication would also work. Authentication methods that require user interaction will not work.
In a development scenario, you should use the developer alternate mode, which is documented at the same link.
Post not yet marked as solved
This does look like a certificate issue. There is a list of trusted root certificates, - https://support.apple.com/en-us/HT209143 and your website's, even if internal, must have a certificate that is derived from one of these. And make sure the intermediate certs are also included.
Post not yet marked as solved
Hi Kian1991,
The 404 response means that for some reason your website is blocking the Apple CDN from accessing the AASA file, and you might need to ask your hosting provider for advice. Also, you should use MIME type application/json. I hope this helps.
Post not yet marked as solved
Hi bumbleparrot, creatingrev,
I am happy bumbleparrot that you are making progress! We have documentation - https://developer.apple.com/documentation/app_clips/testing_your_app_clip_s_launch_experience on testing the launch experience. There are three ways. Direct from Xcode by running the App Clip target.
Local Experience. This is still an important testing scenario for apps under development, that have not yet been uploaded to App Store Connect. (cc. creatingrev)
TestFlight.
To answer your questions: the documentation I linked to above does not mention launching the App Clip from a Smart App Banner, so that's most likely not an option in the GM. Also, on the App Clip page, there is a note in footnote 14 - https://www.apple.com/ios/ios-14/#footnote-14 that the Camera App will add support for reading App Clip Codes in a future update. Until then, use the QR Code Reader in Control Center.
Thanks,
ZK
Post not yet marked as solved
Hi creatingrev,
Thanks for the screenshot. I have some more questions: How are you invoking the App Clip? Local Experience? TestFlight?
What is the URL?
If TestFlight, is it possible that in App Store Connect the App Clip is restricted to a region, and your device is set to a different region?
Thanks,
ZK
Post not yet marked as solved
Hi bumbleparrot,
I tested this with the Fruta sample project - https://developer.apple.com/documentation/app_clips/fruta_building_a_feature-rich_app_with_swiftui, and was able to get it working. Note that the sample project has been updated, and now requires the GM Xcode 12 and iOS 14.
Here is the process: Configure the Fruta sample project according to the instructions in the README.
Build and run the App Clip scheme on your test device once, so the App Clip is deployed to the device.
On your test device in the the Developer app, define a Local Experience: URL Prefix: https://fruta.example.com. In theory, this can be any URL that makes sense for your app. Bundle ID: The App Clip target's bundle ID. Title: Something that makes sense, i.e. "Order a smoothie." Subtitle: "It's yummy!" Action: Open Don't forget to save the Local Experience.
Create a regular QR code or NFC tag with the same URL: https://fruta.example.com.
Add the QR Code Reader button to Control Center on your test device.
Use the QR Code Reader to read the QR code, or touch the NFC tag. I do not have one, so I can't test NFC tags.
The card should show up after step 6, where you should be able to tap on "Open" and bring the App Clip to the front.
Give that a shot and let me know if there are still issues.
Thanks,
ZK
Post not yet marked as solved
Hi creatingrev,
Can you link to a screenshot of the region warning, so I can see what you mean? Is this your own app's app clip you are testing? Are you using Local Experience or TestFlight for your tests? If TestFlight, what's the App Store ID of your app? And please also let me know what region and language your device is set to.
If you don't feel comfortable sharing this information here, please submit a feedback report with the information and let me know the feedback number.
Thanks!
ZK
Post not yet marked as solved
Hi bumbleparrot,
Can I ask you to give me more details on what's broken, and what your expectations are regarding the end-to-end developer experience?
Thanks!
Post not yet marked as solved
Hi. The above procedure should work on watchOS 6. Can I ask you for more detail about what is not working on watchOS?
Post not yet marked as solved
Hi. I realize it's been a few months since you asked this question, and might have already found an answer. However, if you have not, this is indeed possible. There are a couple of building blocks you need to put together to enable reading heart rate when using an extended runtime session, and not using a workout. All the links below contain code snippets to help you get started.
Your app will still need to request authorization to access the user's health data. See [Authorizing Access to Health Data
](https://developer.apple.com/documentation/healthkit/authorizing_access_to_health_data) Obviously, extended runtime session. See [Using Extended Runtime Sessions
](https://developer.apple.com/documentation/watchkit/using_extended_runtime_sessions) Your app needs to be able to make sample queries. See [Executing Sample Queries
](https://docs.devpubs.apple.com/releases/glacier-beta-1-draft/documentation/healthkit/hksamplequery/executing_sample_queries) Optionally, if you need periodic updates, or updates that notify your app during background execution, use an observer query. When the observer query notifies your app that an update is available, your app needs to perform a sample query to actually retrieve the updated sample. See [Executing Observer Queries
](https://docs.devpubs.apple.com/releases/glacier-beta-1-draft/documentation/healthkit/hkobserverquery/executing_observer_queries) When the heart rate HKQuantitySample is delivered to your app, it needs to be converted to a beats-per-minute value:
// Counstruct the count per time unit.
let countUnit: HKUnit = .count()
let minuteUnit: HKUnit = .minute()
let beatsPerMinute: HKUnit = countUnit.unitDivided(by: minuteUnit)
// If this is a UI update, so dispatch to main.
DispatchQueue.main.async {
		self.heartRate = sample.quantity.doubleValue(for: beatsPerMinute)
}
If your app plays audio during the entire time, then instead of an extended runtime session, and audio background session is more appropriate, and will give your app background processing while the audio plays. Please give putting together these building blocks a shot, and if you still need help with the implementation, file a technical support incident with DTS, so we can help you further.
Post not yet marked as solved
Reverting to a dependent watch app from an independent one is not possible after the independent watch app has already been uploaded to the App Store.
Regarding the issues you mentioned about the iOS and the watchOS app becoming "unsynced". The idea behind independent and stand-alone watch apps is that they should function completely independent of the iOS app. It should not matter if the iOS app was installed or not. For most apps, this means that there should be a source of truth in a server-side component. For other apps, it is sufficient to use the WatchConnectivity - https://developer.apple.com/documentation/watchconnectivity framework to update the counterpart app on the companion device with any data that changed.
It depends on each app if a server-side component, or WatchConnectivity is the right approach. If you still need help after attempting to implement one of these technologies, please submit a technical support incident with DTS.
Post not yet marked as solved
Hi boblaublaw,In the device log, you can see the AASA file has been accepted when you see something like this:Updated app ID 'com.my.great.app', domain 'mydomain.com', flags 0x0 < > -> 0x2 < SiteApproved > on checkThe 0x2 flag indicates approval. 0x4 means not approved, which can happen for various reasons having to do with website configuration, or a bundle ID that does not match.This is how I test universal links functionality:Make sure the app has been deleted from your test device.Deploy the app from Xcode.Send yourself an email with the Universal Link you want to test. (Or create a note containing the link in the Notes app.)Receive the email on your test device, and tap on the link. (Or tap on the link in the Notes app.)Observe if your app opens and shows the expected content.If the app opens, then universal links has been properly implemented.You also mentioned the App Search API Validation Tool. This will only successfully validate universal links for apps already on the App Store. If you see that the tool is not validating an app that's been on the store for a couple of weeks, please file a bug report.I hope this helps.
