In which plugin is the `packForXcode` /`buildForXc...

# multiplatform

[darkmoon_uk]

In which plugin is the packForXcode /`buildForXcode` task implemented - has it been deprecated?

[darkmoon_uk]

After not finding these; I wrote my own Gradle task to detemine which link-Executable KMM task to run based on Configuration and Architecture.

After integrating CocoaPods, I now want to respect several other 'flags' environment variables that are being passed into the Xcode build; so the task is getting more sophisticated... wondering if the packForXcode task was designed to handle these - I don't want to reinvent unnecessarily.

[John O'Reilly]

https://blog.jetbrains.com/kotlin/2021/07/multiplatform-gradle-plugin-improved-for-connecting-kmm-modules/#New_approach_integr[…]meworkForXcode_task

[John O'Reilly]

"If you have an existing project that uses the packForXcode task, migrate to embedAndSignAppleFrameworkForXcode"

[darkmoon_uk]

Thanks John, I just found it... but what did JB do, this is not equivalent 🤷‍♂️

[darkmoon_uk]

I am wanting to build the final executable, not a framework

[darkmoon_uk]

Since I currently use a Kotlin main() function to directly launch into Compose/iOS

[darkmoon_uk]

That's all working, it's just getting more sophisticated now I'm involving cocoapods 😄

[darkmoon_uk]

Unless my main function can be found from the framework - I've never attempted that before.

[ribesg]

I don't know if it's related but since I moved from the complicated Gradle tasks to just using the Cocoapods integration I had to make a Swift main that launches my Kotlin main. My 100% pure Kotlin iOS app now has one single line of Swift and I hate it. Still 99.9975% Kotlin though

[darkmoon_uk]

This is what I'm trying to avoid

[darkmoon_uk]

It feels weird that KMP offers link executable tasks

[darkmoon_uk]

And yet they appear to have deprecated using iOS executables by implication of this Xcode integration change

[ribesg]

JB isn't really doing too much effort to push pure Kotlin iOS apps. There's like one old sample with a Kotlin main and that's it

[darkmoon_uk]

Push or not, the feature is there and seems no worse for age

[ribesg]

I mean it's so ignored that maybe they forgot it's supposed to work and broke it

[darkmoon_uk]

I guess I can accept a swift bootstrap, means binding the swift runtime as well though

[darkmoon_uk]

Could potentially compile a Kotlin boot that uses the Kotlin framework. Idk if that's a tested combination though 😁

[darkmoon_uk]

FWIW The falling balls experimental Compose/iOS uses a pure Kotlin main

[darkmoon_uk]

That's what got me started on this path.

[darkmoon_uk]

Maybe it's feasible to lightly reimplement a new linkForXcode task alongside the new framework task, in the Kotlin plugin, will take a look at that, PR potential.

[darkmoon_uk]

I suppose going this way means avoiding responsibility for all the ways Xcode (and Cocapods) may want to link a binary. Perhaps that's why it was chosen. Would be really good to understand why the change... It was never explained in the post.

[darkmoon_uk]

Looks like the author of the post is no longer on Slack

[Landry Norris]

I’d imagine that we will eventually get pure Kotlin main, but honestly, it’s such a small benefit relatively speaking, that presumably adds a lot of work for JetBrains. There’s a lot of stuff like Compose for iOS, K2, stabilization of plugin SDK, new mm, etc. that they are currently working on that provide a lot of value. I can see why it wouldn’t be as high of a priority.

[ribesg]

I don't see not having to use 2 different languages as a small benefit. I also don't see being immune to all the "using Kotlin from Swift" issues as a small benefit.

Also, we did and we do have Kotlin main, it's just either slightly broken on iOS or we don't get how to use it now, but it's there.

[Landry Norris]

When I set up an app, I generally make sure that the swift code just sets up a nav controller and immediately swaps to a pure kotlin VC. There’s no ‘real’ swift code in this case.

[Landry Norris]

Not saying there’s no value in a Kotlin main, but that there’s a lot that jetbrains is doing right now.

[ribesg]

My Swift main just calls MainKt.main(args)

[ribesg]

It's just that you could package the app so that the Kotlin main was called directly and that broke. That's it

[darkmoon_uk]

import shared

@main
struct Main {
  static func main() {
      MainKt.main()
  }
}

😂

[darkmoon_uk]

@Landry Norris I don't need to create a ViewController in Swift - above is my only Swift file. Hope this gives you what you need to simplify your startup but let me know if you have any questions 👍

[ribesg]

I don't know how it works but my Swift main really is just

MainKt.main(args: CommandLine.arguments)

(with an import)

[Landry Norris]

Isn’t that the entrypoint for SwiftUI? How are you doing your UI?

[darkmoon_uk]

@Landry Norris in my case; in a manner inspired by Compose/iOS falling balls example, so within shared iosMain

[Landry Norris]

I see. That looks interesting.

[darkmoon_uk]

It's basically a Kotlin-ified form of a vanilla iOS App start, setting rootViewController with the result of Compose/iOS Application call.

[darkmoon_uk]

I'm not sure of the significance of setting skikoApp parameter in the UIApplicationMain function - perhaps there is none; I haven't gotten around to removing it and seeing if it still works yet 😁

[Landry Norris]

The Application block doesn’t have access to the args unless there’s some deep iOS magic I don’t know about, so I doubt it.

[ribesg]

I just have my whole app in Kotlin, UIs are written in Kotlin with UIKit and some cool Kotlin extensions/wrappers.

[ribesg]

This app has been in production for like 3 years so Compose on iOS obviously wasn't a thing

[Landry Norris]

Yeah. I’m doing the app in Kotlin with UIKit and some less cool wrappers/extensions.

[Landry Norris]

Can’t wait to move to Compose.