Post

Replies

Boosts

Views

Activity

Reply to @Invalidating property wrapper availability
From what I've read online it wasn't available in the early Xcode 13 betas, but supposedly it's available in the current one. You might try upgrading Xcode 13 and see how you go. If you need a version that works back to Xcode 11, macOS 10.11 and iOS 11, I wrote an alternate version with basically the same functionality. It's MIT and the code is available so you can go nuts with it! It should work with any project that supports Swift 5.1 (when propertyWrappers and static subscripts were introduced) You can find it here
Jun ’21
Reply to SwiftUI Previews in Xcode 14 failed to run with SettingsError: noExecutablePath(IDESwiftPackageStaticLibraryProductBuildable)
I've been finding this with my own SPM packages, and reported by a number of users of that package. Filed bug FB11397938 back in August. SettingsError: noExecutablePath(<IDESwiftPackageStaticLibraryProductBuildable:ObjectIdentifier(0x000060000d2b3b70):'QRCode'>) Easily reproducible by adding a package to a blank SwiftUI project in Xcode 14. Cannot be reproduced in Xcode 13.
Sep ’22
Reply to SwiftUI Previews in Xcode 14 failed to run with SettingsError: noExecutablePath(IDESwiftPackageStaticLibraryProductBuildable)
Linking against a .dynamic type library fixes the SwiftUI preview breaking (well, at least for me) both on iOS and macOS For example, linking against QRCodeDynamic (in my package.swift) :-  .library( name: "QRCodeStatic", type: .static, targets: ["QRCode"] ), .library( name: "QRCodeDynamic", type: .dynamic, targets: ["QRCode"] ) the SwiftUI previews start working correctly. Linking against a static library type always fails. At least this is a workaround if you're stuck. This also works if the type is not specified. .library( name: "QRCode", targets: ["QRCode"] ), But not a fix.
Sep ’22
Reply to SwiftUI Previews in Xcode 14 failed to run with SettingsError: noExecutablePath(IDESwiftPackageStaticLibraryProductBuildable)
I followed Microsoft's approach with my own libraries and removed the library type(s) from the Package.swift file and the issue 'goes away'. Hopefully this reduces the bug reports coming in stating that my library has 'broken' SwiftUI. However, this is purely a workaround of the issue and not a solution. Some clients want to explicitly define their library usage and for them the Xcode bug persists. If this is somehow my problem (ie. I'm using SPM incorrectly) then it would be awesome to understand how to fix it (especially since Xcode 13 didn't have this issue).
Nov ’22