It's not uncommon for us at Hattrick to jump in on a project where part of the code for the development of a mobile app has already been written.
When this happens, it's very important to assess the current situation of the app and the codebase to see where we stand and what we need to do to get it to an optimal state and start building from there.
To achieve this, we usually conduct a code audit, and in this post we'll share some of the key factors we check when performing it.

Tasks related to the codebase

The first thing we tackle is the code. It's the foundation for all the new things we are going to build, and like with every building, the foundation needs to be solid or the building will eventually collapse.

Code Style

Not every developer or team writes code in the same way –and that's one of the beauties of programming–, but there are guidelines related to the programming language you're using which should be followed with no exceptions. Also, the style of the code needs to be consistent throughout the entire codebase. Different programmers in the same team might write different code, but they should follow basic principles that guide the way all engineers in the team code.
Some of the things we check when it comes to code style are:

  • Indentation.
  • Spaces.
  • Classes, variables and methods naming conventions.
  • Separators (Regions on Android and MARKs in iOS).
  • Access Control for classes, variables and methods.
  • Project and Folders Structure.
  • Number of unresolved warnings.
  • Check that no code is commented out, and if there is, check that it is done properly.
  • Check that comments' presence is consistent throughout the project.

To make sure we have a good overall picture in this area we use lint tools, like SwiftLint for iOS and Android Studio's Lint Tool to check and get reports around these factors.

Software Architecture

It is also important to check that the previous developers followed a proper architecture pattern to build what has been built so far.
There are several patterns to follow nowadays. We prefer MVVM with Clean Architecture, but others could be valid for sure. What's important is that they are well implemented and that the concept of Separation of Concerns is well respected.

Error Handling

Error handling is a major aspect of app development. Crashes and unexpected errors when using an app are some of the things that lead to a bad user experience. When doing a code audit we pay special attention to not only the way errors are handled in the app, but also how they are informed to the user.

Security

It is crucial that when building a digital product you treat the user's data with professionalism, and that you do all your reach to keep it safe. That's why when doing a code audit we make sure that no sensitive information is stored on the phone, and that sensitive information like passwords travels encrypted to the backend, keeping it safe from unwelcome eyes.

Tests Coverage

In this stage we analyze the state of the current tests’ suite for the app (if any), and check the code coverage of both Unit and UI tests. This will give us a good understanding of how strong the app is in terms of testing, and how much effort will be needed to make sure appropriate tests are in place.

Tasks related to the app's usage

Performance Monitoring

We run the app using profiling tools to make sure that there's no resource hogging and that memory, disk, network and processor usage is optimal.

Test the app in different scenarios

Sometimes developers just follow the happy path, and fail to test their apps in unwanted scenarios. That's why we test apps in scenarios of slow and lossy internet connection, which can cause lots of unexpected errors if these scenarios weren't previously considered.
It is also important to make sure that the app doesn't crash if the user loses their internet access completely, and if operating in that mode is not possible, there should at least be a warning to the user letting them know.

Caching

Using a caching mechanism is not always necessary, but it can help provide a great user experience. For example, using an offline-first approach with a local database, you can allow the user to navigate their content when no internet connection is available, or if their internet connection is active but slow you can show the user cached content while the app fetches the newest content.
When we perform code audits we keep an eye on these types of issues. If they are not properly done, it probably means there's lots of room for improvement.

Platform compatibility

Android and iOS are similar in many ways, but they also have platform-specific aspects that any mobile team that is worth its salt should keep in mind. Here we check that the iOS app is built following Apple's Human Interface Guidleines and that the Android app respects Google's Design for Android Guidelines.

Conclusion

While there might be many more factors to consider when assessing the status of a mobile app, these are some that shouldn’t be overlooked when doing a code audit, and they help us make sure we are stepping on steady ground when building a mobile product.