Brent Haskins / Applied AI
Native Swift beats Electron for file-heavy Mac apps
Electron is fine for prompt palettes; it struggles when you index thousands of screenshots or hash Downloads daily. Brent Haskins ships Shelf Studio and Drawer in Swift and Draft in Electron—and chooses stack by filesystem and GPU load, not ideology.
I ship Draft in Electron because the job is search, tags, and copy over a small JSON corpus on disk. I ship Shelf Studio and Drawer in Swift because the job is watch folders, run Vision OCR, compare hashes, and stay responsive while users scroll thousands of files.
That is not a holy war. It is workload matching.
What Electron still wins
Cross-platform delivery with one UI team is real savings. Hotkey palettes, settings panels, and theming are solved problems. If your data set fits in memory and your background work is light, Electron 30+ with disciplined process separation is fine.
Security discipline is non-optional: tight contextIsolation, no remote content in
privileged windows, signed updates, and treat imports as hostile input.
Where native pulls ahead
Filesystem volume. Indexing screenshots or Downloads means handling partial files, external drives, sleep/wake, and permission prompts. AppKit and FSEvents integrations are boring and reliable; reinventing them in Node bindings is where months go.
On-device ML. Apple Vision for text inside images is a product feature on Shelf—not a server invoice. Thermal and battery behavior on a MacBook Air matters when indexing runs while the user edits in Xcode next door.
Trust copy. Users choosing a privacy-first screenshot library believe the OS vendor stack more than “we promise not to upload.” Native reinforces the story Electron can only approximate with policy text.
Drawer-specific native work
Duplicate detection by size plus hash, archive moves instead of silent delete, and cluster previews need fast metadata reads. Users forgive slow search; they do not forgive wrong deletes.
Draft-specific Electron work
Global shortcuts, clipboard copy, JSON on disk, import/export—the main thread stays UI. The risk is feature creep into filesystem-heavy territory. I keep Draft out of bulk OCR on purpose.
Hiring implication
If your spec says “Mac utility with OCR and Finder integration,” interview Swift and Vision experience. If your spec says “palette over local JSON,” Electron is rational.
Brent Haskins — related work
- Shelf Studio — screenshot grid with on-device recognition
- Drawer — Downloads cleanup with hashing and archive flows
- Draft — cross-platform prompt library
More notes on desktop product engineering live on the blog.
FAQ
Questions people ask about this topic.
When should a Mac utility be Swift instead of Electron?
Choose Swift when the product touches large folders repeatedly, uses Vision or Metal, depends on Finder tags, or must idle without noticeable CPU. Choose Electron when the UI is mostly forms, search over small JSON, and cross-platform shipping is the primary win. If your marketing promise includes on-device OCR or duplicate detection by hash, budget native early—wrappers around shell tools rarely survive support.
Can one engineer maintain both Swift and Electron products?
Yes, if scope stays narrow per app. Brent Haskins keeps shared product principles—local-first data, review before delete, honest privacy copy—while accepting two release pipelines: App Store/notarization for Swift, signed installers and auto-update for Electron. Shared TypeScript does not help the Swift apps; shared judgment about states and failure modes does.
Sources