5 ms·
It's not, it's an Electron-based app (not bad by default). Even says so on their Github page: https://github.com/signalapp/Signal-Desktop https://github.com/sig
by mikhailt 5y ago
It's not, it's an Electron-based app (not bad by default). Even says so on their Github page: https://github.com/signalapp/Signal-Desktop https://github.com/signalapp/Signal-Desktop
Unless you're using a non-official version?
- deleted 5y ago[deleted]
- Klonoar 5y agoIt’s also a bit worse if you’re an M1 user. Last I checked it also runs under Rosetta in compatibility mode, which is annoying since it drains my battery more as a result. I’ve been awaiting an M1 build for a bit now...
- sneak 5y agoI didn't realize you were using the term "native" to refer to compiled versus interpreted. The electron binary is native code, of course, or it wouldn't execute.
- mikhailt 5y ago> The electron binary is native code, of course, or it wouldn't execute. It isn't always; after all you can run Electron apps under Rosetta if there's no M1 version of it even though it is compiled but for Intel instead. So, it is not as simple as "compile vs. interpreted" because there's emulation as well. In this case, many folks don't consider Electron as native because it doesn't use native UI frameworks as it uses the web stack tech (JS/CSS/HTML/etc) to render. That's why Electron apps can run with same UI on all desktop platforms. In other words, pure Swift/Cocoa UI apps are considered to be native macOS apps, even if its backend is built in any native language like Objective C/Swift/Rust/C etc. However, same folks will not consider Electron apps as native even if it is using a backend built in any native language such as Objective C, Swift or Rust/C/C++.