Platform specific resources

Using Swift
,
1

If a package contains iOS specific resources (eg. Xib views), Xcode complains that these resources are not available when building the package for macOS.

iOS xibs do not support target device type "mac".

Is it possible to restrict resources to a specific platform?

Code using these resources is wrapped with #if canImport(UIKit)

1 Like
2

You can exclude certain files when defining a .target in Package.swift. Search for Excluding Files in here: Add resources to Swift packages

3

The only solution I can think of is extracting the resources to a separate package and using conditional dependencies.

This seems rather unfortunate, though, and we should work out a solution. Since this is somewhat Xcode specific, would you mind filing a feedback report for this?

3 Likes
4

Will do, thanks!

5

@eimantas, thanks for the help. Unfortunately, that would exclude the resource from all platforms, not just macOS.

@NeoNacho FB8964378 (for reference)

6

You can conditionally compile excluded sources for every platform you can use #if os with. e.g.:

#if os(iOS)
let ignoredFiles = ["first", "second"]
#else if os(macOS)
let ignoredFiles = []
#endif

And use that value in the Package definition.

7

This doesn't generally work since the manifest is compiled only once during package loading and not necessarily for your target platform. Additionally, both Xcode and CLI SwiftPM will always compile the manifest for the host platform. So in your example, you would always end up in the macOS branch even if you might be building for iOS. This kind of approach does work if you want to distinguish between Linux and macOS, though, at least as long as we ignore cross-compilation.

1 Like
8

Hi there. Does anyone have any workarounds/updates they'd like to share? I've been experimenting with the approach mentioned by @NeoNacho in #2 but am still wrestling with platform specific compile errors.

9

The only success i had so far is using conditional dependencies with local package, however that solution seems to lead to dead end, because it turns out that we can't publish a package that depends on private local package.

So the only option at the moment is to publish any platform specific resources as public packages, then conditionally depend on them. That works, but it is very inconvenient to manage.