You can edit the baseline file directly and add the maxRegression value into it. It seems Xcode does not delete it after changing the baseline from the tests. <key>maxRegression</key> <real>0.010000</real>

Still an issue in Xcode 15 RC1.

Try adding the following to the OTHER_CODE_SIGN_FLAGS in the Build Settings of your app target: -o runtime --runtime-version $DEPLOYMENT_TARGET This will enforce the new signature version for all binaries in your target and the app the can be successfully installed on a device.

Found a workaround and described it in this thread. TL;DR Adding the following options to the codesign command will result in a v=20500: -o runtime --runtime-version "16.4.0" So the solution would be adding those options to the OTHER_CODE_SIGN_FLAGS in the Build Settings of your app target, e.g.: -o runtime --runtime-version $DEPLOYMENT_TARGET After this the app successfully installs on a device.

Just stumbled upon this issue when using an XCFramework Swift package and found a solution. To enforce a specific code signing version you need to use two extra command line options: -o, --options flag,... During signing, specifies a set of option flags to be embedded in the code signature. The value takes the form of a comma-separated list of names (with no spaces). Alternatively, a numeric value can be used to directly specify the option mask (CodeDirectory flag word). See OPTION FLAGS below. --runtime-version version During signing, when the runtime OPTION FLAG is set, explicitly specify the hardened runtime version stored in the code signature. If this option is omitted, but the runtime OPTION FLAG is set then the hardened runtime version is omitted for non-Mach-O files and derived from the SDK version of Mach-O files. Adding the following options will result in a v=20500: runtime --runtime-version "16.4.0" After this the app successfully installs on a device. You can add those option to the OTHER_CODE_SIGN_FLAGS in the Build Settings of your app target.

It is still an issue in the Xcode 14.2 and is very annoying. More to that, the SwiftUI Previews build does not run Swift Package build plugins, making the test target build failing if it relies on those. One has to first build the target for testing to trigger the package plugins, then the previews start working.

Using the GeometryProxy outside of SwiftUI body seems to be unsafe and causing the "AttributeGraph precondition failure: setting value during update: 634424." fatal error. Make sure to copy the necessary information into a variable before storing it for later use or capturing by a DispatchQueue.async or Task closure.

When running a preview on an app target, the target is used as the preview's host. When running a preview on non-app targets, Xcode is using XCPreviewAgent as the host. The problem is that XCPreviewAgent process does not allow debugging. But we can workaround this. The XCPreviewAgent is just a dummy iOS app without any logic, so we can create our own app with same name and bundle identifier, build it with debug capabilities and install it on the simulator used for running the preview. To do that, first install the app on normal simulator by running the app, then copy the bundle to the preview simulator (you can find the path by checking the issue report in Xcode's preview canvas). After that we will be able to attach debugger to now our custom XCPreviewAgent and debug our previews. I'm using this hack to develop SwifUI views in isolation as a separate Swift Package without a real need for a project file. Running SwiftUI previews on the main app is very inefficient as the whole project has to be rebuilt every time you run a preview.