Has anyone been able to use the <new shared lib in...

# multiplatform

[Matheus Finatti]

Has anyone been able to use the new shared lib integration method in iOS apps with multiple projects? My app is made of a few projects and all of them depend on the shared lib, currently I have a target for a shared framework where I call copyFramework in its build phases, this target is then included in all projects.
I have tried adding it by changing copyFramework to the new embedAndSignFrameworkForXCode which didn’t work (project won’t compile because it can’t find the shared lib No such module 'shared' .
Also tried removing this target entirely and recreating the steps in the blog post in every project, but it also didn’t work.

[iamsteveholmes]

I was able to make it work by following the directions but calling the Gradle tasks directly fails

[russhwolf]

The instructions don't call it out, but the Xcode setup needs to change slightly if you have a different module name or framework name. Is your shared module called something other than shared?

[Matheus Finatti]

Yeah the task is supposed to be called from Xcode only. It doesn't work from the CLI.

@russhwolf Yeah my module is called differently from shared but I've adjusted that in gradle by setting the framework's baseName and making the adjustments in Xcode where appropriate

[russhwolf]

So are you getting No such module 'shared' or is the error reporting your actual module name?

[Matheus Finatti]

It's reporting the actual name, sorry if it wasn't clear

[Matheus Finatti]

For example

import MobileCommonLib              --> No such module 'MobileCommonLib'

[russhwolf]

oh it's the Swift side giving the error, not the gradle build. I misunderstood

[Matheus Finatti]

The projects setup in XCode is something like this:

ios_common_X
ios_common_Y
ios_feature_A
ios_feature_B
app

where all the projects depend on the shared lib.

[Matheus Finatti]

Yes, it's the iOS side that's giving me headaches

[Matheus Finatti]

I also tried setting up with cocoapods instead, but adding the pod to all projects causes another set of errors:
A warning for all classes:

Class X is implemented in both module A and mobule B. One of the two will be used, which one is undefined

and this runtime exception

Unable to add 'toKotlin:' method to NSBLock class

[russhwolf]

Did you have it working with copyFramework? There are a lot of limitations when you try to include Kotlin in multiple ios modules

[Matheus Finatti]

It's working with copyFramework.
Under the app project we have a target called MobileCommonLib which calls copyFramework in its build phases.
Then, every module in iOS have it as a dependency.

[russhwolf]

Does the embedAndSignFrameworkForXCode task succeed? Maybe there's just a name mismatch somewhere

[Matheus Finatti]

Is there any way to check that from XCode? Since the task doesn't run from cli

[russhwolf]

You should be able to see build outputs in the report navigator. It's the rightmost tab in the left pane

[Matheus Finatti]

It says Task :common:embedAndSignAppleFrameworkForXcode UP-TO-DATE but I don't see the compiled framework anywhere in my iOS folder

[Matheus Finatti]

Also ran after a ./gradlew clean and it completes successfully

[russhwolf]

I'm not sure, then. Maybe the framework is being generated with the wrong name or something?

[Matheus Finatti]

In my shared module build folder I can find it under xcode-frameworks/Debug/iphonesimulator14.5/ with the correct name
a folder MobileCommonLib.framework and a file MobileCommonLib.framework.dSYM

[Matheus Finatti]

I guess it's expected now that the framework isn't copied anymore, since we set Framework search path to the build folder

[Matheus Finatti]

Just noticed that the SDK_NAME folder from

$(SRCROOT)/../shared/$(CONFIGURATION)/$(SDK_NAME)

is resolved as iphoneos14.5 in XCode, while it's generating iphonesimulator14.5 not sure it makes a difference.

[Matheus Finatti]

Manually changing the folder name still doesn't work