build: add scripts for Windows ARM64 build

[aequivalent2]

Summary

This PR adds native Windows ARM64 build support to the Talk Desktop client.

Changes

• forge.config.js: Replace hardcoded arch: 'x64' in MakerWix with
  dynamic TARGET_ARCH environment variable
• forge.config.js: Replace hardcoded 'x64' in MakerSquirrel dist names
  with TARGET_ARCH
• package.json: Add build:windows:arm64 and package:windows:arm64 scripts

How to build for ARM64

$env:TARGET_ARCH = "arm64"
npm run build:windows:arm64
# Then to create installer:
npm run package:windows:arm64:msi

Testing

Tested on Windows ARM64 device — Task Manager confirms the process runs
as native ARM64 architecture (no x64 emulation via Prism).

[Copilot]

Pull request overview

Adds native Windows ARM64 build support for the Talk Desktop Electron app by making Windows packaging configuration architecture-aware and introducing ARM64 npm scripts.

Changes:

• Parameterize WiX MSI maker arch using a target architecture value instead of hardcoding x64.
• Parameterize Squirrel.Windows artifact naming to include the target architecture.
• Add npm scripts to package/make Windows ARM64 artifacts.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 5 comments.

File	Description
package.json	Adds Windows ARM64 build/package scripts; renames Windows build script(s).
forge.config.js	Introduces TARGET_ARCH and uses it for WiX maker arch and Squirrel artifact names.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

TARGET_ARCH defaults to process.arch, which is the host Node.js architecture and may not match the architecture Electron Forge is packaging/making for (e.g., running electron-forge make --arch=arm64 on an x64 host). This can cause MakerWix arch and Squirrel artifact names to be wrong. Consider deriving the value from the Forge CLI args (e.g., parsing process.argv for --arch) and only falling back to process.arch if no target is specified, or ensure npm scripts always set TARGET_ARCH alongside --arch.

Suggested change

	const TARGET_ARCH = process.env.TARGET_ARCH ?? process.arch
	/**
	* Resolve the target architecture passed to Electron Forge.
	*
	* Supports both `--arch=value` and `--arch value`.
	*
	* @return {string|undefined} The requested target architecture, if provided
	*/
	function resolveTargetArchFromArgs() {
	for (let i = 0; i < process.argv.length; i++) {
	const arg = process.argv[i]
	if (arg.startsWith('--arch=')) {
	return arg.slice('--arch='.length)
	}
	if (arg === '--arch' && i + 1 < process.argv.length) {
	return process.argv[i + 1]
	}
	}
	return undefined
	}
	const TARGET_ARCH = resolveTargetArchFromArgs() ?? process.env.TARGET_ARCH ?? process.arch

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ShGKme]

Thank you for the contribution.

Due to electron-forge cli limitations, we need a different solution for setting and detecting the arch.

Tested on Windows ARM64 device — Task Manager confirms the process runs as native ARM64 architecture (no x64 emulation via Prism).

Could you clarify, did you test only the dev mode and build, or also the distributions (msi and exe)?

Closes #871

Even if we merge it, it does not close that issue.

The purpose of the issue was to see if users are even interested in this option (Windows ARM devices are not as popular, as macOS, for example).

And even with the script to build an ARM64 version, we still need ARM64 compatible infrastructure to publish an official arm64 release.

In other words, even if this PR is merged, it won't directly result in providing an ARM64 distribusion from Nextcloud GmbH.

[ShGKme]

I haven't tested it, but according to the package types, only x86 and x64 values are supported here. I don't have arm64 for testing. Did you actually test it with arm64 here?

[aequivalent2]

Yes, I tested it with arm64 on a Windows ARM64 device (Task Manager confirmed native ARM64 process).
The electron-wix-msi package supports arm64 since v5.1.3 with WiX 3.14 —
candle.exe now accepts arm64 as a valid arch value.

[ShGKme]

In both places where arch is applied, there is a very limited range of acceptable values.
In general, we would support x64 and arm64 only (and universal on macOS).
The range here is much wider. For example, process.arch can be: 'arm', 'arm64', 'ia32', 'loong64', 'mips', 'mipsel', 'ppc64', 'riscv64', 's390', 's390x', 'x64'.
Even if it is unlikely some exotic value would be here, it is worth validating.

Currently, all the build/package parameters are defined via electron-forge args, and not an ENV, including npm config (this seems the most unexpected to me).

There are 4 expected options:

1. Not specified = the current arch
2. --arch=x64
3. --arch=arm64
4. --arch=universal (macOS)

The best would be to use the value from the electron-forge.

Unfortunately, it doesn't provide a simple way to get the params in the config. No function-style config like in bundlers.

One simple (yet dirty) way to get the arch is the generateAssets hook which has it in arguments. But it is only used for building, not packaging (not for makers).

AI above suggested checking process.argv, and this seems the only "simple" solution.
A fallback is needed to process.arch, but only to x64 and arm64. I'd check how electron-forge makes fallback on their side.

This is quite messy, but comes from electron-forge limitation.

An alternative would be to replace electron-forge CLI with our own CLI, which then runs electron-forge. Which is a good solution and makes sense, but IMO too big change to add arm64 build when we won't even release it.

[aequivalent2]

„Thanks for the detailed explanation! I've implemented the process.argv approach with validation to only allow x64 and arm64. Regarding the release question — I understand if this won't be in the official release yet, but happy to keep the build scripts for users who want to build locally. Let me know how you'd like to proceed."

[aequivalent2]

Hello, i tested the MSI and exe as well, i installed the programm and

This is the output from the task manager, every feature seems to be working

I am not quite sure, but windows on arm devices need this support to emerge.

[aequivalent2]

But I don't understand at the moment whether the plan is to support Windows on Arm or whether this option is not available at all, in which case further development in this pull request would not be necessary or am I looking at this wrong?

Github Runners are able to provide the arm64 version or am I wrong?

[ShGKme]

But I don't understand at the moment whether the plan is to support Windows on Arm or whether this option is not available at all, in which case further development in this pull request would not be necessary or am I looking at this wrong?

Merging this PR would allow you and other developers on Windows ARM machines to build the release Windows ARM version locally.

But it doesn't help to officially release and publish a Windows ARM version on behalf of Nextcloud GmbH. It would require support from our infrastructure.

Github Runners are able to provide the arm64 version or am I wrong?

We don't package apps on the GitHub Runners. And even with GitHub Runners, signing would still require additional infrastructure components. It cannot happen on the runner itself completely on the GitHub side.

[aequivalent2]

Is there any reason to support this platform?

[ShGKme]

Is there any reason to support this platform?

What platform?

[aequivalent2]

I'd like to highlight that Windows on ARM has become an increasingly relevant platform. Many major software vendors have already added ARM64 support, and the user base continues to grow — especially with devices like the Snapdragon X Elite-based laptops.

There is a long-standing issue for the main desktop client (nextcloud/desktop#1677, open since 2019) that has not seen any progress. I understand that adding ARM64 support to the C++/Qt-based desktop client is a significant effort.

However, Talk Desktop — being Electron-based — is in a much better position to support this platform with relatively small changes. This PR is an attempt to address that gap for at least one Nextcloud client.

I'd appreciate any feedback on how to move this forward, even if official release support isn't planned immediately. Having the build infrastructure in place would already be valuable for users who build from source.

[ShGKme]

This only handles args with space-separated values like --argv x64 but not = separated like--arch=x64, which is even used in the package.json scripts.

We already have mri package in the app that parses argv. It can be used here to do the parsing.

const mri = require('mri')

const argv = mri(process.argv)

Then argv.arch can be used as the current argArch

[aequivalent2]

const mri = require('mri')

const SUPPORTED_ARCHS = ['x64', 'arm64', 'universal']
const argArch = mri(process.argv).arch
const systemArch = SUPPORTED_ARCHS.includes(process.arch) ? process.arch : 'x64'
const TARGET_ARCH = SUPPORTED_ARCHS.includes(argArch) ? argArch : systemArch

you mean something like this?

[ShGKme]

On macOS we also have universal.

Suggested change

	const SUPPORTED_ARCHS = ['x64', 'arm64']
	const SUPPORTED_ARCHS = ['x64', 'arm64', 'universal']

[ShGKme]

However, Talk Desktop — being Electron-based — is in a much better position to support this platform with relatively small changes. This PR is an attempt to address that gap for at least one Nextcloud client.

I'd appreciate any feedback on how to move this forward, even if official release support isn't planned immediately. Having the build infrastructure in place would already be valuable for users who build from source.

We are fine with adding the support to the build script. It only requires some small changes to correctly parse the --arch=value argument from the script.

We'll also make sure building the application is as simple as possible.

But even if the change in the source code in Talk Desktop might be simpler than in the Nextcloud Desktop sync client, we share the same infrastructure, which at the moment, does not support Windows ARM builds. This may change in the future.

[aequivalent2]

Hey, i changed it with your recommendation, only for me, because i would like to switch my private Home Server to nextcloud are there any plans for the next 6 Months to support this?

I switched to arm because i dont study in my Hometown and i need the good battery life.

[Fuseteam]

But even if the change in the source code in Talk Desktop might be simpler than in the Nextcloud Desktop sync client, we share the same infrastructure, which at the moment, does not support Windows ARM builds. This may change in the future.

Is this also the case for a linux arm build?

[ShGKme]

The code change looks good, tested with different commands.

Unfortunately, I cannot test the arm64 build. We don't have a Windows ARM device in the team. I'll believe your testing :)

[aequivalent2]

How do i fix this error ?

[aequivalent2]

When somebody in your team has aa mac they could test it with a windows vm they run windows on arm

[ShGKme]

I renamed the PR to avoid confusion for an official Windows ARM64 release.

[ShGKme]

How do i fix this error ?

@aequivalent2 Could you squash the commits into a single commit and force push?

[ShGKme]

Hey, i changed it with your recommendation, only for me, because i would like to switch my private Home Server to nextcloud are there any plans for the next 6 Months to support this?

If by "support this" you mean, officially release Talk Desktop for Windows ARM64, I don't know. But without the Nextcloud Desktop sync client for Windows ARM64 — unlikely.

[ShGKme]

Is this also the case for a linux arm build?

This is a different story.
We can have a look at it soon, after Flathub support, where the build would be handled by Flathub infrastructure.

For .zip or .flatpak builds it would be still on us, but without Windows-like limitations it must be doable.

[Fuseteam]

Is this also the case for a linux arm build?

This is a different story. We can have a look at it soon, after Flathub support, where the build would be handled by Flathub infrastructure.

For .zip or .flatpak builds it would be still on us, but without Windows-like limitations it must be doable.

I'm actually interested in testing it on Ubuntu Touch (UT), but that doesn't support flatpak yet— i can however attempt to package for it using the zip. So if we can get an ARM zip build that would be very appreciated

Technically UT does also support snap but that's a whole different packaging format i suppose

[ShGKme]

@aequivalent2 You have 1 extra commit from the nextcloud-command updating translation strings. This was added by mistake and should be dropped.

The second commit is missing DCO. You need to add the following string to the commit description:

Signed-off-by: GOT_COMMIT_USER_NAME <GIT_COMMIT_USER_EMAIL>

You can do it with

git commit --amend --signoff --no-edit

[aequivalent2]

Yes, is added

[ShGKme]

This commit with this change should not be included in the PR

[aequivalent2]

Now everything should be fine, sorry i am currently in the train and its a little bit complicated

[ShGKme]

Your PR still has 2 commits: nextcloud-command with l10n update and your change, that includes reverts for the extra commit.

You can squash them with two commands (if you have no local changes):

git reset --soft HEAD~2
git commit -C "HEAD@{1}"

Could you also remove Closes #871 string from the commit description? Because the commit does not close the issue, and the link automatically creates unnecessary references to the issue.

[aequivalent2]

I hope now everything works, sorry for the long git history, i should plan more time for this

[ShGKme]

Changes are still mixed with commits outside the PR.

I'll push the changes to your branch to resolve the problem.

[ShGKme]

Your commit is authored by github-actions[bot] and contains this change, unrelated to the PR changes

[ShGKme]

• Rebased onto main to remove a second parent of the commit and remove unrelated changes from github-actions[bot] commit
• Updated author
• Added DCO

[ShGKme]

@Fuseteam I'll have a look at Linux ARM possibilities, but it's better to track it and comment on the related issue: #958

[aequivalent2]

Thank you very much for the work : ))

[github-actions]

Hello there,
Thank you so much for taking the time and effort to create a pull request to our Nextcloud project.

We hope that the review process is going smooth and is helpful for you. We want to ensure your pull request is reviewed to your satisfaction. If you have a moment, our community management team would very much appreciate your feedback on your experience with this PR review process.

Your feedback is valuable to us as we continuously strive to improve our community developer experience. Please take a moment to complete our short survey by clicking on the following link: https://cloud.nextcloud.com/apps/forms/s/i9Ago4EQRZ7TWxjfmeEpPkf6

Thank you for contributing to Nextcloud and we hope to hear from you soon!

(If you believe you should not receive this message, you can add yourself to the blocklist.)