Product Xcode Version 26.3 (26C5131e) Platform macOS / iOS Simulator / iOS Device Classification Bug / Incorrect UI Behaviour Reproducibility Always (persists across restarts, scheme recreation, DerivedData clearing) Date Encountered February 20, 2026 Hardware Mac mini (M2) running macOS Test Device iPhone SE (2nd generation), iOS 26.3 Summary In Xcode 26.3, attempting to run an iOS app on any simulator destination using Cmd+R fails with the error: "A build only device cannot be used to run this target. Please select an available device or choose a simulated device as the destination." This occurs despite the selected destination being a valid iOS Simulator (not a "build only" device). The same project builds successfully using Cmd+B within Xcode and builds, installs, and runs correctly via the command line using xcodebuild, xcrun simctl, and xcrun devicectl. Steps to Reproduce Open a valid iOS project in Xcode 26.3. The project in question has target name "h", product name "DiabetesHbA1cPrediction", bundle identifier "com.diabeteshba1c.DiabetesHbA1cPrediction", with IPHONEOS_DEPLOYMENT_TARGET set to 26.0. In the scheme/destination picker toolbar, select any iOS Simulator destination (e.g. iPhone 16, iPhone 17 Pro, or any other available simulator). The destination name appears correctly in the toolbar without any "build only" annotation. Press Cmd+R (Product > Run). Xcode immediately displays the error: "A build only device cannot be used to run this target." Press Cmd+B (Product > Build) instead. The build succeeds with no errors. Expected Behaviour Cmd+R should build and launch the application on the selected simulator, just as it does in previous Xcode versions. The user had been running simulators successfully for the prior week before this issue appeared. Actual Behaviour Xcode refuses to run the app, treating every simulator destination as a "build only device." The error appears instantly upon pressing Cmd+R, before any build activity begins. Cmd+B succeeds normally, confirming the project and scheme configuration are valid. Workarounds Attempted (All Failed) The following troubleshooting steps were performed, none of which resolved the Xcode UI issue: Changed IPHONEOS_DEPLOYMENT_TARGET across multiple values (26.2, 18.0, 26.0) in all build settings within project.pbxproj. Deleted and recreated the Xcode scheme (removed .xcscheme files from xcshareddata and xcuserdata, let Xcode auto-create a new scheme). Deleted the entire DerivedData folder (rm -rf ~/Library/Developer/Xcode/DerivedData). Selected multiple different simulator destinations (iPhone 16, iPhone 16 Pro, iPhone 17 Pro) — all produced the same error. Verified the scheme’s Executable setting (confirmed it was set to the correct .app target). Changed "Show Run Destination" setting between Automatic and Always. Quit and restarted Xcode completely. Confirmed that simulator device names in the destination dropdown appeared normally, without any "build only" suffix. Working Workaround: Command-Line Build and Deploy The project builds, installs, and runs correctly when using command-line tools, confirming the project configuration is valid: Simulator deployment: xcodebuild -scheme h -destination 'platform=iOS Simulator,name=iPhone 16' build xcrun simctl boot 7F0DF8DA-E4A3-41B2-A2E4-B1F528753189 xcrun simctl install booted xcrun simctl launch booted com.diabeteshba1c.DiabetesHbA1cPrediction Result: App launched and ran correctly in the simulator. Physical device deployment (iPhone SE 2020, iOS 26.3): xcodebuild -scheme h -destination 'id=00008030-001128DC2E51402E' build xcrun devicectl device install app --device xcrun devicectl device process launch --device com.diabeteshba1c.DiabetesHbA1cPrediction Result: BUILD SUCCEEDED, app installed and launched on the physical device without issue. Key Observations The disconnect between Xcode’s UI-based Run (Cmd+R) failing and the command-line build/deploy succeeding with identical configuration strongly suggests this is an Xcode IDE bug in the run destination resolution logic, not a project configuration issue. Cmd+B succeeds in Xcode itself, meaning the build system correctly recognises the project, scheme, and destination. The failure occurs specifically in the “run” pathway where Xcode evaluates whether the destination supports execution. The simulator dropdown shows destination names without any "build only" label, yet Xcode internally treats them as build-only when the Run action is invoked. This behaviour started occurring in Xcode 26.3. The same project and simulators worked correctly in the preceding week under the same Xcode installation. Environment Xcode version: 26.3 (26C5131e) macOS: Running on Mac mini (M2) iOS SDK: 26.3 Available simulator runtimes: iOS 18.6, iOS 26.2 Physical test device: iPhone SE (2nd generation), iOS 26.3 Project type: SwiftUI iOS app with HealthKit integration Signing: Automatic, with valid provisioning for both simulator and device

Hello! Because the compilers used by different versions of Xcode 26 may be different, and I find that my app may not be able to ensure that all versions of Xcode 26 are successfully compiled. For example, my app can run on Xcode26.3 but will report an error at 26.4 (I have fixed it now). So I want to confirm which version of Xcode the jury uses to run my app, whether it is a known version or the latest version in the future. Thanks!

Hi! I have a Catalyst app that embeds command line utility. So the project has two targets: Catalyst target, this target depends on #2 and embeds it into its bundle. macOS target, the command line tool. Both targets have package dependency to the same package. I used this to embed the CMD tool. Everything builds, runs and works fine until I try to archive the project. Archiving stops early with such error: error: Multiple commands produce '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' note: Target 'MacrosForSwift' (project 'MacrosForSwift') has a command with output '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' note: Target 'MacrosForSwift' (project 'MacrosForSwift') has a command with output '/Users/kse2/Library/Developer/Xcode/DerivedData/PkgTest-clngkndczxoprpdlwefqqiqlryjt/Build/Intermediates.noindex/ArchiveIntermediates/PkgTest/IntermediateBuildFilesPath/UninstalledProducts/macosx/MacrosForSwift.o' What I have tried to fix archiving: Changing PkgTestCMD target to be on Catalyst/iOS instead of macOS. This works but I'm not sure how to properly run CMD tool with iOS SDK (if this correct at all): I need the main thread to be 'unblocked' and be active while background tasks exist. Adding an aux framework that act as container for the package. Doesn't work. Splitting targets into different projects, making workspace and cross-project reference. Doesn't work. My understanding is that archiving attempts to produce .o files for both Catalyst and macOS simultaneously, due to PkgTest being Catalyst and PkgTestCMD being macOS targets. How to archive such a project? Is there a way to separate archiving of CMD and main app? Maybe separate .o files into different directories. Simple building and running the project works, why archiving doesn't want to? I have a test project for the issue: PkgTest. main branch is the source project, DepFramework contains attempt #2, Workspace—#3. Thank you!

I'm on macOS Sequoia Version 15.7.3 (24G419) and using Xcode Version 26.2 (17C52). In my Xcode project, Transaction.updates and Product.SubscriptionInfo.Status.updates don’t seem to emit updates reliably. The code below works consistently in a fresh Xcode project using a minimal setup with a local StoreKit Configuration file containing a single auto-renewable subscription. class InAppPurchaseManager { static let shared = InAppPurchaseManager() var transactionTask: Task<Void, Never>? var subscriptionTask: Task<Void, Never>? init() { print("Launched InAppPurchaseManager...") transactionTask = Task(priority: .background) { for await result in Transaction.updates { print("\nReceived transaction update...") try? await result.payloadValue.finish() } } subscriptionTask = Task(priority: .background) { for await result in Product.SubscriptionInfo.Status.updates { print("\nReceived subscription update...") print("state:", result.state.localizedDescription) } } } } I initialise it in: func applicationDidFinishLaunching(_ aNotification: Notification) { _ = InAppPurchaseManager.shared } I do not build any UI for this test. I open StoreKit Transaction Manager then click Create Transaction → select the product → choose Purchase (Default) → Next → Done. The console shows that it detects the initial purchase, renewals and finishes each transaction. It also works even if I do not add the In-App Purchase capability. In my actual project, the initial purchase is detected and finished, but renewals are not detected. Subsequent transactions then appear as unverified, presumably because the updates are not being observed so the transactions are not being finished. What can I do to make this work reliably in my actual project? For context, in the actual project: I have a StoreKit Configuration file that is synced with App Store Connect The In-App Purchase capability is enabled The configuration file is selected in the scheme The products in App Store Connect show “Ready to Submit” Loading products works: try await Product.products(for: ...) Also, I use ProductView for the purchase UI. The first purchase works and is detected and finished, but subsequent renewals are not finished because the updates do not seem to be emitted.

This was maddening: I had written a very long and detailed prompt, then went to select "Codex" from the drop down menu at the top "start a new conversation", and it wiped out the entire prompt I was working on. Well, of course it did: that drop down is part of the "Start a new Conversation" icon button, but it's position is too far away from the actual icon to infer that is its purpose. It should be a popup that shows the current choice for model (GPT-5, GPT 4.1, Codex). ANOTHER lost prompt problem. If you have a prompt-in-progress (AI is maybe building some code), and Xcode crashes, it might not save that prompt for when you re-launch. And how might that happen? Well, there's still numerous ways using the coding assistanty might crash. One I've notice is if you switch out to another app, or if you invoke a screen capture, it might crash.

When building in Xcode on MacOS Tahoe, it seems it is no longer possible to dynamically specify a "small" size toolbar for NSToolbar/NSToolbarItem. It works in MacOS code compiled and linked on earlier systems. I don't want to use "SFSymbol", or "templates". I have over 60 custom-made .png toolbars, in individual Image Set files, at the previous requisite sizes of 24x24 / 48x48, and 32x32 / 64x64. Sure -- I can configure an NSToolbar with whatever size .png assets I want. I just can't dynamically switch between the two groups of sizes. According to the Apple Coding Assistant, the only solution is to change the image names of each of the NSToolbarItems at runtime. OK -- but even when attempting that, the NSToolbarItems refuse to take on their smaller size... ...unless: they are attached to a custom view NSToolbarItem with an NSButton of style "Bevel". I have about 10 of those, and YES -- I CAN change those to a "small" size. Is this REALLY what I'm forced to do?! The Apple Coding Assistant just runs me around in circles, making coding suggestions that include properties that don't exists. I've gone around and around on these issues for over a week -- it can't be this hard, right? Is there no way to make multiple NSToolbar objects, one for "large" and one for "small"?

Could you help me with resolving this issue, please. I've got following trace: ksmemory_notifyUnhandledFatalSignal EXC_BAD_ACCESS (KERN_INVALID_ADDRESS) Crashed: com.apple.main-thread EXC_BAD_ACCESS KERN_INVALID_ADDRESS 0x000000000000002b Crashed: com.apple.main-thread 0 KSCrash 0xbff8 ksmemory_notifyUnhandledFatalSignal + 12 1 KSCrash 0xcd6c handleSignal + 100 2 libsystem_platform.dylib 0x4178 _sigtramp + 56 3 libsystem_kernel.dylib 0x42f8 mach_msg2_internal + 76 4 libsystem_kernel.dylib 0x4214 mach_msg_overwrite + 428 5 libsystem_kernel.dylib 0x405c mach_msg + 24 6 CoreFoundation 0x46868 __CFRunLoopServiceMachPort + 160 7 CoreFoundation 0x1d848 __CFRunLoopRun + 1188 8 CoreFoundation 0x1ca6c _CFRunLoopRunSpecificWithOptions + 532 9 GraphicsServices 0x1498 GSEventRunModal + 120 10 UIKitCore 0x9ddf8 -[UIApplication _run] + 792 11 UIKitCore 0x46e54 UIApplicationMain + 336 12 UIKitCore 0x172938 -[UIScrollView contentInset] + 588 13 AppName 0xed9440 main + 4386804800 (AppDelegate.swift:4386804800) 14 ??? 0x189f76e28 (Missing) It appears that a variable or object is attempting to access another object that has already been deallocated. Based on the stack trace, the issue was likely detected while layout was in progress. Our analytics show this happens generally on app launch and occasionally during normal use. Unfortunately, I couldn't gather additional diagnostic data. I tried to reproduce the issue using the Leaks tool and enabled runtime diagnostics (Address Sanitizer, Malloc Scribble, Zombies), but without success. I may be overlooking something — any suggestions would be greatly appreciated. Thank you in advance

I've installed Xcode 26.3 on Sequoia 15.7.3 but I'm not seeing any of the AI options showing in Xcode that I see in usage/example videos. For example that AI icon in the top left hand corner isn't visible, and if I select Settings there is no Intelligence section, yet there is in all the demo videos. Why am I not seeing any of these new features?

Description I've encountered a consistent hang/freeze issue in SwiftUI applications when using nested LazyVStack containers with Accessibility Inspector (simulator) or VoiceOver (physical device) enabled. The application becomes completely unresponsive and must be force-quit. Importantly, this hang occurs in a minimal SwiftUI project with no third-party dependencies, suggesting this is a framework-level issue with the interaction between SwiftUI's lazy view lifecycle and the accessibility system. Reproduction Steps I've created a minimal reproduction project available here: https://github.com/pendo-io/SwiftUI_Hang_Reproduction To Reproduce: Create a SwiftUI view with the following nested LazyVStack structure: struct NestedLazyVStackView: View { @State private var outerSections: [Int] = [] @State private var innerRows: [Int: [Int]] = [:] var body: some View { ScrollView { LazyVStack(alignment: .leading, spacing: 24) { ForEach(outerSections, id: \.self) { section in VStack(alignment: .leading, spacing: 8) { Text("Section #\(section)") // Nested LazyVStack LazyVStack(alignment: .leading, spacing: 2) { ForEach(innerRows[section] ?? [], id: \.self) { row in Text("Section #\(section) - Row #\(row)") .onAppear { // Load more data when row appears loadMoreInner(section: section) } } } } .onAppear { // Load more sections when section appears loadMoreOuter() } } } } } } Enable Accessibility Inspector in iOS Simulator: Xcode → Open Developer Tool → Accessibility Inspector Select your running simulator Enable Inspection mode (eye icon) Navigate to the view and start scrolling Result: The application hangs and becomes unresponsive within a few seconds of scrolling Expected Behavior The application should remain responsive when Accessibility Inspector or VoiceOver is enabled, allowing users to scroll through nested lazy containers without freezing. Actual Behavior The application freezes/hangs completely CPU usage may spike The app must be force-quit to recover The hang occurs consistently and is reproducible Workaround 1: Replace inner LazyVStack with VStack LazyVStack { ForEach(...) { section in VStack { // ← Changed from LazyVStack ForEach(...) { row in ... } } } } Workaround 2: Embed in TabView TabView { NavigationStack { NestedLazyVStackView() // ← Same nested structure, but no hang } .tabItem { ... } } Interestingly, wrapping the entire navigation stack in a TabView prevents the hang entirely, even with the nested LazyVStack structure intact. Questions for Apple Is there a known issue with nested LazyVStack containers and accessibility traversal? Why does wrapping the view in a TabView prevent the hang? Are there recommended patterns for using nested lazy containers with accessibility support? Is this a timing issue, a deadlock, or an infinite loop in the accessibility system? Why that happens? Reproduction Project A complete, minimal reproduction project is available at: https://github.com/pendo-io/SwiftUI_Hang_Reproduction

Hello, We are experiencing a recurring issue when running iOS apps in the Rosetta simulator on Xcode 26. Environment: Xcode: 26.0 macOS: 15.7.3 Simulator: Intel-based (Rosetta) simulators Languages: Both Swift and Objective-C Issue: When launching an app in a Rosetta simulator, the app frequently freezes or fails to run. In many cases, Xcode reports that the debugger has lost connection. Xcode error message: Lost connection to the debugger on “iPhone 12”. Domain: IDEDebugSessionErrorDomain Code: 22 Failure Reason: Message from debugger: lost connection Console log: assertion failed: GPR thread_set_state is unimplemented for NewThread (ThreadContextRegisterState.cpp:920 host_gpr_state_from_guest_state) Observed behavior: Rebuilding after fully quitting the simulator sometimes resolves the issue temporarily. Disabling Scheme > Run > Debug executable allows the app to run normally, but debugging (breakpoints, etc.) becomes unavailable. The issue does not occur: On real devices On ARM-based simulators When building with Xcode 16 using Rosetta Has anyone encountered this issue with Xcode 26 and Rosetta simulators? Is this a known bug, and are there any recommended workarounds besides disabling the debugger or restarting the simulator? Thank you in advance for any insights or guidance.

We are encountering a build and archive failure in Xcode after updating our development machine to macOS 26.2. Environment: macOS: 26.2 Xcode: 16.2 iOS Deployment Target / Runtime: iOS 18.5 App Type: Production iOS app (App Store distribution) Issue: Before updating macOS, the project built and archived successfully. After the macOS 26.2 update, archiving fails consistently, even though no major changes were made to the project code or configuration. Certificates, provisioning profiles, and signing settings are correctly configured. The issue appears to be related to the macOS/Xcode environment rather than application logic. Steps to Reproduce: Open the existing iOS project in Xcode 16.2. Select the App Store distribution scheme. Attempt to Archive the project. Archive/build fails. Expected Result: Successful archive allowing upload to App Store Connect. Actual Result: Archive fails after macOS 26.2 update. Additional Info: This post is linked to Apple Developer Technical Support Case-ID: 18413014.

Following is an error I encounter when trying to run a foundation model function in simulator. Error Domain=FoundationModels.LanguageModelSession.GenerationError Code=-1 "(null)" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=ModelManagerServices.ModelManagerError Code=1026 "(null)" UserInfo={NSMultipleUnderlyingErrorsKey=(\n)}" )} Its a swift playground I'm building in xcode and works fine in the preview and on a real device too but since it's my submission for the swift student challenge I need it to run on the simulator. I have updated my macOS to latest version of Tahoe(26.3) and Xcode is also on latest version. The simulator I run the playground is also on ios and iPadOS 26. I have set my region to US and have turned on Apple Intelligence on my mac too. Any suggestions on how to fix the issue?👾

Are there workarounds for the following bugs in Xcode 16.3? I'm looking for workarounds instead of trying newer versions of Xcode because, from what I read, the Xcode release notes do not mention these issues being fixed. First bug: Resizing a NSSplitView in the UI Editor is buggy. When you try to use the divider, it just does not work as expected. In the case of a vertical split, the bottom view gets shrunk whatever you try to do. Second bug: When you type: (IBAction) in the source editor, you get the following buggy template (extra ')' on the right): - (IBAction)<#selector#>:(id)sender)

Description On iOS 26.1, a ToolbarItem placed in .keyboard is no longer exposed to the accessibility hierarchy. As a result: VoiceOver cannot focus or activate the toolbar button XCUITest cannot discover the element, making the UI impossible to test TextEditor() .toolbar { ToolbarItem(placement: .keyboard) { Button("Done") { /* action */ } } } This worked correctly on previous iOS versions. The button appears visually but is missing from both VoiceOver navigation and XCUI accessibility queries. Steps to Reproduce Create a new SwiftUI project. Use a simple text field with a keyboard toolbar button. Run on an iOS 26.1 device or simulator. Focus the text field to show the keyboard. Turn on VoiceOver and attempt to navigate to the toolbar button. Run an XCUITest attempting to locate the button

Hello, I am trying out Xcode Cloud for the first time. I could connect to Github in the initial setup and had a few failed builds (package resolution error), which I resolved fairly quickly. Now whenever I am trying to build, I get the following error: Xcode Cloud is unable to connect to the repository “<respository-name>”. Reconnect the repository to resume builds. I am unable to remove the connection from settings as well because it's stuck in a loading state. Is there a way to fix this?

I am reporting a regression/behavioral change in the SwiftUI layout engine when building with Xcode 26 (iOS 26 SDK). In previous versions (Xcode 15/16 and iOS 17/18 SDKs), a TabView using .tabViewStyle(.page(indexDisplayMode: .never)) correctly respected the coordinate space when combined with .edgesIgnoringSafeArea(.vertical). However, when compiling with the iOS 26 SDK, the internal views of the TabView render "out of bounds," pushing content vertically beyond the intended safe area boundaries and causing UI overlapping/clipping - an abnormal behavior. TabView(selection: $selectedIndex) { ForEach(0..<data.count, id: \.self) { index in nextPreviousHandlerView(id: data[index]) .tag(index) } } .tabViewStyle(.page(indexDisplayMode: .never)) .edgesIgnoringSafeArea(.vertical) // Causes vertical "jump" out of bounds in Xcode 26

I am trying to sign my Mac app to use Network Extensions capability. But every time I create a profile it displays that to me: on the other hand on the website it displays this to me:

When completing signing on Xcode, it shows the following error message "No certificate for team '' matching 'Developer ID Application' found" I have already followed the steps to generate a certificate from keychain and made a new certificate on developer portal, along with its associated provisioning profile. Viewing "Manage Certificate" window shows the newly created certificate, but Xcode seems to not be able to locate it.

I'm attempting to use Cloud Signing to export the Release version of 3 different apps for App Store, as described in https://developer.apple.com/videos/play/wwdc2021/10204/ The process completes successfully, and appears to be signed correctly, with a newly-created certificate in the developer portal of type "Distribution Managed". When I upload to App Store Connect however, I see the following error for several third-party Swift packages, distributed as frameworks: Validation failed (409) Invalid Signature. Code failed to satisfy specified code requirement(s). The file at path “MyApp.app/Frameworks/MyFramework.framework/MyFramework” is not properly signed. Make sure you have signed your application with a distribution certificate, not an ad hoc certificate or a development certificate. Verify that the code signing settings in Xcode are correct at the target level (which override any values at the project level). Additionally, make sure the bundle you are uploading was built using a Release target in Xcode, not a Simulator target. If you are certain your code signing settings are correct, choose “Clean All” in Xcode, delete the “build” directory in the Finder, and rebuild your release target. For more information, please consult https://developer.apple.com/support/code-signing. If I have a manually created Distribution certificate installed in the keychain at the point of export, the same archive is signed with that certificate, and is accepted by App Store Connect without issue. The xcodebuild command I am using (roughly): xcodebuild -exportArchive \ -archivePath "$ARCHIVE_PATH" \ -exportPath "$EXPORT_PATH" \ -exportOptionsPlist "$EXPORT_OPTIONS" \ -authenticationKeyPath "$API_KEY" \ -authenticationKeyID "$API_KEY_ID" \ -authenticationKeyIssuerID "$API_KEY_ISSUER" \ -allowProvisioningUpdates The plist: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "<http://www.apple.com/DTDs/PropertyList-1.0.dtd>"> <plist version="1.0"> <dict> <key>method</key> <string>app-store-connect</string> <key>teamID</key> <string>$TEAM</string> <key>uploadSymbols</key> <true/> <key>signingStyle</key> <string>automatic</string> </dict> </plist> Is what I’m trying to do supported? Is this a bug?

Hi, I’m seeing an unexpected change in how XCTFail behaves in UI tests after updating Xcode. I use the following helper method: `func waitForExistance(file: StaticString, line: UInt) -> Self { if !(element.exists || element.waitForExistence(timeout: Configuration.current.predicateTimeout)) { XCTFail("couldn't find element: \(element) after \(Configuration.current.predicateTimeout) seconds", file: file, line: line) return self } else { return self } }` In Xcode 16.4, this worked as expected: – when an element wasn’t found, XCTFail was triggered, but the test continued running, allowing my retry logic to execute. After updating to Xcode 26.1 / 26.2 - the test now immediately aborts after XCTFail, without executing the next retry. The logs show: `t = 113.22s Tear Down t = 113.22s Terminate com.viessmann.care:81789 *** Assertion failure in -[UITests.Tests _caughtUnhandledDeveloperExceptionPermittingControlFlowInterruptions:caughtInterruptionException:whileExecutingBlock:], XCTestCase+IssueHandling.m:273 Test Case '-[UITests.Tests test_case]' failed (114.323 seconds). Flushing outgoing messages to the IDE with timeout 600.00s Received confirmation that IDE processed remaining outgoing messages` It looks like XCTFail in Xcode 26 is now treated as an unhandled developer exception, which stops the test execution immediately, even when it’s called inside a helper method. This was not the case in earlier versions. My questions: Is this a regression in XCTest? Or an intentional change in how XCTFail behaves in newer Xcode versions? Should failures now be reported differently (e.g., using record(.init(type: .assertionFailure, …))) if I want to continue the test instead of aborting it? I would like to restore the previous behavior where the failure is logged without terminating the entire test, so my retry mechanism can still run. Has anyone else run into this after upgrading? Thanks in advance! If you’d like, I can also add recommended workarounds that actually work with Xcode 16.4 (e.g., replacing XCTFail with a non-terminating issue record).