file uri scheme

Thank you for your post. When utilizing Universal Links to initiate a call to your application, the delegate that will be invoked in SwiftUI is: func scene(_ scene: UIScene, willConnectTo session: UISceneSession, options connectionOptions: UIScene.ConnectionOptions) { You can see that and how it works in the link: https://developer.apple.com/documentation/xcode/supporting-universal-links-in-your-app In case you are using deep linking to call your app, how have you registered the link in the info.plist? Scene Matching Rules: The handlesExternalEvents(matching:) modifier is used to specify which external events a scene should respond to. Ensure Correct URL Schemes: Double-check that the URL schemes you're trying to handle match exactly with what your app is set up to receive. For deep links like Companion://, ensure that this scheme is properly registered in your Info.plist under the CFBundleURLTypes key.
xml
 Review Scene Initialization: Your URLHandlerScene is initialized with a tem

The problem seems to be that extension targets that contain swift code aren't being handled properly.There's a workaround for this given in stackoverflow:You can put the following in your scheme so that it executes with every build:rm -rf ~/Library/Developer/Xcode/DerivedData/YourAppName-*/Build/Products/Debug-iphoneos/com.yourcompany.Name.extension.*Or, alternatively:touch ${PROJECT_DIR}/SOME SWIFT FILE IN EXTENSION.SWIFTYou need to add either of these, making adjustments for your particular project of course, here:Edit scheme... > Expand the Run mode in the sidebar > Pre-actions > Click '+' > New Run Script Action.It doesn't solve the underlying issue, but perhaps Apple will if they recieve bug reports.

•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.

Seeing similar. SPM previews work—when selecting appropriate scheme—but main app previews don't, failing to launch with very unhelpful message. Tried all the usual resets, cache deletions, restarts and rebuilds, to no avail. Have filed FB13954069 with report and diagnostics.

Go to Product -> Scheme -> Edit Scheme. Select Build in left side column and uncheck Find implicit dependencies But this flag should remain checked when you are building the project for first time..This workaround works great.One thing I notice is that I have to do a clean before the first build, otherwise won't work. After first build, uncheck Find implicit dependencies. The following 10 builds take no more than 30s 😉 . Unfortunately, after about 10 builds, it will start recompiling all swift files. Not sure if some changes I made trigger recompile or something else.

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

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.

I have seen this issue on other versions on macOS as well; I don't think this is specific to this version. You will need to trust the certificate when on the site click the padlock. Show the certificate in the details you should see the CA Issuers, click on the URI. (This will ensure the correct cert required is downloaded) You can then add this certificate into keychain.

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.

I've the same problem. Preview on iOs scheme is working fine but if I switch to macOS scheme I got the same error. Did you find a fix?

You can disable that log with: 1 - From Xcode menu open: Product > Scheme > Edit Scheme 2 - On your Environment Variables set OS_ACTIVITY_MODE = disable

Edit scheme -> Test -> press the + button and add the test (choose test targets to add to this scheme)

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/

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