Merge pull request #285 from nimblehq/release/3.7.0

.github/CODEOWNERS

@@ -1,5 +1,5 @@
 # @suho is the Team Lead and the others are team member
-* @suho @blyscuit @edgarss @markgravity @minhnimble @nmint8m @phongvhd93 @vnntsu
+* @suho @blyscuit @edgarss @markgravity @minhnimble @nmint8m @phongvhd93 @vnntsu @ducbm051291 @Shayokh144
 
 # Engineering Leads
 CODEOWNERS @nimblehq/engineering-leads

.github/wiki/Automating-Wiki.md

@@ -2,4 +2,4 @@
 
 1. Setup the Github Wiki by following this [official guide](https://docs.github.com/en/communities/documenting-your-project-with-wikis/adding-or-editing-wiki-pages#adding-wiki-pages).
 2. Create [Personal Access Token](https://docs.github.com/en/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token.) with `repo` scope enabled - a bot account is recommended to generate that token.
-3. Create a [Repository Secret](https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository) with the above token, the default name for this secret is `NIMBLE_DEV_TOKEN`.
+3. Create a [Repository Secret](https://docs.github.com/en/actions/security-guides/encrypted-secrets#creating-encrypted-secrets-for-a-repository) with the above token, the default name for this secret is `NIMBLE_DEV_TOKEN`.

.github/wiki/Bitrise.md

@@ -0,0 +1,66 @@
+# Bitrise
+Use the Bitrise template to start a new project with Bitrise as the CI/CD tool.
+
+## Workflows and Steps
+
+Out of the box, the Bitrise Template has the following workflows and steps:
+
+| test                      | deploy_app_store                                        | deploy_staging                          | deploy_release_firebase                   |
+|---------------------------|---------------------------------------------------------|-----------------------------------------|-------------------------------------------|
+| Git Clone Repository      | Git Clone Repository                                    | Git Clone Repository                    | Git Clone Repository                      |
+| Bitrise.io Cache:Pull     | Bitrise.io Cache:Pull                                   | Bitrise.io Cache:Pull                   | Bitrise.io Cache:Pull                     |
+| Run CocoaPods install     | Run CocoaPods install                                   | Run CocoaPods install                   | Run CocoaPods install                     |
+| Fastlane - Build and Test | Xcode Test for iOS                                      | Xcode Test for iOS                      | Xcode Test for iOS                        |
+| Fastlane - Run XCov       | Fastlane Match                                          | Fastlane Match                          | Fastlane Match                            |
+| Danger                    | Fastlane - Build and Upload Production App to App Store | Fastlane - Build and Upload Staging App | Fastlane: Build and Upload Production App |
+
+## Trigger Map
+
+| Workflow                | Trigger                 |
+|-------------------------|-------------------------|
+| test                    | Create or Update a PR   |
+| deploy_staging          | Push branch `develop`   |
+| deploy_release_firebase | Push branch `release/*` |
+| deploy_app_store        | Push branch `master`    |
+
+## Environment and Secrets
+### App Environtment Variables
+- BITRISE_PROJECT_PATH
+> e.g., ExampleApp.xcodeproj or in case you're using CocoaPod, it is ExampleApp.xcworkspace.
+
+- TEAM_ID
+> This is your Apple Team ID (e.g., T3T4E84BAA), you can find it in `Membership` at Apple developer portal.
+
+- MATCH_REPO_URL
+> Link to a repository that contains your Fastlane Match it can be either HTTPS or SSH link (e.g., https://github.com/nimblehq/fastlane-match.git)
+
+### Workflow Environment Variables
+All four workflows have their own variables:
+
+- BUNDLE_ID
+> e.g., com.nimblehq.exampleApp
+
+*Depending on which workflow, the value of those variables may differ from other workflows.*
+
+### Secrets
+
+- MATCH_PASSWORD
+> This is an encryption password for the Match Repo
+
+## Installation
+1. Follow the setup instruction in [`README.md`](https://github.com/nimblehq/ios-templates#readme).
+2. To connect your repository to Bitrise please follow the instruction in this page: [Adding a new app](https://devcenter.bitrise.io/en/getting-started/adding-your-first-app.html).
+3. Make sure the option where the `bitrise.yml` locate is set to `Store in-app repository`.
+<p align="center">
+  <img src="assets/images/bitrise/Bitrise-YML-Storage-Location.png" alt="Bitrise Store in-app repository" width="600"/>
+</p>
+
+4. Provide all the required variables and secrets.
+> Final project directory structure
+```
+ROOT
+├── ExampleApp.xcworkspace
+├── bitrise.yml
+├──...
+```
+5. Push changes to SCM.

.github/wiki/Getting-Started.md

@@ -0,0 +1,13 @@
+## Requirements
+
+- Xcode `13.3+`
+- Ruby `3.1.2`
+
+## Use the template
+
+1. Create your repository by pressing the `Use this template` button in this repository or create a new repository and use `nimblehq/ios-templates` as a repository template.
+2. Clone your repository
+3. Setup the project by running the following command in your terminal:
+    ```bash
+    sh make.sh --bundle-id [BUNDLE_ID_PRODUCTION] --bundle-id-staging [BUNDLE_ID_STAGING] --project-name [PROJECT_NAME]
+    ```

.github/wiki/Github-Actions.md

@@ -0,0 +1,65 @@
+# Github Actions
+
+Use the GitHub Actions template to start a new project with GitHub Actions as the CI/CD tool.
+
+Out of the box, the template contains the following workflows:
+
+## Workflows
+
+There are currently 4 workflows:
+
+- test
+- deploy_firebase
+- deploy_release_firebase
+- deploy_app_store
+
+|Task/Workflow           |test                                                                                                                                |deploy_firebase|deploy_release_firebase|deploy_app_store|
+|------------------------|------------------------------------------------------------------------------------------------------------------------------------|---------------|-----------------------|----------------|
+|Trigger                 |merge or push to feature/chore/bug branch                                                                                           |merge or push to develop branch|merge or push to release branch|merge or push to main/ master branch|
+|Lint (async)            |✅                                                                                                                                   |✅              |✅                      |✅               |
+|Test                    |✅                                                                                                                                   |✅              |✅                      |✅               |
+|Deploy                  |❌                                                                                                                                   |Staging build to Firebase|Production build to Firebase|Production build to App Store|
+
+## Jobs
+
+### Lint
+
+1. Check out the current version.
+2. Run a SwiftLint on a Linux machine. Show result on pull request's check.
+
+### Test
+
+1. Check out the current version.
+2. Install dependencies including Gem, Fastlane, and Cocoapods.
+3. Run Test on staging scheme and show result on pull request's check.
+
+### Deploy
+
+1. Proceed to 4 if this job is running after `Test` job
+2. Check out the current version.
+3. Install dependencies including Gem, Fastlane, and Cocoapods.
+4. Install provisioning profiles and certificates using Fastlane match.
+5. Build archive version of the specified scheme.
+6. Deploy to Firebase Distribution, TestFlight, or App Store.
+
+# Installation
+
+## Environment Secrets
+
+Make sure the following secrets are set up.
+
+|Secret                  |Description                                                                                                                         |test|deploy_firebase|deploy_release_firebase|deploy_app_store                   |
+|------------------------|------------------------------------------------------------------------------------------------------------------------------------|----|---------------|-----------------------|-----------------------------------|
+|SSH_PRIVATE_KEY         |SSH key connected to a user with access to the match repo for check out the match repo.                                             |-   |✅              |✅                      |✅                                  |
+|MATCH_PASS              |Fastlane Match Passphrase for decrypting a match repository.                                                                        |-   |✅              |✅                      |✅                                  |
+|APPSTORE_CONNECT_API_KEY|App Store Connect API https://docs.fastlane.tools/actions/app_store_connect_api_key/ for uploading build to TestFlight or App Store.|-   |-              |-                      |✅                                  |
+|FIREBASE_TOKEN          |Firebase token https://firebase.google.com/docs/cli#cli-ci-systems for uploading build to Firebase Distributions and Analytics.     |-   |✅              |✅                      |✅ For uploading dSYM to Crashlytics|
+
+## Installation
+
+1. Following the setup instruction in `README.md`.
+2. Modify the files with project's values:
+    - fastlane/Matchfile
+    - fastlane/Constants/Constants.rb
+3. Provide SECRETS noted in `yml` file in [Github Project's Setting](https://docs.github.com/en/actions/reference/encrypted-secrets)
+4. Push changes to Github

.github/wiki/Home.md

@@ -2,4 +2,4 @@
 
 This wiki contains documentation about our optimized iOS template.
 
-If you want to understand our templates, let's jump into [[Getting Started]].
+If you want to start with our templates, let's jump into [[Getting Started]].

.github/wiki/Project-Configurations.md

@@ -0,0 +1,136 @@
+## Project Configurations
+
+This document presents in detail the set of configurations used in the iOS projects developed at Nimble. Included in this document are:
+
+- Terminologies and topics related to project configurations.
+- Basic targets, schemes, build settings options, etc., for building a project.
+
+### Targets
+
+A target specifies a product to build, such as an iOS, watchOS, or macOS app.
+
+When creating a project from a template, a default target will be added automatically for the main application.
+
+There are 3 default targets in a project:
+
+- {ProjectName}
+- {ProjectName}Tests
+- {ProjectName}UITests
+
+### Schemes
+
+A scheme is a collection of settings that specifies the targets to build for a project, the build configuration to use, and the executable environment to use when the product is launched.
+
+The 2 main schemes in a project:
+
+- {ProjectName}
+- {ProjectName} Staging
+
+### Build Configurations in Schemes
+
+It is possible to build a scheme with different Build Configurations. Initially, there are 2 basic configurations for a project generated automatically by Xcode, which are:
+
+- Debug
+- Release
+
+However, these basic configurations are not enough for our development process. Since our team always wants to ensure the application is working in a designated manner, additional levels of testing are required before the application is ready to be used.
+
+The recommended set of configurations to have is:
+
+- Debug Staging
+- Release Staging
+- Debug Production
+- Release Production
+
+### Active Compilation Conditions
+
+Having distinct flags for each configuration is the preferred solution.
+
+Xcode provides a build setting named `Active Compilation Conditions`, which supports passing conditional compilation flags to the Swift compiler.
+
+In our iOS template project, there are three custom conditional compilation flags: `DEBUG`, `STAGING`, `PRODUCTION`. The following table will describe how the developers differentiate a configuration from the others.
+
+| Build Configurations | DEBUG | STAGING | PRODUCTION |
+|---|---|---|---|
+| Debug Staging | ✔︎ | ✔︎ |  |
+| Release Staging |  | ✔︎ |  |
+| Debug Production | ✔︎ |  | ✔︎ |
+| Release Production |  |  | ✔︎ |
+
+The major advantage of custom flags is to allow customizable specific features based on a particular environment.
+
+Example: 
+
+Specify a value based on the environment:
+
+```swift
+enum Environment {
+
+    static func based<T>(staging: T, production: T) -> T {
+        #if PRODUCTION
+        return production
+        #else
+        return staging
+        #endif
+	}
+}
+```
+
+During the development process, all functionalities and frameworks are available in the application. However, there can be situations when the developers just want to turn on some features for a particular environment without creating separate modules for the application. In these cases, declaring a condition to include or exclude code using `Active Compilation Conditions` is the recommended solution.
+
+```swift
+#if DEBUG
+    // Code the app includes in DEBUG environments
+#else
+    // Code the app includes when it is not build with DEBUG environments
+#endif
+```
+
+### Xcode Configuration File
+
+A Configuration Settings File (`*.xcconfig`), also known as a build configuration file, is a plain text file that defines and overrides the default build settings for a particular build configuration of a project or target. This type of file can be edited outside of Xcode and integrates well with source control systems.
+
+Because of different settings for each environment (such as bundle identifiers, endpoints, etc.), the developers also define them in different *.xcconfig files.
+
+### Settings Bundle
+
+To support multiple levels of testing, the `Settings Bundle` is usually integrated along with the dev configurations (a **.plist** file). In addition, the Settings Bundle facilitates the testing process. It creates a shortcut to change environment values without using any third-party API or server.
+
+Settings Bundle works well when developing:
+
+- [Feature toggle](https://martinfowler.com/articles/feature-toggles.html)
+- [A/B Testing](https://en.wikipedia.org/wiki/A/B_testing)
+- Change API endpoints for testing the application with multiple servers
+- Define a list of prefilled credentials and a toggle for prefilling
+
+The Settings Bundle is only enabled on Dev environments. It is optional for Beta environments.
+
+### Debug Symbol File
+
+Basically, the debug Symbol file (`dSYM` file) is used to de-obfuscate stack traces from crashes happening on the production app. The dSYM files store the debug symbols for the application. Then services (like Crashlytics) use the dSYM files to replace the symbols in the crash reports with the originating locations in the source code. Hence, the crash reports will be more readable and understandable.
+
+Go to **Build Settings** → **Debug Information Format**. The debug symbols with a dSYM file (DWARF with dSYM file) are enabled for the release build by default.
+
+A benefit of using the dSYM is reducing the binary size when building an application. Read more about it in the technical note [TN2151](https://developer.apple.com/library/archive/technotes/tn2151/_index.html).
+
+Only include the dSYM file for release builds.
+
+| Build Configurations | Included dSYM file |
+|---|---|
+| Debug Staging |  |
+| Release Staging | ✔︎ |
+| Debug Production |  |
+| Release Production | ✔︎ |
+
+### Enable Bitcode
+
+Bitcode is a technology that enables recompiling applications to reduce their size. The recompilation happens when the application is uploaded to the App Store Connect or exported for Ad Hoc, Development, or Enterprise distribution.
+
+Enable build with bitcode for Production only.
+
+| Build configurations | Enable Bitcode |
+|---|---|
+| Debug Staging |  |
+| Release Staging |  |
+| Debug Production |  |
+| Release Production | ✔︎ |