Hacker News Reader

Comment by patientplatypus | Hacker News Reader

Yeah...and SwiftUI is by default an iOS only program. Flutter you can plug any phone in that's been made in the last 5 years, type `flutter run` in the terminal, and get hot reloading.

SwiftUI is walled-garden bait. Hard pass.

EDIT: Not sure why I'm being downvoted - (one of) Flutter's main selling point is that it's cross platform by default. SwiftUI doesn't do that and yet is marketed to be very similar in coding style to Flutter, which yeah great, but no cross platform so you still have to code everything twice, unless all your users happen to have iPhones. I mean really?

View on HN

> SwiftUI is by default an iOS only program.

and macOS, tvOS, watchOS (and soon I suppose, AROS?), all counting for over a billion devices.

You can literally run the same SwiftUI code on all of them, then make small changes to adopt each OS's unique paradigms (like menus on macOS, the crown on watchOS, the remote on tvOS) and get the most native performance via Metal etc. for free.

It's ideal for publishing to services like the new Apple Arcade and macOS/iPadOS Catalyst.

How is Flutter for accessibility features? Those seem really effortless to adopt in SwiftUI.

I guessss.....except if I want to make an app (and not a web page) I would probably make it in electron, because again I don't have to code everything twice. Making apps for apple watch or an iPad just doesn't appeal to me I guess - they always seemed like devices that were invented so people could spend more money on needless crap. Is a watch with a touch screen really that much more useful than a smart phone? Seems like just another way to suck people into a walled garden. Your watch sinks to your iPad, iTV, iWhatever...Yeesh, who cares?

As a user, I wish nothing but the eternal torment of nineteen hells upon Electron, for that is what it inflicts upon me.

SwiftUI gives me my device's native performance and UI.

For others nothing. Yeah electron is a better option then nothing.

> they always seemed like devices that were invented so people could spend more money on needless crap

As a view on the other side; I develop business apps. They are distributed via a local enterprise store, and never appear in the public App Store. Often, my apps replace paper in old-fashioned businesses. It's very honest and satisfying work.

> ideal for publishing to services like the new Apple Arcade and macOS/iPadOS Catalyst

I was just looking into this yesterday but found no info - so you're saying it's now possible to write an iPadOS app with SwiftUI and use Catalyst to port it to macOS? It used to be a "known issue" in the beta that this was not supported... does this work now?

I haven’t tried it but it must be one of their top priorities to get it working soon, as Mac/iPad hybrid apps are one of the use cases where SwiftUI makes the most sense.

You can of course write regular (non-Catalyst) projects that share a lot of the same code between Mac and iPad. In that case you may not even need Catalyst, so maybe Catalyst is only UIKit-on-Mac.

Yes, I did it earlier today and it was literally as simple as clicking the ‘macOS’ button under build targets.

That said, the app running out of the box needs a lot of work to feel like a proper macOS app.

Flutter will be abandoned by Google like it's other projects.

It's not native, it emulates native UI. What happens when they can't keep up with the updates for all the platforms they plan to support.

Also, I don't think they support platforms other than iOS/Android, desktop and web is planned, but that doesn't help me now.

I do agree with your premise though, but I use React Native for a true native UI, plus it can target Windows, MacOS, Android, iOS, and Web.

How is RN "native", I mean apart of its naming? AFAIK, RN is bundled with a browser runtime, isn't it?

No, RN isn't bundled with any browser runtime. You're possibly thinking of Apache Cordova (which leverages the device's browser runtime for rendering UI).

RN is Javascript so it will execute on the device's JS runtime, which I guess is connected to the browser in some way, but RN doesn't use the browser for UI. The rendering is true native UI.

The way React does this is by decoupling the core library from UI rendering. The core React library contains no UI rendering code, it just handles UI lifecycles, internal state, events, etc. for logical UI components as object instances. You then plug that into a renderer library (most commonly the "ReactDOM" lib for web browser rendering).

> so it will execute on the device's JS runtime

Close. RN uses JavaScriptCore (Safari's JS VM). On iOS it will use the system provided VM. On Android, it's bundled with the app.

Hermes (https://hermesengine.dev/) is the new Android JS VM optimized for boot time and memory usage.

If I do this my apps are limited to the lowest common denominator which means supporting either 6% best case of Android users, or going back further, supporting say 30%, if Flutter will even support doing so, and giving up many features thus hurting not only my Android users, but also my iOS users who could be way ahead and who stay updated. And tying the future of my project to Google? No thank you. Have you seen any Google projects lately? Shallow and not impressive at all, and often abandoned. OMG I have to code everything twice you say that like coding is not fun, or like it's the end of the world. How about this: code everything once, and target iOS. If cross platform is really needed, go with something from a serious company, like Xamarin.

Flutter will eventually get replaced by Jetpack Composer, just like ChromeOS eventually had to support ART as well.

ART running on Fuchsia gets better every day.

Reply on news.ycombinator.com