Same boat. This change breaks our SDK and just seems odd. Now that Xcode 16.2 has released, using a Task for this seems inappropriate so I'd +1 the MainActor.assumeIsolated but honestly what nonsense and it's frustrating to not know if this change is purposeful. Why are no devs commenting on this; incredibly frustrating.
I like Swift Concurrency but I reckon the devs might be at the point of 'can we make SwiftUI truly concurrent for performance gains' and finding that realistically the answer is no so they need to @MainActor it all. I'm at the same pain point and the biggest and obvious issue is nonisolated contexts that need to access isolated contexts need to be made async so really I need to either @MainActor or async it all.
JoshyMW
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
I think this issue is affecting the GitHub Actions runners as well. The iOS 17 simulators are unusable now; it's a huge pain as it likely means downgrading our validation pipelines back to Xcode 14.
I'm wondering if it's possible to login an Xcode AppleID account on the CI machine using an app-specific password, then rely on xcodebuild to use that account behind the scenes? Has anyone tried this?
It seems a bit more broken than this. Selecting a previous field which has suggestions then selecting the new password field keeps the autofill bar for the previous field and messes with the keyboard change notifications... Very fun.
This reminds me of the mess that is GameplayKit which is mostly dysfunctional and riddled with crashes.
Finding exactly the same thing and no answers. Everything I am doing with GameplayKit and 3D doesn't seem to work...GKNoise; most API isn't functional... Crashing with documented example code...GKAgent3D lasts for a few run loops then everything goes to NaN for no apparent reason. Tweaking the accelleration to 0 locks the speed in place and the agent comes alive but moves continuously so it is stuck in a single direction.I just don't expect this from Apple.
Potentially a slightly different problem but if you are using a Swift Package which has previews within it.- The previews must be in the root folder of your sources, e.g. 'Sources/YourFramework/Previews.swift'.- The active target must be an application target.Then the previews magically work.