The layout and functionality of Purple App and Web Experience sites can, to a great deal, be changed without the need of resubmitting the app to the app stores. This way, changes to the apps experience can be performed fast and cost-efficient.

To configure the dynamic resources, e.g. to edit Purple Experience, App Onboarding, App Analytics and other features, it is recommended to use the Purple Experience Builder.

The dynamic resources of a Purple App consist of a repository tree. There is usually a "default" folder, which contains most resources.

There may be folders named after ISO-639-1 codes as siblings of the "default" folder. Files from these folders override their correspondent files, if the selected language of the app or browser corresponds to the folder name.

There may be folders named after the supported platforms (Android, iOS, web) as siblings of the "default" folder. These folders contain a folder structure similar to the original folder structure, thus beginning with another "default" folder and optional language override folders. Any files placed in the platform folders override the correspondent files in the "default" folder for the particular platform.

Given the following folder structure:

Dynamic resources for Purple App and Web Experience sites are stored in git repositories. The chosen git provider is AWS CodeCommit. There is one git repository per team.

In the team's git repository, there are 2 branches per app, one release branch and one preview branch. We take care of deleting these branches when an app is deleted and moving them to another team's repository when the app is moved.

Committing to any branch leads to creation of new resource zip files for Android and iOS apps. These zip files are stored on the team's Amazon S3 and a reference is stored in the database. If web experience is configured for the app, all single resource files appropriate for the "web" platform are stored at the team's Amazon S3, references to the single files are stored in the database and a message is sent to a kafka topic, which contains the names of all provided resource files and the paths to load them from S3 via Cloudfront.

By tagging commits of these branches with version numbers, existing apps can be forced to load older versions of dynamic resources, while a new version of the app loads the current head versions of the resources. The tag name must follow this scheme: <app-id>_[preview|release]_[ios|android]_<version> e.g. e8fea93e-444f-4137-a96d-5a455150ffb0_preview_ios_1.2. It's easiest to create these tags in the Purple Manager by setting a "Max Version".

When an app is created, the preview and release branches are set up by copying the heads of the appropriate branches of the chosen template app. Thereby, the preview branch is branched from the release branch.

When an app is created by cloning an existing app, its branches start at the current HEAD versions of the cloned app branches.

Dynamic resources for apps are stored as zip files in the team's Amazon S3 bucket and delivered through Cloudfront. The path to the appropriate zip file (for platform and version) is provided on request by the GraphQL Catalog-API. Therefore, the app requests the resources "last change" timestamp for its platform and version at app start. If it differs from the previously stored timestamp, it requests the new zip file and stores the new timestamp. This means that old versions of resources can be delivered as well if they are tagged with the appropriate app platform and version.

Dynamic resources for web are stored in the team's Amazon S3 bucket and delivered through Cloudfront. The names and Cloudfront paths of all resource files are sent to a kafka topic, where the rendering engine can subscribe to receive them.

Cross-links to other resource files through resource://dynamic links are converted to correspondent cloudfront links. If internationalization is done through the aforementioned language folders, resources might be duplicated to have all possible links at hand.