Hybrid Mobile Apps in the Real World

Nowadays most people have heard about hybrid mobile app frameworks and their advantages. There are so many of them and each promises everything you dreamed about for a cross-platform mobile applications development. The idea is nice and simple: hosting a web application inside of the user’s smartphone or tablet with the ability to have a single codebase, involve web developers, reduce costs, decrease time-to-market, and so on. However, we can see that most of the mobile applications are still native and platform specific. Why is that? Experienced developers (especially those who had a really hard time working with early hybrid applications) may notice that the real life cross-platform mobile app development process is far from perfect to make it a standard. DSR Corporation team has rich experience in PhoneGap application development and knows all (or almost all) pros and cons of this technology. In this blog we aim to summarize our experience and share the risks that should be considered when using a hybrid mobile app frameworks.

“Like Native” Still Doesn’t Feel Native

After your hybrid application is ready and deployed I bet the first complaint you will get is the performance. The modern day user has zero tolerance for even a slight delay, especially if he or she is expecting to be entertained. Just try to scroll a list in a native iOS application and then in a hybrid one: you will probably not say the hybrid has delays but it feels different and users notice that.

Additionally, if you want to use the same codebase for all platforms, then your application will look the same on all platforms. Sometimes it is good and desirable. Even if it is not, your application will still work fine. But as you may know the UX/UI guidelines are different for each platform and each user base has specific expectations on how apps work on their respective platforms. For example, an iOS user expects a “Back” button everywhere, where Android users may not find the search if you implement it using the iOS style. So when you are implementing the same UI, you are making a compromise or spending extra effort to make it different.

You Can’t Get Away from Debug

If it works on one platform, it does not mean it will work on another. Each hybrid app has its native part and framework development teams work hard to make them work the same way on all platforms so you could relax and concentrate on HTML, CSS, and Javascript. However, even if the framework you picked is “perfect,” each platform is assumed to have its own browser. Moreover, if you extended the native part, for example, by writing your own PhoneGap plugin, you will have to carefully port it to each platform. The situation gets more complicated when dealing with low cost or old devices: each one of them can have its own surprises. In this case you may need to research the Crosswalk pluggable webview (https://crosswalk-project.org/) to make it easier to maintain your app.

As a result, this is actually a normal case for multi-platform development when “write once, run everywhere” turns into “write once, debug everywhere.”

Platform-specific Nuances

In a perfect world a web developer can develop a cross platform mobile app without learning anything else. Meanwhile, using a hybrid framework, please make sure the team is armed with at least the following knowledge:

  • Environment configuration. At the very beginning, you can rely on a cloud build service. But sooner or later, even if you work on something simple, you will need to debug your application to make sure there will be no surprises the day before delivery.
  • Native support. It would be nice to rely on an experienced mobile application developer on your team. And it will be 100% necessary if your hybrid framework does not provide something you need.
  • Offline mode. Make sure you are developing a mobile application, not a mobile website. It will be nice if it works offline or at least provides a clear message that an Internet connection is required.
  • Guidelines. The users will very much appreciate if you meet their expectations. Everyone likes something he or she is used to and that feels natural with how they use their device.
  • Interact with others. Make sure you know and interact with typical platform applications that are used every day. Building good neighbor relationships is a good habit.
  • Deployment and approval. It can be a real pain for those who are doing it for the first time. You may need to read vendor requirements carefully even before you start the development: some rules can change your plans.

Keep it Simple

Please don’t expect too much from the hybrids. If you need something of flawless quality or great performance or exquisite look and feel – hybrid is probably not a good choice. Note that hybrid apps are fragile: the more complex architecture you have, the more effort you need to maintain it, especially if this is about interaction of HTML/Javascript part and the native part.

It’s Alive!

Considering the fact that you are still able to use native tools and controls you may think about combining web controls with native ones. Be careful not to create a Frankenstein: the application complexity can rise so significantly that it will become a nightmare to debug and maintain. First, the native control you used will need to be considered on other platforms (there is no guarantee that it will work the same way). Second, the integration part (between HTML/JS and native) is the “richest” source of bugs: the more complex the design is, the more “fun” you will have. Third, thinking about using native controls is a good signal that you need a native application. Consider your options and make the right choice for your app.

The Apple Dependency

Another risk that you may need to consider is a high dependency on the App Store Review Guidelines. The App Store is dominating the mobile apps market, so Apple can and does dictate its rules. The Review Guidelines change quite often and, although unlikely, it’s possible that hybrid apps can get banned from the App Store at some point in the future.

Now when you are aware of the risks you may wonder if there are any reasons for you to use hybrid applications. There are many of them!

Low Cost and Quick Time to Market

If you have a limited budget and need a mobile application, using a hybrid framework may be a solution. Easier UI development will give you a cost advantage even if you are planning iOS as your only platform. Make sure to keep it simple and that your single codebase can be easily ported to other platforms without significant changes. At the same time, reducing your effort can save you precious time, so you can deploy early and have the app ready before your competitors.

Startups and Explore

If you are planning to develop a serious application that requires a lot of effort for UX/UI you may consider prototyping it first. It will allow you to have better understanding of all application usage aspects and resolve problems early. Certainly, your prototype can be a quickly developed hybrid application you can use to get early adopter feedback and demo the concept.

Web Development Forces

If you or your team are good web developers, then you can use your experience in the mobile apps as well. Choose a hybrid mobile app UI framework you like the most and do the main implementation using your favorite tools. In most cases you will not need to learn a new programming language. At the same time, you will be able to develop for additional platforms improving your web development experience.

Better Than a Website

If you are thinking about developing a mobile website instead of a mobile app, then you should consider the serious advantages the mobile apps have:

  • Sales and distribution. Everyone knows about platform specific application stores that help users find what they want and allow developers to sell and distribute their apps with ease.
  • Usability. Mobile apps are optimized for use on mobile devices and users expect at least the same level of usability. It would be difficult to compete with a mobile application having only a browser application.
  • Works offline. Your users can work with the app even if the Internet connection is lost.
  • Using device capabilities. In contrast to websites, mobile apps can utilize a full set of device capabilities.
  • Popularity. Today it seems like a good habit to create a mobile app to meet user expectations.

Although we at DSR prefer to build native mobile apps because of their performance, seamless user interface, and best user experience, we have rich experience building cross-platform mobile apps as well. The latter can give you a serious advantage, but only if the related risks are considered. This is not a silver bullet, but it can be a powerful weapon on your side, if your project meets the parameters described above.

If you would like to learn more, have a project in mind, or want to share some comments, please connect with us at contact@dsr-company.com.

The Secure Remote Access Challenge for IoT Cloud

The Internet of Things (IoT) often brings us convenience, economy, fun, and security, but it’s also a source of numerous challenges for developers, installers, and maintainers. In this article, we are talking about one facet of the global IoT challenge – secure remote access.

Every small piece of a Smart Home, be it a Thermostat, a Security Sensor, or a Light bulb, has direct, or more often indirect, access to the Internet. Local or near-field security is a very important topic – but its meaning can’t be compared with security of access to the Cloud services responsible for configuring, notification, alarms, and all other things that make our homes smart. Personal computers, smartphones, printers, NAS have network connectivity that lasts a very long time, but we should not forget that compromising some of the small home devices mentioned above would allow an attacker some control over the physical world, which is definitely a different type of risk than associated with a personal computer.

For example, imagine an attacker has access to notifications from the home’s Thermostat. He can’t control the Thermostat, however, he has access to current mode and temperature. And using this harmless data he not only violates the abstract privacy, but most likely also knows the schedule of the house occupants, as well as if someone is home at that particular moment.

The recent research published by Symantec shows the following vulnerabilities are common for almost all Smart Home Solutions.

While passwords, encryption, account enumeration, and supply chain attacks are more or less obvious and are usually related to the user experience or the corresponding standards, attacks and issues on remote access security (including web vulnerabilities, mitm attacks, and firmware tampering) should be mitigated during design and development.

So yes – it’s recommended to have secure access from Smart Home devices or Gateways. And of course there are dozens of solutions suitable and secure, at least at the current technical level. However, sometimes even a security professional asking, “what to secure?” forgets about the “when.”

What percent of devices in the field are manufactured inside a vendor’s own facilities and prototyping factories? It’s hard to know the exact answer without using floating-point operations. And even the best scheme following all standards and guidelines can be compromised during manufacturing. So here’s where the challenge becomes really intriguing.

This leads to the following requirements:

  • Server side validation (e.g., server must be sure that the client is an approved device).
  • Client side validation (e.g., client must be sure it connects with the right server).
  • Client side security materials should not be accessible by the manufacturer.

With server side validation, everything is more or less standardized. The only thing required to add to the common pattern is custom security materials for each client for the purpose of client identification.

From the client side the solution is trickier – tens of thousands of devices are in sleep mode in a warehouse somewhere when it is discovered that the server is compromised, and, as a consequence, they can’t be reprogrammed. This leads to an additional server validation service. It can be, for example, a dedicated OCSP server or some custom solution with only one function – inform the device that the server’s security materials are compromised.

When talking about compromising during manufacturing, there’s another well known, but not so widely used option – updating security materials when the device is installed. It may be manual activation via the web or just an update on first connection.

In summary:

  • All clients should have pre-programmed security materials containing unique ID for each client that should be updated as soon as the device is installed.
  • Server should have validation scheme for each client. Something simple like white list is more than enough.
  • Separate validation service should be implemented to allow clients to at least detect that the server has been compromised.
    • Note that for better security, it may be reasonable to set the lifetime of the security materials used for access of the validation service to a reasonably short value. For example, instead of years usually used for main services, use 20-30 days.

These 3 simple principles make the entire system much more secure and, as a bonus, this scheme can be implemented using open-source software as described below.

Sample Security Solution

Note that the scheme above is just a sample solution; the services can be replaced with some custom implementation or appropriate analogs.

  • Root CA – In Public Key Infrastructure (PKI) acts as Root Certificate Authority – it signs certificates for Manufacturer, OpenVPN server, and OCSP responder. In addition, you should maintain the list of compromised and expired server certificates as part of the Root infrastructure Certificate Revocation List (CRL).
  • openvpn-server.com – machine (or number of machines) that runs OpenVPN server and Application Server.
    • OpenVPN Server handles VPN connections from devices. Optionally, it can check if device ID extracted from the certificate is listed in the known device list. The device list is provided by the Manufacturer and contains IDs of issued devices. This list can be used to control number of devices issued by the Manufacturer.
    • Note: Server always “knows” if the certificate is issued by the Manufacturer or by the Root CA and can replace certificate on the device after the first successful connection.
  • Manufacturer – 3rd party in the PKI acts as an intermediate Certificate Authority – it issues certificates for devices. In addition, Manufacturer should maintain the list of IDs for all issued devices and provide this list back.
  • Field device – runs different applications. Application sends the gathered info to Data Server performing the following steps:
    • establishes tunnel to OpenVPN server using OpenVPN client
    • checks (using request to OCSP server) that OpenVPN server certificate was not revoked
    • sends data using VPN tunnel to Data Server
    • closes VPN tunnel
  • ocsp-server.com – Instance of OCSP Server.
  • OCSP Server – Online Certificate Status Protocol responder. This is the special service that can be used to check if the OpenVPN server certificate was revoked.
    • Note that the OCSP certificate is equally important as the Root CA certificate since it can be used to block all VPN connections. So it is good idea to run the OCSP service on a separate machine where no additional services are running.