What the difference between native apps and mobile web apps? A lot. Is one better than the other?

Sometimes, and we’re going to give you three questions to ask your client, developer, or project manager to determine if you need to go native. We’ve helped a lot of people and companies choose the best solution for them, and these are the three most common questions we ask.

Are you using device hardware?

Some of the best uses of your smartphone is taking advantage of the powerful hardware in there. Take pictures with your camera, get directions with your GPS, and play a racing game with the accelerometer.

If you’re using the device’s hardware, you’ll want to go native. Native apps have direct and immediate access to all of these useful components. Web apps have limited access and limited support of these functions. It is possible for a web app to access GPS or the camera, but there are security hurdles to make sure the user has that access allowed and enabled. Each browser handles these functions differently, so you’ll have to program and test them all.

Here are some of the most common hardware uses:

• Tracking GPS location
• Bluetooth communication (device to device)
• Taking pictures
• Recording audio, video
• Intensive computing (image filters, local data processing)
• Accelerometer and gyroscope tracking (racing games)

Are you storing data locally or need to work offline?

What happens if the user loses internet while using your app? With web apps, when you lose access to the web, you lose access to your apps. With native apps, you can just plan for offline operation; where the user can continue working locally and then resync any data when internet access is later available.

Native apps can be installed pre-bundled with any media that is needed. For example, if there are large images displayed or instructional videos provided, a mobile web app will have to redownload those files each time. That can add a significant amount of wait time, and users are not patient. Plus it adds overhead to your system. If users are frequently downloading large files from your servers you’ll pay more for hosting. A native app can come with these files built-in, and immediately displayable to the user; even when offline.

Common offline content:

• Large media (videos, HD images)
• Local cache
• Offline data backup
• Sensitive data

Are you going cross-platform?

If you’re planning for cross-platform, and it’s essential for your project be enabled on iOS, Android, Windows Mobile, and BlackBerry, then a web app may be more cost effective.

Here, the benefit of the web is that the “app” is basically a website that is accessed in the browser. Every operating system has a browser, therefore your same app will be available on each. This is compared to native, where you need to rebuild the app for each operating system. When budgets are limited and cross-platform is a requirement, we suggest web apps.

There is another option in this case, multi-compile hybrid apps, although we don’t recommend them. Multi-compile frameworks are great in theory, but in practice they are less reliable and produce lower quality. It can save you some money in development but often costs you in performance, bugs, and functionality.

Release and update cycles

How quickly does the app need to be released and how often will updates be made? Native apps are software packages, and these packages must be delivered and installed on the user’s device. Therefore you need to consider the time it takes to push out updates, and that users may not always have the most up-to-date version. This is being mitigated with automatically updating apps, yet not all apps support this and users can choose to disable this feature.

Next, you’ll need to plan for Apple’s app review process. When you submit an app to Apple, they actually run and test your app. They test it for usability, check that it follows their guidelines, and make sure it doesn’t crash. This ensures the quality of the apps, but this review process can take up to 10 days. The same happens for app updates.

The flipside with web apps, is that every time you access the website you are seeing the most up-to-date version. Releases are instant and updates are not a concern.

Software delivery has come a long way since mailing CDs back in the day, but keep these points in mind. If release schedules are important, you’ll need to plan for these timelines or consider web apps.

The Final Say

Native apps are for quality and reliability, web apps are for convenience. We usually advocate for native development, but web apps have their uses and we utilize them when it makes sense. When you’re planning your project, use these questions to guide your decision. If there are other variables or concerns, or you’d like to talk through the technology, then contact us at hello@jackrabbitmobile.com and we can help.

LinkedIn goes native: http://venturebeat.com/2013/04/17/linkedin-mobile-web-breakup/

Facebook goes native: http://www.theverge.com/2012/8/23/3262782/facebook-for-ios-native-app

People spend more time in native apps: http://blog.flurry.com/bid/95723/Flurry-Five-Year-Report-It-s-an-App-World-The-Web-Just-Lives-in-It

Develop the Right App by Working with Jackrabbit Mobile

At Jackrabbit Mobile, we consider all the factors that go into creating the app you want and your customers want to download. From production design to development, our team will develop an app that builds your brand and helps grow your business.

Contact Jackrabbit Mobile to turn your idea into a reality!