Perhaps a separate framework should be created for handling view presentations.

Review John Sundell's blog post about lightweight presenters for inspiration.

Reviewing Automatic's Presentations library might also be useful.

See Rome.

I believe we should be able to add the Rome cache folder to CircleCI's list of directories to retain across builds to prevent rebuilding when not necessary. Note that we should also add this cache folder to a .gitignore if it's in the repository itself.

This article may also be useful to prevent CircleCI from rebuilding when not necessary if a local Rome cache is not sufficient.

Protocols, protocol extensions, classes, structs, enums, etc. should all have consistent rules around new lines at the top and bottom of the implementation. The linter should enforce this rule.

For all version numbers defined in the dot files at the root of the repo (and any other versions that should be checked) should cause warnings when performing make commands.

SwiftRouter?

Review John Sundell's article about navigation and Automatic's Routing for inspiration.

A script should be run that verifies that no files were changed as part of:

• SwiftGen
• Localization
• swiftlint autocorrection
  etc.

This should increase application launch times significantly as the number of dependencies increases.

In theory this should be as easy as:

1. Write a script that creates a temporary.xcconfig file that contains MACH_O_TYPE = staticlib and then $ export XCODE_XCCONFIG_FILE="$xcconfig" before running carthage build
2. In the project.yml reference the dependency file directly with framework: Carthage/Build/iOS/Static/XXX.framework of carthage: xxx
3. Add -all_load to the Core target's OTHER_LDFLAGS build setting (OTHER_LDFLAGS = $(inherited) -all_load in the Core target's .xcconfig)

IGListKit? MagazineLayout?

Maybe keep a single stack view using AloeStackView?

Moya with ReactiveMoya?

This should include adding a new asset catalog.

Perhaps the asset catalog should go in the Core target to show how sharing image assets with other another target would work (like an extension).

See https://github.com/SwiftGen/SwiftGen

Currently the swiftlint script is run once for each target accross all source files. Linting run as part of building a particular target should only lint the source for that target.

See https://stackoverflow.com/a/3459491/612612

This should include a BDD framework and ReactiveCocoa testing tools.

SwiftyBeaver?
NSLogger?
CocoaLumberjack?

The CI process should include incrementing the build number before generating a new build (which would be uploaded to an ad hoc service like HockeyApp, and optionally to TestFlight as well). How should this be handled?

CircleCI?

Replace most (all?) instances of ‘fatalError()’ with errors and review all ‘NoError’ signals to see if they should be erroring.

2.2.0 added support for relative paths on include which should clean up the spec files significantly by allowing us to move each target’s spec file into its folder.

Also investigate any other changes that could lead to improvements in this project.

_{Sent with GitHawk}

This might be difficult to do in the scope of this project since it would require a server to work properly.

If it should, we likely want to keep track of whether or not it has changed to prevent SwiftGen from running when it doesn't need to. I imagine the generation time could get long in a larger project.

Stylist?

See RxTheme for inspiration on reactive bindings.

Tools like SwiftLint, SwiftGen, etc. should be migrated to SPM.

See Orta’s article about why it’s time to switch to SPM.

Cartography?
SnapKit?

As part of CI, a script should run to check that:

1. The .xcode-version file's version matches the value for jobs:build:macos:xcode: in .circleci/config.yml.
2. Read the .ruby-version file's version when declaring a ruby version in the Gemfile.
3. Remove the .swift-version file since we should use the default Swift version for the specified .xcode-version when compiling the project and nothing else would use this.

This should include SwiftGen for type safety.

realm-cocoa?

Things like

• Why Xcodegen?
• Why .xxx-version files?
• Why have a Core framework?
• Why SwiftGen?
• Why check that files aren't changed after running rebuild scripts (e.g. $ make swiftgen)?
• Why use a layout framework?
• Why use UIStackView? (mention potential performance tradeoffs)
  etc.