Wonder if anyone here might be able to help with t...

# multiplatform

[James]

Wonder if anyone here might be able to help with this?

[tapchicoma]

@Timofey Solonin maybe you could help?

[Timofey Solonin]

Hi! Could you please elaborate what exact build issue you are seeing:

it fails to find the search paths in our QA variant

Do you see a compilation error in the consuming Swift/Objective-C code or is it a linkage error or something different?

[Timofey Solonin]

Can you please also try not specifying any Framework Search Paths at all. Since 2.0.0 just calling embedAndSignAppleFrameworkForXcode should be enough and K/N generated framework should be produced by Kotlin Gradle Plugin at search paths Xcode build system passes to the compilers and the linker implicitly.

[James]

Thanks, I’ll give the second comment a try and see what it does.

For the first item though. It can error in the Xcode project on anything that is in the created lib. Sometimes if you just run, it’ll “just work anyway” but other times it doesn’t and those times checking the header files don’t show the items expected. 😞

[James]

I’ve been working in a side test project to play with some ideas without a QA config and it’s been working fine. So it seeps specifically our use of the second QA config in the main project is what’s causing issues.

[James]

Removing Framework Search Paths just shows the big ? whenever I try and drill into something in the generated lib. 😅

[James]

Just to clarify, if I clean the build folder and then run the QA scheme and config in Xcode then I get the ? when trying to get details for items in the generated lib. If I look at composeApp/build/xcode-frameworks I just see a Debug-QA folder (the name of my config) with the framework.

If I build to prod scheme and config then in the same place I get a Debug folder with the framework in it. Selecting items now works and I do not get the ?. Removing this again and the ? appears again. (this also works if you rename the -QA dir to remove that suffix, so somewhere it’s still expecting the non-suffixed version).

In my mind reading through the docs the KOTLIN_FRAMEWORK_BUILD_TYPE felt like it was trying to normalise this. So whatever config you’ve made in Xcode, you’ll just get a Debug and Release dir in xcode-frameworks. So I’m wondering if I’ve misunderstood this, missed something or found an issue. 😅

[Timofey Solonin]

Could you please try the following workaround: in the script phase where you call

./gradlew :composeApp:embedAndSignAppleFrameworkForXcode

change the call to be

CONFIGURATION="$([ "$CONFIGURATION" = "Debug" ] || [ "$CONFIGURATION" = "Release" ] && echo "$CONFIGURATION" || echo "$KOTLIN_FRAMEWORK_BUILD_TYPE")" ./gradlew :composeApp:embedAndSignAppleFrameworkForXcode

then add the FRAMEWORK_SEARCH_PATH entry:

$(SRCROOT)/../composeApp/build/xcode-frameworks/$(KOTLIN_FRAMEWORK_BUILD_TYPE)/$(SDK_NAME)

and also specify KOTLIN_FRAMEWORK_BUILD_TYPE for each of your Xcode configurations to be either debug or release

Does the Xcode code completion and the build work as you expect with these changes?

[James]

Had to tweak the run script phase a bit to this:

CONFIGURATION="$([ "$CONFIGURATION" = "Debug" ] || [ "$CONFIGURATION" = "Release" ] && echo "$CONFIGURATION" || echo "$KOTLIN_FRAMEWORK_BUILD_TYPE")"
cd "$SRCROOT/.."
./gradlew :composeApp:embedAndSignAppleFrameworkForXcode

But that seems to work. Now in xocde-frameworks there’s a Debug dir when build the QA config/scheme

[James]

Out of interest with KOTLIN_FRAMEWORK_BUILD_TYPE , does it matter about the capitalisation of Debug and Release? I’ve left it as capatalised (like the docs show) but I’ve seen it a few places lowercase 🤔

[Timofey Solonin]

Thank you for validating. I have summarized the issue in KT-76278

capitalisation of Debug and Release

Capitalization doesn't matter

[James]

Thanks for clarification on the capitalisation 🙇

[James]

Thanks for creating the issue also. All looks good and I’ll track it, but I guess we can continue to use the extra lines in the run script as a work around for now?

[Timofey Solonin]

we can continue to use the extra lines in the run script as a work around for now?

Yes

[James]

Amazing. Thanks for all your help 😄