n8chur / advancedios Goto Github PK

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.

CircleCI?

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?

IGListKit? MagazineLayout?

Maybe keep a single stack view using AloeStackView?

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.

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.

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

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.

SwiftyBeaver?
NSLogger?
CocoaLumberjack?

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 should include SwiftGen for type safety.

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

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

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.

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.

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.

Moya with ReactiveMoya?

This should include a BDD framework and ReactiveCocoa testing tools.

Cartography?
SnapKit?

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

Stylist?

See RxTheme for inspiration on reactive bindings.

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.

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.

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

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

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)

realm-cocoa?