AirCasting

AirCasting

Conventions

Marking technical debit

For potential bugs or severe code quality issues:

Place warnings in places that can potentially cause a bug (or bugs), and are too big to resolve ad hoc.
When placing a warning, add a comprehensive explanation of the issue in the comment. Also link the ticket from 3) in this comment.
Add a ticket to github issues section with correct tag:
- A "warning" tag for every warning related issue
- An "AirBeam needed" tag for issues that reuquire an AirBeam to resolve/reproduce

For less severe stuff like minor code quality issues

When the problem is not causing bug-level issues, but is too big to resolve ad hoc, add a // FIXME: marking in code and explain it really well, so that someone with more time that stumbles across this will be able to fully understand and refactor/fix. Also link the ticket from 2) in this comment.
Add a ticket to github issues section with correct tag:
- A "code quality" tag for quality issues
- An "AirBeam needed" tag for issues that reuquire an AirBeam to resolve/reproduce

SwiftLint

We use swiftlint to preserve clean code. Please, install it first using Homebrew: brew install swiftlint

Fastlane

We use fastlane to automate building and releasing our app. Currently we're using 2 paths of release:

Beta

This lane is used for beta releases to the Firebase Distribution. In order to deploy a beta build:

cd into top project directory
make sure you'll on a develop branch and your git status is clean
run fastlane beta
after fastlane finsishes you'll find yourself on a version branch beta/${new_version_number}. Make a PR out of it and merge it immediately into develop

Release

The Release lane will build and release the app to the appstoreconnect and Firebase. Versions released this way will be marked as Release Candidate (RC). To run this lane:

cd into top project directory
make sure you're on a develop branch and your git status is clean
run fastlane release
after fastlane finishes push the release branch to repo, but don't make a PR out of it
bump version number to the next one on develop (might need prior consultation with the AC team)
after the version is accepted and released to AppStore merge the release branch into master

Release update

Use the release_update lane when you need to add some changes to the release candidate:

cd into top project directory
git checkout to the release branch (i.e. release/1.3.0)
apply and commit changes that are needed. DO NOT cherry-pick commits from develop branch. Remember to merge PRs with fixes directly to the release branch
run fastlane release_update

Release hotfix

Use the release hotfix lane when you need to add quick changes to the app that is already in the App Store:

cd into top project directory
git checkout to the main branch
run fastlane hotfix_init. After that you should be checked out to the hotfix branch
apply and commit changes that are needed
run fastlane hotfix_release
create PRs to main and to develop branch

Bump version after release

Use the bump_version_reset_build lane when you need to increment version number and reset build (to 0) after release is completed:

cd into top project directory
make sure you're on a develop branch and your git status is clean
run fastlane bump_version_reset_build
once the Fastlane finish, push the branch onto remote repo
merge the branch into develop

Integration

For the fastlane setup to work you'll need to obtain an .env.default file and place it inside Fastlane directory. It contains secret keys used for Firebase communication and appstore connect key details. If you want to integrate the app into your custom setup, provide this file using template:

FIREBASE_TOKEN = XYZ
APPSTORE_KEY_ID = XYZ
APPSTORE_ISSUER_ID = XYZ

And change the app identifier inside Fastfile.

You'll also need an AuthKey.p8 (an appstoreconnect API key) file placed inside Fastlane directory

Feature Flags

The app uses a concept called feature flagging to control which parts of code are ready to release and when. We're using Firebase Remote Config as a backend for those so we can adjust audiences on the fly not having to release new versions of the app. For beta testers there is a convenient AppSettings view which enables to manually flip any flag.

Configuration	Firebase	AppSettings
`DEBUG`	🛑	✅
`BETA`	✅	✅
`RELEASE`	✅	🛑

HabitatMap / AirCastingiOS