Every once in a while I get questions about which languages I used to author F-Bar and GitFTP-Deploy.
I wrote F-Bar in 100% Swift 3 and GitFTP-Deploy has a mix of Objective-C and Swift. The reason is that Swift was not mature when it started writing the first classes of GitFTP-Deploy.
There are other techniques to write mobile and desktop apps today. Electron is one of the more popular. To be honest, I have not written any major apps in Electron or any other hybrid frameworks.
The objective is compelling to be able to write a fully cross-platform app that shares codebase and can run on macOS, Windows, and Linux. However, in my research before starting my projects, there are several significant downsides with Electron.
Memory usage
An Electron app is essentially a fully-featured Chromium browser and a Node.js process that communicate via IPC. The is, unfortunately, a show stopper for a small and long-time running menubar-app. GitFTP-Deploy is shuffling around thousands of files with tiny memory footprint.
Large builds
Packaged Electron apps contain everything they need to run, so they’re typically quite large. The “Hello World” app for Electron weighs 115 MB. This overhead is not a problem for large apps like Visual Studio Code. It does pose a problem for smaller apps that would like to use the Electron model. A typical desktop user may have a dozen utilities open. If each of these has a copy of the whole Electron stack in memory, it wastes over a gigabyte for essentially nothing.
Not truly native
The super snappy hierarchal menus native in macOS is not available in a cross-platform environment.
By all means, I don’t want do dismiss Electron, it’s a fantastic project, but it’s still important to choose the right tool for a particular job. I may case if think that going native and Swift gives me more control and F-Bar is a lot less conservative with the memory.