UIkit vs SwiftUI
If you are in the dilemma of what to use for your app, let me tell you my personal opinion on how to create interfaces within iOS.
UIkit:
UIkit is reliable, if you program natively you will know what is stable and robust, with which you can program with storyboards or programming the views (this will give you more control to customize the views)
SwiftUI:
It is Apple’s new bet, to incorporate this new tool that promises to be equally powerful and at the same time faster when it comes to coding, making use of predefined inputs that offer us a range of functions.
This framework is based on a system of hierarchy and reactivity.
We could start by comparing it with the main items, to discern which is your best option for choosing the most convenient technology to generate your graphic interface.
( https://github.com/SelenaGarcia/Widget )
This point would be taken by UIkit, because is older than SwiftUI, and it does not have a considerable variation in its documentation, which in swiftui for the moment the keywords were changed or mutated, since it is constantly growing, perhaps the difference between the documentation because the whole community pays special attention to write the constant changes (in my opinion it is annoying to find the information in forums and not in the official documentation).
In large teams having a code review is essential, not only because it helps to detect errors, but also because it helps to maintain code consistency, improve performance and encourage positive development by letting us know how well we are. In my experience, swiftUI handles it splendidly, because it is written in plain text (code)t, with keywords that refer to the elements and their modifiers, that although UIkit can be written only with text (code), the most common is to use the files of view (.xib) that when reviewed create code that is unfriendly to code reviewers (nearly impossible for mortals).
To create a quick application, it is much better to use SwiftUI, since with less code you can get what is necessary to carry it out, here I will leave 2 links that make the same application but with different frameworks.
It should be noted that if your goal is to create an application with high levels of customization, UIkit is still the best option, or you could choose to make a hybrid where you compensate for the shortcomings of SwiftUI with UIkit files, by combining them you could achieve the functionality desired, such as a custom camera or a navigation system that requires sending data between screen navigations through buttons.
Storyboards: https://github.com/SelenaGarcia/Personal_Card_Storyboard
SwiftUI: https://github.com/SelenaGarcia/Personal_Card_swiftUI
Although both can create or assign animations or aesthetic mutators (font color, background, etc.), the ones that SwiftUI allows to use are an interesting range, and easy to use, which can be found in the official SwiftUI documentation.
https://developer.apple.com/documentation/swiftui/animation
Always keep in mind that if your design does not correspond to those available, they should resort to UIkit or have a hybrid between both Frameworks, that is, use SwiftUI and UIkit functions, as can be seen in multiple examples provided by the documentation.
https://developer.apple.com/tutorials/swiftui/interfacing-with-uikit
UIkit has a life cycle where AppDelegate and SceneDelegate are used, to control transactions or predefined events.
In my experience, this point is critical, both for new developers and for those who have been programming for years, since it helps companies to modularize, decouple the modules, allow us to create in less time, and add third-party code.
Now, it is true that you can cut and paste UIkit view files, but it is not recommended at all, also it would take more time to try to reuse than rewrite from scratch. That is where SwiftUI comes in. If you have found a post or documentation that solves your problem or if you did it in a previous project, it will only be enough to copy and paste the code, and it will just work, just like that.
An important element added in SwiftUI is the reactive view that it offers us. This view shows perfectly what the final user will be able to see on their screen, so we can even modify the styles, colors, and behavior while we press a button and it is displayed in real-time.
It indeed has a couple of bugs, maybe it deactivates itself or it doesn’t want to show the Live Preview but it is enough to restart the XCode and it will work again (it is an item that bothers a lot but as I mentioned before, it continues to mature and improve, I hope what soon present less of these bugs).
Conclusions:
Although both are different and can make competent and powerful apps, the choice of which one to use will depend on the requirements you have for it, the time, and how customizable you want to make your code. At the time of writing this article, SwiftUI continues to have problems and they continue to make improvements to it, which makes it very changeable.
Applications that are standard in terms of their design would be better to consider with SwiftUI, since it is much faster to code, on the other hand, if a special configuration and a more stable environment are necessary, UIkit is your best ally.