Why isn’t the `iosSimulatorArm64()` target part o...

# multiplatform

[spierce7]

Why isn’t the iosSimulatorArm64() target part of the ios() target yet? Same for tvosSimulatorArm64() and tvos().

[Sebastian Sellmair [JB]]

Hey! In my first commits, this indeed was added to those shortcuts (because it seems intuitively like the right thing todo, right?). However I had to revert this change, because adding a target to such a shortcut is a breaking change: When using a library that does not support this new target, then upgrading to a new Kotlin Version will just silently break import (because of missing dependencies).

We thought about how to solve such problems in the future and did not come up with some short term solution, yet.

Personally, I would consider not using the shortcuts anymore and just declaring all targets explicitly. We do only have a long term solution for this, but are not ready to share it as of right now!

[Rick Clephas]

IMO the benefit of the shortcuts is that you don’t need to configure the source sets and get e.g. the iosMain source set automatically.

With that in mind how about making the targets of the shortcuts a parameter with a default value?

This way the current behaviour stays the same while it allows developers to easily add an extra target.
Then in a future release the new targets could become part of the default (once most of the libraries have added support for it).

[spierce7]

the benefit of the shortcuts is that you don’t need to configure the source sets

100% agree with this.

When using a library that does not support this new target, then upgrading to a new Kotlin Version will just silently break import

I mean - it gives you a build error right? That kind of seems like something that comes with the territory. Also - it should be pretty rare in the future that new targets are added, right?

I created a ticket about this so that the discussion can be tracked - https://youtrack.jetbrains.com/issue/KT-50615

[Sebastian Sellmair [JB]]

We indeed did think quite a lot of how to handle this Situation. I really notice feeling quite defensive here, which is very likely a sign that this should indeed be re-thought in a more short to mid-term timeframe. Thanks for pinging and creating a ticket! Hope that we will find time to make improve this here!

[spierce7]

Sorry - I didn’t mean to make you feel defensive! I’m just voicing an opinion. This is also the kind of of opinion that I could easily find myself disagreeing with my past self in a year or 2 if there is some unforeseen consequence 🙂

[Sebastian Sellmair [JB]]

Oh! No worries at all! I felt defensive, because I would love to have a good argument for “why it has to be this way”, but to be honest: It’s also bothering me, but I just know, that I (and the rest of the team) will not be able to tackle it short to mid term) 😫

When we reverted the commit, we also started justifying this for us, and then never thought about it much. But the more I think about this, the more I do not like the situation!
It would not pass the “tell an ex-coworker how this works”: Pretty sure my folks from QuickBird Studios would just raise their eyebrows when hearing this and think that this is stupid 😁

Soooo long story short: Should be changed and made more easy, but unsure yet how (and when)!

[spierce7]

Thanks for explaining. In the short term we have a clear work around 🙂

[Marc Reichelt]

Upvoting the ticket since I think this is important.
@Sebastian Sellmair [JB] any update on the ios() situation?

Idea: how about having a flag in gradle.properties to introduce the behavior change?

1. In the first step ios() will preserve the old behavior, and the same for having this gradle property set: kotlin.mpp.ios.sourceSetBehavior=legacy
2. By setting kotlin.mpp.ios.sourceSetBehavior=allArchs we can have ios() including the arm64 arch (also same for watchos, tvos, the likes)
3. Then, in a future Kotlin version, the new behavior becomes the default
4. After the deprecation cycle is over the flag + old functionality can be removed

[Marc Reichelt]

could this work?

[Sebastian Sellmair [JB]]

We have a replacement for this planned in 1.8.20

[Sebastian Sellmair [JB]]

Shortcuts will very likely be deprecated in 1.9 or later!

[Sebastian Sellmair [JB]]

https://kotlinlang.slack.com/archives/C0474L1Q8DR/p1666617544825379?thread_ts=1666344363.000959&cid=C0474L1Q8DR