SKIE release delayed timing update Hey folks, we’r...

# touchlab-tools

[kpgalligan]

SKIE release delayed timing update
Hey folks, we’re targeting November for the full release.
Why:
• This release is more complex due to the recent Kotlin compiler changes.
• Touchlab's current project load is keeping us from dedicating more time to the update and it's making progress slower than we would all like.
We know everyone needs this as soon as possible, and we appreciate the patience. Please know we are working to change the way SKIE updates get staffed in 2026 to avoid these delays in the future. As we have more details on that, we'll share them.
We’ll share another update in early November.

[dylan]

Is there any timeline when the skie plugin is going to support 2.2.20 and 2.2.21? is the update early november the plugin update or only the details on how you are proceeding?

Since we have IOS devs on the team that want to start updating to xcode 26.

Also is there a way we can help to improve development of the plugin since its opensource off course. Or can the plugin be split up into multiple smaller plugins that can be applied per feature/usecase you want. Since if you only need flow/suspend functionality its currently much better to use native coroutines since that plugin/library gets updated quite quick.

[dylan]

This is also not by any means an attack on touchlabs or skie for doing bad job.

[Filip Dolník]

Hi! Unfortunately, I cannot give you a more precise estimate at this time than what was already stated. We are actively working on it and full stable release will most likely be somewhen in November. The "another update in early November" was meant as a lower bound on when we might have some news to share.

Due to the nature of how updating SKIE works, it's not possible to make a meaningful estimate on the upper bound for the time needed. Simply because until we overcome the last blocking problem we don't know if there isn't another one.

Or can the plugin be split up into multiple smaller plugins that can be applied per feature/usecase you want.

Splitting the plugin would only make things much worse for us because usually the individual SKIE features don't take that much time to fix. The difficult part is updating the foundational framework that these features are built upon and then validating that everything works as expected. This change would never "pay for itself" because of the upfront investment needed (easily in the range of months) and the high complexity this would introduce - the individual features interact with each other so it's not that easy to split them apart.

Also is there a way we can help to improve development of the plugin since its opensource off course.

I don't think there is unfortunately. Not in a way that would actually save us any time. Maintaining SKIE requires a very specific set of skills - ignoring the need to be familiar with the codebase, you would also need a high level of expertise in the Kotlin compiler, Gradle, and probably Swift as well (its compiler, and especially the Obj-C to Swift interop). SKIE is not a regular Kotlin compiler plugin, it's much more deeply integrated with the Kotlin compiler and pushes the obj-c interop to its absolute limits. So much so that we for example have to carefully navigate around bugs in both the Kotlin compiler and the Swift compiler (and there are many :D) to get it to work.