I know SKIE doesn't support pre-releases, but are ...

# touchlab-tools

[Zac Sweers]

I know SKIE doesn't support pre-releases, but are y'all considering adjusting for K2 testing given the longer incubation time and "big deal" nature of the release?

[Filip Dolník]

Hi! I expect we will eventually do a preview version for 2.0, but most likely, we will do it only once we get to the RC phase (Kotlin 2.0-RC1, etc.), at which point the codebase is close to stable. (Which is what we do for most major Kotlin versions). Note that the longer incubation time is precisely why we are hesitant to have multiple preview versions - it’s a lot of work to release new previews during the Beta phase when the compiler code changes a lot.

The K2 compiler itself doesn’t affect SKIE directly, so from our perspective, this release isn’t that different from others. I understand that users might want to check that their KMP code base works with K2. But you can do that already because you can turn off SKIE for a single build and try to compile the iOS framework with Kotlin 2.0.

That way, you cannot easily compile the entire iOS app and, therefore, test the runtime. However, you can verify that the new front end parses your code base without errors. That will catch almost all issues you could encounter with K2.

[Zac Sweers]

We can’t use most of our CI tooling though because we would have to carve out anything involving iOS.

Would you be open to doing something like KSP where version compatibility checks can be optionally disabled? Can stick a giant “this isn’t supported, don’t file bugs” warning, but in the meantime would allow the community testing against K2 to better proceed.

For example, I’m in the EAP champions program and would like to make sure we can get better signal to Jetbrains about our project that uses SKIE.

[Filip Dolník]

> We can’t use most of our CI tooling though because we would have to carve out anything involving iOS.
Yeah, I know that this isn’t a good long term solution that would allow you to use K2 continously. I meant it as a one time test you could do locally on your machine - just to check the KMP project compiles.

> Would you be open to doing something like KSP where version compatibility checks can be optionally disabled? Can stick a giant “this isn’t supported, don’t file bugs” warning, but in the meantime would allow the community testing against K2 to better proceed.
This flag exists, it’s called skie.kgpVersion (it’s a Gradle property) and you can use it to override the detected Kotlin version to something that is supported by SKIE.

However, the problem most likely isn’t the compatibility check so I don’t think this flag will help you. The reason why the compatibility check exists is that the crashes that are caused by the compatibility issues are usually very difficult to debug (and understand) so we got a lot of confusing bug reports.

SKIE isn’t a regular compiler plugin, it internally depends on many compiler internals that are not exposed to regular plugins and as a result change a lot. Therefore, SKIE doesn’t automatically work for basically any new compiler versions. By not working I mean “a crash during the compilation” kind of problem. The only exception are bug fix releases like 1.9.21 that have a reasonable chance to work. But major versions so far always required a lot of changes in the SKIE codebase.

[Zac Sweers]

I’m the author of a few compiler plugins so I get it :). That property’s existence might cover it for me, I’ll give it a try. Thanks!