Nycturne
Elite Member
- Joined
- Nov 12, 2021
- Posts
- 1,550
I left this out but I am not at all happy with SwiftUI as a dev. Nor have I been happy with the direction Swift has taken over the last few years. Swift has become an incredibly complex language because rather than build new things as library's or frameworks they keep just making the language itself have to do more and more and more.
Except this isn’t even a rebuttal of my statement. The developers who went Electron/ReactNative skipped over Swift entirely for the most part, assuming they ever wrote Objective-C against UIKit at all. SwiftUI is a response to React and similar frameworks to provide something more familiar to that sort of developer.
Swift has gotten complex, partly because of the language additions, and partly because it now enables DSLs like SwiftUI (to compete with JSX). The more I work with DSLs, the more I find them to be a mixed bag. But it has been a pretty painful transition dealing with language-level async in Swift IME.
I am leaning towards a JS React app for my next project partially because I am tired of Apple's ever worsening UI decisions in their native frameworks. If I am going to have to basically rewrite the UI anyway (to actually offer the discoverability, and ease of use I want) then why bother building on Apple's buggy mess?
This feels like a grass is always greener moment. As someone who spent a bunch of time doing React Native on mobile, it’s got its own problems, as does React. The larger the project, the more pain I’ve had with the JS world. I don’t miss package dependency hell when I can get back to native development.
You can replace UIKit and SwiftUI, other than very minimal stuff such as the app lifecycle methods (and probably you can get around the need for that too). In fact as far as I know there are technologies out there such as Flutter that have their own renderer and mostly don’t use UIKit/AppKit/SwiftUI for that. There’s really nothing forbidding a 3rd party company from building such a thing.
If by replace you mean "still use UIKit for events and providing a drawing canvas to hook into", sure. But you can’t get away from the fact that it is UIKit that gives you your UI events (keyboard, finger, etc) and provides a CALayer to draw into if you want to go that route yourself. And about the only folks willing to go down this route are teams that already have a UI framework they are willing to port, like Google.