What's the state of support for UIKit?

[djryanash]

I know - SwiftUI is the future but is there any support for UIKit?

[marcprux]

We have very minimal built-in UIKit support. Basically, just enough to fill in the blanks on missing SwiftUI functionality. For example, UIPasteboard.

Note, of course, that since Skip doesn't intrude on the iOS side, you are free (and encouraged) to use whatever UIKit types you want within #if SKIP block (see https://skip.tools/docs/platformcustomization/). This can be useful for integrating with components that we don't yet have any support for; but you'll need to figure out what to do on the Android side. For examples, see the Travel sample app's MapView and WebView.

But do let us know, either in this thread or directly at [email protected], if you have particular UIKit needs that could be useful for skip-ui to provide. And as you can see with UIPasteboard, some things are fairly straightforward to implement on your own, so PRs are definitely welcome!

[djryanash]

Thanks for the reply. :)

So I would use:

#if !SKIP 
    //  Write my UIKit code here.
#else
    // Write my Kotlin code here.
#endif

I know just a little bit more SwiftUI than I do Kotlin, so my best option would be to learn more SwiftUI and pick up some Kotlin along the way while I get to know Skip. Is that a good plan?

My big app is built using UIKit's UICollectionView with UICollectionViewDiffableDataSource and UICollectionViewCompositionalLayout so getting analogs of those in Kotlin/Skip would be great.

I have a few other questions (which I can move to a new discussion if needed):

Do you have "Sign in with Apple" implemented yet? Does it transpile to "Sign in with Google"? If not, this is a MUST! :)

Skip is predominantly open-source. Is the plan to tap into community resources to ultimately get 99.99% of Swift transpiled into Kotlin via Skip? This is an exciting prospect and the first time I have seriously considered contributing to any repo.

It seems that migrating an existing large Swift project to Skip is more of a hassle than it's worth. And when I say large, I mean on the order of 25K lines of code:tiny in the scheme of things but my definition of large. What are my other options and which will be the fastest and will they all be faster than learning Kotlin and building an Android version of my app?

I've been programming less than two years, Swift is my first language and I adore Swift and now I love that Skip goes from Swift to Kotlin but not the other way around. I hope that this means that Swift sees more widespread use in the future.

[jeffc-dev]

"I know just a little bit more SwiftUI than I do Kotlin, so my best option would be to learn more SwiftUI and pick up some Kotlin along the way while I get to know Skip. Is that a good plan?"

Yep!

I'm unaffiliated with Skip and this is just my personal opinion only, but I would highly suggest focusing on getting your SwiftUI knowledge up to speed if you want to continue developing for Apple platforms. Apple has not been shy about making it very clear that this is the future of development from their perspective - not UIKit.

(from the WWDC 2022 keynote)

UIKit isn't exactly deprecated, per se, but mostly in the same way Objective-C isn't technically deprecated. I fully expect investment in it to wane over time while SwiftUI becomes more mature. More and more things will become SwiftUI-only.

Getting back on topic: While the Skip folks have been exceedingly accommodating to special requirements in my experience, they are also have limited time/resources to invest and I'd much rather they focus it on where Apple is going, not where Apple has been.

Like the rest of UIKit, UICollectionView is on its way out. It's also comprised of a pretty complicated set of related APIs, and supporting it (development, documentation, maintenance, etc) would add a great deal of tech debt for limited utility unless they also add a bunch more UIKit to go along with it. I'd much rather Skip put that effort toward adding support for more forward-thinking technologies than supporting an old UI framework that Apple is actively trying to get us to move away from.

[jeffc-dev]

The good news is that if you haven't done much SwiftUI yet, now is a great time to pick it up. The first couple of years were pretty rough, but that has changed.

It's finally starting to reach a level of maturity that it can replace most UIKit use-cases, and if you have UIKit knowledge you can use that to "fill in the blanks" - though, increasingly, there aren't nearly as many blanks to fill in any more.

You'll also benefit from the fact that most discussion, blog posts, books, etc. assume people are working with SwiftUI now. Finding help is going to be easier than it was before (and, arguably, than it is to find help with current UIKit - a lot of people have switched over by this point).

[marcprux]

In addition to Jeff's help response, I'll add:

Thanks for the reply. :)

So I would use:

#if !SKIP 
    //  Write my UIKit code here.
#else
    // Write my Kotlin code here.
#endif

Yes, that will be the general pattern.

I know just a little bit more SwiftUI than I do Kotlin, so my best option would be to learn more SwiftUI and pick up some Kotlin along the way while I get to know Skip. Is that a good plan?

Yes, we recommend trying to do as much as possible using direct Swift and SwiftUI, and only falling back to Kotlin when you need to tap into any of the Android or Java APIs that Skip does not yet provide a library for.

My big app is built using UIKit's UICollectionView with UICollectionViewDiffableDataSource and UICollectionViewCompositionalLayout so getting analogs of those in Kotlin/Skip would be great.

UICollectionView is a large enough surface with no direct Android equivalent that it is unlikely to have a Skip analog anytime soon. Ideally you would be able to use one of the SwiftUI container views to provide equivalent functionality.

I have a few other questions (which I can move to a new discussion if needed):

Do you have "Sign in with Apple" implemented yet? Does it transpile to "Sign in with Google"? If not, this is a MUST! :)

We do not yet have an authentication component, but it is certainly on our roadmap.

Skip is predominantly open-source. Is the plan to tap into community resources to ultimately get 99.99% of Swift transpiled into Kotlin via Skip? This is an exciting prospect and the first time I have seriously considered contributing to any repo.

There are two components to Skip: the Swift-to-Kotlin language transpiler, and the library ecosystem like SkipFoundation and SkipUI. The language transpiler already supports most of the Swift language, so much of the remaining work to be done is in the library ecosystem. If you are interested in contributing, please take a look at https://skip.tools/tour/contributing-to-skipui/

It seems that migrating an existing large Swift project to Skip is more of a hassle than it's worth. And when I say large, I mean on the order of 25K lines of code:tiny in the scheme of things but my definition of large. What are my other options and which will be the fastest and will they all be faster than learning Kotlin and building an Android version of my app?

It really depends on how much of your project can be transpiled with the existing Skip support. If it mostly uses Swift standard library and Foundation functions, you might be able to get a large portion working without too much trouble. In undertaking this, you should definitely try to modularize your project into multiple SwiftPM packages and write unit tests for much of it, so you can take advantages of Skip's parity testing, as described at https://skip.tools/docs/modules/skip-unit/

I've been programming less than two years, Swift is my first language and I adore Swift and now I love that Skip goes from Swift to Kotlin but not the other way around. I hope that this means that Swift sees more widespread use in the future.

So do we!