“translate scheme”

Seems like you have some UI which needs to change its appearance based on color scheme so SwiftUI reads the color scheme value from the environment and your view updates. Because of the way State works, transient instances of ModelData could be created and destroyed. Are you performing any side effect-like work in the model initializer? You should defer side effect-like work in the initializer to task or onAppear modifier.

I still can't figure out a way to stop the list from jumping back to the top when the device's Dark Mode setting changes. Why does SwiftUI think the data is different? A user changing the system appearance in isolation should not cause the the list scroll position to change. However. the body of a view will be called whenever you change the view such as by passing a value into its initializer from the parent view, and that value changes, or a dynamic property changes either explicitly because you changed an @State variable, or implicitly because you read something from the environment and that value changed such as like the color scheme. You can include let _ = Self._printChanges() in a view body while debugging to see why the view’s body was triggered.

Hello, The solution I came up to was: Close Xcode. Remove the hidden folder .swiftpm from the Package folder. I noticed the UserInterfaceState.xcuserstate file in a subfolder of this folder contained some references to the languages (I could find language codes in it like pt-PT). Open the package again with Xcode. The languages that weren't translated at all (0% progress) got removed from the string catalog. The other languages where at least one string was translated stayed in the string catalog. I don't think this is ideal but I hope it can help others. Axel

Okay, I made it working exactly as I wanted, so I'd like to inform all people participating here, but also others who might see this while searching for similar content. The first stumbling block was making sure the application can actually send Apple Events in the first place. And in that regard I admit I should've listened better to @Etresoft and I apologize to him for not listening more carefully and dismissing his remark about hoops so that the app can actually send Apple Events too easily. It turned out that, even though the application is NOT sandboxed, com.apple.security.automation.apple-events entitlement is mandatory in the entitlements file. I couldn't assume it would be necessary even for a NON-sandboxed app, but it is. From my experience with executing AppleScript from another, sandboxed, application I remember that defining com.apple.security.automation.apple-events in the entitlements file and NSAppleEventsUsageDescription in the Info.plist file always go together and that's the case here too. S

Sure, that's the translation of the picture content. Thank you very much for your help! /Users/hututu/Downloads/IMG_E6E06923A6AB-1.jpeg

Thank you for the post. Unfortunately, I am unable to translate the image at this time. Would you be able to post the output so that I can view the error message? Looks like is TestFight issue? Thank you. Albert Pascual
  Worldwide Developer Relations.

When you build with xcodebuild, you have either a -target or -scheme option to reference what to build, and all of the build settings set on the referenced target will then be automatically used, the same as when building through Xcode. Most projects are configured for xcodebuild to build using the Release configuration of a target, so make sure that when you've configured the build setting for the target, that you've set the value you want for the Release configuration, or whatever other configuration you will target with you command line build. If you have a reason to alter the build settings for specific xcodebuild innovations, you can also override build settings for a target by passing overridden values at the end of your xcodebuild command by the exact setting name, such as GENERATE_PRELINK_OBJECT_FILE. The man page for xcodebuild has the syntax for that. — Ed Ford,  DTS Engineer

I'm aware that IOBufferMemoryDescriptor::Create can be used in DriverKit to allocate memory and share it with user space. However, is the allocated memory physically contiguous? True physical continuity is largely irrelevant on our platforms. At this point, all of our platforms include an IOMMU which manages mapping 64-bit memory ranges into the physical addresses visible to devices on the PCI bus. You can read more about how this actually works in Background Info on PCI Address Translation. Can it guarantee that when I subsequently call PrepareForDMA in IODMACommand, there will be only one segment? Yes. Many of our DEXTs actually check that segmentsCount==1 and assert (crash) on any value other than 1. Having the descriptor segment would imply that the machine was so far out of the expected behavior range that they'd prefer to crash instead of trying to sort it out. I'm actually not sure a DEXT could get IODMACommand to segment. Inside the kernel, this is typically caused by IOMultiMemoryDescriptor,