3 ms·
While that certainly squares with my mental model, do you happen to have a link to that decision?
by mdaniel 5y ago
While that certainly squares with my mental model, do you happen to have a link to that decision?
- drcongo 5y agoSorry, yes. There's multiple sources, but a lot of it collected here: https://github.com/signalapp/Signal-Desktop/issues/4461 https://github.com/signalapp/Signal-Desktop/issues/4461 They keep shutting down tickets about it, refuse to review a PR that implemented it for them, and won't even tick the box on the Signal iPad app that would make it available on M1 Macs (where side-loaders have already confirmed for them that it works perfectly. 90% of my Signal usage was on desktop, so this has left such a bad taste that I'd rather use almost anything else now.
- wlesieutre 5y ago> won't even tick the box on the Signal iPad app that would make it available on M1 Macs Isn’t that box ticked by default? I think what Signal has done is gone in and deliberately unticked it to make you use the Intel Mac app in Rosetta rather than the iPad app. Edit: yup > After you sign the updated developer agreement, the App Store automatically makes compatible iOS apps available to users of a Mac with Apple silicon. However, if you’re already planning to ship a macOS version of your app, or if your app doesn’t make sense on the Mac, you can change your app’s availability in App Store Connect.
- drcongo 5y agoWow. That's even more user-hostile then.
- wlesieutre 5y agoI can see it making sense if you're a cross platform shop and a high quality Mac app is something that you're prioritizing. You might not want people to inadvertently happen on an iPad app that will run on the Mac but is worse than the Mac app. But it doesn't sound like Mac is a big priority here, so who knows why they would do that.
- willk 5y ago> tick the box on the Signal iPad app that would make it available on M1 Macs This annoys me the most. I don't see the downside of them enabling it. It would bring the Mac client into feature parity with the IOS client and eventually reduce complexity. It seems like it would be an easy win-win.
- Klonoar 5y agoThe reason for this is that the iOS and macOS security models for attachments are not the same, and so additional work has to be done before it could work. It’s not just click and go. (At least this is what I read months ago)
- 0_____0 5y agoIs there a substantial benefit to running something like Signal on M1 natively vs. through Rosetta? I don't have an M1 Mac so I don't a feel for this issue but my understanding was that between Intel and M1+Rosetta, x86-64 native applications run approximately the same.
- Klonoar 5y agoBattery life, especially with regards to Electron.
- vinay427 5y agoNot the person you replied to, but a GitHub issue thread [1] seems quite close. I find it somewhat confusing and potentially troubling that (from a few minutes of searching so correct me if I’m wrong) a full-featured ARM-native fork seems to have been created in the community, but the team apparently doesn’t want to go the extra mile of designing the build/CI system to incorporate this as an official release. [1] https://github.com/signalapp/Signal-Desktop/issues/5612 https://github.com/signalapp/Signal-Desktop/issues/5612
- mdaniel 5y agoThat's why I said it squares with my mental model. IIRC they have been super hostile to any 3rd party clients, which is (likely) what "created in the community" means to them I also have a ton of bitterness about their build system since it seems every few months they make their gradle and codesigning process more and more hostile to self-building. And I appreciate that is kind of an edge case but if they ever want people to chip in and try to fix the seemingly unbounded MMS (and now SMS!) bugs, they'd be well served to have less wizardry