Is there a way to get any sort of autocomplete whe...

# touchlab-tools

[Michael Friend]

Is there a way to get any sort of autocomplete when using swift bundling in skie? At one point we had a setup for a kmp lib repo where we put swift code in a separate Sources directory at the top level of the repo and added it as a target in our Package.swift which depended on the kmp target which gave us some autocomplete when editing the swift code in Xcode. After moving the swift code into iosMain/../swift we dont have autocomplete in the swift

[Tadeas Kriz]

You could probably configure it, but it's not straightforward. We definitely want to bring such feature to SKIE, where we'd probably have a Gradle task like ./gradlew :shared:skieEditSwift which would generate a temporary Xcode project and open it so you could edit the Swift with autocomplete. But we didn't get to it yet (so much to do, so little time).

The way I approach it so far is writing the Swift code in Xcode first and then copying it over to the iosMain/swift when I'm done. It's not ideal, but better than not having autocomplete.

[Michael Friend]

Ah i see. Are you editing the swift code with the local dev flow in the ios side of a monorepo codebase for the most part? We're running three repos (ios, android, kmp lib) right now which is definitely part of the issue with ease of use

[Michael Friend]

Also thanks for the waves everyone hope yall are well! 👋

[Tadeas Kriz]

No so far I only wrote Swift that I had to write once and then do only minor modifications where I wouldn't need code completion so I'd first write it in the app target directly and just copy it over when I'm done. What usecase you have for that Swift code/what are you implementing in Swift as compared to Kotlin?

[Michael Friend]

We're adapting a file of test tags we pulled from the android codebase to share across both apps for automation purposes but the existing file has a very nested structure that doesnt get translated well into swift. The wrapper were writing is just to flatten out the structure without having to refactor too much to appease other team ios devs that dont like the look of OuterInnerAInnerBInnerC that swift sees from kotlins Outer.InnerA.InnerB.InnerC structure.

[Michael Friend]

Imm guessing the nested structure is something skie could generate on the off chance youre looking for more work to pile onto your long backlog

[megax]

In our case, we are developing a library and while skie does a great job providing a Swift friendly API we came to the conclusion that it would be better to write a tiny wrapper manually over it in Swift. Mainly for SwiftUI parts and proper error handling as we are using Kotlin's Result class in the Kotlin side which is a ValueClass that doesn't compile well to Swift but that is a lot of code to do without code completion... so we are now thinking about having a separate project and wire them together so the kotlin provides an xcframework that the swift wrapper gets we write the swift api there and release that instead of the kotlin project

[Michael Friend]

replied to your thread as well but we do have another kmp library that has this set up in the company. Basically a whole separate SPM repo that consumes the kmp lib and i think exports most of it while adding some additional wrappers. I think if you dont expect to mess around with the swift code too much in the future and instead just want to write some helpers like a result class mapper/wrapper then leave the swift code alone for the most part from there Tadeas' write then copy flow is prob the best path. If you expect to be editing the swift code more often during development like writing new wrappers for all the new functions having a separate wrapper lib is probably a good way to do it