macOS client - M1 CPU

[jbishop129]

• [x] #3852
• [x] #3853
• [x] #3854

Probably not the best place to post this, but couldn't find anything better. Is there a roadmap for getting a native Apple Silicon, ie a Universal App, for macOS? I'd love to get on the beta program when such a client appears

[mthsbk]

+1

(the current client runs fine with Rosetta 2 btw)

[user858753257]

That's a good request 👌

[manolo4711]

This is a great request. I can only agree with it

[haozhou]

any detailed plan to support Apple Silicon natively? or how can we contribute

[haozhou]

maybe it's a good opportunity to upgrade to QT6? QT is targeting to support Apple Silicon in 6.1 https://bugreports.qt.io/browse/QTBUG-85279

[JimLoose]

big upvote, at the moment it's one of the app is one of the worst battery eater on my M1 system

[mariokorte]

+1 here

[saddle-gaudier-06]

+1 here. I've found that the x86 version of the Nextcloud desktop software ends up being a memory hog on my Mac mini (M1 version). The app consistently takes up the most memory on my computer.

[vitobotta]

Does it work fine for you under Rosetta? I am having problems where recent builds often quit after a few seconds, while with the latest daily built it doesn't quit but I get checksum errors when syncing.

[user858753257]

So Version 3.1.1 is M1 ready ?

[vitobotta]

@F3000 I installed it on a new computer yesterday and it's still working under Rosetta.

[user858753257]

Yes for me also . So with 3.1.0 it couldn't be installed ?

I have seen in the system report that the NC client is still the "intel" version

[Upperholme]

Following. +1

[cyayon]

Following

[pszypowicz]

Hey everyone.

Please stop spamming this issue with "following" or "+1" messages. Instead, click "thumbs up" on the first comment or subscribe to this issue in notifications section.

Thanks!

[Upperholme]

Probably not the place to post this, but in my usage on an M1 Mac mini with version 3.1 (build 4316), when I set up the connection to the server, if I want to specify a local directory other than the default, the client provides a dialog box to navigate to and/or create a local directory for the sync. This dialog box is unresponsive to mouse/trackpad, but can be used with keyboard commands.

[iskios]

The client does not really work on my M1 mac.

[jpp46]

I would suggest doing work to make the iOS / iPad app a universal app that you just download from the Mac app store. Then you can drop QT all together and just use apples native gui tools. Also this would mean that any features added to the mobile app would also be in the desktop app and vice versa

[michaelstingl]

I would suggest doing work to make the iOS / iPad app a universal app that you just download from the Mac app store.

iOS/ iPad app can already be installed on your M1 Mac. Just search in the Mac App Store.

[cyayon]

I would suggest doing work to make the iOS / iPad app a universal app that you just download from the Mac app store.

iOS/ iPad app can already be installed on your M1 Mac. Just search in the Mac App Store.

How does it really work ? It should be sandboxed on macos and not access to the filesystem ? unable to really sync ?

thanks

[laydros]

I would suggest doing work to make the iOS / iPad app a universal app that you just download from the Mac app store.

iOS/ iPad app can already be installed on your M1 Mac. Just search in the Mac App Store.

How does it really work ? It should be sandboxed on macos and not access to the filesystem ? unable to really sync ?

thanks

The iOS app doesn't really work as a background sync the way that the desktop app does. Same with Dropbox, Google Drive, or any other similar software. The NextCloud desktop app actually syncs folders to and from your computers drive, but the iOS app just gives you access to those files in the cloud, and thankfully integrates with the Files app. Using the iOS app with an M1 Mac would not enable doing things like directly seeing the files in finder or from the terminal, or saving to a folder you are syncing and knowing it will upload the data.

[fdelucchijr]

Same request here! Recently some news declare than Rosseta 2 apps are taking extra swap from the ssd's, port the client to the "Universal" .app architecture would be ideal...

[jmhammond]

If anyone on this thread has the time and the head space to you do this, here are the steps to build a universal binary of the source.

and since nextcloud-desktop uses cmake, perhaps this flag (suggested on stackoverflow) is all that is needed for the build process? CMAKE_OSX_ARCHITECTURES=arm64;x86_64

In full disclosure, I don't have a mac, so I personally can't do any of this.

[dnv]

+1 for this. Nexctloud is one of the very few apps that have to be run via Rosetta2 on my new MacBook M1 Air.

[davidpfahler]

I would like to help creating a native Apple Silicon client as the Intel version via Rosetta 2 really eats away at the battery. Unfortunately, I do not think I can do this on my own. Can anyone, who is familiar with the development workflow of nextcloud work with me on this?

[FlexW]

@davidpfahler I bring that up internally and come back to you with an answer on how we will handle that.

[FlexW]

@davidpfahler We discussed that internally, and we are probably going to do a few changes to the build system to properly integrate that new architecture. As this involves quite some coordination internally we would like to do it our self. At the moment there is no customer request that wants to have this architecture supported, so it can take some time until the feature will be delivered.

[dnv]

You can consider me the 2nd user who is waiting for a native M1 build 🙂

On Mon 12. Apr 2021 at 13.18, Felix Weilbach @.***> wrote:

@davidpfahler https://github.com/davidpfahler We discussed that internally, and we are probably going to do a few changes to the build system to properly integrate that new architecture. As this involves quite some coordination internally we would like to do it our self. At the moment there is no customer request that wants to have this architecture supported, so it can take some time until the feature will be delivered.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nextcloud/desktop/issues/2659#issuecomment-817685595, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJB5Y6RV3XOJ6QQPTZBL4DTILCFRANCNFSM4T753T5A .

[pszypowicz]

Please, people. There is (at the moment) 100 people wanting this feature. Do you know how I know this? Because all those people 'liked' first issue report.

Please, again, do not spam this thread with '+1' or 'me too'. You are not helping the developers :)

[davidpfahler]

@davidpfahler We discussed that internally, and we are probably going to do a few changes to the build system to properly integrate that new architecture. As this involves quite some coordination internally we would like to do it our self. At the moment there is no customer request that wants to have this architecture supported, so it can take some time until the feature will be delivered.

Thank you for your response. I understand how difficult it can be to coordinate such large changes. If I can help speed any of this up, please let me know.

[thenickname]

+1

(the current client runs fine with Rosetta 2 btw)

I'm afraid it does not run quite fine. While it technically works, CPU usage is at 10% at all times. Even with synchronization paused, CPU usage is at 5%. The app shows up as "using siginificant energy", even when nothing is being synchronized. While just a guess, I hope this would improve with a native build.

[andrey0001]

+1

[yudshj]

If anyone on this thread has the time and the head space to you do this, here are the steps to build a universal binary of the source.

and since nextcloud-desktop uses cmake, perhaps this flag (suggested on stackoverflow) is all that is needed for the build process? CMAKE_OSX_ARCHITECTURES=arm64;x86_64

In full disclosure, I don't have a mac, so I personally can't do any of this.

Tried to build it, but Qt5-WebEngine (or WebKit) has a known issue on aarch64 macOS. Thus I can't build native nextcloud successfully. I found that the Qt5 in the brew repo does not contain a WebKit widget (link, line65-68). Any tips here?

    if Hardware::CPU.arm?
      # Temporarily fixes for Apple Silicon
      args << "-skip" << "qtwebengine" << "-no-assimp"
    else
  ......

[ggruen]

At the moment there is no customer request that wants to have this architecture supported, so it can take some time until the feature will be delivered.

This attitude concerns me. I understand the need to prioritize work based on customer demand, and that Apple has cushioned the transition to the M1 chip, but the underlying reality is that Apple's entire MacBook lineup is now running on the M1 chip, meaning that any Mac app not running on that architecture is running on borrowed time. Engineers will bring it up first (e.g. this issue) and start making recommendations to their bosses and clients. Apple will make more OS changes to support their new File Provider API. But by the time an Enterprise client brings it up, it will be because the 5000 Macs they are upgrading won't run NextCloud any more, leaving them scrambling to find a solution and NextCloud scrambling to fix something with so much technical debt that they won't be able to fast enough. But, more likely, the aforementioned engineers, after reading this issue, will take preemptive measures to avoid that embarrassing situation and look into updating the client themselves a bit, then keep a cautious eye out for a change in NextCloud or for other file storage/sync solutions that support current hardware.

[FlexW]

@ggruen Just for the record it's now possible to build the client for Apple M1. If you compile it yourself, you can already use it. We working on integrating the M1 build into our build system.

[maddie]

Following the compilation instructions from the Wiki, I'm not able to build the client in M1 Mac from the source tagged at v3.3.0-rc2. make output attached.

nextcloud-compile-m1.log

So what's the correct way to compile Nextcloud for M1 Mac?

[FlexW]

@maddie It's not straightforward as for x86 because you have to build OpenSSL and the latest version of Qt5 yourself from the source because there are no binary packages (Qt5 is not officially supported on the M1). So the procedure is somewhat: Build OpenSSL yourself then build Qt5 yourself and then tell CMake where to find the correct OpenSSL and Qt5 version and then build the client like you build any other CMake project. Another hint I can give you is just don't follow blindly the wiki as every computer is different. The error messages that CMake or the compiler emits should be helpful enough to get a build done.

For building Qt5 for ARM64 you might find this article helpful https://www.reddit.com/r/QtFramework/comments/ll58wg/how_to_build_qt_creator_for_macos_arm64_a_guide/

[maddie]

The OpenSSL and Qt5 (qt@5) from Homebrew all seems to be arm64 binaries already:

$ cd /opt/homebrew/Cellar/qt@5/5.15.2
$ file *
balsam:                  Mach-O 64-bit executable arm64
canbusutil:              Mach-O 64-bit executable arm64
fixqt4headers.pl:        Perl script text executable
lconvert:                Mach-O 64-bit executable arm64
lprodump:                Mach-O 64-bit executable arm64
lrelease:                Mach-O 64-bit executable arm64
lrelease-pro:            Mach-O 64-bit executable arm64
lupdate:                 Mach-O 64-bit executable arm64
lupdate-pro:             Mach-O 64-bit executable arm64
macchangeqt:             Mach-O 64-bit executable arm64
macdeployqt:             Mach-O 64-bit executable arm64
meshdebug:               Mach-O 64-bit executable arm64
moc:                     Mach-O 64-bit executable arm64
qcollectiongenerator:    Mach-O 64-bit executable arm64
qdbus:                   Mach-O 64-bit executable arm64
qdbuscpp2xml:            Mach-O 64-bit executable arm64
qdbusxml2cpp:            Mach-O 64-bit executable arm64
qdistancefieldgenerator: Mach-O 64-bit executable arm64
qhelpgenerator:          Mach-O 64-bit executable arm64
qlalr:                   Mach-O 64-bit executable arm64
qmake:                   Mach-O 64-bit executable arm64
qmlcachegen:             Mach-O 64-bit executable arm64
qmleasing:               Mach-O 64-bit executable arm64
qmlformat:               Mach-O 64-bit executable arm64
qmlimportscanner:        Mach-O 64-bit executable arm64
qmllint:                 Mach-O 64-bit executable arm64
qmlmin:                  Mach-O 64-bit executable arm64
qmlplugindump:           Mach-O 64-bit executable arm64
qmlpreview:              Mach-O 64-bit executable arm64
qmlprofiler:             Mach-O 64-bit executable arm64
qmlscene:                Mach-O 64-bit executable arm64
qmltestrunner:           Mach-O 64-bit executable arm64
qmltyperegistrar:        Mach-O 64-bit executable arm64
qscxmlc:                 Mach-O 64-bit executable arm64
qtattributionsscanner:   Mach-O 64-bit executable arm64
qtdiag:                  Mach-O 64-bit executable arm64
qtpaths:                 Mach-O 64-bit executable arm64
qtplugininfo:            Mach-O 64-bit executable arm64
qvkgen:                  Mach-O 64-bit executable arm64
rcc:                     Mach-O 64-bit executable arm64
repc:                    Mach-O 64-bit executable arm64
syncqt.pl:               Perl script text executable
tracegen:                Mach-O 64-bit executable arm64
uic:                     Mach-O 64-bit executable arm64
xmlpatterns:             Mach-O 64-bit executable arm64
xmlpatternsvalidator:    Mach-O 64-bit executable arm64

$ cd /opt/homebrew/Cellar/openssl@1.1/1.1.1k/bin
$ file *
c_rehash: Perl script text executable
openssl:  Mach-O 64-bit executable arm64

$ cd /opt/homebrew/Cellar/openssl@1.1/1.1.1k/lib
$ file *
engines-1.1:         directory
libcrypto.1.1.dylib: Mach-O 64-bit dynamically linked shared library arm64
libcrypto.a:         current ar archive random library
libcrypto.dylib:     Mach-O 64-bit dynamically linked shared library arm64
libssl.1.1.dylib:    Mach-O 64-bit dynamically linked shared library arm64
libssl.a:            current ar archive random library
libssl.dylib:        Mach-O 64-bit dynamically linked shared library arm64
pkgconfig:           directory

I guess that means they're already native binaries, does that mean I still have to compile OpenSSL and Qt5 manually? If so, does that mean I have to turn on certain flags when compiling them to make them compatible with Nextcloud?

Another hint I can give you is just don't follow blindly the wiki as every computer is different.

I'm sorry but I had to say that I don't agree with this, because in the wiki it's called "step by step instructions", and instructions are meant to be followed. I understand every computer is different, but if this compile guide works on only x86 Macs, with manually compiled components (not from Homebrew), tested on only certain version of Nextcloud, and have to export different envs to make CMake work, then it would be great to have this pointed out in the instructions, so people reading the wiki will at least have some level of expectation that it will fail and the responsibility to find out what's wrong falls in the user's hands.

[FlexW]

I guess that means they're already native binaries, does that mean I still have to compile OpenSSL and Qt5 manually? If so, does that mean I have to turn on certain flags when compiling them to make them compatible with Nextcloud?

As far as I'm concerned the Qt binaries in homebrew are from version 5.15.2. There is a beginning of a 5.15.3 branch (actually you need to checkout 5.15) that was never released, so you need to build Qt from the source. You don't have to set any special flags other than not building Qt3D and QWebEngine (as it will fail). You probably can use the OpenSSL version from homebrew. Just try it out :)

[maddie]

Thanks for your pointers, after compiling Qt 5.15 and QtKeychain from the source, I've successfully compiled Nextcloud, but unfortunately fails to run: nothing happens after double-clicking the result application in build/bin, and running the Nextcloud binary within the bundle, gets killed immediately:

.../build/bin/Nextcloud.app/Contents/MacOS $ ./Nextcloud
[1]    54339 killed     ./Nextcloud

[FlexW]

@maddie Good to hear. Did you try to use a self-compiled OpenSSL lib? If not, see if that resolves the issue.

[maddie]

I noticed there are two lines in the compile log:

Running macdeployqt...
ERROR: no file at "/usr/local/lib/libssl.1.1.dylib"
ERROR: no file at "/usr/local/lib/libcrypto.1.1.dylib"

... so I copied the two dylibs into /usr/local/lib and voila, it worked.

Thanks a lot for your help! @FlexW

[BJKle]

@maddie Awesome, can you provide the pkg-file to download somewhere? Did you create a M1-Version only or a big universal app? Thanks again.

[maddie]

@BJKle M1 only version, Intel ones already works great with the existing version, so I didn't bother.

Sure I can provide a download link for the app, but I'm not sure if it's against policy here.

[FlexW]

@maddie This will probably not work because the app is not signed or at least not signed by Nextcloud, but I think it would be better to not post a download link here.

[maddie]

@FlexW Got it.

For those who want to compile the M1 version of Nextcloud themselves, the following steps are what I did to compile:

1. Compile Qt5 following the link in this reply
2. Download OpenSSL source tarball from the official website
3. Compile OpenSSL using this guide. You don't have to edit the Configuration/10-main.conf, as the latest OpenSSL already includes the change.
4. Build QtKeychain from the source.
5. Clone Nextcloud from source, and export the environment variable for compiling:

# Change the paths to match your local path
export OPENSSL_ROOT_DIR=~/git/openssl-1.1.1k
export Qt5LinguistTools_DIR=~/git/qt5-5.15-macOS-release/qtbase
export Qt5_DIR=~/git/qt5-5.15-macOS-release/qtbase
export Qt5Keychain_DIR=~/git/qtkeychain/qtkeychain

6. Compile Nextcloud following the Wiki

# Assume we have cloned the source into ~/git/nextcloud-desktop
cd ~/git/nextcloud-desktop
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=/Applications -DCMAKE_BUILD_TYPE=Release
make -j16

The result app bundle will be in nextcloud-desktop/build/bin.

[ggruen]

I want to say how impressed I am with NextCloud and its development community.

The day I posted my previous comment 10 days ago, I posted a similar one on Dropbox's feature request for M1 support. To date, nobody from Dropbox has responded (they had previously responded to the request saying they needed more votes to address it), Dropbox doesn't run natively on the M1, and posts on M1-related threads in the forum mostly talk about people cancelling their subscription and metaphorical sinking ships. Meanwhile, NextCloud can be compiled on the M1.

[BJKle]

With some tweaking, I could build and install it as well. Thank you very much. The compiled Apple-M1-only version uses 77 MB only on my disk, compared to almost 300MB for the Intel-only version. Memory and CPU usage has dropped as well. Some reported errors have disappeared, like the squeezed icon on second monitor,... It would be great if there could be an additional official M1-only version next to the Intel version.

[dukekautington3rd]

I'm curious...For someone who isn't a developer but knows how to follow instructions and compile things... If I build my custom NextCloud for ARM will there be a complicated process for installing an official release later?

PS - Great job folks

[ghost]

Wow, thanks everyone! I'm definitely not a developer but was finally able to get it going. My mistakes were missing Inkscape and a few other dependencies, and the Nextcloud cmake and make commands couldn't find bits of qtkeychain, e.g., ~/include/qt5keychain/ instead of /usr/local/include/qt5keychain. But hey, it works! There something very satisfying about seeing an Intel-less list of processes in Activity Monitor...