“translate scheme”

[quote='868298022, bims, /thread/806594?answerId=868298022#868298022, /profile/bims'] Looking at the ips-file I found that it does not show the finding that Xcode show [/quote] Right. Xcode has MTE smarts beyond what the human readable crash report shows. To see the underlying data, open the JSON crash report and search for memoryErrorReport. With some reformatting you get this: memoryErrorReport : { faultAddress:0x0c00000d9de112c0, blamedAllocation: { size:48, allocationTrace:…, deallocationTrace:…, isFreed:true, address:0x0c00000d9de112c0 }, errorType:use-after-free }, The allocationTrace and deallocationTrace backtraces need further massaging. I did a hack-ish job of that and have included the results at the end of this post. I wanted the JSON crash report so that I could run it through some internal tools. I was able to do the first part of that today. I was hoping it might point me at some known bugs. It did, but those were resolved a while bug and thus are unlikely to be the cause of this issue. Unfortu

This is tricky. My best guess is that translationTask(_:action:) is missing all the magic concurrency decorations required to make this work nicely. To get this to build right now you can mark the closure as sendable, like so: .translationTask(configuration) { @Sendable session in do { try await session.prepareTranslation() } catch { // Handle any errors. } } This compiles in Xcode 26.1 using the Swift 6 language mode and: Approachable Concurrency enabled Default Actor Isolation set to MainActor Note I’m using prepareTranslation() in my examples because it’s simpler, and that makes it easier to focus on the core issue. The drawback to this is that you can no longer access main-actor-isolated state from the closure. You can work around that using MainActor.run(…): try await session.prepareTranslation() … no isolation … await MainActor.run { … main-actor isolated … } Clearly this is less than ideal and I encourage you to file a bug against… actually, I think it’d be best to file a bug against the Translating

One thing that may be happening here is that your app is launching without the debugger attached, which is where Quinn's points about the system log come in. You can use the macOS Console app to look for your logs once you're using OSLog. Something I like to do in addition to that is configure LLDB to wait to attach until your process is launched. That way, when you use Siri to launch the app, the logs you're expecting will be picked up in the LLDB console. You can configure this in your Xcode scheme, under the Run options. With that configuration set, if you press the Run button in Xcode, the system starts LLDB, but not your app like usual when you press the Run button. You can then launch your app through Shortcuts or Siri, LLDB will now attach automatically, and record all of your OSLog statements inside of Xcode for that launch sequence. — Ed Ford,  DTS Engineer

Hello Apple Developer Community, Following my previous unanswered post, I created a very simple macOS test application to reproduce the issue in the smallest possible setup. I’m having an issue with ASWebAuthenticationSession on macOS when trying to authenticate with Microsoft Azure AD. I wrote a very simple macOS application whose only purpose is to sign in to Microsoft Azure and obtain an authorization code/token. The app is registered in Microsoft Entra as an iOS/macOS public client. Target macOS: 15.7+ App registration in Azure: Bundle Identifier: com.organization.testauthapp Redirect URI: msauth.com.organization.testauthapp://auth MSAL configuration: let kClientID = CCCCCCCC-CCCC-CCCC-CCCC-CCCCCCCCCCCC let kRedirectUri = msauth.com.organization.testauthapp://auth let kAuthority = https://login.microsoftonline.com/TTTTTTTT-TTTT-TTTT-TTTT-TTTTTTTTTTTT let kGraphEndpoint = https://graph.microsoft.com/ (I intentionally anonymized tenantId as TTTT... and clientId as CCCC....) My app contains only one button,

Here is a sample (in French, but easy to translate).

We've observed that the I/O behavior differs drastically depending on whether it goes through the system file cache: Quick question— how are you validating what the actual issue is? More specifically, are you pulling, unmounting the device, and testing with a known good driver? Or are you testing with your development DEXT? That's crucial because testing through your DEXT means you don't know whether this is a write or a read issue. That leads to here: At the end of the operation, to ensure data is flushed to disk, the macOS file system issues an fsync, which is ultimately translated into a SYNCHRONIZE CACHE SCSI command (Opcode 0x35 or 0x91) and sent to our UserProcessParallelTask_Impl. Are you sure about that? How have you validated that? I haven't tried to validate the entire I/O path, but I’m fairly sure that copyfile() (what cp calls) does not call fsync(). FYI, the history here is somewhat complicated and “ugly, but in general, if the system were going specifically trying to flush data, it woul

More Context: Xcode 26.1.1 New standalone watchOS project - default settings. There is a project with two targets - an iOS target and a watchOS target. The iOS target is at default - no code added or taken away all certificates and profiles point to my distribution certificate and provisioning. The bundle_id's seem good. The Project and ios share a bundle id of com.myteam.myapp The watchOS bundle id is com.myteam.myapp.watchkitapp There are identifiers for both in App Store Connect. The app compiles and runs on the simulator with no errors, all sizes, all languages. I do not have a watch connected to the account, but the code has been tested and I can't imagine that the lack of a physical device is causing the problem The scheme has the 3 archs in top to botton project, ios, watchOS - all marked to do everything they can and everything I see is marked to release. This is my first swift program and xcode experience, so I am confident that the error is my understanding of the workflow. thank you anyone

I update to the latest Xcode : Version 26.1.1 (17B100) Toolchain: Swift 6.2 Release 2025-09-11 (a) and MacOS to the latest : 26.1 (25B78) and still have the same crash problem, I give the crash report to an AI to summarize it : Primary Issue Assertion Failure in Scheme Execution: The crash occurred during scheme execution operations, specifically when Xcode was trying to create an execution operation for running a scheme. Key Technical Details Crash Location Thread 0 (main thread) crashed with SIGABRT (Abort trap: 6) Trigger: Assertion failure in IDEScheme class Specific Method: -[IDEScheme _executionOperationForSchemeOperationParameters:build:onlyBuild:buildParameters:title:buildLog:dontActuallyRunCommands:restorePersistedBuildResults:deviceAvailableChecker:error:actionCallbackBlock:] Crash Sequence Assertion triggered in IDEScheme operations Assertion handler called abort() Main thread terminated with abort signal The crash appears to be an internal Xcode assertion triggered by in