Hello everybody, I hope you are doing well. I have...
# multiplatform
m
Hello everybody, I hope you are doing well. I have migrated to Kotlin 2.0.0 then when I build the iOS framework I noticed that the structure of the generated folders changed but Xcode can still find the framework even though the folder "xcode-frameworks" that is mentioned in the Framework Search Path in Xcode does not exist in the new structure of the generated folders. Do you have any idea how is this possible ?
2
@Marceli Grabowski I found a blog post by JetBrains talking about linking Xcode to the shared module. At the end it comes down to a Gradle task "embedAndSignAppleFrameworkForXcode" that can be executed only in xcode.
p
Yeah specifying
Framework Search Path
and
Other Linker Flags
seems that is not needed anymore. Basically is done in the various KMP Gradle tasks.
k
I'd want to test this out. Any chance you're building dynamic frameworks? Dynamic doesn't need the search paths. Static does (iirc). If we don't need it anymore, that would make the process somewhat simpler, although I could see projects with odd config needing updates to accommodate the change (multiple targets, etc)
👀 2
j
Is the embedAndSignAppleFrameworkForXcode task documented anywhere other than this blog post? https://blog.jetbrains.com/kotlin/2021/07/multiplatform-gradle-plugin-improved-for-connecting-kmm-modules/ Which is quite old and still mentions the framework search path is needed
k
I don't know, honestly. I was adding it to some docs I wrote, and that's the best I could find. I know 1.9.2x still needed paths, but haven't tried 2.0 yet (about to).
p
I believe the last project I created in https://kmp.jetbrains.com/ was just opening Xcode and run. No additional steps AFAIR. I did select shared UI not sure if that makes a difference.
k
I'll probably dig into the kotlin source at some point, but not today...
👍 2
l
Builds pass, but do your Xcode IDE inspections work without Framework Search Paths though? Mine do not, I had to hardcode the
Framework Search Path
to the new location:
$(SRCROOT)/../composeApp/build/bin/iosSimulatorArm64/debugFramework
I am using custom xcode build configurations though (
DEV Debug
etc.) and I have the
KOTLIN_FRAMEWORK_BUILD_TYPE
mappings defined in Build settings.
m
@Lukáš Kúšik - did you switch
isStatic = true
to
isStatic = false
in
binaries.framework
? Xcode autocompletion wasn't working for me as well until I changed that setting
s
Hi folks! We would like to further simplify the initial integration of KMP into iOS target. So in the future there will be no need to explicitly specify the path to the framework in Search Path, and this feature is partially working. We plan to finalise it for the next minor release, and we will explicitly talk about it. Related YT tickets: • firstsecond Thanks for your consideration!
👍 4
l
@Marceli Grabowski I tried switching to
isStatic = false
, cleaned XCode and Gradle but I still get
No such module 'ComposeApp'
in XCode ☹️
k
Making this easier to set up is good. I don't find the search paths and liker flag thing to be too bad, but I've making Android things work in Xcode for almost a decade at this point (if you count the J2Objc work). This method is really better overall than using CocoaPods or the various local SPM options. We also need a better "name" for it. "Embed" isn't accurate for static frameworks. IIRC the current name is "direct linking", but that's kind of vague. It's more of a description than a name. But I digress...
p
Lukas I think you can't hardcode a fixed path but instead it has to be flexible for the directory change according to the selected target/scheme. To get this value, generate a project in the kmp website, open project.pbxproj file, look for the value of
framework_search_path
and copy it.
l
Yes I'm aware, I could figure out the template for the new path, but as long as the builds work okay I just keep the hardcoded path for the Xcode IDE suggestions. The official Kotlin KMM template still has the old path with the xcode-frameworks folder in the project.
💯 1
👍 1
p
In my experience pretty much all the integration solutions behave the same. I initially thought it would be possible for Xcode to pickup changes immediately as soon as they happen in KMP side but it doesn't seem to be possible since it is depending on a compiled framework not swift code. I think it is a limitation we are going to live with(maybe not if exporting individual files changes incrementally to the xcframework). But if not possible, I guess it is a motivation to push the most code to kotlin side 🤷‍♂️
k
In my experience pretty much all the integration solutions behave the same.
Depends what you mean by "behave". As far as picking up changes, sure. However, CocoaPods has that weird "dummy" thing where you need to run it first, then run pod install again. It also has all the extra "stuff" from CocoaPods (Pods folder, workspace, etc). When most teams used CocoaPods, that made sense, but not any longer. As for SPM, you can't really integrate it directly without wiring your own run script. Then you'd want to get specific with build type (release/debug) and architecture. You could, of course, but that's a fair bit to configure. From a dev perspective, the direct option is simpler. However, I'm sure some iOS teams will push back on it and insist on some kind of SPM-based solution.
💯 1
p
Well I actually haven't touched cocoapods in a while and I don't plan too. I do feel direct integration, at least for development, is the more convenient approach. SPM is great for when you have all the artifacts (packages) ready and then just need to run a pipeline or so. But yeah most iOS folks will buy easier into SPM than anything else