I discovered this nugget of Apple Documentation. It visualises how the scheme is the link specifying which build target is used by the test target. Unfortunately this doesn't seem to be the case. The host application field in the test target (general tab) appears to be the main determinator. So my assumptions above seem to be correct, and you can be easily be misled into assuming one build target is used whereas in fact another target is used. Tip: Include a screenshot of the about page of your app/clip/widget to avoid being misled.

I've researched. The diagram is a slight oversimplification. Alternative 2 (@State) is the correct answer.

Apple replied today to say the problem has now been now fixed: Xcode 16.3 beta (16E5104o) https://developer.apple.com/download/ Posted Date: February 21, 2025

Posted in the wrong forum and I cannot figure how to move it so I’m closing this post.

Here's how to fix it... In the target for the Test Flight App in the general tab you'll find a framework, library, clips section and this contains the reference to the clip ( a relic of copying the original production target.) This must be deleted. However, you cannot delete it here (if you try, you'll get warning popups etc but the deletion fails. ) Instead, navigate to the Build Phases tab and scroll down to the Embed App Clips section and here you can delete it. Warning: Make sure you do this in the test flight target not the production target.

Additional information.... Even if I use safari to download the file from google drive or icloud it fails with no message at all. I suspect it's either an authorisation problem (can't determine how to authorize safari to access the simulation files) or a missing directory (i.e. simulator is trying to download to a non-existent directory).

I checked on a Mac mini . The share method worked there. Here’s hoping the next macOS update solves the problem for my MacBook.

LocalizedStringResource didn't seem to work. The .environment modifier may work on Views but not on the content of the view ( strings in the view used to build the shared content) However, the localizedString method suggested by AI did work despite looking messy. A shame there's not a simpler solution. @State var isOtherLanguage = false var body: some View { var myLocale: String { isOtherLanguage ? "de" : "en" } VStack { Toggle("Switch language", isOn: $isOtherLanguage).frame(maxWidth: 200) HStack { Text("❌\(myLocale): ") Text( LocalizedStringResource( "Hello world!", table: "Localizable", locale: Locale(identifier: myLocale) ) ) } HStack { Text("❌\(myLocale): ") Text( String( localized: "Hello world!", locale: (Locale(identifier: myLocale)), comment: "To share" ) ) .environment(\.locale, Locale(identifier: myLocale)) } HStack { Text("❌\(myLocale): ") Text(localizedString) } HStack { Text("✅\(myLocale): ") Text("Hello world!") .environment(\.locale, Locale(identifier: myLocale)) } HStack { Text("✅\(myLocale): ") Text(localizedString("Hello world!", locale: myLocale)) } } } func localizedString(_ key: String.LocalizationValue, locale: String) -> String { guard let path = Bundle.main.path(forResource: locale, ofType: "lproj"), let bundle = Bundle(path: path) else { return String(localized: key) } return String(localized: key, bundle: bundle) }

Many thanks Apple Engineer, func localizedString( is exactly what I needed and the fog is clearing :) Reminder to myself: func localizedString(_ resource: LocalizedStringResource, _ myLocale: String) -> String { var locale: Locale { Locale(identifier: myLocale) } var resource = resource resource.locale = locale return String(localized: resource) }