Anyone successful in moving small to medium apps to SwiftUI?

i would strongly caution against proceeding full-on with SwiftUI, it is just plain broken in a lot of places. The list of things that don't work in SwiftUI seem to grow the more you use it.

For instance, SwiftUI does not offer a pull to refresh feature (a deal breaker for me). SwiftUI provides no way of customizing the return key type on a keyboard. Keyboard support in general is just lacking, there is no way to set a first responder and no way to resign a first responder.

Using UIHostingController to bridge UIKit code to SwiftUI leads to other issues like Lists not behaving as they should (NavigationLinks will remain highlighted after you return from the Detail View). And the list goes on and on.

I would not, now, move any sizeable app to SwiftUI.

What we read in all forum posts shows how complex it is to get fine tuning of UI.
So either your UI is very generic (page display, segues, update views when data change…), then SwiftUI may do the job; but if you need to gert precise control on display and interaction, I would stay with UIKit.

Situation may improve in the next 2 years.

Thank you very much nokey4 and Claude31.

I hadn't got to the part of working with keyboards yet, but my app does indeed need to modify the return button type as well as to have control over the first responder.

And agreed, Claude, in that it seems SwiftUI is only ready for either static displays of information, or very basic interactions.

What I will do is to continue to build out a sample app with all the things I need. Then file bugs and annotated the code with FIXMEs referencing the feedback numbers. Hopefully we'll all see these things fill in over time. Once my sample is all working, that should then be the trigger to move to SwiftUI.

I have been experimenting with SwiftUI since day one.
Unfortunately even now I would categorize it in early beta stage.
Let me explain.

This year I decided to update one of my apps from UIKit to SwiftUI. After two months, all I can guarantee you is that you will cry for many nights over your keyboard. And this for the following reasons:

1) Too many Views and modifiers have bugs, and you have to become an instrument ninja to understand what is causing the problem.

2) All ready-made Views are in their simplest versions, or even worse there are no matches with UIKit at all.

3) For the previous reason, it is certain that you will have to make your own custom versions, or you will have to use UIKit Views with SwiftUI wrappers. And this leads us directly to the next *huge* problem ...

4) The biggest problem of all. After programming in SwiftUI, when you go back to UIKit you feel like you went back to something old and dusty, like you went back from Swift to ObjectiveC.

And that's because SwiftUI is really great, and you'll fall in love with it right away, it's just not ready yet.

InstantInteractive, it is easy to get around not being able to customize the return key type on a keyboard:

You simply create a UIViewRepresentable that wraps the good old UITextField we have come to know and love; it sucks to have to do it this way but at least there is a workaround. For some of the other issues i mentioned in my initial reply, there is no workaround.

Don't get me wrong, SwiftUI is here to stay and is indeed the future and when things work, it's magic. i can understand it having bugs when it was first released in iOS 13, but glaring issues and feature omissions remain in iOS 14 as well.

Agreed Nick. I started with Swift when it first came out and there were some things that were indeed quite painful. I'm glad though to have started at that point though. And since around five years ago, I have only written Swift code.

Nokey4, understood, but I would only move to SwiftUI if I can completely move to it. If having to deal with hosting view controllers and write code to work with the underlying UIKit items, I prefer to stick with pure UIKit instead.

Agree that SwiftUI is the future. All we can for now though is to keep filing those bugs.