971 release tag seems wrong

.github/workflows/cd.yml

@@ -11,13 +11,13 @@ name: CD
 # |-----------------|---------|------------------------|----------------|------------------|
 on:
   schedule:
-  - cron: '32 1 * * *' # NIGHTLY @ 01:32
-  - cron: '00 2 * * 1' # WEEKLY @ 02:00 on Monday
+  - cron: '32 1 * * *' # Nightly download.kiwix.org @ 01:32
+  - cron: '00 2 * * 1' # Weekly testflight          @ 02:00 on Monday
   push:
     tags:
-      - testflight**   # TestFlight Tag
+      - testflight     # On-demand TestFlight
   release:
-    types: [published]   # Post App Release
+    types: [published] # Release
 
 env:
   KEYCHAIN: /Users/runner/build.keychain-db

README.md

@@ -146,25 +146,50 @@ https://developer.apple.com/documentation/safari-developer-tools/inspecting-ios
 
 ### Nightly to FTP
 
-Each night 01:32 am CET, we build our iOS and macOS apps.
-These are developer signed builds, notarized (a process required to install them outside of the app store) and uploaded to our FTP nightly folder. The files are versioned using the current date.
+Each night at 01:32 am CET, we build the Kiwix iOS and macOS apps.  These
+are developer signed builds, notarized (a process required to install
+them outside of the app store) and uploaded to our [nightly
+folder](https://download.kiwix.org/nightly/). The files are versioned
+using the current date.
 
 ### Weekly to TestFlight
 
-Mondays at 02:00 am CET, we build our apps, but only if there were code changes within the last week (any git commits to main).
-These are AppStore builds, which are uploaded to TestFlight, using the current app version from code (see `project.yml`).
+Each Monday at 02:00 am CET, if there were code changes within the
+last week (any git commits to main), we publish Kiwix for iOS and
+macOS to [Testflight](https://testflight.apple.com/).  These are
+AppStore builds, using the current app version from code (see
+`project.yml`).
 
 ### On-demand TestFlight
 
-It is also possible to create TestFlight builds on-demand, by pushing a git tag starting with "testflight" to the repo. This will run the same process as the "weekly" build (we just do not need to wait a whole week).
+It is also possible to trigger
+[Testflight](https://testflight.apple.com/) builds - on-demand - by
+tagging `testflight` any revision of the code base. You reuse the very
+same tag for consequent testflight releases. This will run the same
+process as the "weekly" Testflight (we just do not need to wait up to
+Monday).
 
 ### Releasing to AppStore and FTP
 
-Once we are happy with the quality of the app in TestFlight, we can send it for approval to Apple. Once approved by Apple, we can release them to the AppStore. At the same time, we do want to release our macOS app via FTP as well. For this, we run our "Post App Release" workflow, which can be triggered by creating a Github Release, based on the git commit used for the TestFlight apps (the ones that were approved by Apple). The specific commit that triggered the (now approved) TestFlight app, can be found under Github Actions. This Github Release (based on this specific commit) will rebuild the macOS application and upload it to FTP to the release folder. Again, the purpose of this is to make the very same macOS app - which was released to the AppStore  - also available via FTP.
+Once satisfied with the quality of the app in TestFlight, we can
+proceed with the Kiwix release process.
+
+The release process is triggered by a by [GitHub
+Release](https://github.com/kiwix/kiwix-apple/releases). Only the
+version released (to Testflight) that way can be then sent to
+approval to Apple. Once approved by Apple, we can release them to the
+AppStore. At the same time, will publish the macOS DMG to our [file
+server](https://download.kiwix.org/release/kiwix-macos/).
+
+In case the app is rejected by Apple in a way that requires a new
+build to fix the issue, a new patch release should be prepared and
+released... and re-submitted to App Store.
 
 ### Last step
 
-If all that is done, we should create a PR, incrementing the version number of the project (see: `project.yml`), and the deployment cycle can start again.
+If all that is done, we should create a PR, incrementing the version
+number of the project (see: `project.yml`), and the deployment cycle
+can start again.
 
 ## Reporting a bug