Preview Assets in Swift Package

[MarcoEidinger]

In a .xcodeproj I am able to enrich SwiftUI Previews with resources that are stripped during an archive of an app when placed in a “Preview Assets” asset catalog. See Development Assets in Xcode to enrich SwiftUI Previews for more info.

In a Swift Package, I am not aware of an option that resources, specified for a target in a package manifest, can be made conditional based on configuration.

Adding resources to Swift Package to enrich SwiftUI Previews have a negative impact on an app as it bloats its IPA size unnecessarily.

Do I overlook something or are there plans for Swift Packages to support development assets?

[NeoNacho (Boris Buegling)]

I can't talk about future plans for an Xcode centric feature like this, but there's currently no support for development assets in packages.

[MarcoEidinger]

@NeoNacho If Package Manager Conditional Target Dependencies would support configuration conditionals then it would be an option to create a dedicated helper target containing SwiftUI previews and resources for DEBUG configuration. But I guess there are no plans to introduce support for configuration conditionals?

[anreitersimon]

We are using this approach.

Swift Packages: exclude developments resources/assets from package used in archived app

One workaround is to rely on environment variables in your Package.swift You can then do something like this // swift-tools-version:5.7 // The swift-tools-version declares the minimum version of Swift required to build this package. import Foundation import PackageDescription let mocksEnabled = ProcessInfo.processInfo.environment["MOCKS"] != "NO" let package = Package( name: "MyPackage", defaultLocalization: "en", dependencies: [ ], targets: [ // your targets ]…

[MarcoEidinger]

Thanks for sharing your approach on this matter, anreitersimon.

[Joseph_Heck]

I'm doing exactly the same thing - environment variable triggers that are used to manipulate whats in, and out, of Package.swift. Not for this specific use case (preview assets), but the same pattern anyway.

[MarcoEidinger]

A question to you, @Joseph_Heck, out of curiosity: you are doing this for an internal Swift package (to modularize an iOS app) or for an open-source reusable Swift package? Using environment variable seems fine for an internal Swift package but not for an SDK-style Swift package

[Joseph_Heck]

I'm using it within an open-source package, specifically to expose a CLI exec that I use when developing the package - generating images for docs in one case, or enabling a benchmarking executable in another. I mostly came at it from the area of not wanting these additional targets "clogging up" a developer's experience when they go to "just use" the package.

[MarcoEidinger]

Interesting, thanks for sharing more lights on how you use this technique of environment variables.

[macserv (Matthew Judy)]

In the SE-0273 Acceptance thread, @NeoNacho stated that…

@NeoNacho

…it would be better to give target conditionals its own type instead of re-using the existing BuildSettingCondition type.

@NeoNacho: Was this effort tracked in a new proposal or other visible location? If not, can you give us an update regarding the current direction? Apologies if there's a discussion that I missed... I've spent a fair bit of time searching to no avail, and it's been quite some time since that quote. Thanks!

[NeoNacho (Boris Buegling)]

From what I see in the code, there's a TargetDependencyCondition type.

[macserv (Matthew Judy)]

@NeoNacho

TargetDependencyCondition

Sure, but unless there's something I'm missing, you can only create a TargetDependencyCondition for a collection of platforms, not build configurations (the scope of this thread).