Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apple’s Use of AppKit, Mac Catalyst and SwiftUI in macOS

blog.timac.org

Post reply on HN
Print view View original

121–130 of 145 posts

Re: Apple’s Use of AppKit, Mac Catalyst and SwiftUI in macOS

#121

Post by nikanj »

dangelov wrote: post #38

I recently took to rewriting what should be a very simple app from Obj-C to Swift with SwiftUI - because it's the future. The CPU usage was at 5% while idle, just for having a simple tiny pie chart that updates. Not to mention that for some seemingly basic things I still had to use AppKit anyway. Wrote basically the exact same thing 1 day later in Swift with AppKit and NO SwiftUI and it sits at 0% CPU usage with less…

”Premature optimization is evil” is dogma, but you can’t keyhole optimize the architecture after the fact.

Just like cars, you can’t build a Kia Soul, and then just replace a few parts to reach Ferrari-like performance.

Re: Apple’s Use of AppKit, Mac Catalyst and SwiftUI in macOS

#123

Post by microtonal »

hbn wrote: post #3

I hate this consolidation of mobile and desktop apps and I hoped Apple would have had the design sense to keep them separate like they should be. Mobile and desktop UIs are two different worlds with different interaction paradigms. Trying to combine them makes an awkward UI that feels good nowhere.

I hoped Apple would have had the design sense to keep them separate like they should be

I don't think Apple lost their religion. I think Catalyst/SwiftUI were created as an answer to desktop applications moving to Electron. Moving to web-based applications significantly reduces the value proposition of macOS and to some extend also iPadOS/iOS. Most likely, a SwiftUI app will still be a better macOS app than an Electron app. And if you can use a single framework across Macs/iPhones/iPads, it might entice developers to use SwiftUI for Apple platforms instead.

IMO, Catalyst and SwiftUI (at least so far) are a regression compared to good-old AppKit apps. But the world has changed, and I'd rather have a Mac/iOS world with SwiftUI apps than one with Electron/Ionic/whatever apps. At least the SwiftUI apps will look somewhat consistent and provide stronger platform integration.

Re: Apple’s Use of AppKit, Mac Catalyst and SwiftUI in macOS

#124

Post by skygazer »

whywhywhywhy wrote: post #122

Boggles my mind that as they rewrote preferences to match iOS not one person said “hang on, is this design even any good on iOS?” Because honestly I find it impossible to find anything in it and the search doesn’t even work reliably.

Interestingly, the search index in iOS Settings is not based on localized UI strings, as one would assume or hope, but on keywords that are updated independently of the UI as a neglected afterthought. So, while it’s technically “reliable,” you’re right that it can’t be relied upon.

Re: Apple’s Use of AppKit, Mac Catalyst and SwiftUI in macOS

#125

Post by GeekyBear »

130e13a wrote: post #116
GeekyBear wrote: post #61

Earlier quoted context omitted.

> 4 iterations later AppKit (NextStep) has been iterated on for over 30 years now. Apple's development strategy is like that of old school Microsoft. They make a choice like Win32 and just keep on iterating on it over the long haul. Four years of SwiftUI would still be described as very early days. Nothing like the development strategy of the week you see Google and the Microsoft of the past decade push as the one tr…

UIKit after four iterations (i.e., iOS 6 in 2012) was far from its "very early days": it was a well-designed, production-ready, powerful UI framework that was way closer to AppKit than SwiftUI (in its fourth iteration) is to UIKit now.

UIKit started out with more polish because they took the AppKit they had iterated on for so many years and slimmed it down for extremely resource constrained devices.

They weren't starting from scratch.

Re: Apple’s Use of AppKit, Mac Catalyst and SwiftUI in macOS

#126

Post by pennaMan »

conradev wrote: post #13
WoodenChair wrote: post #9

It's really not an impressive showing for SwiftUI. 4 iterations later and after being told it's "the future" in unequivocal terms, it's still at 12% (and only like 3% without any AppKit combined (last chart)). It's not dogfooded for any productivity apps. For Ventura, rewriting "Font Book, System Settings, and Tips" is not exactly confidence inducing. If they rewrote Pages or Final Cut Pro, that would wake people up.…

Why would they rewrite Final Cut Pro in SwiftUI? Rewriting code is a large effort and a waste of time without proper justification – new developer tooling for UI is not usually a good enough justification to rewrite the entire UI

Plan to throw one away

https://inkdroid.org/talks/notredame/plan.html

Re: Apple’s Use of AppKit, Mac Catalyst and SwiftUI in macOS

#127

Post by klabb3 »

trinix912 wrote: post #32
alexashka wrote: post #28

Meh. Apple has near infinite resources, it can do whatever it wants. The rest of industry has moved on to Electron and keeps bucking, trying to get react native or some other cross platform thing to work well enough on mobile. Apple itself uses webviews for complex UI in their desktop Music app. Are there any non-trivial apps Apple has created from scratch in the past decade using its own libraries and frameworks? No…

Electron is not a good option either. It defeats the entire point of making a desktop app in first place. It's slow, wasteful, abstracts too much of the filesystem away for a desktop app, doesn't integrate into the OS, doesn't use the OS-provided UI widgets, etc. etc. It also depends on what you mean by "non-trivial". For me, something like Final Cut Pro is non-trivial. I'm yet to see that kind of thing (one that's a…

> Electron is not a good option either.

Nobody is saying that. It's a good stop gap for building cross platform apps that don't need to be rewritten every 2 years, when MS and Apple design PMs launch a new fad framework. (Friendship ended with rounded flat buttons, new best friend is glassomorphism)

What people want is primarily a good rendering target, and for that you just need a webview. You can port many electron apps to Tauri today and reduce footprint to native levels. OS vendors have slowly and reluctantly come around to provide webviews.

> It defeats the entire point of making a desktop app in first place.

Absolutely false. Sure, there are a few apps that could have been web only, but have you seen Electron's API surface? It provides a ton of useful features for apps that can't be achieved through the web, such as.. Opening a file by path.

> It's slow, wasteful[...]

Electron is perhaps slow to start, but fast afterwards unless you bloat it with your own crap. And electron is wasteful though, a lot. However, webviews used correctly has no meaningful perf downside. In fact, JS- and web rendering engines are some of the most optimized pieces of code there is.

> [...] abstracts too much of the filesystem away for a desktop app

I'm not sure what you mean? Electron provides the Node APIs directly, which are similar to any other std lib. Speaking of abstracting the file system, have you seen Apple's "bookmarks" they created for persistent file permissions within a sandboxez app? That's abstraction for you.

> [...] doesn't integrate into the OS

Partly true, and it should be better. Any cross platform UI framework is at a disadvantage because native is completely non-standardized. At the same time, web gives you accessibility, zoom, system fonts, rtl, locale etc, so it's much better than most bespoke UI frameworks.

> [...] doesn't use the OS-provided UI widgets

Text fields and similar inputs are native by default. For say sidebar nav, it's again not standardized, so you have to either provide high-maintenance-greatest-common-denominator APIs or trouble the developer with per-OS moving target APIs. I understand why devs don't bother, and as a user I prefer that VSCode works the same across my computers over 2-3 per-OS uncanny valley same-but-different experiences.

Re: Apple’s Use of AppKit, Mac Catalyst and SwiftUI in macOS

#128

Post by odshoifsdhfs »

dangelov wrote: post #38

I recently took to rewriting what should be a very simple app from Obj-C to Swift with SwiftUI - because it's the future. The CPU usage was at 5% while idle, just for having a simple tiny pie chart that updates. Not to mention that for some seemingly basic things I still had to use AppKit anyway. Wrote basically the exact same thing 1 day later in Swift with AppKit and NO SwiftUI and it sits at 0% CPU usage with less…

Did you find out what was causing it? I have developed 'heavier' (aka 50k lines of code) applications in SwiftUI on mac and it mostly sits idle (0-1% cpu based if it is doing some regular background stuff). Heck, I just created a quick Charts based app from an online example on Mac and stays at 0,0%.

Is it possible it is re-rendering the view hierarchy due to some data invalidation you haven't noticed?

Re: Apple’s Use of AppKit, Mac Catalyst and SwiftUI in macOS

#129

Post by lapcat »

microtonal wrote: post #123
hbn wrote: post #3

I hate this consolidation of mobile and desktop apps and I hoped Apple would have had the design sense to keep them separate like they should be. Mobile and desktop UIs are two different worlds with different interaction paradigms. Trying to combine them makes an awkward UI that feels good nowhere.

I hoped Apple would have had the design sense to keep them separate like they should be I don't think Apple lost their religion. I think Catalyst/SwiftUI were created as an answer to desktop applications moving to Electron. Moving to web-based applications significantly reduces the value proposition of macOS and to some extend also iPadOS/iOS. Most likely, a SwiftUI app will still be a better macOS app than an Electr…

> I think Catalyst/SwiftUI were created as an answer to desktop applications moving to Electron.

How is it an answer? Electron gives the developer the same code for the web and for Microsoft Windows. Catalyst and SwiftUI give the developer none of theses.

Re: Apple’s Use of AppKit, Mac Catalyst and SwiftUI in macOS

#130

Post by pohl »

klabb3 wrote: post #127
trinix912 wrote: post #32

Earlier quoted context omitted.

Electron is not a good option either. It defeats the entire point of making a desktop app in first place. It's slow, wasteful, abstracts too much of the filesystem away for a desktop app, doesn't integrate into the OS, doesn't use the OS-provided UI widgets, etc. etc. It also depends on what you mean by "non-trivial". For me, something like Final Cut Pro is non-trivial. I'm yet to see that kind of thing (one that's a…

> Electron is not a good option either. Nobody is saying that. It's a good stop gap for building cross platform apps that don't need to be rewritten every 2 years, when MS and Apple design PMs launch a new fad framework. (Friendship ended with rounded flat buttons, new best friend is glassomorphism) What people want is primarily a good rendering target, and for that you just need a webview. You can port many electron…

> Electron is perhaps slow to start, but fast afterwards

This triggered my JVM PTSD.

Post reply on HN