“file uri scheme”

This is driven by the Optimization Level setting in the build settings for the target that contains the file you're editing. One of two things is happening… That value accidentally got set to something other than Onone for your debug build The scheme you're using has a configuration set that isn't your debug one. By default, projects come with a Debug and Release config. The Debug config is configured to build Onone, which means without optimizations. And the Release config is configured to build with optimizations. You just need to double check the build configuration selected for your scheme is your debug (usually Debug) one.

Sorry I didn’t reply sooner. At the time this thread started I wasn’t supporting universal links. [quote='763107021, kariaduu, /thread/763107, /profile/kariaduu'] Does hide app feature support custom URL scheme and universal link? [/quote] Another developer filed a bug about this (FB14973639) and the conclusion there is that this is behaving correctly. When an app is hidden, the system behaves as if the app isn’t installed. This affects a variety of features, including URL schemes and universal links. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

Hello,Did you set the OS_ACTIVITY_MODE variable by any chance?To check if you have this variable set (and turn it off), in Xcode 9, do the following:Select from Xcode menu Product -> Scheme -> Edit Scheme..Select the Run scheme and look under Arguments.If you see the OS_ACTIVITY_MODE variable checked, deselect it.

This is a different issue, which a long-standing bug in Xcode Intelligence. Many model providers don't support the /v1/models uri, and Xcode chokes on it. You can probably work around the problem with a proxy like tingly-box, but it's one more thing to set up.

As a workaround, I recommend that you try running your app with Metal API validation disabled (Click your build target -> Edit Scheme -> Options -> Metal API Validation -> Disabled).Additionally, please file a bug report for this issue using our feedback assistant tool at: https://developer.apple.com/bug-reporting/

•Initial Conditions ••Xcode Version 12.2 ••Deployment Info •••iOS 13.4 ••••iPhone ••••iPad •••macOS 10.15.4 ••••Mac enabled ••Two AppIcon Files w/ all image sizes •••Devices iPhone and iPad •••Device Mac ••Scheme Device •••iPhone 8 Simulator •Information given at end of the Issue Log ••Command CompileAssetCatalog failed with a nonzero exit code ••…/assetcataloggeneratedinfo.plist ••Instead of going to the info.plist file •••Went to the Project TARGETS > General Tab > App Icons and Launch Image ••The App Icons Source Drop-Down-List was empty •••1st selected the macOS AppIcons - The Issue did not change •••2nd selected the iOS AppIcons - The Build Succeeded ••Then changed the Scheme Device to My Mac - The Build Succeeded •Conclusion: The App Icons Source must be the iOS AppIcons file name This is a simple Reply, hope it saves other people some of their valuable time.

I resolved this issue by moving my pre-action and post-action bash scripts in the Build step of my scheme to scripts in the Build Phase. I added the following pre-action script in the Build step of each configuration.# TEST corresponds to the current Xcode scheme (Test). environmentFile=${PROJECT_DIR}/BuildProcess/CurrentEnvironment.txt echo TEST > $environmentFileI check my CurrentEnvironment.txt file to determine which configuration is active from the Build Phase scripts. I don't know how else to determine the active configuration from a Build Phase Run Script. If anyone knows of a better way, please respond.

It appears that the build system under Xcode 12 and higher is now validating that any files referenced in the Other Linker Flags (probably other build settings as well before actually building the target. The workaround to the problem is to force the file into existence before the target itself starts to build by touch-ing it prior to the build. The the existing project build phase script can still be used to populate the file before the build gets to the linking stage, the file just has to exist on disk. The Pre-action scripts in build schemes don't really work well for our situation, as we have several schemes that include the build targets. The best solution I've found is to move the generated plist file to a project relative location (instead of in $DERIVEDFILESDIR which is target specific). I then added an Aggregate build target to the actual target's project and made it a dependency of the original build target. This dependency gets built BE

I use a workaround: Create a new Xcode project, in the same git repo as your-swift-package, without adding any source code files. Add your-swift-package as a local package to your Xcode project (File-> Add Packages) Add your-swift-package as a dependency to the Xcode project's target (In the Xcode project select the target and add framework as usual) Add the test target of your-swift-package to the test scheme of the project (Open the scheme editor in the Xcode project, in test-phase, info tab, add the test target of your-swift-package to the enabled tests using the '+' button Configure the Xcode project to build in Xcode Cloud I hope that Apple will soon support building stand alone swift packages, so we do not need this additional workaround.

Update: It’s better to use preferredColorScheme(), otherwise you need to style the status bar and some swiftui view’s don’t style properly with colorScheme(). So, my strategy is to cache the current device color scheme on load (by reading the .colorScheme environment variable) and basically revert the color scheme to that when the end user wants to go back to ‘auto’ mode. However, it seems that you ultimately need to pass nil to preferredColorScheme() to react to system color scheme changes (this isn’t documented), so you can kick off a background task to set this to nil after you revert to the cached original color scheme. The only edge case where this doesn’t set the correct color scheme is if the system color scheme changes after your app launched.

You'll have to specify the path to the file. When you are running in the Xcode debugger, you may be able to specify that in the scheme settings somewhere. Normally these kinds of simple apps are designed to be compiled and run from the command line. In this case watch.txt would be located in the current working directory of wherever your Terminal shell happened to be using at that time.