top of page
Search
Writer's pictureQuinne Farenwald

Helpful Nuggets

Setup Links:


Processes

  • MR Questions

    • Are there tests supporting the business logic?

    • Were both platforms tested? (if flutter)

    • Is code named in a readable way for future developers?

    • How is current architecture? Is data decoupled from UI?

    • Is work in MR relevant to the ticket requirements?

    • Remove debug statements and commented code?

    • Are repeated strings/data pulled into variables?

    • Accessibility:

      • How does VoiceOver read?

      • What happens if I enlarge fonts?

    • How will QA test?

    • If INTERNAL flags are used, build production configuration to ensure app builds

    • Did I trust but verify by building the app and matching functionality with the ticket?

  • When to squash commits

    • Squash when merging a feature branch into an integrated branch

      • This helps in streamlining the commit history by condensing feature branch work into one commit

    • Do NOT squash when merging between any integrated branches

      • Since each integrated branch holds the feature commits, squashing would remove this important history and granularity level we can use for crucial for debugging, auditing, or tracking changes

  • Handle merge conflicts between release and develop

    • Create new branch off develop

    • Pull in release

    • Fix merge conflicts

    • Put up for MR and merge branch back into develop

  • Release Process

    • Create feature/release-<version> from release

    • MR to merge develop into feature/release-<version> (Don't squash)

    • Update develop branch version number

    • Any current release version bug MRs should be merged into feature/release-<version>

    • For a hot fix, create new feature/release-<version> off of release

      • Update version number

      • Make code changes

      • MR to merge feature/release-<version> to release

    • Merged feature/release-<version> into release to generate RC build (Don't squash)

    • Merge release back into develop to ensure parallell commit history (Don't squash)

  • Branching strategy

    • develop: main development trunk

      • Bitrise auto builds internal test builds on pushes to this branch and uploads to Firebase

    • release: current release ready code

      • Bitrise auto builds release version on pushes to this branch that can be uploaded to App Store

    • feature/*: Any long-running feature branch

    • <ProjectCode>-<TicketNumber>_<ShortDescription>: branch for ticket work

  • Presenting to product

    • What is the questions?

    • What is the issue?

    • What action do I need to leave the conversation with?

    • Other considerations:

      • Does this code need to continue to be maintatined

      • Are there test cases to ensure functionality of the ticket

  • Overwrite API Response with Charles

    • Http responses

      • Capture API response in Charles you want to edit

      • Save to a json file and change values

      • Right click endpoint in Charles and select 'Map Local'

      • On Edit mapping window, can replace host with *

      • Upload custom json file

      • Make sure Map Local is enabled and refresh app

    • GraphQL responses

      • Get URL of response to rewrite

      • Open Charles > Tools > Rewrite

      • Enable Rewrite

      • Add a new Rewrite or check an existing Rewrite to turn on

      • In Location Panel, add or double click an existing location to edit

        • Paste the full url you wish to rewrite in the Host section (it will auto populate to correct sections)

        • In Type/Action Panel, add or double click on an existing location to edit. Select the proper Type and Where that applies to what you are trying to rewrite. In the Match section, enter the value you are currently receiving, but with to overrride. THERE CAN BE NO SPACES. In the Replace section, enter the value you wish to see. There CAN be spaces here. Select a Replace style that matches best what you need.

      • Trigger call again and check Charles

    • SPM Formula

      • File > Packages > Reset package caches

      • Right click on package > Update package

      • Delete derived data

        • Xcode > Settings > Locations > Derived Data

      • Clean

      • Close Xcode

      • File > Packages > Resolve package versions

      • *check for stashed changes

      • *check building the workspace file

    • How to test INTERNAL wrappers

      • App Target > Build Settings > Active Compilation Conditions > Debug > Remove 'INTERNAL'


Good practices

  • Coordinator pattern

  • Dependency injection

  • Unit tests

  • Use combine over notifications

  • iOS supports 2 versions back


Running stack

  • Gitlab

  • Github

  • Chalk

  • Figma

  • Webex

  • Jira

  • Apple Developer

  • App Store Connect

  • Google Play Store

  • Xcode

  • Android Studio

  • Charles Proxy

  • Postman

  • Homebrew

  • Cocoapods

  • SPM

  • Git Large File Storage

  • SourceTree

  • Git

  • Quantum

  • Prism

  • Helix

  • Volt

  • Adobe Analtyics

  • Kibana/Open Search

  • Lucid

  • iOS

  • tvOS

  • Swift

  • Flutter

  • Dart

  • Kotlin

  • JetBrains Toolbox

  • Bitrise

  • Veracode

  • Firebase

    • Messaging

    • Crashlytics

    • Google Analytics

    • Remote Config

    • Notifcations

  • In-house design sytem

  • In-house backend

  • AppTest

  • TestFlight

  • GraphQL

  • Apollo

  • Chromecast

  • google-cast-sdk

  • Apple TV

  • Apple Shortcuts

  • Jotform

  • SwiftLint

  • Combine

  • VoiceOver

  • TalkBack

0 views0 comments

Recent Posts

See All

Comments


bottom of page