Picture this: You’ve built an exciting new mobile app and you’re now planning on shipping to market. When it’s released, it will upgrade the customer experience, reduce pressure on the CS team, and reduce costs. So far, so good.
But here’s the challenge: Since the app processes sensitive customer and financial data, security is non-negotiable. But time is of the essence. Every day you spend implementing security controls is another day you can’t ship to market.
In these situations, there are several options on the table. Generally, these fall into three categories: Compiler, wrapper, and hybrid. So what are the relative pros and cons of each approach? And which is the right option for your mobile app?
Here, we take an objective look through the options and discuss the strengths and weaknesses of each approach.
Compiler-based security focuses on integrating security measures directly into the app’s source code or an intermediate representation, during the compilation process. This means security is integrated organically into the code during the build process, rather than being added retroactively when the app is complete.
This process involves two major stages:
This makes it much more difficult to reverse engineer and tamper with the app, since key security controls are dispersed throughout the code in a complex, entangled manner. Therefore, it’s incredibly difficult for hackers to isolate and disable security features. Here are some of the pros and cons of this approach:
Instead of directly modifying the app's source code, wrapper-based security creates a secure container for the app that can enforce several security policies and controls. Generally, these are stored in a library that’s separate from the app’s source code. This means security controls can be applied after the app has been architected, without needing significant changes.
This approach offers several potential security features, including encryption, jailbreak detection, and runtime protection. This helps protect the app from issues like tampering, reverse engineering attempts, and more.
Here are the main strengths and weaknesses of this approach:
There are clearly several pros and cons to both wrapper and compiler-based security. Compilers generally offer better security and customizability, but the time and cost taken to implement them can often be prohibitive. While wrappers can offer a wide range of effective security protections, the separation from the codebase can make them easier for hackers to disable.
But in both cases, the devil is in the details. In practice, a compiler-approach can easily create a worse security posture if the team tries to cut corners in the lengthy and complex development process. And while some wrappers are straightforward to disable, it depends how the security wrapper is architected and how it interacts with the codebase. In short, there are no easy answers.
Yet regardless of their relative strengths and weaknesses, they’re not the only options available. That’s where the hybrid approach comes in, attempting to combine the best of both the compiler and wrapper-based approaches.
Fundamentally, a hybrid model has a lot of similarities with the pure-wrapper approach. Generally, these products can be added to an existing app post-compile. They can also offer a range of security features ‘out-of-the-box’, requiring minimal coding and security expertise for the development team.
But a hybrid model also includes several additional security features that aim to either reduce or eliminate the drawbacks of the pure-wrapper model. These include:
Read more: Obfuscation explained: A comprehensive guide to code protection techniques
The hybrid approach introduces a small degree of extra complexity, when compared with the classic wrapper model. But in return, it offers a much more robust security posture, while still eliminating the excessive cost and complexity of the compiler-based approach.
Here’s how the three models shape up across eight main categories:
Compiler | Wrapper | Hybrid | |
Integration |
Requires access to and significant modifications of the source code | Simple integration with a wide range of codebases, requiring minimal changes | Flexibility of approach allows for a range of integration scenarios on a spectrum between the compiler and wrapper-based options |
Cost |
Higher initial development costs due to extensive modifications | Lower upfront costs due to significantly reduced development effort | Balanced costs due to less invasive manual work upfront |
Impact on performance |
Higher initial development costs due to extensive modifications | Generally, a lower impact on performance than a compiler-based approach | May impact performance due to multiple security layers |
Defense |
Robust protection against reverse engineering and tampering | Provides consistent security features across different apps, but can be easier for hackers to disable | Offers the best balance of security and low cost, integrating the security wrapper into the codebase to make it more difficult to disable |
Customization |
Allows for fine-grained control over security measures | Limited customization options for specific security needs | Enables customization through compiler-based modifications and wrapper configuration |
Maintainability |
Security protections need updating every time the app’s code is changed, patched, or, altered | Minimal changes are required after updates, since the security layer is separate from the codebase | Requires more effort to maintain and update than a wrapper-based approach, but generally less than a compiler |
Flexibility |
Limited flexibility as it requires access to the source code | Flexible in applying security to existing apps without major changes | Combines the flexibility of wrappers with the deep integration of compiler-based security |
Expertise required |
Good security requires a developer with expert knowledge of the app, as well as knowing how to build overlapping protections in a way that avoids significant impact on performance | Limited security expertise required from the app development team | Offers a good balance, as developers can focus on protecting the app’s code while knowing the security layer is already secure |
Read more: 10 things to consider when comparing mobile application security solutions
When it comes to wrapper, hybrid, and compiler approaches, there are no straightforward answers. If the security requirements of your app are relatively light, there’s a good chance a classic wrapper will be the best option for you. But if you need high security controls and a particularly customized approach, the compiler option may be better–despite the extra resources it may require.
But for many businesses, security vs. time and resources will always be a balancing act. In this case, the hybrid model is often the best choice on the table, because it combines a range of effective security controls with a lightweight approach and relatively swift deployment. This is the best way to get a robust security posture without excessive time or costs.