Multiple desktop architectures overwrite eachother

[roryabraham]

Problem

The desktop app currently builds for three separate architectures:

1. x64
2. arm
3. universal (dmg is about 2x as large, supposed to work architecture-independently).

When the app deploys, each build artifact is called NewExpensify.dmg, and overwrites the previous one. This defeats the purpose of building for multiple architectures. Using a universal build only creates an unnecessarily large app.

Solution

TBD. At least a few options:

1. Create architecture-specific DMGs: Desktop build is not updated  #7987 (comment)
2. Use only universal build
3. (most ideal)
   1. Create architecture-specific DMG's
   2. (Using Cloudflare magic?) detect the architecture of the downloading client visiting https://new.expensify.com/NewExpensify.dmg (if that info is available via user-agent)
   3. Deliver the correct architecture-specific DMG based on the client.
4. Create a UI for the desktop download page that shows the available download options.

[roryabraham]

cc @kidroca

[kidroca]

@roryabraham
It seems it was possible for some people to download other than the universal app from: https://staging.new.expensify.com/NewExpensify.dmg

• Desktop app size is 161 Mb instead 90 Mb #8014 (comment)

  When I download the staging app now, its size is 91MB as expected, but it shows as an unsupported app and I can't install it at all.

Perhaps there's a window of time where one of the app that are uploaded before the universal app can be downloaded?

[francoisl]

Does that mean this should be a deploy blocker? The installer on staging only contains the Arm app as far as I can tell, so if we release to production, does it mean it would break the app for everyone on Intel MacBooks via the auto-update?

[kidroca]

Does that mean this should be a deploy blocker? The installer on staging only contains the Arm app as far as I can tell

Strange https://staging.new.expensify.com/NewExpensify.dmg gives me the universal app, could it be due to me being in a different region?

so if we release to production, does it mean it would break the app for everyone on Intel MacBooks via the auto-update?

Actually the auto happens from the generated zip file and those aren't overwritten, and this would probably install the x64, because everybody on production have that

Also triggering the production flow, would rebuild the Desktop App for production

---

To be on the same side we can stop building from 3 platforms for the moment and

• build for x64 like we used to do (90MB app that works everywhere)
• build for universal - (160MB app that works everywhere natively)

Building only universal might mean that people would have to re-download the .dmg and install it again

[roryabraham]

build for x64 like we used to do (90MB app that works everywhere)

I like this plan for now.

[francoisl]

Strange https://staging.new.expensify.com/NewExpensify.dmg gives me the universal app, could it be due to me being in a different region?

Huh just tried again and I get the universal app now. Also checked my Chrome download history to make sure I'm not going crazy, I was definitely using that same link yesterday too... go figure.

Anyway yes, building for x64 sounds good to me too!

[kidroca]

@roryabraham
This PR #8160 make it possible to build 2 (or more) architectures and host them at

• x64: /NewExpensify.dmg (same as before)
• arm64: /NewExpensify-arm64.dmg (new)

Or we can remove the arm64 version if you want to

[roryabraham]

Assigned @kidroca since he's got a PR up. I just need to finish reviewing and test it out.

[kidroca]

PR was merged #8160

[kidroca]

We have a problem with auto-updates after #8160

It turns out we can't build multiple architectures in sequence and we should either:

• build multiple targets with one electron configuration
• build only one target - the x64 like we did in the past
• build only one target - the universal that works on both x64 and arm64 but is 2x the size

If we want to build multiple targets we can no longer use the name NewExpensify.dmg but have to use the following naming:

• NewExpensify-x64.dmg
• NewExpensify-arm64.dmg

Related slack discussion: https://expensify.slack.com/archives/C01GTK53T8Q/p1648493950691769?thread_ts=1648166165.861939&cid=C01GTK53T8Q

[roryabraham]

If we want to build multiple targets we can no longer use the name NewExpensify.dmg

This would really not be ideal because it would potentially force people to redownload the app in order to start getting updates. But long-term it seems like the best solution so that we can support multiple architectures.

[kidroca]

This would really not be ideal because it would potentially force people to redownload the app in order to start getting updates.

I think people will continue to get updates - updates rely on the .zip file and we're not touching it
In the past updates broke because we accidentally deployed to prod instead of staging and not because of the name change
Right now updates break because of the overwritten yml file

---

If we remove dmg.artifactName altogether the build names would be

• New Expensify-1.1.46-2-mac.dmg
• New Expensify-1.1.46-2-arm64.dmg

vs

• NewExpensify-x64.dmg
• NewExpensify-arm64.dmg

if we use dmg.artifactName: 'NewExpensify-${arch}.dmg'

Whatever we decide the downloaded file name should be easy to set like link.setAttribute('download', 'NewExpensify.dmg')

[kidroca]

I've opened a slack thread on the topic, and it seems we might go in a different direction and build just one target - the universal app, because it's simpler
Let's capture a decision here, and then apply it as a fix for this ticket: https://expensify.slack.com/archives/C01GTK53T8Q/p1648661425531989

[kidroca]

We decided to stick with what we previously did and build only the x64 version
If we ever decide to switch the door is open.

PR is ready

• Build only the default Desktop architecture #8416

[roryabraham]

I think we are good to close this for now. We can reevaluate if/when we have issues again in the future.