Building mobile apps is a business necessity today, but it’s hard to get it right. Too many apps don’t live up to expectations. They may be slow, hard to use, prone to crashing, or just not doing the job they were meant to.
Asynchrony’s third-party App Review can help you identify the underlying problems to help you get your apps back on track. Our experienced iOS and Android engineers dive deep into the code base and figure out what’s working–and what isn’t. We look at over 15 specific factors that could affect your app’s performance.
At the end of the process, we deliver a detailed report on the inner workings of your app. It includes the analysis and metrics you’ll need to move forward and get your apps back on track.
The code review process begins by identifying various code-quality elements relating to the mobile technologies in question, and then proceeds with the evaluation. By supplying underlying metrics and noting whether or not the identified code-quality elements are present, the code review process remains as objective as possible while delivering real, actionable results.
Phase One: High-level overview
In this phase, our team will gain a sense for the overall health of your mobile application(s). A senior software engineer will guide the effort, leading the collective team through analysis and prioritization activities which will drive the subsequent analysis phases.
Code Repository: Frequent commits tend to illustrate a dynamic code base where features are implemented in consumable bites. Longer gaps between code commits tend to illustrate complex pieces of code that may carry bigger application risks. Our team will assess the current code repository tool used and the underlying check-in/commit frequency of the development team.
Application Build: The team will ensure that your mobile projects build cleanly without warnings and errors. If warnings are present, we will capture them in our analysis.
Backwards capability: Application builds will be tested for all of the supported iOS and/or Android operating systems and validated for backward capability. If no authoritative “Supported Operating Systems” list exists for your applications, we will suggest one based on the technologies/libraries used in the software.
Static code analysis: Source code may have subtle errors that slip by the compiler and manifest themselves only at runtime. These bugs are much harder to identify and fix. The Xcode IDE and Android SDK Tools include static analyzers that find flaws and potential bugs in the source code of a project.
Project structure: The larger the project is, the more important it becomes to impose a reasonable structure, in order to assist in long-term maintenance and sustainability. Our engineers will examine your application project structures to ensure that source code files are organized in a reasonable hierarchy.
Automated test analysis: Our engineers will determine the presence and quantity of unit tests and/or integration tests. If they exist, the suite of tests will be run to ensure they complete without failure.
Test coverage metrics: If unit tests exist, we will record coverage metrics that document how much of the application is tested.
These first steps provide our team with an initial “sniff test” of your mobile applications and pave the way for subsequent discovery in Phase Two.
Phase Two: Deeper Dive
This phase consists of a closer examination of your mobile apps. Every source code file will be observed to establish common patterns across the application.
Definition of Architectural Patterns: Before diving into the code, we will determine the common architectural patterns being used (e.g., Model-View-Controller). This will not only provide a roadmap for the Phase Two code analysis, but also help our team provide implementation-specific suggestions moving forward.
Syntax relevancy: In this step, our team will compare how the code base leverages the latest features and capabilities from iOS7 and Android 4.4, KitKat. Syntax relevancy is often a good way to determine how up-to-speed the current development staff is on emerging technologies. We will also note the syntax and relevance of any 3rd party library components used in the app as well.
A note on Android: For various reasons, including the market share of KitKat-equipped devices for your customers, Android 4.4 KitKat may not be the best target platform for your app. If this is the case, we will orient our investigation and backwards compatibility tests accordingly.
Naming conventions: Good class/object/variable naming conventions don’t necessarily imply healthy or unhealthy code, but they do indicate a self-documenting and cohesive development strategy. If standard naming conventions are followed, it’s indicative of a shared code base amongst a group of developers as opposed to a set of disparate, singleton units of code written by individual entities.
Memory Management: Application memory management is the process of allocating memory during your program’s runtime, using it, and freeing it when you are done with it. Our engineers will compare your app’s memory management with established best practices for the mobile platform.
Exception handling: Good exception and error handling is an indication of an application’s health because it shows awareness of issues that may arise in a runtime environment and how to gracefully react to them if they should occur.
Code size/responsibility: Oversized methods are hard to maintain long-term and are an indication of code that is doing too much (making them harder to unit test and diagnose). Our team will note whether or not core classes, methods, and architectural layers are sized manageably. We will explore the responsibility, use, and benefit of any large 3rd party libraries as well.
Model layer construction: The model layer is responsible for encapsulation/persistence of application data. If the app is using Core Data (iOS) or SQLite (Android), our team will ensure that the data model is sufficiently normalized and sensible.
Threading: In this step, our team will determine if multi-threading is leveraged in the application. Specifically, we will determine if all application activity is managed on one thread or if some activity (e.g., the Core Data stack in iOS) is set up on a background thread for concurrent processing.
Localization: Although translating your app for foreign markets may not be a business objective right now, it’s a good coding practice to localize your apps for multiple in case multi-language support becomes an objective in the future. In Android, hard-coded strings signal poor code quality even if there’s no localization. Our team will look for good use of string resources across the applications.
Phase Three: Platform Deployment Analysis
In this phase, our team will determine the applications’ readiness for the Apple App Store or the Google Play store. Due to the technical and visual requirements of this phase, requirements will be split between one iOS or Android engineer and one UX/Designer. This phase includes the following activities:
Test for memory leaks: Memory leaks are blocks of allocated memory that the program no longer references. Leaks waste space by filling up pages of memory with inaccessible data. In addition being an indication of bad coding patterns, if you are developing on the iOS platform, memory leaks will cause an application to be rejected by Apple.
Human Interface Guidelines: in this exercise, our team will compare the front-end components of the applications against Apple’s Human Interface Guidelines and Google’s Android Style Guide. These guidelines describe visual patterns (e.g., hit target size, navigation paradigms) that should be followed across applications in the App and Play Stores. Similarly, failure to follow published guidelines can cause an application to be rejected during review.