Search code examples
javascriptswiftmacosmac-app-storeelectron

What are the limitations of using Electron to build Mac Apps?


I have found limitations in using frameworks like Ionic for building mobile apps. These are mainly to do with accessing device specific functionality. So two questions:

  1. Are there any similar limitations with using Electron for building Mac Apps?

  2. What are the advantages of building native apps using swift?


Solution

  • Some native capabilities are available in Electron, like adding an entry to the Dock menu or showing a menu bar icon. Other capabilities have been added by third parties, like this one, which plugs into System Preferences. If nothing else, there's a JS-to-Obj C bridge, to invoke Objective-C code.

    Another important factor is that apps made using write-once-run-anywhere frameworks often have an odd UX and don't fit in to platform conventions. You get this free when you build a real native app using Cocoa and Swift / Objective-C.

    For example, toolbars should change in appearance when the window loses focus. You can see this for yourself by opening (say) Safari Preferences and then switching to another window or app. Electron apps don't do this.

    As another example, if a right-click menu is open, the user should be able to press "C" to move the selection to "Copy". Electron again doesn't do this.

    This results in an app that looks and feels odd and second-tier. If a native-quality UX is a priority, build your app in Cocoa.

    If you don't have the resources to build separate Mac and Windows apps (say you're a two-person startup or a charity) but still want a better UX than a web app, then consider Electron.

    Reference: Making a web app feel native, and a subsequent email discussion with Ben Gotow, the engineer who gave that talk.