I already did that: FB17603899

The snippet from the sample app is also not displaying properly in dark mode.

I tried it around the time I originally posted this thread, and that sample code project displays the dialog correctly, but it's not analogous to what I'm discussing here, because it uses IntentDialog. The repo I posted with the reproduction only uses a snippet view without a dialog. The dialog adds a top section with additional information. I just want to display the snippet. Also, when I wrap a snippet in an IntentDialog, sometimes I get the same behavior where the snippet doesn't adapt to dark mode. When I tried to build Apple's sample code project again just now, I got this error: Invalid value of WKCompanionAppBundleIdentifier key in WatchKit 2.0 app's Info.plist: com.example.apple-samplecode.AppIntentsSampleApp (expected com.example.apple-samplecode.AppIntentsSampleApp<redacted>)

I'm running iOS 18.5, and the snippet view is still showing the light colorScheme environment value in dark mode, with black text instead of white text.

Sorry, I forgot to make the repo public. It's now public. You're wrong about specifying .foregroundColor(.secondary). I tried that and it does not change the fact that the snippet view is not displaying properly in dark mode. Please read again what I wrote: The colorScheme environment variable is even showing light when the device is set to dark mode, so this is a bug in iOS. Please try the reproduction in the repo to see it for yourself.

I created a minimal reproduction here: https://github.com/DePasqualeOrg/Test-App-Intent-Snippet As I noted, this appears to be a bug in iOS.

@DTS Engineer , I don't see anything in that view that is different from what I already have: struct ResponseSnippetView: View { let text: String var body: some View { VStack(alignment: .leading, spacing: 8) { Text(.init(text)) } .padding() .frame(maxWidth: .infinity, alignment: .leading) } } As I mentioned, the text appears black in dark mode, not white as in the screenshot you posted. The colorScheme value inside the view corresponds to light mode even when the device is in dark mode.

@Scionwest2, I had the same problem: Moving a @ViewBuilder element of my view into a separate View struct fixed the compiler crash that happened during archiving. This was happening on Xcode 16.3 (16E140). I think this part of my code didn't change after I updated to the latest Xcode, so it seems to be an issue with the build tools in the latest Xcode. Cc @DTS Engineer

I deleted and re-created AppShortcuts.xcstrings, and then I got a different error about AppEnum and AppEntity being the only allowed types for a parameter. I had a phrase with a parameter that is a string. After removing that parameter from the phrase, my app builds.

It happens during the "Validate app shortcut strings metadata" build step. model is an AppEntity. There is an associated AppShortcuts.xcstrings for this project. The file contains the localizations for the different phrases, most of which have not yet been entered.

Yes, I noticed that I now no longer get the dialog about accessing files when launching my app in the development environment. I'm glad that's finally resolved.

And the solution to the "Unable to Install" error was to disable the App Sandbox in the build settings.

Now I'm getting this error when I try to run my app from Xcode on an iOS device: Unable to Install “” Failed to verify code signature of /var/installd/Library/Caches/com.apple.mobile.installd.staging/temp.PIDzl9/extracted/.app : 0xe8008015 (A valid provisioning profile for this executable was not found.) Please ensure sure that your app is signed by a valid provisioning profile. If this issue persists, please attach the following when sending a report to Apple: - A sysdiagnose from this Mac - A sysdiagnose from the device failing installation - An IPA of the app failing installation

These are the steps that I seem to have resolved it for me: I created a provisioning profile in my developer account, used this provisioning profile instead of the automatic signing (although it couldn't find a corresponding certificate), and then switched back to automatic signing in Xcode. I was prompted several times to enter my password, including during the archiving/uploading process, and then it finally worked when I submitted the build to App Store Connect.

It mysteriously got resolved when I changed my code signing settings to sign manually with a local provisioning profile and then changed them back to automatic. While uploading the build to App Store Connect, I had to enter my password several times to access the certificate. This seems to be a bug in Xcode or macOS.