I'm trying Electron for the first time.
For the past many months, I have been working on a notes app for macOS. I decided to build this app using native tools for macOS, which is the Swift programming language with SwiftUI and AppKit.
In the future, I want the app to be made for multiple platforms as I personally use different devices running different operating systems. Building a native app makes this problematic as I then need to build a completely new app for each platform. That's going to take a massive amount of time as a single developer, even with AI to help... For example, for iOS I would need UIKit, for Android it would be Kotlin with JetPack, for Windows it would probably be a C# framework, and for Linux it would most likely be some C or C++ framework.
Electron would immediately work for Windows, Linux, and macOS.
My reason for choosing the native route was just to experiment and learn, and I'm happy I made that decision. I have learned a lot.
Regarding SwiftUI and AppKit, I have found the developer experience to be somewhat disappointing. The documentation has not always been the best and online resources are quite limited. Performance has also been a problem with SwiftUI and same with customizability. When implementing a new feature, I usually started out in SwiftUI and then I learned that what I wanted to build wasn't possible in SwiftUI, so I ended up having to use AppKit anyways.
And don't even get me started on AppKit. It's old. Very old. And you can easily feel that.
I find that features take a long time to get perfect with AppKit. I usually have some bugs that I end up spending way too much time trying to solve.
It also was not uncommon for me that I had to use some "low-level" APIs from AppKit. This is where it got really difficult, because as already stated, the official documentation isn't always very informative.
**Let me explain my native macOS dev experience with a bug that I experienced:**
Try to insert an `NSTextView` and then place a SwiftUI view above it.
Then try to change the `NSCursor` to arrow when hovering the SwiftUI view. You will notice that the cursor is NOT the arrow, but instead `iBeam`. This is because `NSTextView` is super aggressive with overriding the cursor no matter whatever you do. You wouldn't believe the amount of time I have spent trying to solve this bug and others alike...
This has been my experience with AppKit and SwiftUI. I feel like I have spent more time solving bugs than implementing features - that's an exaggeration, but still, you get the point :)
This sort of stuff just works by default in Chromium. Instead of solving stupid bugs, you get to actually implement features.
Login to reply
Replies (4)
Btw. here is a solution I came up with for the bug I described regarding `NSTextView` hijacking the cursor type:

GitHub
GitHub - frederikhandberg0709/SwiftUI-NSTextView-CursorFix: Fix for NSTextView aggressively hijacking the mouse cursor through SwiftUI overlays.
Fix for NSTextView aggressively hijacking the mouse cursor through SwiftUI overlays. - frederikhandberg0709/SwiftUI-NSTextView-CursorFix
I think the hot reload feature alone is worth it to use Electron over native. Having to restart the app in Xcode each time you need to test a change you made in the code is super annoying 😂
You could look into exposing the note taking functionality in a platform agnostic library and then write simpler client apps for each platform that consume the API of that lib. Ghostty solved it that way. Still a lot more work, not just because you'd have to write each app from scratch anyways, consider UI conventions for each platform, familiarize yourself with various build systems, etc. I get why Electron is among the first choices. Too bad Flutter requires knowing Dart.
Apparently, scroll bouncing does not work in scrollable divs, only the `BrowserWindow` can have the native macOS scroll behavior. That's really annoying.

GitHub
Always set NSScrollViewRubberbanding scroll bounce pref by kevinsawicki · Pull Request #9134 · electron/electron
Previously Electron was only ever setting this pref to false when the scrollBounce web preferences was set false.
Now it is always set, and set to ...