We're seeing > 1 hour. Again, nothing showing on the System Status page.

I'm getting the exact same error, very similar circumstances: extension NSItemProvider { func loadObject<T>(ofClass: T.Type) async throws -> T? where T : _ObjectiveCBridgeable, T._ObjectiveCType : NSItemProviderReading { return try await withCheckedThrowingContinuation { continuation in _ = self.loadObject(ofClass: ofClass) { item, error in switch (item, error) { case (.some(let item), .none): continuation.resume(returning: item) /* Task-isolated value of type 'T' passed as a strongly transferred parameter; later accesses could race; this is an error in the Swift 6 language mode */ case (.none, .some(let error)): continuation.resume(throwing: error) default: let error = NSError(...) continuation.resume(throwing: error) } } } } } Based on the advice below I changed the method signature to: func loadObject<T>(ofClass: T.Type) async throws -> T? where T : _ObjectiveCBridgeable, T._ObjectiveCType : NSItemProviderReading, T: Sendable which seems to have fixed it!

Shortcuts involving Text URLs are equally broken in iOS 17.6 beta 3, although the error message has changed:

In the end I had to escalate to the App Review Board, who approved the release. Since then I’ve added some text at the top of the “Notes” section of each release asking App Review not to reject me for 4.0 as use of a browser in this way is a) required and b) has been approved by App Review Board. I haven’t had an issue since then. Really not good that you are still getting rejected for this though - it doesn’t reflect well on App Review that this message still hasn’t got out.

It's not just a GoogleSignIn issue: they just rejected my app for using completely standard OAuth 2 web authentication, for precisely this reason. It's incredibly frustrating: if they don't like it they should be complaining to the Apple team who develop ASWebAuthentication. It's not like we app developers can do anything about it - we are just caught in the middle. I've raised an appeal to App Review but I have no idea what the "Plan B" is if they reject my appeal.

I switched to Github Desktop a month ago. It's like Xcode used to be: a simple list of changed files, side-by-side comparison and a big blue commit button. A breath of fresh air. And it works perfectly next to Xcode too e.g. Xcode updates in real time when you check-in. Until Xcode gets fixed I can recommend it.

Another new Github Desktop user here. I've battled with Xcode 15 long enough and I'm fed up with commits which take twice as long as they should (because it's so hard to review changes) and then seem to leave half the committed files behind. And that's if it doesn't freeze. Am not sure what was driving these changes and why Apple thought adding steps, complexity and poor UX to this process was necessary but it needs a fast re-think. This isn't something we'll learn to love given time. We will just switch away.

Just to add to this, it's not even consistent on the same surface in Xcode. For code it's: Right-click -> Copy -> Copy But if you want to copy the an error message or warning it's: Right-click -> Copy just like the rest of the world uses. PLEASE FIX THIS

The new "Integrate" options have been a car crash for me: I've had several partial checkins where not all files seemed to get included, countless occasions where the Commit and Push button does nothing until I restart Xcode, and I still have no idea how to specify on a per-file basis which should or shouldn't be included in a commit. But the disappearance of side-by-side comparison is worst of all - I'm going to have to stop using Xcode for VCS at this rate. Please fix this Apple.

Still seems to be an issue in the release candidate. Here are 2 more bug reports: FB13006620, FB12808549.

Did you manage to resolve this? Am getting the same error. Have submitted bug reports FB13006620 and FB12808549 but the issue still seems to be there in the release candidate.

You need to reach-out to Dolby I'm afraid. They wanted to see screenshots of my app when I did this.

I'd love to know the answer to this one too - such a basic requirement. I raised feedback on it months ago (FB11706965). Also you'd think that if you tried to edit a playlist that you weren't allowed to edit at least it would throw a specific member of MusicLibrary.Error which indicated what happened. But no - you get a completely generic error. The only way you can tell what happened (as far as I can see on 16.1) is by looking for a specific string in the error text (reported as FB11740727).

I’m seeing this too: the call arbitrarily blows-up when saving larger playlists. There doesn’t seem to be a specific upper limit - sometimes 3,000 tracks will fail, other times 6,000 tracks will work fine. Suspect it depends on server loads (fyi 500 is a gateway error). It wouldn’t be so bad if you could break the call up and add to a playlist chunk by chunk but the “new” MusicKit call to add to a playlist is completely unusable as it seems to map to the old (comically slow) MPMediaPlaylist.addItem method. The other interesting thing you will find is that if you read the playlist tracks immediately after creating a new playlist, there aren’t any. They come along a few seconds later. So much for async/await. Worse still, if there’s a failure between when the call apparently “succeeded” and when the tracks subsequently appear, it’s completely silent. You just end up with a playlist with no tracks. I get the impression that Apple are not eating what they cook when it comes to MusicKit. And incidentally all of the above issues have been reported by me via Feedback Assistant for months without so much as an acknowledgement.

Hi - is there any update on this please? I've just added additional details to FB11733455 as error reports are continuing to come in from users.