Did you ever figure this out? I have the exact same question.

Team ID + bundle ID. So: 678ade.com.A.a

I wouldn't disable Bitcode to work around this. Bitcode allows your app to be recompiled for specific devices and iOS versions which makes the app package as small as possible when users download it from the App Store. Instead do all of this: Remove libswift_Concurrency from all of your targets (Target ⇢ Build Phases ⇢ Link Binary With Libraries) Remove libswift_Concurrency from the Frameworks group in the Project Navigator Remove all Swift concurrency keywords from your sources: @MainActor, async, await, etc According to the release notes this only happens when the app targets <iOS 15, so presumably all of your users weren't getting these features to begin with and you were already branching on availability of iOS 15. If you're like me, you were doing this to get the subscription management screen in iOS 15 but thanks to this Xcode 13.3 regression your users won't get that even on iOS 15.

Sad to report that the iOS 15.4.1 update didn't address this 😞 Devs: if you haven't done so already, file a ticket with Apple using the Feedback Assistant app.

I know this is 2 years old, but why on earth isn't NSUbiquitousKeyValueStore supported by watchOS? That would make sharing small bits of data so much easier. The fact that I have to bring up an entire CloudKit infrastructure just to share an auth key is criminal.

Just chiming in, I'm running into the same problem. As of this morning Xcode (14.0.1) won't show any of my teams in Accounts prefs even after signing out/in and I can't submit builds to the App Store/TestFlight. Submitted a support request to Apple but haven't heard anything back.

Not sure if this will work for everyone but I was able to upload builds using Apple's Transporter app (available on the Mac App Store) WITHOUT having to switch to manual code signing and creating provisioning profiles. I just dragged in the exported .ipa file and it uploaded without a hitch.

I think the problem has to do with what's being requested from NSTextContentStorageDelegate.textContentStorage(range). Even though in the performEditingTransaction block I deleted the entire paragraph range and then re-inserted it with the replacement string and longer length, the delegate is getting called twice with two ranges: a range covering the original length before the edit and a smaller range covering only what was added during the edit. But my delegate is returning a full paragraph object for both, resulting in the duplicates. I need the delegate to only get called for the new aggregate range.

The only workaround I've found that works 100% of the time is this: Disconnect iPhone from USB cable if already connected Put iPhone in airplane mode Connect to USB cable and wait for Xcode to finish connecting to it Take iPhone out of airplane mode Apparently Xcode doesn't switch back to wireless debugging after establishing a wired connection so you should be fine for the duration of the session. But ofc if you disconnect the device for any reason (or relaunch Xcode?) then you'll need to repeat this.

Good news! After a bit of trial and error I found replacement URLs that work: Messages settings: App-prefs:com.apple.MobileSMS Phone settings: App-prefs:com.apple.mobilephone Verified on iOS 18 beta 4. These URLs do not work with iOS 17 or (presumably) earlier.

I appreciate that Apple engineer answer, but respectfully I don't think that answers the question. Yes, openURL has been deprecated since iOS 10, but the OP (and me) aren't using openURL, we're using open, which is NOT deprecated. Perhaps some clues: The calls to UIApplication.shared.open() aren't showing a deprecation warning. Going to the definition of that function takes me to a protocol in FBSDKCoreKit: /** Internal type exposed to facilitate transition to Swift. API Subject to change or removal without warning. Do not use. @warning INTERNAL - DO NOT USE */ NS_SWIFT_NAME(_InternalURLOpener) @protocol FBSDKInternalURLOpener - (BOOL)canOpenURL:(NSURL *)url; - (BOOL)openURL:(NSURL *)url; - (void) openURL:(NSURL *)url options:(NSDictionary<UIApplicationOpenExternalURLOptionsKey, id> *)options completionHandler:(nullable void (^)(BOOL success))completion; @end Is FBSDKCoreKit intercepting these calls and sending them to the deprecated openURL version? A little more googling turns up https://github.com/facebook/facebook-ios-sdk/issues/2205 So it looks like the Facebook SDK is swizzling ALL calls to UIApplication.open and is instead using the deprecated version which no longer works. 🤦

@markyin can you follow up with if and how you were ever able to deal with this? We are in the same position, removed the group entitlement, released the new app without the entitlement to the App Store, and it still cannot be transferred with the same error.