Quite recently it was reported that Apple is rejecting apps written using the Electron framework from the Mac App Store. The apparent problem is that Electron is calling private macOS APIs which are APIs that Apple has not documented. The presumption is that the use of these APIs provided some performance benefits.
This is where we see the advantage of writing a native application. Native apps utilize more of the look and feel of the host OS and thus appear and behave more inline with the end user’s expectation. At Xojo, we use Slack for text chatting. On desktop operating systems such as MacOS and Windows, Slack is an Electron app. As such it doesn’t look and feel like other desktop apps. It also suffers (needlessly as I understand it) from the fact that it does not auto-correct as you type the way nearly every other native desktop app does. It’s interesting to note that the mobile version of Slack, which is a native app, does auto-correct text as you type just as you’d expect. This makes the native version pleasant to use and the Electron-based version annoying. It’s unfortunate, because I use the Electron-based version far more than the native version simply because I spend a lot of time on my computer everyday. I’ve been told that the Electron-based version could be made to auto-correct but I’m suspicious of this because if it were easy, I have to believe that the fine folks at Slack would have done so long ago.
Slack no doubt chose Electron upon which to base their product because of the time it would save them building it. They could focus on what makes their app unique rather than all the details of Linux, macOS and Windows. While that’s a sensible goal, Electron may not have been the best choice. It’s possible (perhaps even likely) that Slack didn’t know Electron was using private APIs. I’m surprised that those behind Electron would not have the foresight to realize the significant negative impact of using private APIs but sometimes as humans we get so far down the path with something only to run into a show stopping obstacle at the last moment that we begin to become more morally flexible in order to reach our goal. This is of course short-sighted and can come back to haunt us. We could have done the same with Xojo, but we didn’t nor would we. We always strive for what is right over what is easy.
One of the comments on the blog post I linked to above said that perhaps Slack would now choose to write a native app. I’m doubtful about this. However, that is what Slack should do. A native app would provide a better end user experience and that’s what ultimately counts. It’s all well and good to save development time but if the result is a user experience that annoys the end user, then the saved development time wasn’t worth while.
There are options (Xojo among them) for building cross-platform native applications. Xojo has a lot of text-parsing functions and our TextField control has built-in support for both spellchecking and auto-correct because it’s a native control on all platforms. This is something that we provide to Xojo users nearly for free because we use native controls. It’s another example of why native applications are inherently better.
If you want your app to provide the best user experience, it should be native on whatever platform it runs. HTML is great for the web because that is the native way to create web pages. Anyone who ever tried a Java app running in a browser knows how unnatural that feels. On the desktop or mobile, the app should be written using native (and public) APIs. In the end, software is for the user and should be written first with their user experience in mind. Saving time with a particular tool or framework is a secondary consideration.
Update: Electron has submitted an update to resolve the private API issue.