Same repo, multiple apps proof-of-concept

Goals

Avoid separating repo management efforts into another location
- Who is maintaining old PrivateKit? not us
- Who is maintaining old tripleblind/covid-safe-paths? not us.
Minimize need to “sync” manually and face merge conflicts.
- Sync + merge overhead will increase churn, and risk burn out.
Visual design patterns are changed in one place, shared.
- Visual alignment and polish is a never ending process, it can always be better. e.g Animations, delight, performance fixes. Diverging would hurt both repos.

Open questions

How do we keep GPS and BTE separate enough that one will not accidentally turn on via a release?
- Deploying an app that doesn’t have one of the assets enabled will make it so we can’t request it, IIRC. Apple and Android won’t accept a build that requests permissions it doesn’t have access to.
How would i18n work?
Branding, logos, splash screens.
How will we sync any manually linked native packages between the two projects?

Options

Two RN heads, shared packages with yarn workspaces or lerna

Each “app” contains a distinct react-native root.
Tracking provider is a service in each app
Views are mostly the same, and can be configured with props
“Containers” abstract out the difference between apps, that is… MainContainer listens to the GPS/BTE TrackingService, and reports such “state” down via props to a shared Main component
- Main switches between all the core “No known exposure”, “tracking disabled” states.
When functionality is very different, those components remain in the app directory, not in shared. e.g. Share location history might be different.

# existing app
gps/
  app/
    services/
      GpsService.js
    views/
      # fetch state from service, but pass to shared view
      MainContainer.js
      ExposureHistoryContainer.js
      ShareLocation.js # different, no shared component
    App.js
    ...
  android/
  ios/
  .env
  .env.release

# BT app
bte/
  app/
    services/
      GaeService.js
    views/
      ShareLocation.js # very different, no shared comp
    App.js
    ...
  android/
  ios/
  .env
  .env.release
  
# shared packages via yarn workspaces
packages/
  @safe-paths/
    ux/
      Theme.js
      Button.js
      IconButton.js
      NavWrapper.js
  # shared views, could work. We could have containers around them in app land ^
    views/
      main/
        NoExposure.js
        UnknownExposure.js
    services/
      # would there even be shared services?
      # language.js?

App specific containers

Each “head” can provide services or different routing/navigation, flows.

// gps/app/views/MainContainer.js
import { GpsService } from '../services/gps_service';
import { Main } from '@safe-paths/views/Main';
import { Button } from '@safe-paths/ux/Button'; // or whatever

export const MainController = ({navigation}) => {
  // assume useEffect
  const {canTrack, hasExposure} = await GpsService.checkStatus();
  
  return (
    <Main canTrack={canTrack} hasExposure={hasExposure} showHistoryPress={goToHistory} />
  );
}

Shared components will need to be developed to allow some customization. This is not a new thing, common components should always consider slight variations and extensibility/config.

Theming/branding

The theme system already has a decent amount of power, but it could be adapted to allow each app to share some themes, and define new themes. The basic concept of themes stays the same: theme config flows down and common components read from theme config. It could be extended to iconography and logos:

// bte/app/themes.js
import {defaultTheme} from '@safe-paths/ux/themes';
import {bteLogo} from '../svg/bteLogo.svg';

export const defaultTheme = {
  ...defaultGpsTheme,
  logoSvg: BTELogo,
};

CI/CD

Currently we have github workflows set up to run tests, generate artifacts, and deploy. We’ll want to duplicate the workflows for artifact generation and deployment, but run tests for the entire repository as one.

Bundle/App ID’s

New bundle and app identifiers will be generated for the BTE and GPS apps repsectively.