Heyho! My iOS colleague wrote that he gets the fol...

# kotlin-native

[Marc Reichelt]

Heyho! My iOS colleague wrote that he gets the following warning when importing the shared iOS framework:

ld: warning: ignoring file .../debugFramework/SharedCode.framework/SharedCode, building for iOS-arm64 but attempting to link with file built for iOS Simulator-x86_64

And indeed the debug framework only contains x86_64. I followed the tutorial on https://play.kotlinlang.org/hands-on/Targeting%20iOS%20and%20Android%20with%20Kotlin%20Multiplatform/01_Introduction

Is there a way to build a debug framework containing both architectures (i.e. a ‘fat framework’)?

[Sam]

See: https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#building-final-native-binaries

[Sam]

One thing to note, if you're including both x86 and arm instructions in the binary that you are uploading to Apple, it will be rejected. You'll need to use lipo to remove the x86 slice when archiving. It's a simple run script that can be added to the project file. https://stackoverflow.com/questions/30547283/submit-to-app-store-issues-unsupported-architecture-x86/51324598#51324598

[Marc Reichelt]

Thanks, that looks handy. Although the sample code shows how to support 32 and 64bit - we only need arm64 and x86_64 for the debug framework.
Shouldn't the upload be unaffected, because that should be the release framework? We only want to change the debug framework...

[Sam]

The compiler still has much room for speed improvements. Building two cpu architectures when most of the time you will only ever need one is slow. I recommend looking up some of the examples that have a packForXcode task in them that is called by the Xcode build process. It only ever builds the active architecture and is a much faster build run test cycle. This does mean that your iOS app code will have a direct dependency on the Kotlin code. Those iOS devs will need to have the Kotlin build tools on their machines in order to build everything.

[Marc Reichelt]

@jonnyzzz maybe you have the magic lines of code lying around somewhere? 😉

[Marc Reichelt]

Ok, I think I got it thanks to the documentation on https://kotlinlang.org/docs/reference/building-mpp-with-gradle.html#building-final-native-binaries and some GitHub code search… Thank you @Sam! 🎉

[jonnyzzz]

The main trick in Gradle script was to have it started from Xcode. Xcode sets environment variables depending on the target. We use it I. Gradle script

[Marc Reichelt]

Yep, I understand - but our iOS developer wanted to consume the binary artifact directly for trying it out. That’s why I wanted to know how to solve this.

[Michal Harakal]

@Marc Reichelt did iOS developer requested also bitcode?

[Marc Reichelt]

Not yet 😉

[Michal Harakal]

anyway, an interresting approach, if you don’t mind, I will use it as a sample in my next talk

[Marc Reichelt]

Yeah, sure!

[Marc Reichelt]

:)

[Sam]

The current EAP line can build bitcode versions compatible with Apple’s bitcode version.

[Michal Harakal]

1.3.60+?

[Sam]

Yes, there is a sample watchOS project in the repo. That’s something only possible with compatible bitcode support. https://github.com/JetBrains/kotlin-native/tree/master/samples/watchos

[Michal Harakal]

Thanks, I didn’t know about watchOs, what I have found was https://github.com/JetBrains/kotlin-native/issues/1202 So my interpretation is, that it was possible to build bitcoded frameworks before with 1.3.50, but “proper” one are commig with 1.3.60

[Sam]

Yes. Apple’s bitcode is a fork of LLVM’s. I do t know why it is still different after so long. Either Apple never submitted patches to LLVM or they never made it into the mainline.

[Michal Harakal]

Wav, thnaks for interesting insides