Live data from Hacker News

Why I quit using SwiftUI

chsxf.dev

191–200 of 257 posts

Re: Why I quit using SwiftUI

#191
post #19

Earlier quoted context omitted.

I’m with you, however mac os remain the best dekstop OS and iOS remain the best mobile one, even after all those years. So, they must be doing something right..

Not really. Remember that their "competition" at the time the iPhone came out was utter shit, and Android (although a far cry from those days) is still pretty much shit.

Symbian was quite alright from user point of view, not so much from Symbian C++ developer experience though.

Some of its features are yet to appear on iOS.

Re: Why I quit using SwiftUI

#192

Earlier quoted context omitted.

iOS lacks many features that have been standard on Android for years and the only reason it feels so smooth is because the UI thread has pretty much the highest QoL that anything can ever have. iOS would rather drop your network call than drop a single frame. Android variants all have things that iOS can only dream of having in five years (notifications was a fun one), just spread very unevenly throughout manufacture…

Android has been years behind having a framework for low latency audio and it has always struggled with power efficiency.

That was sorted out with Oboe/AAudio, when they took Samsung's audio SDK into Android.

Re: Why I quit using SwiftUI

#193

People burn an astounding amount of CPU and brain cycles pretending that UIs are something they are not. (i.e. "pure" functions) I hope Apple never goes the way Microsoft did with their fad UI toolkits that utterly destroyed developer trust in native Windows development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, w…

MFC is a thin wrapper around Win32. I don't recall it ever being a fad, either. WinForms is basically Delphi's VCL ported to .NET. And back in 90s, Delphi was one of the most popular ways to make native Windows desktop apps.

On the Microsoft side, it is still the best way to do C++ GUI development, after they killed C++/CX, and replaced it with the pre-historic C++/WinRT tooling (return to the ATL days but without VS tooling support).

Re: Why I quit using SwiftUI

#194
post #2

SwiftUI is a big opportunity that Apple's not investing enough in, IMHO. It's good tech, and the reactive approach is excellent for many typical view-based needs, but at the same time the docs are terribly lacking at how to handle any kind of edge cases. Success to me looks like steering clear of SwiftUI for now, and advocating for Apple to hire documentation editors/leaders who can 1) create SwiftUI documentation of…

We've been hearing this for years now, though. And we've seen SwiftUI takedowns on here before, a year or more ago, and even then SwiftUI wasn't exactly new. Meanwhile, my team has built an entire cross-platform desktop app in Qt with QML, which has been around for years and works refreshingly well. You're telling us that Apple, starting fresh and with several years under its belt now, still hasn't gotten its shit to…

> Remember the "ground-up rewrite" of Finder we were promised several major OS releases ago?

No? I've never heard of this. Do you have any citation for such a promise?

Re: Why I quit using SwiftUI

#195

People burn an astounding amount of CPU and brain cycles pretending that UIs are something they are not. (i.e. "pure" functions) I hope Apple never goes the way Microsoft did with their fad UI toolkits that utterly destroyed developer trust in native Windows development (MFC, WinForms, WPF, UWP, WinUI, .Net MAUI). They are pretty wise for keeping SwiftUI be the "for kids" vanity UI toolkit to lure in React webdevs, w…

MFC? As somebody who has worked with MFC in some way or another for the past 25 years, there are worse examples out there. The beauty of MFC was that it was pretty simple layer on top of Win32 and the source code was provided. You can continue to use it with some of their newest stuff using XAML Islands.

Ironically it is still the best way to do C++ GUI development on the Microsoft stack, after they killed C++/CX, and replaced it with the pre-historic tooling C++/WinRT.

However for a real nice C++ GUI development experience on Windows, going with C++ Builder or Qt would probably be a saner option, as the WinUI team doesn't seem to get it, and MFC only gets minor updates nowadays.

Re: Why I quit using SwiftUI

#196
post #174

Earlier quoted context omitted.

Google was forced to do it, because contrary to iOS, Android updates only take place when one buys a new phone, for all pratical purposes, even if Google pretends we have lots of nice OEMs doing updates.

They were not forced to do it because of their OS woes. They just did the correct thing. Apple's not doing the correct thing. SwiftUI just created a barrier where people pre-iOS 13 lose access to a lot of apps, and those apps will be raising their minimum version a lot more often than before. So if anything, you could consider this a ploy by Apple to get people to upgrade their phones.

Nope, if Android updates were a reality, there was no need to ship a system library with the application.

That is the whole point of Jetpack libraries, to ship newer versions of Android with the application, with polyfills, as the OS updates will never happen.

Re: Why I quit using SwiftUI

#197
post #176

Earlier quoted context omitted.

Some? More like all AAA applications use ~100% ObjC. I'm talking about apps like Facebook, Messenger, Instagram, YouTube, etc.

Those use mostly C++ alongside Objective-C, or nowadays Swift, unfortuly what most use is something like React Native, Flutter,....

I'm pretty sure that Adobe Photoshop is still C++.

Funny story. It started off as Object Pascal, and used MacApp 0.9 as its framework.

I think the codebase was converted to C++, around Photoshop 3.

Snapseed[0, 1] (won awards) had its engine written in C++.

C++ is a good language for image pipelines. Doesn't really pass the "ooh, shiny!" test, though...

[0] https://apps.apple.com/us/app/snapseed/id439438619

[1] https://play.google.com/store/apps/details?id=com.niksoftwar...

Re: Why I quit using SwiftUI

#198
post #111

Earlier quoted context omitted.

I hope you don’t apply the same philosophy to security patches.

In what world would security critical parts affect the UI. What does my ui care if the system libcurl changes? Swiftui is a ui framework, keep that stuff separate

A UI library does a lot of text processing, often with data coming from external sources. Lots of potential for buffer overflows etc.

Re: Why I quit using SwiftUI

#199
post #176

Earlier quoted context omitted.

Those use mostly C++ alongside Objective-C, or nowadays Swift, unfortuly what most use is something like React Native, Flutter,....

I'm pretty sure that Adobe Photoshop is still C++. Funny story. It started off as Object Pascal, and used MacApp 0.9 as its framework. I think the codebase was converted to C++, around Photoshop 3. Snapseed[0, 1] (won awards) had its engine written in C++. C++ is a good language for image pipelines. Doesn't really pass the "ooh, shiny!" test, though... [0] https://apps.apple.com/us/app/snapseed/id439438619 [1] https:…

Yes, the initial Photoshop version source code has been made available.

https://computerhistory.org/blog/adobe-photoshop-source-code...

Re: Why I quit using SwiftUI

#200

Earlier quoted context omitted.

iOS lacks many features that have been standard on Android for years and the only reason it feels so smooth is because the UI thread has pretty much the highest QoL that anything can ever have. iOS would rather drop your network call than drop a single frame. Android variants all have things that iOS can only dream of having in five years (notifications was a fun one), just spread very unevenly throughout manufacture…

You must be kidding. There's no excuse for Android's incompetent architecture, which orphans millions of devices with every release because it apparently lacks a competent hardware-abstraction layer and driver model. You can install creaky old Windows on millions of devices with disparate hardware configurations on the day of its release, but Android users must wait weeks, months, or forever for their telcos to dribb…

That's out of date. They added a very competent HAL and driver model yonks ago:

https://source.android.com/docs/core/architecture/hal-types

The big lift here was scrapping the Linux driver model which was at the root of most of the pain.

Post reply on HN