<p>Of course. QT, the GUI framework Bitcoin Core uses, is one of the most portable GUI frameworks. Sooner or later, Apple Silicon support will be added. Meanwhile you can track the progress here: <a href="https://bugreports.qt.io/browse/QTBUG-85279" rel="nofollow noreferrer">https://bugreports.qt.io/browse/QTBUG-85279</a></p>
<p>Then Core developers will do the rest: <a href="https://github.com/bitcoin/bitcoin/issues/20371" rel="nofollow noreferrer">https://github.com/bitcoin/bitcoin/issues/20371</a></p>

CC BY-SA 4.0
2020-11-22T17:46:34.637Z
2020-11-22T17:46:34.637Z
MCCCS
<p>It was discussed at an anonymized Sydney <a href="https://diyhpl.us/wiki/transcripts/sydney-bitcoin-meetup/2020-07-21-socratic-seminar/" rel="nofollow noreferrer">Socratic Seminar</a> in July. I'm assuming MacOS will continue to be supported but it is becoming harder &quot;to build and distribute binaries in the completely reproducible, trustless manner&quot; that Bitcoin Core would like to.</p>
<blockquote>
<p>Apple is introducing these notarization requirements where we would
have to build our binary and then send it to Apple servers so they
could notarize it. Then they would send it back to us and that’s the
only way we could distribute a binary out to end users that would run
on their Macs. Obviously doing that sort of stuff is tricky for us
especially if it requires more official things like having an
organization. I guess we already do that in some part because we have
code signing certificates but I think the direction that Apple is
going is making it harder and harder for us to continue or want to
continue releasing Mac OS binaries. I know some of the developers are
getting less enthused about having to deal with all of Apple’s changes
and distribution requirements.</p>
</blockquote>

CC BY-SA 4.0
2020-11-22T18:41:33.537Z
2020-11-22T18:41:33.537Z
Michael Folkson
<p>Should we expect in the foreseeable future a Bitcoin Core release optimised for ARM-based Macs?</p>

CC BY-SA 4.0
2020-11-22T18:43:18.600Z
Why are people voting to close this? I am perplexed sometimes at what people vote to close. This is a perfectly reasonable question and specific to Bitcoin Core.
Michael Folkson
CC BY-SA 4.0
2020-11-22T20:27:35.540Z
Well, the question sounds like it's asking for an option. Whether Bitcoin Core releases for ARM-based Macs will exist in the future depends on whether someone works on it. It would be different if the question were formulated as e.g. "Are there any technical hurdles that prevent Bitcoin Core from being compiled for ARM-based Macs?".
Pieter Wuille
CC BY-SA 4.0
2020-11-22T20:57:19.640Z
Ok fair enough. There is the technical hurdles part to this question but there is also the "Is it being discussed amongst core developers?", "Are there signs from those discussions that this will happen?", "How much work will it be?" "Will it need an outside contributor to work on this or is it looking like existing core developers will ensure it happens?" like questions too. Closing it seems harsh to me.
Michael Folkson
CC BY-SA 4.0
2020-11-23T20:33:27.393Z
Yeah, agree - I didn't vote for closing; just giving some context why people may have an "opinion based" impression here.
Pieter Wuille
<bitcoin-core><bitcoind><client>
Bitcoin Core for ARM-based Macs?
Brqoo
# Bitcoin Core for ARM-based Macs?

(Asked by: username_0 on 2020-11-13)

Should we expect in the foreseeable future a Bitcoin Core release optimised for ARM-based Macs?

**Tags:** bitcoin-core, bitcoind, client

> **Comments:**
> **username_1**: Why are people voting to close this? I am perplexed sometimes at what people vote to close. This is a perfectly reasonable question and specific to Bitcoin Core.  
> **username_2**: Well, the question sounds like it's asking for an option. Whether Bitcoin Core releases for ARM-based Macs will exist in the future depends on whether someone works on it. It would be different if the question were formulated as e.g. "Are there any technical hurdles that prevent Bitcoin Core from being compiled for ARM-based Macs?".  
> **username_1**: Ok fair enough. There is the technical hurdles part to this question but there is also the "Is it being discussed amongst core developers?", "Are there signs from those discussions that this will happen?", "How much work will it be?" "Will it need an outside contributor to work on this or is it looking like existing core developers will ensure it happens?" like questions too. Closing it seems harsh to me.  
> **username_2**: Yeah, agree - I didn't vote for closing; just giving some context why people may have an "opinion based" impression here.  

---

## 2 answers

### Answer by username_3 on 2020-11-22. Score: 2 | Accepted answer

Of course. QT, the GUI framework Bitcoin Core uses, is one of the most portable GUI frameworks. Sooner or later, Apple Silicon support will be added. Meanwhile you can track the progress here: <https://bugreports.qt.io/browse/QTBUG-85279>

Then Core developers will do the rest: <https://github.com/bitcoin/bitcoin/issues/20371>


---

### Answer by username_1 on 2020-11-22. Score: 0

It was discussed at an anonymized Sydney [Socratic Seminar](https://diyhpl.us/wiki/transcripts/sydney-bitcoin-meetup/2020-07-21-socratic-seminar/) in July. I'm assuming MacOS will continue to be supported but it is becoming harder "to build and distribute binaries in the completely reproducible, trustless manner" that Bitcoin Core would like to.

> Apple is introducing these notarization requirements where we would
> have to build our binary and then send it to Apple servers so they
> could notarize it. Then they would send it back to us and that’s the
> only way we could distribute a binary out to end users that would run
> on their Macs. Obviously doing that sort of stuff is tricky for us
> especially if it requires more official things like having an
> organization. I guess we already do that in some part because we have
> code signing certificates but I think the direction that Apple is
> going is making it harder and harder for us to continue or want to
> continue releasing Mac OS binaries. I know some of the developers are
> getting less enthused about having to deal with all of Apple’s changes
> and distribution requirements.


---

