Signal won't support M1 Macs anytime soon | Hacker News Reader

Signal won't support M1 Macs anytime soon

github.com

5 pointsmthld17 comments

I am sorry, but I disagree with the notion that Signal has to support any platform, as well as a store version for Windows 10. I have an M1 and don't expect any piece of software to cater to my weird choice in platform (got it for free, nice device, but it has the usual Apple restrictions). Why should any project jump through hoops to support the Windows store? In any case, you are still free to fork or adapt it. A pull request for support still needs review and I don't think anyone has to justify not embracing it. Make a separate project to wrap it into Windows store if you really need that.

The community already done that: https://github.com/dennisameling/signal-desktop (working on Windows & Apple ARM). Still, I think it's a shame that all the work was done, ready to be merged (needed PRs were open) and Signal devs just shut the door on it.

Was there an agreement beforewise with them that they would integrate it?

That is awesome that they did, but as I said they would want to review these changes which can bindsa significant amount of developer time. There is probably nothing at all wrong with their pull requests, but given the nature of the app a review is important. And when support is made available by the community, I don't see the immediate issue as users have a solution to run Signal in these configurations.

I just searched, there's no result on the word fuck, someone got butthurt because their free work for apple didn't pay off.

The signal guy responds with a perfectly reasonable explaination, including explaining what a bug is, and why support of a new platform is indeed a feature.

So I flagged for editorialised title. Sigh.

English isn't my mother tongue, I thought the expression was appropriate but reading your comments I realised maybe not. Update the title accordingly.

That's good of you. Unflagged by me, then, but still apparently flagged by someone else.

Fuck off is a rather rude response, not suitable for use in writing in many professional contexts. It's the kind of wording you shouldn't put in other people's mouths.

Thanks for the detailed explanation, I better understand now and indeed it has no place here.

I didn't flag either, I just don't think the people in the thread has a valid point. It's entirely up to signal which platforms to add support for, and when to do it, and having whatevertheapp on your platform is a privilege, not a right, even if you make a patch for it.

Yeah I was confused when I opened up the link as well. This is basically a meta-bug complaining about why the original bug was closed: https://github.com/signalapp/Signal-Desktop/issues/4461

But as the other comments here point out, it's a perfectly reasonable response from Signal's part.

They have a policy to not talk about future features? What is there to hide/protect by witholding such information I wonder. I wont speculate, would like to have someone inform me.

Signal is slowly stacking up bye-bye points from me

Don't know what their specific reasons are, but from the obvious "not talking about future features" benefits: 1. removes unnecessary induced expectations pressure from the outside (there's already enough of it), 2. allows to focus/arbitrate on your priorities depending on your resources. They very well may have an other higher priority item on their hands at this time.

As for accepting contributed large contributed changes may be more complex overall (not just reviewing the code for correctness, but being confident it covers appropriately all desired cases and integrates appropriately with other plans - among which long term support, also managing contributors IP).

Although this argument (1) seems reasonable at first, I'm not really convinced, because although it does introduce expectations for what's to come, at the same time it removes the expectations for what's not to come.

The bye-bye points are more for the lack of transparency rather than the actual decision not to support/merge this. They could have very well given a nice explanation saying something along these lines:

- Thanks for the contribution - We don't have the resources to properly support arm64, it's not just a matter of accepting this PR but also ongoing budget allocation for supporting this platform on our products - Here is a link to a donations page, if we get X money we can allocate resources for this feature

I wonder why they wouldn’t let the iOS version downloadable from M1 Macs. Early on I had a better experience with that app .ipa on my MacBook Air and with a couple shortcut tweaks it would be perfect. It’s sad that they deliberately uncheck the box to just let it run as is on M1 in their AppStore release. Especially so for an open source app. It is also not feasible to compile manually as you would miss push notifications.

Thankfully, the x86 version runs just fine due to the compatibility layer, so it's not a big deal, anytime soon.

It became slow and unresponsive over the months, eating more and more memory. I'm currently trying the community supported ARM version and it's a relief.

Reply on news.ycombinator.com