Hi, I am tryin to follow one of the new tutorials ...

# kotlin-website

[Michal Klimczak]

Hi, I am tryin to follow one of the new tutorials with spm local packaging of multiplatform lbraries, but I feel like it lacks some important details:
https://kotlinlang.org/docs/multiplatform-spm-local-integration.html

1. The pre-actions script should be on the app scheme, not the package?
2. What's the Package.swift for our local package? Does it require any special reference for the embeded framework?
3. How is that supposed to work anyway, i.e. how running embedAndSign on the app module would make it importable on the local spm package and indirectly importable on the project?
4. import Shared? Usually it's import shared?
5. What's so special about Kotlin 2.x that it's needed for that to work?
There seems to be some magic involved, however this magic doesn't work for me unfortunately 😞 Any hints?

[Piotr Krzemiński]

wrong channel, I think - I'd ask on #C3PQML5NU or #C9JM6Q2UX

[Michal Klimczak]

I asked on multiplatform for the guidance, here I am rather pointing out, that the tutorial might need some development and clarification

[Nikolay Pachkov]

fyi @Danil Pavlov

[Michal Klimczak]

I made it work and will have a few additional notes later

[Michal Klimczak]

Promised notes:
1. It's worth noting, that this embeds the dependency on the project level and packages only get it via some magic (I don't know, hope you do). It's important, because it means that the local packages cannot be built as standalone packages (e.g. for previews or isolated feature development) which limits their usability.
2. It would be great to understand what's changed in kotlin 2.0 that enabled this behavior.
3. The tutorial assumes that we have embedAndSignAppleFrameworkForXcode already, so it also makes some additional unmentioned assumptions about "other linker flags" and "framework search paths".
4. It's good to only run the pre-action script when the build is running, not clean, sth like the script below
5. It's a bit weird that the framework isn;t mentioned anywhere in the Package.swift (even though it works), so a quick explanation how it works and why package.swift doesn't need to contain any reference to the build lib would be a nice addition.
6. Finally, I put the pre-script under Run, not Build, which I feel absolutely stupid about, but maybe I'm not the only one 😉 Just like you add a red border over one place of that screenshot, you could draw it over the "Build". Anyway, hate xcode with all those UI based configs that you can only show on screenshots, gradle files are so much nicer.
7. Not sure why import Shared, so far everywhere I've seen import shared

if [ "$ACTION" != "clean" ]
then
    cd "$SRCROOT/.."
    ./gradlew :shared:...
fi

In general, I'd love some more explanation that makes it less "automagical", because it's hard to adjust the tutorial to specific cases when we don't know how things work under the hood.

[Michal Klimczak]

Oh and for my specific usecase where I need those SPM packages to be built standalone I used pre-action script building of an xcframework with a binaryTarget in spm, which I haven't seen anywhere - which is weird because after a quick usage it seems like the best way to go forward. Maybe that should be presented as a yet another option - or at least the binaryTarget local SPM in general, even without the pre-action script

[Nikolay Pachkov]

Michal, thank you for the detailed comment! kodee loving
Our Technical Writing team will take it into consideration.
cc @Danil Pavlov

[Thomas Flad]

@Danil Pavlov Is it correct that SwiftUI Previews will not work with the approach mentioned here?

[Danil Pavlov]

Hey! If understand you correctly, Xcode can show SwiftUI previews even if it's a separate module, yes, regardless of the integration method

It depends on your IDE, rather then integration method. Xcode can previews SwiftUI layout, but not Compose Multiplatform layout. For that, you'd need Fleet