When do you need to audit your mobile apps?
Most business owners become aware of their audit needs when they already have a serious problem with either the performance, security, or usability of their current mobile app. There are some most typical scenarios where mobile apps review is needed:
- When you are not satisfied with the current state of app development. You either observe this is too slow, bugs are mounting and the bad reviews start to take over the app rating in AppStore or Google Play. This is a time when you need to search for mobile app testing and auditing companies.
- When your app development team is changing and you want to check the status quo to set the expectations for the future roadmap and investigate potential technological debt.
- When you are buying or simply investing in an existing company with digital assets and you want to run the due diligence report on the current state of these assets.
- When you are experiencing organizational difficulties in running the current IT project and want to look for more efficient ways on how to manage that.
- When you want to transfer your existing old applications onto a new tech stack and want to plan the migration so that to sustain the current operations and avoid data loss.
- When you consider moving your native iOS and Android app development to cross-platform solutions based on Flutter or React Native and you are investigating the roadmap and exploring possible options.
You need to state the mobile apps audit goals
Depending on the needs of the business owner there are specific types of tests and audits that could be performed on both native iOS and Android apps and cross-platform React Native and Flutter apps. They differ in terms of the main purpose of the audit and allow the testing team to keep the focus on the business priorities. We can distinguish the following types of mobile apps audit and testing techniques:
- Technical audit - this type of audit is made to assess the overall code quality and system architecture. This type of audit can be performed by an independent team/testing company in order to reassure that the efforts of the main app development teams are properly focused and that no technical debt is incurred.
- Security audit - this type of audit is performed often before integrating the new solution with existing infrastructure to better understand what risks can it bring to the working product. It helps to identify some quick red flags and lists potential threats that need to be addressed and/or monitored after the integration. This would be then subject to the business owner's decision on how to handle potential leaks and security flaws and how is your mobile application vulnerable to hackers attacks on different operating systems.
- Discovery audit - this is a type of audit that allows the business owner to understand what digital asset they possess, what does it consist of (native vs cross platforms), and what is the overall quality of the mobile application.
- Migration audit - this type of audit helps to analyze the code with a clear target to prepare a better roadmap for product migration into a new platform/language. This is often a case when companies are shifting their mobile applications from an all-native approach with a focus on iOS and Android operating system to using cross-platform solutions like Flutter or React Native. This mobile app audit allows giving recommendations for the specific app migration strategy, possibly including the add-to-app approach, a popular strategy when changing the development platform to Flutter.
What should you prepare before running the mobile apps audit?
The preparation for an audit requires gathering comprehensive information for the mobile app testing company on the IT system and its infrastructure. Specific items on the preparation checklist depend on what is the purpose of an audit and what are the building blocks of the application. However, there are certain must-have elements for the mobile application audit that need to be addressed before IT experts are starting the complete review on the apps:
- Tech stack description, general guidance on the approach used (whether native based on iOS and Android or cross-platform using Flutter or React Native). This is a high-level overview of what is included in the application and what can be expected by the auditing team. This is a highly important document that can help us to better adjust the auditing team based on their qualification and practical experience with the key parts of the IT system.
- Access to the source code of the application. This can be sent either through the ZIP file or as access to the shared code repository (with GitHub, GitLab, and Bitbucket being the most popular).
- Application building instructions with the documented guide to run the app in Xcode, Android Studio, etc. The best-case scenario is a readme file with all the details for a quick setup.
- Instructions in CI/CD (continuous integration, continuous deployment) process. Access to the tools and their setup. Popular solutions in this space are for example NeverCode (Code Magic), Bitrise, and AppCircle.
- Access to the hosting environment including key information about the staging between testing and production environment if applicable.
- Project documentation. This can be listed either as the separate, complete documentation with diagrams and graphs or the access to the project management software where this information is stored (Atlassian, Asana, or other tools.).
- Security requirements. What measures have been taken in order to provide the proper encryption, how are users' credentials managed and who is responsible for the overall application security?
- [optional] Access to AppStore and Google Play Store to review the reported bugs and issues with the current and previous app versions. The lack of a properly configured distribution center can also be considered a red alert for the auditing team.
There are also some non-technical prerequisites for the application audit which are worth mentioning.
- Access to the project roadmap to better understand expected features and their impact on the current mobile apps.
- Team description with the roles and responsibilities in the project, together with the contact details so that to investigate any doubts and issues spotted during the mobile apps audit.
- List of any 3rd party components (including graphics) together with the applicable licensing program (MIT, Apache, MS-PL, etc.).
- UI/UX files, source files for all graphic components, or access to Figma, AdobeXD, Sketch, or equivalent tool.
- [optional] Screen recordings or mockups with the complete customer journey through the apps.
- [optional] Test scenarios, access to the automated testing tools, and apps testing services.
It often happens that not all components are available, for example, due to the conflict within the team or the previous provider. In case of the limited data, the audit team can infer risks and potential drawbacks related to that particular, less transparent component. However, this approach is subject to higher uncertainty.
What is taken into account during the audit process?
During the audit process, the auditing team is analyzing the mobile application using the top to bottom approach with the focus on areas specified upfront, like technical overview, security, etc. listed above in the audit types.
Mobile app architecture
The first part of an audit is dedicated to the project architecture. During this phase, the audit team specifies high-level elements like:
- Language or framework version used to build the app.
- Minimally supported Android and iOS versions.
- External dependencies.
- Main libraries being used in the project and the method they are injected in the project.
- State management methods.
- Code structure and any distinctive logical parts.
The second phase of the audit focuses on code quality. Depending on the conclusions from the analysis of the architecture this part can include research on the following items (this is not a complete list):
- Usage of Object-Oriented Programming and SOLID principles.
- Clear division of responsibilities of separate classes according to the Single Responsibility Principle.
- Project Structure in a package-by-feature rather than package-by-type manner.
- Relation between the UI and the business logic to avoid tight logical coupling. Examples of such patterns include MVP (Model-View-Presenter) or MVVM (Mobel-View-ViewModel).
- The overall code consistency. This is an issue if the application has been built by several developers without the clear responsibility for analyzing the pull requests to the master code.
- State management.
- Existence of any old artifacts, which the application is no longer using.
- Performance issue.
- Storage management.
- Comments and unresolved issues described by devs in the source code.
- Code reuse between different applications without separation into code libraries.
- External integrations.
Performance of the mobile apps
This part of the audit is focusing on the performance of the mobile applications. At this stage the attention is focused on:
- Framework version and usage of the newest Android and iOS version benefits. It is often the case that projects are upgraded to the latest SDK version, however without taking advantage of the recent performance improvements.
- Reports on crashes and issues from distribution centers as well as any external tools such as Firebase or Bugfender (issue tracking solutions).
- Performance against specified test scenarios and results from automated testing if available.
- Hardware-related performance issues like high-level frequency of usage of location-based features.
- API-related performance issues like the uncontrolled loops in the calls to API.
- Size of the application and existence of the unutilized resources.
Security analysis in mobile apps
The fourth phase is related to the security analysis and takes into consideration any potential risks and threats to both users and the whole system. Some of the typical tests include:
- Analysis of the data kept at the SharePreferences packages. It often happens that this space is excessively used to store confidential data leaving room for fraud.
- Keychain (iOS) / Keystore (Android) management.
- Encryption of data while communicating with server (SSL).
- Access to confidential financial data such as credit card numbers.
- Storage and access to health-related data if applicable.
Maintenance of the code
This part helps to answer the question of whether the application development process is professionally structured and if there will be potential problems during further development or takeover process to another development team. During this phase the audit team pays attention to:
- Documentation of the project. Both separate as README files, and inline, in the code source stated as comments.
- Testing and the code coverage by unit and UI tests. Although the implementation of the tests adds an additional burden to the project this allows developers to gain a huge advantage in the long run by greatly improving the overall code quality. Sometimes lack of Unit and UI tests could be compensated later on but if this is coupled with the lack of separation of the business logic and the interfaces this solution is almost impossible to implement.
- Dependencies on external packages and libraries. Here the audit team pays attention to external libraries, their updates, regular support, licensing models, and usage within the mobile app. It often happens that some packages are no longer supported which creates a risk for future app development. It is also often the case that certain packages are no longer in use and the app requires a cleanup.
- The CI/CD tools and processes and details of their implementation are in the README file. This is critical for further agile development that the app can be instantly built after new merges to the master. It improves the efficiency of the testing and allows to release of an application in very short cycles, so demanded by the business.
What are the most popular mistakes we’ve spotted after making 10+ mobile audits?
Here at LeanCode, we’ve conducted more than 10 mobile apps audits (including flutter apps). We would like to share our experience on the most frequent problems which were reported by our audit team so that you can avoid them in the development of your future apps and plan to mitigate those risks in advance. It is wise to plan that beforehand, as certain problems we have identified not only increase the tech debt but also make the apps very hard to maintain. As a result, those apps receive the worst recommendations, which is to rewrite the code.
This type of outcome causes anger and frustration and you don’t want to find yourself in this situation neither from the perspective of a business owner nor the developer behind the problematic apps. On our list problems are classified using the matrix of severity and effort needed to solve particular problems.
Low Severity & low effort
Problems reported in the first part of the matrix may include for example storing the apps confidential data (like a Keystore) in the repository, which is convenient during the development process but developers often forget to take it out afterward. The severity of this problem is relatively low and this problem is simple to solve. There are other examples in this category, but other parts of the matrix are definitely more interesting.
High Severity & low effort
Problems belonging to the second category may cause serious implications to the business and they require immediate attention.
It is often the case that typical security issues are listed here. The most critical bug we’ve identified, which was relatively easy to solve, was that the credit cards of users subscribed to the service were stored in plain text. This was a result of the wrong Stripe integration within the apps and could end up in potential lawsuits even without the fraud incident happening.
Low Severity & high effort
Problems reported in the third part are more technical and relate to the general project architecture. This category consist of issues like:
- Insufficient test coverage and the lack of automated testing.
- Missing apps documentation.
- Lack of CI/CD tools.
- Lack of any bug reporting integration.
- Problems with some relevant packages which require updates and are no longer supported.
These are the issues we often observe during the audit. They are a result of either limited budget and the pressure from the business owner or incompetence of the development team. Whatever the reason, these problems are not immediate blockers for further development of the app, but a significant effort has to be placed in order to solve those issues before starting to work on new features.
High Severity & high effort
Last but definitely not least is the 4th part of the matrix. In our experience, we’ve encountered 3 cases (25% of total reports), where the problems identified during the audit process were serious enough to recommend throwing the entire code into the garbage. Those are the problems that make it almost impossible to add new functionality and make it really hard to maintain the current app by fixing existing bugs. Typically the main reason behind this red flag recommendation is the wrong application architecture, which doesn’t follow the Object-Oriented Programming principles and provides no separation between the UI and business logic. What is typical, is the fact that this result is rarely a surprise to the business owner. What comes first are the problems with communication between the development team and the business owner, extended bug solving times, and a general lack of transparency in the materials provided for the audit. If this is the case, not only the source code requires the change, but the whole development process needs to be revised.
The other side of the rainbow
What is more, our own apps have also been audited by external partners before they were integrated into bigger IT systems of our corporate clients. The audit process is not much different in those cases except for the fact that it is extended by the additional part on general compliance with the client’s (corporation) IT policies. This involves alignment with the tech stack as well as the usage of certified, approved providers of external services. It is recommended that for large-scale projects with corporations the complete list of external libraries is set up in advance and approved by the internal IT department.
What can you expect after an audit?
What is the outcome of an audit?
The audit is a very formal process with a clear outcome in the shape of the audit report. This report provided insights into the areas mentioned in this article, but also provides an extensive executive summary for the business owners, where most critical issues, as well as recommended solutions, are provided. The summary greatly depends on the type of audit, whether this is purely technical, discovery or security, or migration audit.
This report could be used as a justification for further implementation and approval for the development team or as instruction on what should be done to reach better quality standards. Typically the report is a 12-20 pages long A4 document and gets created within 5 days from signing the audit order and providing the prerequisites.
What is the price of the mobile app audit?
Clients are often asking how much does the mobile audit cost? Our answer is, that the price depends on the type of audit with discovery audits being typically the cheapest and starting from $800 for two days-long processes. The price for more advanced mobile audits, with complex deliverables like the AddToApp roadmap, can be more expensive. During the estimations, we need to understand what is the background and project tech stack (native vs cross-platform solutions using flutter apps or react native apps).