In which plugin is the `packForXcode` /`buildForXc...
# multiplatform
d
In which plugin is the
packForXcode
/`buildForXcode` task implemented - has it been deprecated?
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.
"If you have an existing project that uses the
packForXcode
task, migrate to
embedAndSignAppleFrameworkForXcode"
d
Thanks John, I just found it... but what did JB do, this is not equivalent 🤷‍♂️
I am wanting to build the final executable, not a framework
Since I currently use a Kotlin
main()
function to directly launch into Compose/iOS
That's all working, it's just getting more sophisticated now I'm involving cocoapods 😄
Unless my
main
function can be found from the framework - I've never attempted that before.
r
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
d
This is what I'm trying to avoid
It feels weird that KMP offers link executable tasks
And yet they appear to have deprecated using iOS executables by implication of this Xcode integration change
r
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
d
Push or not, the feature is there and seems no worse for age
r
I mean it's so ignored that maybe they forgot it's supposed to work and broke it
d
I guess I can accept a swift bootstrap, means binding the swift runtime as well though
Could potentially compile a Kotlin boot that uses the Kotlin framework. Idk if that's a tested combination though 😁
FWIW The falling balls experimental Compose/iOS uses a pure Kotlin main
That's what got me started on this path.
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.
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.
Looks like the author of the post is no longer on Slack
l
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.
r
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.
l
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.
Not saying there’s no value in a Kotlin main, but that there’s a lot that jetbrains is doing right now.
r
My Swift main just calls MainKt.main(args)
It's just that you could package the app so that the Kotlin main was called directly and that broke. That's it
d
Copy code
import shared

@main
struct Main {
  static func main() {
      MainKt.main()
  }
}
😂
@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 👍
r
I don't know how it works but my Swift main really is just
Copy code
MainKt.main(args: CommandLine.arguments)
(with an import)
l
Isn’t that the entrypoint for SwiftUI? How are you doing your UI?
d
@Landry Norris in my case; in a manner inspired by Compose/iOS falling balls example, so within shared
iosMain
l
I see. That looks interesting.
d
It's basically a Kotlin-ified form of a vanilla iOS App start, setting
rootViewController
with the result of Compose/iOS
Application
call.
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 😁
l
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.
r
I just have my whole app in Kotlin, UIs are written in Kotlin with UIKit and some cool Kotlin extensions/wrappers.
This app has been in production for like 3 years so Compose on iOS obviously wasn't a thing
l
Yeah. I’m doing the app in Kotlin with UIKit and some less cool wrappers/extensions.
Can’t wait to move to Compose.
132 Views