"Nativeness" of IPFS Desktop

As of building #866, we clearly verify that the app could be much better and simpler if done natively or with something else than Electron that is even snappier/faster. Although, the approach of going full native have pros and cons. I’d like to discuss with you all if this is an effort we should focus on or not.

How

By going native, we’d need to create separate macOS, Windows and Linux apps. During transition period, we could eventually build one by one and keep the Electron version alongside.

• For macOS: we could write an app natively in Swift.
• For Windows: we could write an app natively in C#.
• For Linux: we could either keep the Electron version or see if we could manage to do something else with Qt perhaps. To refer that Linux is the OS where things can vary more and is harder to support.

We could perhaps have a shared library in C++ if needed for something like a ipfsd-ctl. Or perhaps we wouldn’t even need it.

Cons

Usually people start by the pros, but I thought about starting with the negative aspects of going native:

1. We’d need to support three different technologies.
2. The above requires more work to keep the three platforms in parity of functionality.
3. We’d need to, perhaps, ditch the “so-deep” integration with Web UI. It’s not that deep: it’s just the language and three preferences. We could just open the Web UI on user’s default browser.

Pros

On the bright side of the situation:

1. Native means native.
2. Better functionality:
   • Right now, the macOS app is the one which seems more native because Electron uses the native menus. On the other hand, on Windows, Electron doesn’t use the native menu’s and doesn’t feel as native.
   • There are some features really hard to implement using the current solution. Please see https://github.com/ipfs-shipyard/ipfs-desktop/issues/678#issuecomment-472479791 for an example.
   • By being native we could perfect the functionality.
3. Smaller binaries.
4. Faster.

---

I’d really like your thoughts on this. There are some things I’d like to implement (native integrations) but that won’t be really easy to do with Electron/Node.js. Not impossible, just harder.

This would be a big change and would require a lot of work. Would it be worth it?

[hacdias]

cc @SgtPooki related to #2184

[olizilla]

I’d like to improve the stability of what we have first. I think 0.7 is a good release, but I know we can make it better.

We’re a small team with a large number of websites and apps to look after, so I’d rather we spend the next quarter improving what we have before we explore starting again.

I do totally take your point @hacdias that now we have reduced the scope of IPFS Desktop right down, it’d make a lot of sense to try out a fully native alternative, but don’t forget that we need to also come up with reliable installers and update mechanism for each platform, it just feels like we should spend our time improving proto.school and js-ipfs and webui in time for camp.ipfs.io as a much higher priority.