- Mobile Security
- Hybrid versus Native Mobile App Development: Methodologies, Risks and Tools
As our focus changes from content on the web to content on mobile, our mobile devices play an increasingly vital role in the way we communicate, consume content, conduct business and more. For organizations and businesses in every vertical, mobile applications are no longer an option, but a requirement in order to stay ahead of the curve and relevant with their customers. Read on to learn about hybrid versus native mobile development when it comes to methodologies, risks and tools.
This blog post is a summary of the webinar “Hybrid vs Native Mobile Development: Methodologies, Risks and Tools” by IT Researcher, Developer, Software Team Leader Daniela da Cruz, PhD. A full recording of her presentation is available on demand here.
The first things to consider when building a mobile application are the habits and behavior of your target audience. Once you understand how will they interact with your business and the goods, or services, being offered in your application, you will be able to build an application which lets you manage your business efficiently through mobile devices.
Now that you’ve established that you need to build a mobile application, where do you start? In order to successfully build, launch and maintain a mobile app that matches your product, or service, to your customers’ businesses needs there are a few important factors to take into consideration before your break ground on your mobile strategy. These factors include determining the level of development skills possessed by your team (if you have one), understanding what types of device functionality are required as well as the importance of security, offline capability and interoperability.
In many cases, there is no “perfect” choice in terms of development methodology, however planning ahead when it comes to your development path will help you determine the right way to build your application.
Native applications are built using the development tools, and language, that is specific to the mobile operating system such as iOS, Android and, to a lesser extent, Windows Mobile.
Hybrid applications are constructed of HTML5 embedded in a native container and the best, and worst, elements of hybrid and native design come together to form the application. Hybrid mobile development can be broken down into two distinct approaches:
The choice between these two methodologies has been a cause for much debate in recent years amongst developers, and businesses alike, as both offer advantages and disadvantages.
Native apps are smartphone and tablet applications developed precisely for a specific mobile operating system. Developers building applications for iPhone will code in Objective C, or Swift, using X-code while Android developers will use Android studio and code in Java, although Kotlin is becoming quite popular.
Apps developed using a native methodology have a much better user experience (UX) as they perform faster and are able to render data and graphics at high speeds which is a major concern for developers who create games, or photo editing apps which depend on complicated algorithms. Adding to the high quality of user experience, apps developed specifically for Android, or iOS, perfectly match the platform specific user interface (UI) standards that their users are used to. This could include, on Android, the use of material design and a physical, or omnipresent, “back button” or the “swipe-heavy” iOS navigation that users are familiar with. While these may seem like small points, the way we navigate on our mobile devices, often for hours each day, is something that is second nature to most of us and encountering a navigation path that doesn’t flow as we are used to can be frustrating.
Functionality also is a major pro for native mobile development as both Apple and Android have core features within their operating system such as the camera, contacts, microphone, calendar etc.) which are easily accessible through native development while limited access is given to hybrid apps.
Lastly, for an application to succeed, it needs exposure, and on both Google Play and the App Store, the best way to get exposure is by getting featured, or showcased as an “Editor’s Choice.” Getting featured can lead to 1,000’s of downloads per day, however, it usually depends on utilizing the latest OS features released by each platform, something dependent on native development.
While it’s easy to see the advantages of native development, it does, however, come with its drawbacks as well. First of all, development is harder when it comes to native applications as developers need to be fluent in Objective-C, Swift, Kotlin and other highly focused languages. Another roadblock facing developers who want to branch into the mobile languages is the fact that often the resources available to learn these specific languages are either too theoretical, or too practical, and it can be difficult to find resources with a good balance.
Additionally, platform specific code written for either operating system needs to be rewritten from iOS to Android and vice versa due to the divergent languages and API processes. Finally, the cost needed to maintain two distinct development teams can be out of the reach of many organizations who find themselves in need of a mobile application.
Development in Cordova is similar to the development needed to build a web page as html, CSS and JS all combine to create a webview that is wrapped in Cordova.
Xamarin has a C#-shared codebase which developers can use to write native Android, iOS, and Windows apps with native user interfaces and share code across multiple platforms focused on C#. Xamarin works in a similar way to Cordova.
Hybrid applications are not only faster, and simpler to develop, but they’re also much easier to maintain as you’re only dealing with one codebase, rather than multiple platform specific ones. Once you’ve finished developing your hybrid application, you can add additional platforms with one line of code. The simplicity in development for hybrid applications comes from the fact that developers are not required to learn additional languages in order to develop platform specific versions of the same application. Additionally, because hybrid applications depend on one language for all platforms, once development is finished, hybrid applications are ready for use on both platforms.
While being faster, and simpler to develop than native applications, hybrid applications lack the “genuine” platform specific native user experience that native applications deliver. Developers using the hybrid methodology also face losing access to built it capability and core device features such as the camera, GPS, calendar and more, although some additional plugins. Lastly, hybrid apps lag behind native applications when it comes to performance and on particularly demanding graphic rich apps such as games. Also, due to the fact that one application is being adapted to two operating systems, users will be able to sense a difference in their interaction with your application compared to native apps.
Now that we’ve established the advantages and disadvantages with each methodology, what further questions are needed to understand which development methodology is right for your application?
If you will need access to core device, and platform, features native is definitely the answer for you. For hybrid developers, depending on which framework is used, access to native features could be limited, or even non-existent.
Time-to-market will ultimately depend on your organization’s resources and your applications, however, if time is a factor, hybrid development will allow you launch on more platforms in a shorter period of time at the same time.
Native development, as you are probably well aware of by now, is quite budget dependent. At the very minimum, your existing developers will need to train and learn new languages in order to effectively build two versions for two platforms, and, in most cases, you may need to allocate a budget to hire two separate development teams. If you’re lacking the budget, or time needed, to either hire, or train, your developers to code specifically for iOS and Android, you will want to develop your application using a hybrid methodology.
If you plan on updating your application frequently, you will also want to choose hybrid as your methodology of choice. Unless you are making an integral change to your app, or to its functionality, one line of code will push that update immediately to your application on each platform. Frequent updates is one of the reasons why many banking and major new applications choose hybrid as their development methodology.
While this may seem like an obvious question, it’s an important one. Native applications will trump hybrid ones when it comes to providing the end user with a high quality of user experience that is fast and what they are used to in terms of how they are used to interacting with their phones. If providing your users with the best possible experience, native development is definitely your choice. While experienced front end developers are able to bring the hybrid UX close to a native experience, it will never match a completely native experience.
Just like most modern web applications, mobile applications bring big value to our lives, but also can introduce in big risks. When considering which development methodology best suits your needs, security should also play a role in your decision making.
Native applications are considered more secure than hybrid apps for numerous reasons which include the fact that they are able to leverage platform-specific built-in security features. The fact that hybrid apps are dependent on webviews means that they are prone to injection attacks when using certain API’s. Various techniques, tools and third party libraries that are specific to each platform have been made available to minimize the attack surface.
How can attackers get unauthorized access to mobile devices?
When it comes to the security of native applications, vulnerabilities stand almost the same for any platform although the exploitation techniques and tools are different. On Android, native apps could be storing sensitive data in the phone’s local data storage which attackers could potentially exploit by putting a shell on the device, or by simply making a backup of the application.
On iOS, hackers are able to operate through a similar vector if the phone is jailbroken.
Hybrid apps are not exempt to vulnerabilities either, especially if they contain poorly written code.
Will a hybrid approach affect the release of the app in the official application stores?
Yes, although both Apple and Google have released a list of requirements that your application should obey in order to be published, most of the developers that develop hybrid apps, find themselves stuck on the approval part of publishing because they got rejections that are needed to be corrected and resubmitted.
On Android, native apps usually take around 24 hours to be approved, while hybrid applications while hybrid apps can take around 3 days to even a week.
With the inclusion of WebGL since iOS 8, what are the potential performance and security issues for both mobile websites and hybrid applications that are considering using WebGL?
The concerns are the same as when other features are used, if you use webGL, you need to be aware of the web attacks that your application can suffer, however, these are still not categorized enough.
Which of the hybrid app platforms, are most, or least, secure against reverse engineering and application modification?
Web-based hybrid apps are the least secure, and can be as vulnerable as websites, if you’re not careful while writing code, especially concerning where the data will be stored within the application. If you are using Cordova for development, you should consider your application insecure, although there are plugins which can help provide protection for your application.
Is it possible to scan applications built with Cordova using Checkmarx?
Yes. Checkmarx scans specifically for the OWASP top 10 mobile threats which will help you understand which categories have the most vulnerabilities in your code. Checkmarx scans also provide dedicated reports for mobile applications.
In your opinion how well do frameworks like Ionic, that offer a very close match to a native application’s appearance and behavior, compare to native with regards to look and feel?
Ionic is coming close to Titanium which offers some of the closest to an actual native look and feel. So close, in fact, that some users will not even notice that they’re in a hybrid application. With a really well designed Ionic, or Titanium, application, even Cordova, you will be able to get close to the look and feel of an actual native application, although there will always be a small gap in the UI/UX.
What are some of the good tools to test the mobile security according to OWASP?
While there are open source solutions which will help test your mobile security, these solutions are usually focused on specific attacks rather scanning for a general security overview. Checkmarx scans all the 20 programming languages, and their most common frameworks, for security, quality and compliance issues and will give you the best insight into your application’s security posture.
What is the difference between M4 (Insecure Authentication) and M6 (Insecure Authorization)?
While these two threats on the OWASP Project Mobile Top 10 may sound similar, they are actually different. M4 (Insecure Authentication) is usually related to the end user (bad session) management, such as when you fail to identify the user when it’s required.
M6 (Insecure Authorization) relates to failures in authorization. Authorization decisions in the client side (forced browsing) which is different from user related authentication.
One threat is related to bad session management/bad session management and the other captures failures in authorization
To watch the full webinar “Hybrid vs Native Mobile Development: Methodologies, Risks and Tools” click here.
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.