@t9mike, How are you able to add the new sizes to the complication assets? The template in xCode 13 is not updates for the 41 and 45 sizes.
Post
Replies
Boosts
Views
Activity
Same issue here. Same Xcode and OS versions, on M1.
I tried removing and re-adding the package, but that didn't fix it.
You'll find many good quality mockups of older devices here, courtesy of Facebook
https://design.facebook.com/toolsandresources/devices/
Same. I implemented the Complication controller in the watch app, and set ClockKit Complication - Principal Class to $(PRODUCT_MODULE_NAME).ComplicationController in the app plist.
It's never called.
I'm hunting the same bug. Didn't see it until recent versions of watchOS 9. I'll be sure to post something here if I figure it out.
Thanks @mikrasya for documenting this. I have the same problem, but already have inverses set. Removing inverses didn't help either. (I've read that inverses aren't necessary when using iCloud, that they are automatically inferred). 🤷🏼♂️
I sent in a question to Developer Tech Support, and will repeat any solution here for you and the other five who've marked your posting with "Same Here".
On One-to-Many relationships, Apple's sample code typically shows the @Relationship macro on the One side. Although it's supposed to work either way, I'll bet it was tested more thoroughly on that direction. And I've certainly found the @Relationship macro to have some fragile quirks.
Seeing the same bug on 17.4.1 iPads too. Can't reproduce on Mac or iPhone
Fixed by Apple on the evening of May 1
Any SwiftUI in your app @agnel_joseph ?
Same here. Starting with iOS 17.4, my app waking in the background would crash when accessing an invalid modelContext environment variable.
Even moving the app into the background with recent SwiftData changes (especially changes to Relationships) caused the same crash. My guess is that an autoSave is triggered? Easier to reproduce on iPad.
My workaround, based on the helpful discussion above....
Create a globally accessible modelContext and modelContainer. In my case I created a singleton "DataCenter" object created in the first line of the app's init.
Remove ALL @Environment(.modelContext) private var modelContext from your project
Add the modelContainer modifier to the WindowGroup, in my case WindowGroup{...}.modelContainer(DataCenter.shared.container)
Use that global context directly when needed, such as DataCenter.shared.context.insert(...)
Half measures didn't work for me, such as just removing the modelContext environment variable from the root view. Had to **** it entirely in the project.
I found that I had to remove ALL usage of @Environment(.modelContext) private var modelContext to eliminate all SwiftUI/SwiftData background crashes since 17.4.
See https://developer.apple.com/forums/thread/744194?answerId=788019022#788019022
Yes, same here.
Related bug, calling .count on a Query's array seems to load all models, including the large items in external storage, causing a memory overflow. Calling .count on iOS 17 is fast and inexpensive.
Jeff
Reported as FB14323934
It's been fixed server-side. Xcode Cloud status page was never updated to show the error or the resolution. 😐
I'm experiencing unusually long build times, maybe just demand as everyone catches up?