Our signing key, which expires annually around the first week of August, is stored in a secure S3 hello-keys bucket.
Run make bootstrap to install development tools, and ensure Xcode
development tools are installed via xcode-select --install
We are using git flow.
All new code is added to branches forked from the develop branch, which is where everyday action happens. When releases are immiment, develop is merged into master and tagged with the latest version.
We are using a modified version of WebKit style, detailed in the style specification file. Notable differences are "attach" (same line) style for braces, a space in pointers, and allowing inlining of short statements. Explanation for the options in the specification file can be found here.
We are using deliver
for build deployment. deliver init will configure your credentials.
To upload to iTunes Connect, run make deploy.
The application was initially built with the standard MVC architecture, but once we released and we continue to add changes to the application, the controller has become a dumping ground for lots of logic that is not well tested and hard to reuse / debug / maintain.
To remedy the situation, various architectures have been considered including MVP, MVVM, and lastly VIPER (https://www.objc.io/issues/13-architecture/viper/). Ultimately, the goals of the architecture are:
- Increase testability without dependencies to UI
- Create a shared understanding within the team about how to structure a module so that when changes are needed, developer knows where to look
- Increase reusability of components
- Prevent class explosions and allow the use of out-of-box UIKit classes
Based on experimentation, it seems that VIPER was the best choice, except that the naming of the architecture just does not vibe with me. In place of the Interactor, we chose the term Service, which is already an element inside the app. Purpose, however, is the same. To manage the business logic around use cases without references to UIKit. The Presenter, which is not the same as the Presenter in MVP, essentially manages the views and works with the Service to enable the interaction for each module. The Controller, lastly, is responsible for setting up the presenter, services, view and then managing the navigation between the controllers.