4 ms·
I think your view is lazy. The article explains some of the actual reasons, none of which have to do with laziness. I’ve built for Electron and did a course on
by port11 8mo ago
I think your view is lazy. The article explains some of the actual reasons, none of which have to do with laziness.
I’ve built for Electron and did a course on Swift for macOS apps. Not out of laziness, but I don’t think I’d ever build native for Macs. And the Windows folk have been complaining for a long time about the native APIs.
Now, native on mobile, that’s something else. I’ve been stuck on RN/Expo because that’s what the resources the business had allowed for, but native Kotlin is much more enjoyable (AFAIK). Swift… dunno, still icky.
- JKCalhoun 8mo agoFTA: "Looks could be good, but they also can be bad, and then you are stuck with platform-consistent, but generally bad UI (Liquid Glass ahem)." Since the discussion was specifically about platform-consistency, odd that the author would decide that personal taste might take priority over platform-consistency. "It changes too often, too: the app you made today will look out of place next year, when Apple decides to change look and feel yet again." Seems to be arguing the exact opposite? If you adopt a native API for controls, windows, etc., your app will change next year to look completely in place (perhaps for better or worse according to the author). Going DIY on UI and your app might still, in 2026, have brushed aluminum and "lickable" buttons.
- port11 8mo agoI read it as criticism on how the native APIs don’t give you a sure-fire way of getting to a consistent native UI. Case in point is Apple’s own software, with some of its apps looking completely out of place despite being built on native UI.