Hi, seems that there is no discussion about this since 2021 so hopefully we can get some new answers:
How the current build of KiCad 6 for Intel Macs runs on ARM Macs? Is there any performance hit for using the translation layer? Are there significant bugs?
It is possible to build an native M1/ARM version from sources following the official instructions?
Are there nighty builds or development branch of the M1/ARM version?
When it is planned that there will be an official native M1/ARM version of KiCad?
As a heads up, M1/ARM macs where released almost 2 years ago, and according to stats 44% of software developers use MacOS.
Too bad all the KiCad developers are electrical engineers.
There is only a single developer for macOS on the KiCad team who handles all the packaging and builds. Apple basically makes it incredibly difficult to build full featured apps for macOS now because they want everyone to build app store grade junk for the quick buck. So he spends the limited free volunteer time he has to contribute constantly just trying to get KiCad to build as Apple breaks more shit each macOS release intentionally.
So that’s the M1 status.
KiCad is open source, contributions are welcome to add M1 support. We ain’t stopping anybody.
No. (well, at least not to build something that works)
Supporting M1 is not a huge priority because KiCad runs just fine through the emulation layer. It will happen eventually, but this assumption that we should be jumping to whatever new stuff Apple releases in the same year it comes out doesn’t make a lot of sense as long as the old stuff is still working fine. We have no commitment to a schedule to support M1, because nobody is paying for that as a contract project.
According to your statistics, 108% of the software developers are using Windows and/or Linux. So your statistics could indicate that software developers are using macOS only for testing their software. (So do I.)
I’ve contributed code to KiCad, and I’m a software engineer. I do electronics, and thus PCB layout, as a hobby.
The question at hand is not “what do most software engineers use”; it’s “what do most PCB layout engineers use”. I believe that heavily skews towards Windows and Linux.
Personally, I detest Apple’s business philosophy, which is to make Apple products as incompatible as possible with everything else to make switching as painful as possible. They want to lock in their user base to their proprietary software and (overpriced) proprietary hardware.
My most recent client required me to use a Mac, even though the target platform was an RTOS that required a Linux build environment. I used the Mac almost exclusively to host a Linux VM and did all my work in the VM.
The first M1 Mac Machine was launched in 2020 June (WWDC 20). It’s now the second half of 2022. And the transition is completed and all Macs sold by Apple are AArch64. If MacPort can generate the AArch64 binary from the source, just wondering what is the Technical challenge for the official binary.
If there are any open Bugs in Gitlab related to generating M1 build, Would love to check and provide help if possible.
My understanding is that only one of the developers uses a Mac as a primary device, so there is very little time to devote to fighting apple to make proper releases. If you are willing to test and help, you could try out the current system and note errors that you encounter. There are already a few tracking issues about M1 support.
A few of us use Apple devices, but generally older ones without the M1. Nobody is specifically funding KiCad for macOS, and we have only one maintainer of the macOS release process.
If some organization were to provide dedicated funding for us to purchase new M1 hardware and pay someone to work full-time on M1 support, it would likely go faster. Since that is not happening, we prioritize dealing with the macOS changes (which are already nearly a full-time job, since Apple tends to introduce breaking changes with every release). This is because dealing with that is necessary for KiCad to be released at all (on any hardware arch) on macOS. Native M1 support is not nearly as important because KiCad runs just fine under x86 emulation, so the lack of it is not stopping anyone from using KiCad.
Will an M1 MAC mini ($699) help the dev team? if yes how can we contribute to that? I am sure there will be a lot of MAC users willing to contribute to this.
Is it the normal contribution option we have on KiCad website? earlier I remember there was an option to specify for what the contributed money should be used to
At this point no, although we appreciate the offer. The main blocker is people’s time. M1 support is definitely on the to-do list, and we have access to hardware now.
Is it the normal contribution option we have on KiCad website? earlier I remember there was an option to specify for what the contributed money should be used to
For various reasons, we do not have the option for people to “earmark” donations to specific requests. The only way to pay for a specific feature is through contracting a developer, for example via KiCad Services Corp. Doing so allows you to have a specific negotiation about what you’d be getting for your money, the timeline, etc.
If you or anyone has good understanding of cmake, the Apple app bundling system, and the packaging system, we could use more technical help on this front.
FWIW, I installed the MacPorts version (ARM 64) of 6.0.6 and it works fine.
But, somewhat surprisingly, it’s not perceptibly faster than the Intel version of 6.0.6 from the Kicad link. Rosetta II does a very good job…
I’m not sure.
I don’t use the 3D rendering feature. I tried a comparison on a demo design, and the ARM64 version felt faster, but it wasn’t a fair test, since that version can’t find all the 3D models (for some reason I don’t feel like solving right now), so it only rendered the board.
I was talking about comparing emulated vs not emulated (on the same machine) because we cannot compare apple with oranges (intel with arm). I think that the board rendering frame rate should be a valid indication.
