iOS Code Review Checklist

As iOS Software Engineer, i’ve been always looking to have a checklist to check against my code.Most of Software Engineers are usually interested in writing clean code that is working fine, meeting requirements and also easy to understand and maintain. So i thought about creating a basic iOS checklist and let the iOS developers community enhance it so we can have a great checklist common for all iOS Apps. As Apple now believes in the power of the community and made Swift Open Source, we as iOS community need to think in the same direction and create a good checklist that can be used as reference to any iOS developer around the world looking to deliver a high end product.

The checklist is divided it into 7 aspects as follows:

1-Static Code Analyzer(Swiftlint)

[1.1] Make sure No compilation error or warning.

2-General

[2.1] Single Responsibility Principle (SRS)
-Do not place more than one responsibility into a single class or function, refactor into separate classes and functions **(Plain Objects).**

[2.2] Open Closed Principle
-While adding new functionality, existing code should not be modified. New functionality should be written in new classes and functions **(extensions)**.

[2.3] KISS(Keep it simple and stupid)
-The KISS principle is descriptive to keep the code simple and clear, making it easy to understand. After all, programming languages are for humans to understand computers can only understand 0 and 1 — so keep coding simple and straightforward. Keep your methods small. Each method should only solve one small problem, not many use cases. If you have a lot of conditions in the method, break these out into smaller methods. It will not only be easier to read and maintain, but it can help find bugs a lot faster

[2.4] Comments
-If you need to add a comment to describe anything in your code then probably the code is ugly and not understandable so you need to revise naming and logic to keep it simple

[2.5] Magic #
-Avoid any magic number, define constants instead.Think first if this constant is specific for this view or it’s a global setting that should be shared between views

[2.6] DRY(do not repeat yourself), we should avoid any code duplication.

[2.7] Unused code
-Always delete unused code also code that is generated by IDE. In code review when you see empty method, unused variable, outdated comments, imports hanging around your code, don’t just leave it, it should be removed.

[2.8] Clarity is more important than brevity
-Take more time when writing code to optimize for reading. Code is read much more often than written.

[2.9] Avoid Nested if.

[2.10] Prefer switch over if-else.

[2.11] Localization, do you have any unlocalized strings. All strings shall be localized.

[2.12] Third party dependency version, please make sure to add the dependency version.

3-Architecture

[3.1] Project architectural pattern,, make sure you follow the project’s architectural pattern.

[3.2] Responsibility, ask yourself if this code is the responsibility of the layer you added in or not eg.rounded corner, shadows are the view responsibility not the model or the business logic, but if it’s for a cell shall the cell set it or the viewController ?!
- Naming convention, make sure you follow the project’s naming convention.
- Prefer dependency injection for dependencies.
- Prefer Composition over inheritance as Swift does not support multiple inheritance.
-create Protocols and extend them using Protocol Extensions to provide default method implementations. This allows us to create much cleaner code, compared to what we could implement by relying solely on the Classical Inheritance pattern.

4-Performance

[4.1] Main thread, heavy operation shall not be done on main thread, main thread is designed mainly for UI operations.

[4.2] Debug view hierarchy.

[4.3] To determine if you have any UI issue or overlapping views, please debug view hierarchy.

[4.4] Debug memory graph
-To determine if you have any strong reference cycle, please debug the memory graph and make sure we don’t have any memory leak

[4.5] Remove observers/invalidate timer on view dismissing.

5-UI

[5.1] Different screen sizes, does the design fit on all screen sizes.

[5.2] Constraints logic, does the constraints logic makes sense or will break in any case.

[5.3] Fonts, spacing and colors, do they match the prototype, are they added in a 1 generic place for reusing.

[5.4] “Empty states” for all views which can be empty. An empty state should always be there and make clear, how to add content.

6-Requirements

[6.1] Task possible errors handling eg.server down, no internet connection, slow internet connection…etc

7-Styling

[7.1] Code separation and organization, user pragma marks to organize the code as well as extensions eg.extension for the view controller conforming to UITableViewDataSource

[7.2] Files architecture, make sure you follow the project’s files architecture

Conclusion

This is a basic checklist that could be enhanced a lot, if you wish to contribute please follow this github repo and submit a PR for anything you see would add a value for the checklist.