Since we are creating and setting the versions of our releases thanks to GitHub release / tag, we no longer need the build_number to be present in the info.json files.

#The problem

In the current info.json files we cannot use a full URL.
The reason for this, is that in .xcconfig files slashes are not parsed correctly.

#Solution
Actually we can bypass this now.
Currently these custom app values go from:
info.json -> dwds.xcconfig as a variable, that variable goes into the dwds.plist file.

At the moment all the custom .plist files are essentially identical, but we can move the actual value from info.json to the custom .plist file, this way we won't have the limitations that the xcconfig file format has, so we can use a full url.

Requires updating both the info.json and the kiwix/apple repo.

The CD GitHub action should start from a published tag.
The tag should contain the folder name (brand name), the build number (the [PATCH] part of the version) as the [MAJOR].[MINOR] is based on the ZIM file date (see issue on versioning).
The tag should be validated, if it has the right format, and if the folder actually exists.
Eg. a valid tag should look like:
dwds_03 out of which we have the dwds folder/brand to be built with the build number 3 (there are no zeros in semantic versioning).
Also it should be possible to extend the tag with a further optional part, such as:
dwds_11_A1 or dwds_11_test02 in order to be able to retry building or overriding builds with the same number, but having different tags.

We want to build and deliver custom apps via a manual trigger, similar to kiwix/kiwix-android-custom.
Assumptions:

• The build should be triggered by a release, with the appropriate tag (see below)
• On a single run only the apps of one brands should be built.
• The versioning should be inline with the ZIM file based approach described here: kiwix/apple#559,
  meaning we have the version [MAJOR].[MINOR].[PATCH] = YYYY.MM.build_number
• The build_number should be taken from the tag we create on the release
• In order to be able to create the same build_number twice (we might need to restart or overwrite the build), any additional parts can be appended to tags.
• Tags should be validated, and should come in the form: brandName_buildNumber(_optionalPart), where the brandName must be an existing folder (on the main branch), containing an info.json file.

We want to dynamically generate the Xcode project files with XcodeGen for custom projects as well, using the kiwix/apple repository as our base and build on top of it.

The kiwix/apple repository has been prepared to contain all the "base" settings for the Xcode project, that we inherit for the custom apps.

We are creating a new project file that is importing the "project.yml" from the kiwix/apple repo.
This way we are re-using the XcodeGen template from the kiwix/apple repo, and adding new custom targets.

This way all the base settings are still applicable, and we only customising the bare minimum, without any duplications.

The current setup is based on a similar info.json file as the Android one (see: kiwix/kiwix-android-custom), each contained in a "brand" folder. Currently we have 1 brand: "dwds".

What we need in each brand folder:

• an info.json file
• xcassets (these are mostly images and icons for the brand)

The rest of the process is automated to create the appropriate branded targets:

We need a reference branch, that we can build the DWDS app from manually,
and also a reference point to compare to while working on the 2 repository setup for custom apps.