I've encountered a significant sync issue with watchOS 10 RC on every device combination I've tested, running both iOS 17 and watchOS 10. I'm curious if others have noticed a similar problem.
Context:
Standalone watchOS app developed in SwiftUI with a companion iOS app.
Both apps use NSPersistentCloudKitContainer for bi-directional CloudKit CoreData Sync between the iOS app and watch.
Previously, this sync mechanism was near instant in the foreground and took max 1-2 minutes in the background
NSPersistentCloudKitContainer has been reliable since the app was first developed in the watchOS 6/iOS 13 era.
Issue:
In watchOS 10 RC, sync can take hours--and doesn't even occur when the app is in the foreground.
Sync only reliably happens when the watch is placed on the charger, seemingly only if the charge is over 50%.
Once taken off the charger, the watch will continue push and receive CoreData changes briefly before becoming unresponsive to sync again.
Additional Info:
The problem persists even when recompiled with the latest Xcode RC.
It's problem is consistent in both production and development CloudKit environments.
The CloudKit log shows no watch activity upon CoreData object updates, until placed on the charger (with over 50% charge). The sync starts in the background while the watch is charging.
The iOS app, however, reflects immediate activity in the CloudKit log after a CoreData change from the device and reacts promptly to pushes when they eventually occur from the watch.
The NSPersistentCloudKitContainer code hasn't changed since it was implemented.
Background modes for remote notifications are set correctly, and when sync finally happens, it's accurate.
I'm stumped. Perhaps there's a new watchOS 10 setting affecting CloudKit sync QoS? Or could this be a known watchOS 10 RC bug?
Eboles
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Ran into a challenging EXC_BAD_ACCESS iOS app crash that provides no real information on the culprit within my code. Tried Zombie Objects to no avail.
After some extensive trial and error, the issue seems to point to using a sorted and sectioned SwiftUI List pulled from a CoreData FetchRequest.
If I change from a List to a ScrollView/VStack, things work just fine without any other code changes. (Obviously not preferred since I'll lose native swipe-to-delete, etc).
Using the same List code, the issue didn't exist in iOS 13 nor did it seem to exist in earlier iOS 14 versions.
Some code snippets below showing how I'm handing the FetchRequest, Sort/Sectioning by date, and ultimate display. Also included a snippet of the crash log.
If anyone's run into a similar issue or has some insight, it would be appreciated. Wondering if the true root cause is an OS-level bug since the problem didn't exist before.
Fetch Request:
@FetchRequest(entity: StoredTrip.entity(), sortDescriptors: [
NSSortDescriptor(keyPath: \StoredTrip.blockStart, ascending: true)]) var storedTrips: FetchedResults<StoredTrip>
Sorting:
func update(_ result : FetchedResults<StoredTrip>)-> [[StoredTrip]] {
return Dictionary(grouping: result){ (element : StoredTrip) in
dateFormatter.string(from: element.blockStart!)
}.values.sorted() { $0[0].blockStart! > $1[0].blockStart! }
}
Display:
List {
ForEach(update(storedTrips), id: \.self) { (section: [StoredTrip]) in
Section(header: Text( self.dateFormatter.string(from: section[0].blockStart!)).padding(.top,2).padding(.bottom,2)) {
ForEach(section, id: \.self) { trip in
ListItem(trip: trip).environmentObject(self.dataStorage)
}
}
}
}
OS Version:					iPhone OS 14.2.1 (18B121)
Release Type:				User
Baseband Version:		1.14.06
Report Version:			104
Exception Type:	EXC_BAD_ACCESS (SIGSEGV)
Exception Subtype: KERN_INVALID_ADDRESS at 0x0000000000000008
VM Region Info: 0x8 is not in any region.	Bytes before following region: 4333666296
			REGION TYPE								 START - END			[ VSIZE] PRT/MAX SHRMOD	REGION DETAIL
			UNUSED SPACE AT START-->	
			__TEXT									 1024e8000-10251c000 [	208K] r-x/r-x SM=COW	....app/***
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [1171]
Triggered by Thread:	0
Thread 0 name:	Dispatch queue: com.apple.main-thread
Thread 0 Crashed:
0	 AttributeGraph								 0x00000001aa77b91c AG::AttributeID::size+ 92444 () const + 44
1	 AttributeGraph								 0x00000001aa76f604 AG::Graph::add_indirect_attribute+ 42500 (AG::Subgraph&, AG::AttributeID, unsigned long, std::__1::optional<unsigned long>, bool) + 140
2	 AttributeGraph								 0x00000001aa781d80 (anonymous namespace)::create_indirect_attribute+ 118144 (unsigned int, std::__1::optional<unsigned long>) + 80
3	 SwiftUI											 0x00000001890a3c0c partial apply for thunk for @callee_guaranteed () -> + 9710604 (@unowned IndirectAttribute<A>) + 32
4	 SwiftUI											 0x00000001890a3a1c closure #1 in AGSubgraphRef.apply<A>+ 9710108 (_:) + 72
5	 SwiftUI											 0x00000001890a3810 Attribute.makeReusable+ 9709584 (indirectMap:) + 276
In WatchOS 6 a presented .sheet could be dismissed by swiping down or tapping on the navigationBarTitle. In the WatchOS 7 beta, presented sheets are no longer dismissible by either method...forcing the addition of a button to dismiss.
It appears as if .sheet is now acting as .fullScreenCover within WatchOS 7.
Anyone else running into this? Wondering if this is now expected behavior on WatchOS or if it's a bug...