[HOLD for payment 22/08/23] [$1000] Enable developers to install multiple app variants simultaneously

[Julesssss]

P/S from @mczernek

Problem

As a developer when working on mobile applications I cannot have two versions of the App being installed at the same time, even when one of them is staging and the other is a production app. I want to be able to have a production app installed at all times and simultaneously install new versions of the app I am working on. I want to be able to easily distinguish between both installed apps.

Solution

Both iOS and Android prevent users from having the same app installed twice on the device. This is determined by bundleID on iOS and applicationID on Android. In order to have multiple apps we need to alter their ids.

• [x] Agree on the environments which will be split into separate apps @mczernek @Julesssss
• [x] Set up new internal Firebase apps @Julesssss
• [x] Configure the Android app package ID, name, and app icon @mczernek
• [x] Configure the iOS app buildSchemes, bundleID, name, and app icon @mczernek
• [x] [Android only] The Main page icon shows Dev for the AdHoc builds:
• [x] Figure out the dev build pipeline, do contributors need to change their workflow? @Julesssss
• [x] Document the various Android build flavours to make this clearer to the team @Julesssss
• [x] Share this change with the internal engineers and wider contributor team @Julesssss
• [x] Deprecate the old AdHoc provisioning profile and identifier @Julesssss
• [x] Confirm we should point to staging envfor the AdHoc build @Julesssss
• [x] Question about the type of iOS profile I used for AdHoc builds
• [x] Create follow-up issue for installing AdHoc Desktop apps side-by-side

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01a69dd286c1e8c009
• Upwork Job ID: 1689297187278802944
• Last Price Increase: 2023-08-09

[MelvinBot]

Triggered auto assignment to @NicMendonca (NewFeature), see https://stackoverflowteams.com/c/expensify/questions/14418#:~:text=BugZero%20process%20steps%20for%20feature%20requests for more details.

[Julesssss]

Hey @NicMendonca, SWM are going to work on this, so no UpWork issue is required.

[mczernek]

As agreed on Slack we're gonna start with adding two build types (or flavors) with different applicationId than staging and production (they share the same one).

[staszekscp]

Hey, I'd like to inform that I'll be working on this issue :)

[Julesssss]

Hey @staszekscp, that's great! Nice to meet you.

[Julesssss]

So, starting with the environment mapping, I believe this is our current build env config:

Android build variants

release: production app
e2eRelease: clear traffic build for automated performance testing
internalRelease: internal testing for beta channels, Applause testing, and browserstack(?)
debug: local dev builds

iOS packaging(?) I'm not exactly sure how this works today, I can't see any buildScheme configured 😕

production: production app/testflight
staging|internal: dev builds

---

I think we're aligned on allowing these three variants to be installed simultaneously. This would be consistent for Android, iOS, and Desktop:

• Expensify Chat: [production|staging] PlayStore/App Store/Testflight/Production Desktop builds
  • signed with production key, only available via the PlayStore/AppStore/Testflight
  • A single app for official both production and staging builds, depending if the user is on the official app store beta testers list
  • iOS: com.chat.expensify.chat, Android: com.expensify.chat
• Expensify Chat AdHoc: [internal|ad-hoc] Internal testing via ReadyToBuild browserstack label
  • Allows a single BrowserStack build to be spun up and tested alongside the official app release
  • While e2e performance builds are unlikely to be installed to a device, we may as well keep these builds within the 'Internal' bucket PlayStore/AppStore build
  • iOS: com.expensify.chat.adhoc, Android: com.expensify.chat.adhoc
• Expensify Chat Dev: [env pulled from local .env file] local developer builds for internal employees and external contributors
  • Environment is pulled from the .env config, it can point to Ngrok/production environment depending on who is building the app
  • iOS: com.expensify.chat.dev, Android: com.expensify.chat.dev

[staszekscp]

Hey @Julesssss! As a follow-up from Slack to keep everything in the issue: Could you add com.expensify.chat.internal and com.expensify.chat.dev projects to Google Services? Without that I’m afraid I won’t be able to build android app.

[Julesssss]

Hey @staszekscp, yep no worries. I created an issue for our infra team to create the environment and will update you as soon as this is ready. If I recall correctly, I'll also need to share the updated google-services.json file with you 👍

[Julesssss]

Internal issue

[Julesssss]

Okay, I created all of the new apps in Firebase. @staszekscp I'll send you the files via Slack

[Julesssss]

Oh one more thing. Lets just use AdHoc instead of internal

[Julesssss]

We merged the first issue (badge), progress ongoing

[staszekscp]

Hey @Julesssss , I think everything works nicely, I would only have one request - could you provide Dev/AdHoc versions of the splash screen logo? I would like to include there badges with DEV or ADHOC depending on the build type. When it's implemented we could have a short round of tests :)

[Julesssss]

Hey, yep no problem. I created an internal issue here. Will report back once I have the assets.

[Julesssss]

Files:

[Julesssss]

Iconmark.zip

[Julesssss]

Hey @staszekscp, is there anything I can help with here?

[staszekscp]

Hey @Julesssss! Sorry for lack of update - I was asked to focus 100% on the navigation reboot. I may find some time next week, but if not, I'm going to hand it to someone in SWM. As I've mentioned some time ago, most of the job is done, but I bumped into some issues with integrating correct splash screen on iOS builds, and I didn't have time to investigate it properly 😄

[melvin-bot[bot]]

Looks like something related to react-navigation may have been mentioned in this issue discussion.

As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our DeprecatedCustomActions.js files should not be accepted.

Feel free to drop a note in #expensify-open-source with any questions.

[Julesssss]

Hey @staszekscp, that's no problem. We can wait a bit longer. Hope you're enjoying App.js!

[roryabraham]

Excited for this to pick back up 🙂

[mczernek]

Since @staszekscp is busy with other assignments, I will be taking it over. There are some questions to be answered:

• decide what to do with e2eRelease buildType. I’m leaning towards adding e2e flavor and keeping buildTypes to two for Android. If anyone thinks this is not good idea, lmk
• decide what to do with staging flavor - it will most likely be deleted since staging and production are basically the same app (app decides on its own which environment to connect to). There might be P/S for that, but I think it is out of scope

[Julesssss]

Hey @mczernek 👋

My only concern is that we'll have a total of 4(flavour) * 2(build type) variants, a lot of which will be useless given that our environments are configured in JS. I know this is the correct way to configure varients though, so as long as we can keep the total variant number low, I'm happy.

Is your suggestion to switch to something like this? Where ✅ is a useful variant? and ❌ will be unused.

Current	flavour
debug	✅
e2eRelease	✅
e2eInternal	✅
release	✅

Planned	v flavour v / > build type >	release	debug
default	✅	✅
AdHoc	✅	❌
Dev	✅	✅
e2e	✅	❌

[Julesssss]

Hey @mczernek, just wanted to check the above is accurate?

[Julesssss]

I'm still excited to make progress with this task, we're just awaiting availability on SWM's side.

[kowczarz]

Hey, I'm from SWM and I will help with this task.

[Julesssss]

Hey @kowczarz. That's great.

Here's where we're at, we just need to confirm that this flavour categorizationwill work for us on Android.

[kowczarz]

Yes, I think this categorisation works, we will disable unused variants, so we will have 6 of them.

[kowczarz]

I've just asked a question in a slack thread https://expensify.slack.com/archives/C01GTK53T8Q/p1687424434878779?thread_ts=1680176779.298009&cid=C01GTK53T8Q

[Julesssss]

WeNot overdue, we're discussing the above comment in Slack

[Julesssss]

We're discussing the options for iOS here in Slack:

Well basically targets are much much more powerful. They allow you to basically define each file in a per target base - you can substitute any resource, Info.plist or even implementation files.

They are generally used to define multiple apps or distributions from one codebase. In that manner they are very similar to android’s flavors. However, some iOS devs consider them to be misused very often. I came across some very strong opinions that changing only environment (and icon) is not enough to setup new target and introduces unnecessary confusion and complexity. They say that targets should be reserved for cases like building watchOS and iOS apps from the same codebase. I generally disagree and would lean towards targets as a go to solution, especially if we’re facing any limitations now.

If we stick with buildScheme we might encounter situation in the future that we could do something on android with flavours but buildSchemes would limit us from achieving the same thing on iOS. At the same time I can totally understand someone who sees that as preoptimisation.

TL;DR: In my opinion we should use targets as they are more powerful, but some iOS devs might disagree.

---

@Expensify/mobile-deployers can you please share your thoughts on the following options:

TLDR: A) Use buildScheme: Provides fewer features, but is often preferred by iOS devs B) Use targets: Simpler implementation? More powerful. Might make it harder to use targets for watch/vision apps in the future

[kowczarz]

In discussion on slack we chose, we will be using buildScheme.

[Julesssss]

Making good progress. Currently held while I create/update the iOS provisioning profile. Based on this comment I need to change the packageID, but obviously this will break the current flows... Likely need to create a temp one

[Julesssss]

For iOS we'll need a new App, so the next step is to create a new app for the AdHoc flavour and retest the WIP PR.

[Julesssss]

Today I created a new AdHoc identifier and provisioning profile. Next step is to share the provisioning profile with SWM and to retry the iOS build.

[Julesssss]

Today I recreated the provisioning profile to match our existing case formatting. Then I encrypted the profile and submitted the PR for review.

[Julesssss]

Installed multiple apps on a physical device for the first time today 😍

[roryabraham]

It's a dream come true 🥲

[Julesssss]

PR is looking good, I just requested some asset re-imports to fix a border issue. AdHoc builds are installed side-by-side on both iOS and Android nicely.

[Julesssss]

Tomorrow I'm going to try the dev builds. I'll also need to configure the iOS provisioning file for .dev:

[Julesssss]

PR is testing well on Android also. Just requested a few small fixes:

• Splash screen has a regression with the logo and transition
• App icon needs to be reimported with more spacing (I can do this after we merge)

[Julesssss]

Today I verified the npm run ... commands would build the correct flavor. I think the final task now is to fix the splash screen 👍

[Julesssss]

I think we're very close to being able to merge, we just need this splash screen icon issue to be resolved.

[Julesssss]

PR is looking good, we made a few small changes today.

Just to let you know I'll be away until Monday. I'm hoping to run the final tests and review on Monday, then after merging will quickly follow up with the icon PR update.

This also means that I will be online when the changes go live and I can explain the changes to everyone 👍

[Julesssss]

Hey @kowczarz, just bumping a few final conflicts and comments

[Julesssss]

Testing this today along with @allroundexperts

[Julesssss]

Getting very close now:

• Contributor+ reviewed the PR
• All varients installable to Android
• All varients installable to iOS
  • Simulator (Dev)
  • Physical (Prod, AdHoc)

Remaining tasks:

• [x] Decide whether to regen the provisioning profile to enable dev builds from XCode to physical devices
• [x] Fix issue where Android AdHoc app show Dev icon
• [x] Update App launcher logos (WIP PR ready to go)
• [x] Inform engineering team and contributors
• [x] Update Documentation

iOS	Android

[melvin-bot[bot]]

Job added to Upwork: https://www.upwork.com/jobs/~01a69dd286c1e8c009

[melvin-bot[bot]]

Triggered auto assignment to @twisterdotcom (External), see https://stackoverflow.com/c/expensify/questions/8582 for more details.

[melvin-bot[bot]]

Current assignee @allroundexperts is eligible for the External assigner, not assigning anyone new.