Having the exact same set of problems here with complications and WatchOS 9 & iOS 16. Wondering if it might be an Xcode 14 problem too as its causing problems for an old version of my app that used to work. An update from Apple Engineers would be very appreciated...
Post
Replies
Boosts
Views
Activity
Second this issue.
Xcode 14 GM
iOS 16 GM
iPhone 12 mini
As of today I have now been able to upload a build using Xcode 14 Beta 5. Hope yours is fixed too!
Same issue here, not resolved yet...
This was fixed in iOS 15, issue persists for iOS 14 even if built with Xcode 13.
This issue has not been solved for me even using Xcode 14 Beta 4 when distributing via TestFlight. I've not been able to test Beta 5 yet as I can't submit any builds currently, will report back once I've tested this.
Same for me trying to ship a TestFlight beta of my app which uses the new Charts framework. Crashes on launch for a large proportion of users with the following message:
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: DYLD 4 Symbol missing
Symbol not found: _$s6Charts11BuilderPairVMn
Referenced from: <E7FDC397-7B61-3C7C-A6A0-441BD43EFDC1> /Volumes/VOLUME/*/<App_Name>.app/Heart Hive
Expected in: <D800F5CA-04A9-3D85-A4A1-8AEACDF75A13> /System/Library/Frameworks/Charts.framework/Charts
(terminated at launch; ignore backtrace)
I second this question and behaviour here.
I'd like to know if my independent Watch app will still be available in the WatchOS App Store on WatchOS 6 devices if I release an update with the minimum deployment target of WatchOS 7. And if the user has a newer iPhone that supports a later version of my app, but the watch doesn't, what happens then?
Thanks
I've not been able to get the always on display feature working throughout the entire summer.
My app has a deployment target of WatchOS 6 mostly to support Series 1 & 2 Apple Watch models.
Do you think that I need to drop support for WatchOS 6 & 7 in order to get my app working with the Always On display for WatchOS 8? Because even in the latest RC build (RC Xcode 13, RC iOS 15 and RC WatchOS 8), I can't get it to behave differently from how it did with WatchOS 7 and the time.
I've also tried adding WKSupportsAlwaysOnDisplay and setting it to TRUE. No luck.
Yes of course, it's FB8970333. I filed it 6 months ago when I first thought it was a bug but heard nothing back so still wondering if its intended behaviour? The feedback include a dead simple sample project with similar to above code. Thanks
Did you get anywhere with this? I basically only want widget refreshes when the device is unlocked for the HealthKit data store. It seems frustrating to have to request updates every 15 minutes when most return no data because the device is locked.
Ideally I'd like to say update every 5 minutes, but only when the device is unlocked, and preferable with a priority call on unlock. Along side this Apple Watch only syncs its HealthKit data to the watch periodically. Calling a widget refresh at this point would be perfect.
Same here, so frustrating and so unnecessary to release software of this quality....
Edorphy,
I'm not sure I can really comment on iOS 12.2, though I suspect Apple will only really investigate bugs with iOS 14 currently....
I've not bothered with a HKObserverQuery in the end as I wasn't able to get it to work reliably. Instead I just use the Widget update callbacks to do fresh HKSampleQueries.
Regards
Simon
I'm also having this issue. I've submitted a Feedback on the issue and made a sample project which I attached. It's a basic project that just uses SwiftUI to implement a Tab View Application. Toggling the Full Keyboard Access on before launch causes this very basic app to grind an iPhone 12 mini to a halt on iOS 14.3
Nope. I'm considering opening a TSI but really don't want to waste it if the response is just "This feature is not currently available, please file an enhancement request".