Is there a way to set the Konan `osVersionMin.ios_x64` and `osVersionMin.ios_arm64` on a per-projec...

# kotlin-native

[salomonbrys]

Is there a way to set the Konan osVersionMin.ios_x64 and osVersionMin.ios_arm64 on a per-project basis (rather in ~/.konan) ?

[russhwolf]

Oh wow I never knew you could configure those at all

[salomonbrys]

So, turns out you can from Kotlin 1.4.30:

compilations.all {
    kotlinOptions.freeCompilerArgs += "-Xoverride-konan-properties=osVersionMin.ios_x64=13.0;osVersionMin.ios_arm64=13.0"
}

[louiscad]

Why do you need this?

[salomonbrys]

https://medium.com/kodein-koders/create-a-kotlin-multiplatform-library-with-swift-1a818b2dc1b0

[salomonbrys]

@louiscad look at the SwiftChachaPoly.def file.

[louiscad]

I've seen. So the way iOS is architectured and Apple support decisions force developers to stop supporting the iPhone 6…

[louiscad]

Unless you can avoid using new APIs of course

[salomonbrys]

Not really. It's related to the way the Swift standard library is packaged with the app (or, more exactly how it is not).

[salomonbrys]

When using XCode, you can target whichever version of iPhone you want and XCode will package the app and test executables correctly.

[louiscad]

That doesn't restrict support to iOS 13+?

[salomonbrys]

With XCode, no restrictions.

[salomonbrys]

XCode automagically detects the dependencies to Swift Stdlib and, since you are targetting a version of iOS that do not provides said lib, copies and packages it with the app.

[louiscad]

With Xcode… It'll always be built by Xcode at the end anyway, right?

[salomonbrys]

Nope. Not the Kotlin/Native test executable, for example.

[salomonbrys]

If you target iOS 9 (default for K/N) and use a Swift static lib, your code won't run unless you use the swift-stdlib-tool to analyse the binary and copy the Swift stdlib in the directory of the executable.

[salomonbrys]

Furthermore, the shared code framework is built by K/N, and not XCode. When K/N builds a framework for iOS 9+, and you configure your XCode app to target iOS 13+, somehow XCode does not detect that the framework contains Swift and is linked the old way (so the app fails at runtime).

[louiscad]

So you must use the xcode plugin instead of say the packForXcode task or an equivalent?

[salomonbrys]

So, it is possible to interop K/N with Swift for iOS 9+ but it requires a lot of fixes (use of swif-stdlib-tool to copy the Swift stdlib, either packaging the stdlib with the framework, or editing binary links on the fly on the produced framework, correctly configuring XCode, etc.)
Considering how iOS 13 & 14 are deployed, it's way easier to limit to iOS 13+

[salomonbrys]

Nope, you cannot use XCode to compile the K/N framework. The packForXCode Gradle task is merely a copy of the compiled framework to a location XCode understands.

[louiscad]

Couldn't the Kotlin/Native compiler make it so it works like Xcode and can make supporting iOS 9 to 12 easier even when relying on Swift stdlib?

[salomonbrys]

Sure. The K/N team can add any feature to the compiler !

[salomonbrys]

It wouldn't be just the framework. The test executable is also a concern 😉

[louiscad]

I see. I idealize that developers can support years of OS versions to minimize e-waste, but at the same time, it seems like people installing apps nowadays are substantially more likely to be on iOS 13+, and even more in the future, so I'm not sure I should backlog the K/N team with that 🤔

[salomonbrys]

I guess this is linked to the "direct support of Swift" item in the Kotlin backlog, which is "postponed for later", so I don't think it would be a priority.

[salomonbrys]

(which is why I did not report it).

[louiscad]

I see, thanks for all the info

[salomonbrys]

In our usecase, we needed the CryptoKit iOS API, that is available only in iOS 13+, so it was a no brainer anyway 😉

[salomonbrys]

However, using the swift-stlib-tool is not very complicated. A motivated individual who would really need K/N Swift interop for iOS 9+ could figure it out, I think.