feat: native apple silicon

[lidel]

This is exploration into better support of Apple Silicon.

electron-builder supports producing either universal package or one for each architecture.

In case of Desktop, things are more complicated: we also bundle go-ipfs binary. This means that unless the go-ipfs binary is also universal or per-arch, we can't improve much.

Due to the way we depends on go-ipfs via npm-go-ipfs universal binaries all the way sound like way easier route (downside being the disk size), however dist.ipfs.io already has amd64 and arm64 for darwin.

Universal binary test

Main cost of universal package is size, even with out go-ipfs (still being amd64) it adds ~75 MB:

• 195M IPFS Desktop-0.16.0-universal.dmg (electron amd64&arm64 + go-ipfs arm64)
• 119 MB IPFS-Desktop-0.16.0.dmg (amd64, M1 will use Roseta)

TODO

• [ ] decide if we want to provide single universal binary or one for amd64 (legacy intel) and one for arm64 (new apple silicon)
  • Data point from Brave:
    • atm IPFS integration is using amd64: go-ipfs binary is amd64, it runs on M1 via Rosetta. Brave plans on using arm64 in the near future, as they already provide arm64 version of Brave itself.. In that contenxt universal binary is wasteful (IPFS component is fetched on-demand, so small size matters).
• [ ] based on previous decision, decide how we handle go-ipfs dependency (right now it downloads go-ipfs only for arch of CI worker, which is amd64).

[AlexxNica]

@lidel, do we know where the difference in size comes from, specifically? We could find where they are and try something to minimize the impact of shipping the universal package.

[unbeatable-101]

@lidel, do we know where the difference in size comes from, specifically? We could find where they are and try something to minimize the impact of shipping the universal package.

Not a dev, but I'm pretty sure the size increase is just the binaries about doubling in size due to basically containing two apps.

[jenkijo]

Hello, any update? I've committed fix for go-ipfs https://github.com/ipfs/npm-go-ipfs/pull/44

[dvcrn]

Thanks for the PR! I wanted to build this locally but ran into issues with the build step trying to download a arm ipfs binary that obviously didn't exist. How did you build this?

[jenkijo]

It work fine with me, what error that you got?

[hacdias]

I think that Universal would be easier for the end users despite the storage size. In general, storage is cheap and 75 MB won't probably affect many people.

Iff storage size is very important, we could either build universal + download go-ipfs on first run, or ship different binaries.

[SgtPooki]

@lidel Have we looked into https://github.com/tauri-apps/tauri at all? It claims significant improvements over electron across all platforms, though I haven't investigated more deeply. I also haven't found any apps that have migrated from electron to tauri

[SgtPooki]

Regarding universal app vs rosetta on M1.. the speed increases you get by running M1 native is significant in every benchmark I've seen. However, it would be great to see a breakdown of the risks & benefits for our specific application.

I don't think we should decide to just force rosetta forevermore. If the decision is to wait for some period until we have more bandwidth, I think sticking with rosetta and the smaller bundle for now is fine. Ultimately, we should be moving to the type of app bundle the platform we're targeting recommends.

For Apple/macOS, that is the universal build.

[hacdias]

@SgtPooki an issue you may want to look at too is #867

[lidel]

Have we looked into https://github.com/tauri-apps/tauri

I think we looked at it briefly, but it was very alpha back then. IIRC the main downside was lack of tooling for end-to-end autoupdate solution, which is raison d'être of ipfs-desktop. It seems they work on it, but it is still undocumented? https://github.com/tauri-apps/tauri/discussions/2776

Long term, we want to move away from fetching updates from centralized HTTP server like github and leverage IPFS+IPNS instead (see old notes in https://github.com/ipfs/ipfs-desktop/issues/789), so if we have working setup for that, we could move away from Electron (literally the only value it brings is https://www.electron.build/auto-update working on all three platforms: macOS+Windows+Linux(AppImage))

75 MB won't probably affect many people.

Usually I would be against doubling the size of download, but we talk Apple here – it is fair to assume that if someone uses mac they most likely don't care about additional download cost over the mobile carrier (just being realistic here).

Ultimately, we should be moving to the type of app bundle the platform we're targeting recommends. For Apple/macOS, that is the universal build.

Yeah, sounds like universal binary is the way to go. The caveat here is that we don't have "universal go-ipfs binary" – iiuc this PR (in current form) still bundles the intel version of go-ipfs.

Figuring out how to include both binaries (arm64 and amd64) for darwin is the key to unblocking this. Someone familiar with Apple hardware and ecosystem needs to investigate if ipfs-desktop should fetch independent binaries during the build of DMG, or if dist.ipfs.io website should add universal binary upstream (if it is even possible for standalone CLI binaries).

[Whitedragon2772]

lo

[lidel]

I wrote a plan for unblocking this in https://github.com/ipfs/distributions/issues/770#issuecomment-1329178981. Not a macOS user myself, but if someone wants to work on this, I'm around to advise.

[SgtPooki]

I wrote a plan for unblocking this in https://github.com/ipfs/distributions/issues/770#issuecomment-1329178981.

Not a macOS user myself, but if someone wants to work on this, I'm around to advise.

I read that comment and the approach seems reasonable and clear. Thanks for the backlink!

[whizzzkid]

@lidel should this be closed as https://github.com/ipfs/distributions/issues/770#issuecomment-1329178981 is closed.

I was also wondering if this could be solved as part of https://github.com/ipfs/ipfs-desktop/issues/2441 where instead of "shipping" a binary, we download and validate checksums and then use that?

[lidel]

There are two separate topics at play (mind I am not macOS user, below is my rough understanding on Apple Silicon situation)

• architecture of go binary (kubo daemon)
  • What we did on dist.ipfs.tech is we provide separate Kubo binaries for amd64 (intel) and arm64 (arm/apple silicon) (https://github.com/ipfs/distributions/pull/838, https://github.com/ipfs/distributions/pull/841).
  • Brave downloads correct binary at runtime.
  • There is no universal binary for Kubo, but you could build one as noted in https://github.com/ipfs/distributions/issues/770#issuecomment-1329178981 – afaik nobody is doing that atm.
    • IPFS Desktop DMG bundles NPM version pulled in during the build – afaik this is still amd64, so it runs emulation.
    • IPFS Desktop needs to either stop embeedding and fetch correct binary at runtime, or include both and run correct one on macOS.
• architecture of electron app (ipfs desktop)
  • this feels unresolved, but maybe not a big deal, since the majority of work happens in kubo?
  • iiuc what happens on macOS is that we produce DMG that is amd64 and when run on Apple Silicon it runs emulation

I agree we should close this, as universal DMG does not solve it end-to-end. If we want to use native arch on macOS, need to fill new issue and make a new plan for both topics above.

[SgtPooki]

please see https://github.com/ipfs/ipfs-desktop/issues/2681 for a continuation of this work