Generate images and colors inside a Swift package

Using Swift
,
1

I saw that now, Xcode 15 beta can help us generate our assets to facilitate the access instead of passing the color/image name.

I saw that ASSETCATALOG_COMPILER_GENERATE_SWIFT_ASSET_SYMBOL_EXTENSIONS should be true in Xcode 15 beta to make this happen.

How can we set this value to true in the case of a Swift Package?

Tried this, but it's not working:

// swift-tools-version: 5.9

import PackageDescription

let package = Package(
    name: "Common",
	platforms: [.iOS(.init(stringLiteral: "17"))],
    products: [
        .library(
            name: "Common",
            targets: ["Common"]),
    ],
    dependencies: [],
    targets: [
        .target(
            name: "Common",
			dependencies: [],
			resources: [
				.process("Resources")
			],
			swiftSettings: [.define("ASSETCATALOG_COMPILER_GENERATE_SWIFT_ASSET_SYMBOL_EXTENSIONS")]
		),
        .testTarget(
            name: "CommonTests",
            dependencies: ["Common"]),
    ]
)
2 Likes
2

Those extensions are generated by Xcode invoking actool with a set of arguments to produce .swift source files based on the project's assets.

SPM doesn't have support for that directly, but you might be able to write a build plug-in that does the same invocation (look at Xcode's build log to see what flags it's passing) and then wire that source file into the rest of the build.

2 Likes
3

At least Xcode 15 beta 3 generates asset symbols automatically for packages, as per release notes.

So, it might be that future releases will also generate symbol extensions.

From what I'm seeing build logs have a Generate asset symbols invocation for each Swift Package target (when building an Xcode based target that links to packages or in isolation), and for some reason not only --generate-swift-asset-symbols is passed when actool is called for them but also --generate-swift-asset-symbol-extensions NO which disables the generation of symbol extensions.

4

Am running Xcode 15 Beta 4, but and not even seeing the "Generate asset symbols" step in the build logs for my local Swift Package. What am I doing wrong?

Ok, Xcode 15 Beta 5 is now generating the asset symbols correctly, but the extensions are still not being generated. :frowning_face:

5

is it possible to expose these generate symbol outside the package in the main app or other package

6

Does anybody know if it's possible to turn off this symbol generation? It's causing conflicts with existing symbols in our code, and the quickest (temporary) workaround would be to disable this new generation. But, I don't think you can set a build setting like ASSETCATALOG_COMPILER_GENERATE_ASSET_SYMBOLS=NO via SPM.

Are there any other clever workarounds to get it to skip or ignore this new generation?

1 Like
7

I am also interested in this.
In addition, I would love to know how to get the ShapeStyle & Color extension generated for color resources that are part of an Xcode project. The "Asset symbol generation" does seem to be incomplete for Swift packages...

8

any one able to generate symbols from package yet?

9

anyone know if you can make these extensions public? We have a design system swift package and would like to expose all of our colors/icons in this way.

8 Likes
10

I'm really interested in this as well, using XCode 15.0.1 we still don't have access to the generated symbols outside the swift package manager.

1 Like
11

There actually is a workaround to use Assets from a Package in other Packages or in the App.

You can create the target as you did.
The swiftSettings: [.define("ASSETCATALOG_COMPILER_GENERATE_SWIFT_ASSET_SYMBOL_EXTENSIONS")]
is not necessary for this workaround.

You just need to create a public extension on Image like

public extension Image {
static var yourImage: Image { .init(.yourImage as ImageResource) }

init(_ image: Image) {
        self = image
    }
}

The .yourImage is the image from your asset catalog, which is automatically generated.

As soon as the public auto-generation works you can just delete the extension and there should be no changes on the call side.

For colors you can use sth like:

public extension Color {

static var customColor: Color { .init(.customColor) }
}

public extension ShapeStyle where Self == Color {

static var customColor: SwiftUI.Color { .init(.customColor) }
}

Color seems to work without the extra init method.

2 Likes
12

@Eirias asset generation is introduced to reduce these kinds of boiler codes. if we create these manual properties in the extension so what will be the benefit of using it? and in this approach manual work is still there

1 Like
13

is anyone able to achieve that ?

14

I can assure you that there's currently no way to change the access-level of generated assets to public. @Eirias's solution is currently the best out there in my opinion. We could possibly think of a Swift macro to apply on an enum and make these boilerplate automatically generated as well.

One of the benefits of not having the public auto-generated assets is that, unless you have a package to store all your assets, it is unlikely that you will need to have all your assets public.

15

Seems like there is no change to this in Xcode 16 Beta 1 right?

16

Nope.

I posted about it on the Apple dev forums, don't have much hope though Public generated asset symbols | Apple Developer Forums

17
1 Like
18

Finally :tada:

19

Asset catalogs now provide an inspector property for enabling system color and image accessors for generated asset symbols, which allows Swift packages to opt-in to generating these accessors. (113704993)

Can anyone who has downloaded Xcode 16 beta 3 try this out and confirm that this new asset catalog inspector property will allow for generated symbols to have public accessors?

(Will test this out in the morning, just wanted to see if anyone was available.)

20

Xcode 16 beta 3 adds this dropdown to the inspector when an asset catalog is selected:

image
image522×810 51.6 KB

Xcode 15.4 for reference:

image
image520×750 38.8 KB

There doesn't appear to be a way to make the generated symbols public. So this is still "unsolved".

3 Likes