“DTiPhoneSimulatorErrorDomain Code 2”

Thanks for the focused reproducer and the video — they made this easy to investigate. There are two separate problems in what you're seeing, and the right answer is to switch to a different SwiftUI API for this kind of programmatic text editing. The bug in your code: String.Index invalidation after replaceSubrange RangeReplaceableCollection.replaceSubrange(_:with:) invalidates all indices into the collection (per the documentation), not just indices at or after the modified range. In your code: self.text.replaceSubrange(from..

@hydrudcatt3 Thanks for the post. The thread is 4 years old, I think will be a great idea if you could post a new thread with all the details of the issue and the code you have posted. Is what you experiencing like SwiftUI's implementation of .searchable sometimes holds onto the Binding longer than the view's lifecycle? Is that what you are seeing? Looking forward to see your new post with all the details. Albert
  Worldwide Developer Relations.

You've narrowed this down well, and the corroborating reply confirms it isn't device-specific. What you're describing isn't expected behavior — third-party MusicKit clients shouldn't lose access to playback because the native Apple Music app has a pending post-update onboarding modal. Shared service initialization (account readiness, subscription state, and so on) should happen independently of the native app's UI state, and the fact that a single Apple Music launch + modal dismiss restores everything to working order points to some shared component lazy-initializing only when Apple Music itself runs. A few things: On a force service initialization API: there isn't one in public MusicKit, and adding one wouldn't be the right fix — the underlying services shouldn't get into a broken state in the first place. That's the bug. Please file a Feedback Report. Even if other developers have already filed, duplicates matter — independent reports count as a signal of impact, so each FB from an affected app raises visib

We are also running into the same issues. Test broke in iOS 26.3 [SKTestSession] Error saving configuration file: Error Domain=SKInternalErrorDomain Code=3 (null) [SKTestSession] Error clearing overrides: Error Domain=SKInternalErrorDomain Code=3 (null) [SKTestSession] Error deleting all transactions: Error Domain=SKInternalErrorDomain Code=3 (null) [SKTestSession] Error setting value to 1 for identifier 2 for com.keepsafe.development.KeepSafe: Error Domain=SKInternalErrorDomain Code=3 (null)

Thank you for the post. Please check your SSL certificate as seems to have intermediate SSL errors. curl -v https://rob-auth.bankalbilad.com/.well-known/apple-app-site-association After you fix the SSL certificate you should read the Tech Note TN3155: Debugging universal links | Apple Developer Documentation#Use-universal-links-on-your-site {applinks:{details:[{appIDs:[2TK5X82C47.com.bankalbilad.NewRMB],components:[{/:/*,comment:}]}]}} As your AASA format is not correct neither. Look for an example of the AASA file. If you go over the troubleshooting and still have issues, I'd like you to submit a code-level support request so we can discuss this further privately. When you create the request, indicate that you were referred by Albert Pascual at Apple and make sure to include a link to this thread. Thanks Albert
  Worldwide Developer Relations.

I am seeing the same issue with a native iOS app using WeatherKit.framework. Runtime error: WeatherDaemon.WDSJWTAuthenticatorServiceListener.Errors Code=2 I verified: WeatherKit is enabled for the App ID A new iOS App Development provisioning profile was created after enabling WeatherKit The app is manually signed with the new profile The app was deleted and freshly reinstalled on a physical iPhone The built app contains com.apple.developer.weatherkit = true The embedded provisioning profile also contains com.apple.developer.weatherkit Bundle ID and Team ID match the App ID The issue persists after waiting and rebooting the iPhone Bundle ID: de.praxishartlep.weathermat Application identifier: .de.praxishartlep.weathermat This looks like the same server-side JWT minting/authentication issue described above.

I got my app released with 48 hours of waiting but for the first update we have been waiting for 2 months. We didn't get any rejections before at all, and I tried all of the ways to contact them (Support Ticket, email, forum, expedited review). Do you now any ways to solve this? We cannot publish the game because the first version had lots of changes and the game looks completely different in iOS and Android (which got approved so fast).

Followup: filed FB21570087 per Quinn's suggestion. Digging into the behavior for the write-up turned up something my original report missed. The check in xcrun / clang is on the basename of the developer path, not the full path: basename CommandLineTools -> accepted as a CLT install path matches *.app/Contents/Developer -> tried as Xcode (also needs Info.plist + xcodebuild) anything else -> rejected with the unable to find Xcode installation error The parent directory isn't checked. My attempt with /Library/Developer/CommandLineTools-26.2.0 failed because of the basename, not the location. Since DEVELOPER_DIR is a per-process env var, not the global xcode-select selection, parallel multi-version CLT actually works: DEVELOPER_DIR=/opt/clt/17/CommandLineTools clang --version # 17.x DEVELOPER_DIR=/opt/clt/16/CommandLineTools clang --version # 16.x Two shells can run these concurrently and each sees its own CLT. /Library/Developer/CommandLineTools can still point at one of them as the default fo