https://kotlinlang.org logo
#touchlab-tools
Title
# touchlab-tools
b

Bradleycorn

11/14/2023, 3:24 PM
Hi all! I’m having a bit of a weird issue with KMMBridge. I have my project all configured and published, and I’m using cocoapods integration with my existing iOS app. Everything seems to work. I can build my ios app, it runs (on the simulator at least), and doesn’t seem to have any issues (hooray!). BUT … In the Xcode IDE, whenever I import my shared module at the top of one of my swift files, it shows an error:
Copy code
Failed to build module 'SharedModule'; this SDK is not supported by the compiler (the SDK is built with 'Apple Swift version 5.7.2 (swiftlang-5.7.2.135.5 clang-1400.0.29.51)', while this compiler is 'Apple Swift version 5.8 (swiftlang-5.8.0.124.2 clang-1403.0.22.11.100)'). Please select a toolchain which matches the SDK.
(Note,
SharedModule
is the name of … wait for it …. my shared module) As I mentioned, the app still compiles and works fine, but that error is annoying and confusing. Also, it’s probably worth mentioning that another developer on the team does NOT get that error. The only difference we are aware of is that I am on a mac with an intel architecture and he’s on a newer mac with M1 architecture. May also be worth mentioning that we are using SKIE as well (version 0.5.5). Has anyone else seen this issue?
My cocoapods config looks like this:
Copy code
cocoapods {
        name = "SharedModule"
        summary = "Shared business logic for our ios and android apps"
        homepage = "<https://github.com/myorg/myrepo>"
        ios.deploymentTarget = "14"
        extraSpecAttributes["libraries"] = "'c++', 'sqlite3'"
        license = "BSD"
        extraSpecAttributes.put("swift_version", "\"5.0\"") // <- SKIE Needs this!
        framework {
            baseName = "SharedModule"
            linkerOpts.add("-lsqlite3")
            export(project(":core:models"))
            export(project(":feature:program"))
            isStatic = true
        }
        xcodeConfigurationToNativeBuildType["TS-DEBUG"] = NativeBuildType.DEBUG
        xcodeConfigurationToNativeBuildType["DK-DEBUG"] = NativeBuildType.DEBUG
        xcodeConfigurationToNativeBuildType["KS-DEBUG"] = NativeBuildType.DEBUG
        xcodeConfigurationToNativeBuildType["OA-DEBUG"] = NativeBuildType.DEBUG
        xcodeConfigurationToNativeBuildType["BA-DEBUG"] = NativeBuildType.DEBUG
        xcodeConfigurationToNativeBuildType["TS-PROD"] = NativeBuildType.RELEASE
        xcodeConfigurationToNativeBuildType["DK-PROD"] = NativeBuildType.RELEASE
        xcodeConfigurationToNativeBuildType["KS-PROD"] = NativeBuildType.RELEASE
        xcodeConfigurationToNativeBuildType["OA-PROD"] = NativeBuildType.RELEASE
        xcodeConfigurationToNativeBuildType["BA-PROD"] = NativeBuildType.RELEASE
    }
t

Tadeas Kriz

11/14/2023, 4:16 PM
Could you check what version of Xcode the framework is built with, what version you have and what version your colleague has?
b

Bradleycorn

11/14/2023, 4:35 PM
@Tadeas Kriz We are both on 14.3. The framework was built by github actions (using the touchlab kmmbridge github workflow). It looks like that workflow uses the
macos-12
runner, and as near as I can tell, that runner uses Xcode 14.2 by default, assuming this is correct: https://github.com/actions/runner-images/blob/main/images/macos/macos-12-Readme.md#xcode
t

Tadeas Kriz

11/14/2023, 4:36 PM
Are you sure you both have 14.3 active? Is it possible one of you have the local switch enabled for KMMBridge?
b

Bradleycorn

11/14/2023, 4:38 PM
Yes I’m sure. When you say the “local switch”, I presume you are reffering to the setup where you can set an environment variable and have it use a local podspec and build locally instead of using the published podspec? We actually haven’t set that up yet in our podfile, so I am sure we are not using it 😄
t

Tadeas Kriz

11/14/2023, 4:38 PM
That's weird, you should both see the warning if you're on the same Xcode.
Could you share more of the build log that has the
Failed to build module 'SharedModule';
in it?
b

Bradleycorn

11/14/2023, 4:40 PM
Sure. But like I said, the build doesn’t ACTUALLY fail. I get that error in the IDE, but if I build (CMD+B) and/or run (click the ▶️ button) my app, it builds and runs fine. it’s very odd
t

Tadeas Kriz

11/14/2023, 4:41 PM
So it's not in the build log at all?
b

Bradleycorn

11/14/2023, 4:41 PM
I don’t think so, but let me double check
yep. nothing.
t

Tadeas Kriz

11/14/2023, 4:44 PM
Huh, that honestly sounds like a weird Xcode caching issue. Could you try cloning the project in a separate directory and opening it in Xcode to see if you have the same error?
b

Bradleycorn

11/14/2023, 4:44 PM
ok. I’ll also try deleting DerivedData .. that seems to be common source of problems
@Tadeas Kriz deleting my DerivedData seems to have solved it. I have another dev on the team who was running into the same issue, but his actual build failed. After talking with him, his build started working as well, and I think maybe I know what was happening. Perhaps you can tell me if this sounds right. So, he did
pod install
and then opened our ios app workspace in Xcode. It showed the same error I was seeing. He did a build, and the build DID fail. But it also included several new errors about Ambiguous (kotlin) types. Those are known errors that we had. In version 0.0.15 of our KMM library we had configured the framework with transitive exports (oops):
Copy code
export(project(":core:models")) { transitiveExport = true }
export(project(":feature:program")) { transitiveExport = true }
I then published a new version (0.0.16) that removed the transitive exports, and update the app to use version 0.0.16 When my other dev pulled the updated app project, and then opened it in Xcode, he still saw the “Failed to build module …” error in the IDE. But then, when he did a build (CMD+B), it succeeded. The “Ambiguous type” errors are gone, but the other error still shows up. I had him do Product > Clear all Issues to remove it, and then do another build, which also succeeded. Now, he can close and open the project in xcode and it all works fine. So, I think that originally there WAS a build error due to the exporting of transitive dependencies in the kmm library, but until trying to do a build, the Xcode IDE would just show “Failed to build module ‘SharedModule’. SDK is not support by the compiler…“. Only after doing a build would you see the REAL errors. And then once that issue was fixed (in the new 0.0.16 version), the build would work fine, but Xcode was still showing that original error because of, as you put it, “a weird Xcode caching issue”. And once we “manually” told xcode to clear it’s issues list, it went away and does not come back, because there is no issue. Does that seem right?
5 Views