This repository contains the StanfordBDHG Template Application. It serves as a template repository for projects requiring a mobile application using continuous integration and continuous delivery setup.

The Beta Deployment workflow is triggered when a new commit is added to the main branch.

It first runs the Build and Test workflow to ensure all tests are passing. Once the Build and Test workflow passes, it builds the iOS application so it can be archived and sent to TestFlight for internal beta deployment.

The Build and Test workflow builds and tests the iOS application, shared Swift package, and web service. It runs all unit and user interface (UI) tests defined in the targets. The iOS application is tested on the iOS simulator on macOS. The shared and web service Swift packages are tested on Linux and macOS as well as in release and debug configuration to demonstrate all possible variations.

The Swiftlint workflow is triggered by every pull request (PR) and checks if the files found in the diff contain any SwiftLint violations. You can change the SwiftLint configuration in the .swiftlint.yml file found at the root of this repository.

It is a prerequisite to have access to an Apple Developer Account that allows TestFlight releases and create an app in App Store Connect that matches the bundle identifier you have defined in the App project.

The TestFlight deployment requires access to the App Store Connect API using an API key. Please follow the Apple instructions to Creating API Keys for the App Store Connect API. The key needs the App Manager access role. Store the following information in the following GitHub secrets:

• APPLE_ID: The Apple ID you use to access the App Store Connect API.
• APP_STORE_CONNECT_ISSUER_ID: The issuer ID of the App Store Connect API is displayed in the App Store Connect API keys section.
• APP_STORE_CONNECT_API_KEY_ID: The key ID of the API key created in the App Store Connect API keys section.
• APP_STORE_CONNECT_API_KEY_BASE64: The content of the key created in App Store Connect condensed into a Base64 representation, e.g., using base64 -i AuthKey_ABCDEFGHIJ.p8 | pbcopy.

The GitHub Action imports the Apple certificate and provisioning profile from the GitHub secrets and installs them in a local KeyChain on the GitHub runner instances. Please follow the GitHub instructions to Installing an Apple certificate on macOS runners for Xcode development.

Obtaining the Apple provisioning profile requires you to follow the following steps:

1. Register the app identifier in the Apple Developer Account Identifiers section using the bundle identifier for your application, e.g., com.schmiedmayer.continousdelivery.
2. Create an AppStore distribution provisioning profile in the Apple Developer Account Profiles section using the app identifier you have created in the previous step.
3. Download the provisioning profile and convert it to a Base64 representation as detailed in Installing an Apple certificate on macOS runners for Xcode development and add it as the value for the BUILD_PROVISION_PROFILE_BASE64 secret.

After following the setup steps detailed in Installing an Apple certificate on macOS runners for Xcode development and obtaining the Apple provisioning profile as described above, you should have the following secrets configured in the repository settings:

• BUILD_CERTIFICATE_BASE64: The Base64 version of the Apple signing certificate to build your iOS application.
• P12_PASSWORD: The password for the Apple signing certificate.
• BUILD_PROVISION_PROFILE_BASE64: The Base64 version of the Apple provisioning profile to build your iOS application.
• KEYCHAIN_PASSWORD: A password for the keychain that will be created on the runner instance.

Be sure that you update the name of the provisioning profile in the Gymfile and update the app name, bundle identifier, Xcode project name, paths, and other settings in the fastlane files when modifying the template to your needs!

The Swift Package and Fastlane Update workflow requires an ACCESS_TOKEN secret: a GitHub Personal Access Token (PAT) allowing write access to the repository. We suggest using a bot account to create the access token. Using the PAT triggers the GitHub Actions in the create PR. The GitHub documentation provides instructions on creating a PAT. The scrop of the token can be limited to the public_repo scope for public repositories or the repo scrope for private repositories as well as the workflow scope.

Removing the token input in the GitHub action workflow results in using the default GITHUB_TOKEN and the GitHub Action bot account that does not trigger any possible merge checks in the newly created PR.

This project is based on ContinousDelivery Example by Paul Schmiedmayer. You can find a list of contributors in the CONTRIBUTORS.md file.