1️⃣ Cross‑platform UI toolkits – Qt, Flutter & Kotlin Multiplatform
- Qt is defended as a mature, high‑quality option, but licensing worries many:
“It’s licensing is expensive though unless the app is opensource.” – afidrya
- Flutter is seen as a solid choice for many teams, yet its “reimplementation” critique surfaces:
“Flutter is not the 'right way', due to the nature of Flutter being a lousy reimplementation of a UI frameworks.” – krzyzanowskim
- Kotlin Multiplatform is praised for being a library rather than a full framework, enabling true native integration:
“What I like about Kotlin Multiplatform (KMP) vs Flutter is that KMP is not a framework… pure native apps can pretend it is a 'pure' Android/iOS library.” – palata
These points highlight the recurring debate over which stack offers the best balance of performance, licensing, and native access.
2️⃣ Native‑look vs. “Liquid Glass” & SwiftUI friction
- Several users argue that Apple’s Liquid Glass design creates a hidden cost for cross‑platform frameworks:
“Liquid Glass has been a headache lately.” – rumori
- Native‑specific UI elements (e.g., deep iOS animations) are often missing or require drops to UIKit:
“As soon as you need something non‑standard, you have to drop down to UIKit and figure out how to play nice between the two, which is often non‑trivial.” – rumori
- The native look is frequently cited as a make‑or‑break factor for users:
“Most loved UX update in iPhone and macOS history. Massive dealbreaker for an app not to look like Liquid Glass.” – lowbloodsugar
Thus, the tension between achieving a truly native Apple experience and the constraints of declarative UI frameworks remains a dominant theme.
3️⃣ Declarative/functional UI paradigms – benefits & pitfalls
- Advocates of functional UI argue that state‑as‑function models can be elegant, yet they acknowledge the inherent complexity:
“Functional programming is superior for representing state in user interfaces.” – mpweiher
- Critics point out that reactivity can become a black box, leading to unpredictable re‑renders and “event hell”:
“The UI updates itself automatic, and yes: MVC already solved the 'problem with MVC' React/Redux/Elm/SwiftUI claim to solve.” – mpweiher
- Some developers find the mental model of SwiftUI’s modifiers and state propagation counter‑intuitive and hard to debug:
“Each modifier doesn't actually modify the main view but it modifies what the modifier before it decided to return… This makes no sense as the modifiers should each be modifying the main view to make everything predictable and easy to debug.” – (paraphrased from a comment on modifier ordering)
These perspectives reveal a split between the appeal of declarative simplicity and the practical headaches it introduces.
4️⃣ Apple’s developer experience & framework direction
- Apple is frequently accused of prioritizing marketing over engineering, leaving developers frustrated:
“Apple seems to be loved by users, but hated by developers (and for good reasons). They just seem to not give a shit about the developer experience.” – palata
- Long‑standing native APIs (Objective‑C, UIKit) are missed for their stability and straightforwardness:
“Apple had a real winner with ObjC and AppKit. Swift is horrendously complicated for the benefits it offers over ObjC, and SwiftUI is a massive step backwards from AppKit.” – spacedcowboy
- The perceived “regret” over SwiftUI’s current state fuels calls for Apple to either double‑down on feature parity or step back:
“SwiftUI it is the type of framework that makes the easy things easier to accomplish but the harder things harder.” – ardit33
Together, these comments capture a growing sentiment that Apple’s recent UI direction is at odds with developers’ practical needs.