The UI of Foldy
A Detour with Zed
GPUI is beautiful. The fact that the team went from building Electron to “let’s just draw the damn pixels on by ourselves” is inspiring, and the size of such an undertaking cannot be understated.
That said, Kochoran is not as well-funded as the Zed team, and I do not have anywhere enough experience with performance-critical code to make something like that. Thankfully, we don’t build text-editors that require super-specific bespoke user interactions, nor is 120fps a requirement (at least, until animations start to happen). While we are focused on building the best product possible, with deep integration into whatever platform it runs on, we can still accept a 5ms delay when you open a menu - our performance requirements, although still high, are nowhere as stringent as they are in a text editor.
Just Say it’s an Electron App
Foldy, is very proudly not an Electron app. I love the Electron team and I’m super grateful for all the work they put into making it as easy and performant as possible - but shipping an entire browser with a flashcard app just couldn’t meet our requirements.
Our app needed to be:
- Small (it’s a flashcard app, it really shouldn’t be more than 100mb)
- Easy to use (familiar!)
- Fast (no dropped frames, even in massive layout shifts)
- Mac App Store compatible
- Native platform integration
This ruled out Electron in particular, but also any other webview built on Chromium. WebKit layout performance was significantly improved, and with Tauri we could make a super small binary - but it still lacked the native platform features that we wanted, such as iCloud Sync and haptics.
Yes, haptics. We’re putting haptics over cross-platform compatibility - but that’s a story for another time :)
Foldy is built with SwiftUI - Apple’s UI framework for Apple platforms. It comes with a lot of really nice things, like Spacer, and a lot of annoyances, like how there isn’t a good, functional TextEditor - for that, we have to expose either AppKit or UIKit depending on the platform.
We’ll be putting out more posts with the technical details on how our custom components were made. We tried to keep most of our components standard, as they have a uniform look with the rest of the Apple apps, and make it significantly easier to onboard a new user, as they already have an expectation of how the app will behave based on the familiar UI.
SwiftUI comes with a lot more quirks that we simply don’t have the capacity to build workarounds for - and unfortunately this is where our own product falls short of our expecations, such as the lack of animations when switching views with NavigationLink. However, we still believe that the benefits of SwiftUI are still worth these smaller blips in experience, and we hope that we have the capacity to build workarounds for them in the future.