Rewriting Notion in SwiftUI

"Notion is one of the most widely used productivity apps on the Mac"

Never heard of it and their home page does not help figuring out what this solution actually does. Is it an announcement as big as when Maya was ported to Mac OS X?

I’d be curious to know how many others like Notion will do the same (Slack and Asana would be nice for instance) and if SwiftUI will make the resulting app any good, where “better than Electron” isn’t a bar high enough.

Meanwhile Gruber just tore SwiftUI a new asshole https://daringfireball.net/2026/06/swiftui_only_makes_it_easy_to_develop_bad_apps

These SwiftUI guys are clowns. Look at all the comments here and on various forums. It has flipped. SwiftUI haters are the majority now I think. Give it the Liquid Glass treatment so they fucking deprecate it and/or put it on the back burner where it belongs. Think of all the improvements that could've been made to AppKit over that last 10 years. Instead they obsess on this shitty side project and they can't even get Undo/Redo right. I encourage everyone to keep telling Apple that this shit sucks otherwise this is what we are going to get stuck with.

> I’d be curious to know how many others like Notion will do the same

Not many. All these AI apps are Electron. Claude, Codex. Hermes Desktop. They probably bribed them..."we'll mention you at WWDC if you use SwiftUI." Traditionally you go native to provide better UX but SwiftUI sucks just as much so there is no point.

ObjC, too bad Gruber doesn’t know what he’s talking about. Journal is a Catalyst app, not SwiftUI

@Anonymous It looks to me a like a SwiftUI Catalyst app.

@ObjC4Life, I share your sentiment almost 100% (I’m a bit less angry, I’d say :-)), but I’m afraid it’s already far beyond the point of no return. Stop dreaming about ObjC 3.0, it’s not going to happen, because “oh my God, square brackets are soooooo scaaaaary and uuuuuugly, I can’t even look at such code on my screen, without my sensitive, self-entitled stomach making me puke”. It’s been 12 years since Swift (about just 2 years less than the whole Mac OS X period prior), 7 years since SwiftUI, tons of resources invested, not to mention PR disaster if Apple eventually gave it all up. Foundation is already converted to Swift, they’re already pushing SwiftUI lower and putting AppKit/UIKit on top of it (it’s been vice-versa before), if I heard correctly in WWDC26 keynote, they mentioned starting to rewrite OS internals and fundamentals in Swift…

Personally, I still use ObjC/AppKit combo EXCLUSIVELY in my applications. I was planning to start migration to Swift once I drop support for older macOS versions (I didn’t want to bundle Swift libraries into application bundles), although I never liked how Swift and AppKit work together, it just seems clumsy, with AppKit designed with ObjC in mind and around it, plus a lot of Swift Cocoa type conversions, plus the pain of using Swift with plain C code (and I have a lot of such code). Then, when the time to start conversion came, the whole “Swift concurrency” disaster has already been going on, with things drastically changing even between point releases…

In parallel, SwiftUI came out with great promises, only to deliver more and more disappointments every following year. Today, it’s still not possible to make a decent macOS application with SwiftUI, provided the application requires something more UI related than what one usually sees in almost toy examples in all SwiftUI books and tutorials. Yes, it’s possible to make the application, but note the word “decent”. I mean c’mon, after 7 years they still can’t figure out drag’n’drop and undo/redo, two techniques Mac was always praised for (“in Mac, you can drag anything and drop it on anything, and it will do the right thing”) and which Mac (and partially Lisa beforehand) actually brought to the wider audience in early ‘80s.

With latest SwiftUI backlash I had a tiny hope AppKit (and UIKit) would start getting some attention, mostly to modernize and make them work better with Swift, eventually converting them to full Swift and make them feel like at home when used in that language. However, WWDC26 keynote killed that last tiny hope as well.

I guess I’m lucky that my applications don’t really need (yet) anything, which can be achieved with Swift/SwiftUI only. So, for the time being I’ll keep doing what I already do. I still have one last tiny hope that, by the time I finally HAVE TO make the switch, things around Swift/SwiftUI will somehow, magically, be sorted out and in decent order to actually have some pleasure working with and achieving the full potential macOS offers.

Apologies to everybody for being this long.

@Dragan But it really is Objective-C for life so I can't stop dreaming! I believe ObjC 3.0 will eventually happen, with or without Apple.

> Foundation is already converted to Swift, they’re already pushing SwiftUI lower and putting AppKit/UIKit on top of it (it’s been vice-versa before), if I heard correctly in WWDC26 keynote, they mentioned starting to rewrite OS internals and fundamentals in Swift…

Yea but the Swift version of Foundation sucks. It has so many bugs. SwiftUI being at the 'lower level' than AppKit/UIKit has proven to be the source of many performance issues/bugs.

Apple themselves can't even get acceptable performance with SwiftUI in SIMPLE apps like Contacts (https://mjtsai.com/blog/2025/11/21/contacts-in-tahoe/). I want to see them rewrite Finder in SwiftUI (actually I don't). I don't think they can even if they want to.

> not to mention PR disaster if Apple eventually gave it all up.

As they keep adding more and more SwiftUI they are painting themselves further into a corner. They will have to walk it back. The longer they wait to revert the worse it will be. If management is so stubborn on this, they will release a really unstable OS and the PR disaster will be way worse (users are more important to Apple than developers). Also I'm not sure if the developer backlash from walking away from SwiftUI will be as bad you think. Look at all the negative comments: https://mjtsai.com/blog/2025/06/18/swiftui-at-wwdc-2025/ ...most devs have had enough, I think. They will use cross-platform frameworks instead.

They should just let devs write UIKit/AppKit apps in both Swift and ObjC and not try to bind features to one particular programming language. Stay on that track and quietly put SwiftUI in "maintenance mode." I don't like Swift but clearly some devs do so just going back to that will avoid a PR issue. Most of these Swifts only care about avoiding square brackets so they'll be happy as a pig in shit writing UIKit in Swift, or asking an LLM to do it for them. They don't have to even deprecate it. Just slowly, quietly, stop emphasizing it. And stop using it everywhere because it is dragging everything down. Then in like five years maybe, deprecate it.

> But I’m afraid it’s already far beyond the point of no return.

Now is not the time to tuck tail and cluck! https://mastodon.social/@stroughtonsmith/115808174025220815

Devs can very easily make SwiftUI the next Liquid Glass. Just tell Apple you don't like it. Stop using it.

I really don't understand this absolute hatred of Swift. I've been developing commercial software since before obj-c became the language of choice on Mac. I liked obj-c compared to what was used prior: c & c++ (back in the days of CFront). I've been using Swift since v3.0 and have generally been happy with it. No, I don't make use of some of the more esoteric aspects of the language added since, but in general, it is concise, expressive and, dare I say, delightful to use.

I don't understand the SwiftUI hatred. SwiftUI is great in many situations, but not all. Sometimes imagining all of my UX as a purely state-driven system is as complex, if not more so than the imperative code I have. So I'm adopting SwiftUI where it makes sense.

I don't need to be a purist on language or UI toolkit. These tools(toolkits) are designed to work together. Sometimes SwiftUI is the quickest and best way to get a straightforward interface (vs. managing a XIB), with some nice animation to boot. In other cases, a mixture of SwiftUI components with AppKit (UIKit) works best. And sometimes, it's all AppKit (UIKit). I am grateful that can do all of the above.

Personally, I'm not "rewriting my entire app in SwiftUI." I'm also not clinging to obj-c with everything I've got. My main app is now mostly Swift, but with components in obj-c, I even have some components in pure c, and a mix of AppKit and SwiftUI for the interface. No need for absolutes on anything.

@ObjC4Life, I agree with every point you made, the only difference seems to be that, given Apple's current behaviour, I think they're more willing to risk eventual PR disaster you described (and hope it won't happen) than rather certain PR disaster if they made any drastic changes now. Regarding that post from S T-S, I was hoping to see any, even the slightest proof of it on WWDC26. Since it didn't happen, I assume the rumour was either blown out of the proportion, or the critical mass for the change still isn't there (and questionable if it ever will be).

@Mark Munz, I can't speak for others, but I personally have no hatred toward anything. I do have some gripes though. With Swift, it's primarily about tooling, which still is terrible, after 12 years! And constant significant changes even in point releases. I know we live in the world of rapid changes, especially when it comes to technology, but with Swift it's just over the board. Compare it to languages of the same age, even older. Not to mention when it comes to the number of reserved words (including contextual keywords, declaration modifiers, keywords introduced by the standard library, and compiler directives) it, slowly but surely, reached No3 (after COBOL and PL/1, soundly beating C++). Like said, I was about to start migration when "concurrency fiasco" (yes, I consider it a fiasco) started happening (and introducing about 15+ more keywords in the process).

With SwiftUI, the problem, and here I believe many complainers would agree with me, is that Apple keeps pushing it as THE solution for everything UI, including macOS, where it's obvious it SUCKS as a solution to everything. Now, pushing it as such solution only in terms of continuous development accompanied and verbal noise would not be a problem per se. The problem is it happens at the huge expense of AppKit/UIKit, which have been neglected for almost a decade, yet still being the only solution in many cases, especially on Mac. I think the fact that arguably still the best SDK stacks in macOS come from NeXT days is rather discouraging.

> I really don't understand this absolute hatred of Swift.

Swift itself the reasons are:

-Slow compile times
-Compiler crashes
-Cryptic build errors (compiler timed out) / compiler timeouts. Often compiler does not suggest how to fix an error.
-Encourages developers to not document code.
-Public/private API + documentation are in the same file (yes I like headers). This forces Xcode to have to "Generate an Interface" which makes things even slower.
-Jump to Definition almost never works.
-Frameworks generate a huge single "generated header" for the entire framework ...all in the same file.
-Live Previews crash.
-Type checking sucks https://mjtsai.com/blog/2025/11/14/roadmap-for-improving-the-swift-type-checker/

SwiftUI well the hatred there is tied to the results it produces. The links in previous posts document many of the issues this framework has. I don't appreciate Apple trying to force it down my throat. Wag that finger in my face "SwiftUI or you're in trouble"...
And I don't appreciate the prospect of having to inherit all these SwiftUI bugs when I specifically wrote my entire app in AppKit just because some doofus manager thinks because he's the one who made the call it'll make him the Godfather and they will put a statue of him in Apple Park. What a schmuck.

The timestamp for the section raving about SwiftUI — including that Notion rewrite — is 27:09–28:45 : https://www.youtube.com/watch?v=yl2jsIoMfDU&t=27m09s

It's full of hilarious gems right from the start!

^ wow. They are delusional

>> I’d be curious to know how many others like Notion will do the same
> Not many

I mean, this is probably a slop conversion, right? If you can tell an LLM "make this a native Mac app" in the evening, and you have something you can ship to customers in the morning, this might be something other companies do as well. Particularly if Apple gives them a Keynote spot in return for their tokens.

If it turns into an unmaintainable mess of garbage in six months, they can always just go back to shipping the Electron app; it's not like enough people would notice to cause a stir.

One interesting thing (to me) is how Apple, or Apple "community" or whoever managed to create widespread association of Swift(UI) with "Mac native app".

I rarely visit reddit and I don't really like it, but lately I tried to use it to promote my applications a bit there and hence I also read many replies/discussions to posts targeting particular applications, but also general Mac questions. Occasionally there are questions/surveys like "what do you consider being a native Mac app and how to recognize it", mostly targeted to bash things typically associated with Electron applications. It amazed me how many responses were "SwiftUI", "Plain and simple: SwiftUI" and similar (even though probably many responders wouldn't even be able to verify that an application actually contains SwiftUI code).

From that "marketing" point of view, Apple (+ "community") definitely managed to push SwiftUI-mania quite far.

reddit Mac "communities" are flooded with mostly ignorant teenagers / vibe coders. I wouldn't put too much stock in what you read there.

It's really on developers to step up. They complain so much about SwiftUI's shortcomings and then continue to use it! We need some of that anti-Liquid Glass energy applied to SwiftUI. SwiftUI is harming the platforms (Mac especially) way more than Liquid Glass.

> @Anonymous It looks to me a like a SwiftUI Catalyst app.

@Michael, I checked with otool to confirm it's using SwiftUI somewhere. But attaching with the view debugger shows that Journal's main editors aren't using SwiftUI at all, just custom UIKit views.