Error 'unsupported Swift architecture' in generated -Swift.h file

Using Swift
, , ,
1

We are developing a bunch of xcframeworks, that are using some other xcframeworks, that are distributed via cocoapods.

Problem

After switching to xcode 14 build system, generated headers for our frameworks started looking like that:

#if 0
#elif defined(__arm64__) && __arm64__
// Generated by Apple Swift version 5.7 (swiftlang-5.7.0.127.4 clang-1400.0.29.50)
... bridging for arm64
#else
#error unsupported Swift architecture
#endif

For that part of developers and consumers of our framework, which uses Intel macs, it leads to errors, while trying to build for simulator.

Screenshot 2023-08-23 at 14.40.57
Screenshot 2023-08-23 at 14.40.571254×118 14.5 KB

Sample

I've created sample project that, reproduces issue and also includes script for creating xcframework, which is similar to the one we use - create-xcframework.sh.
I found out that the presence of pods affects this. If the framework does not use them, then there is no such error. Code fro creating xcframework is the same and can be found in branch no-pods-no-issues

For creating xcframeworks I've followed instructions from Creating a multiplatform binary framework bundle.
I've tried to resolve error following TN3117: Resolving architecture build errors on Apple silicon.

Common issues

I've found some common issues on stackoverflow and apple forum, but there is no working solution in any of them.

Questions

How to force generated swift header to contain define for x86_64 alongside with arm64?
Which setting leads to that kind of generation?
How should pods project be changed to avoid that side effects?

1 Like
2

I had this exact same problem, except that I was not using cocoapods, but it occurred when I used a home-made local Swift package. In addition to going down the same rabbit hole of "debugging" the generated header and finding the same problem as Aliaksei described, I also found that I needed to add a reverse-engineered User Header Search Path to Build Settings, so that this generated header would be included, and these Paths were different for Debug and Release. How could Apple have made using local packages so hard?

Answer, thanks to Brian Webster: Don't try to include the problematic generated Swift header of a local package or cocoapod. Instead, use the relatively new @import feature of Xcode to import the package's module. I reckon it would work similarly with your cocoapods. To do this, find all occurrences of

#import "MyPackage-Swift.h"

and replace with

@import MyPackage;

If it doesn't work, verify that Build Settings Enable Modules and Link Frameworks Automatically are set to their default YES values.

1 Like