The moment you consider investing in a mobile app, you’re immediately faced with a barrage of terminology. What’s the difference between iOS and Android? What are native, hybrid and web apps? More importantly, which is most appropriate for you and your app?
As it stands, most mobile devices use one of the two dominant operating systems: Google-developed Android (48.3%) and the Apple-developed iOS (41%).
The difference between these operating systems and their related devices isn’t just aesthetic: Just as your MacBook won’t run a Windows application, an Android phone can’t run an app built for iPhone — in most cases at least.
Native apps are what typically springs to mind when you think of an app. You download them from the App Store or Google Play, they sit within your device’s applications and you launch them by tapping their icon.
Developing Native Apps:
What distinguishes native apps from the alternatives mentioned is that they are designed and coded for a specific kind of device. For instance, iPhone apps are written in Objective-C, Android apps in Java, etc.
Each mobile platform offers developers their own development tools, interface elements and standardised SDK. This should enable any professional developer to develop a native app relatively easily.
There are a number of advantages to writing apps in this way:
They offer the fastest, most reliable and most responsive experience to users.
They can tap into the wider functionality of the device; including the camera, microphone, compass, accelerometer and swipe gestures.
Publishers can make use of push-notifications, alerting users every time a new piece of content is published or when their attention is required. This is a key method of engagement. You get the opportunity to continually bring your audience back for more.
Users spend time on apps. The popularity of apps has increased enormously and is continuing to rise.
It’s not just about access to core device capabilities though, native apps, when well designed, respect the design patterns and standards of each platform. It goes beyond a left-aligned header on Android vs a center-aligned header on iOS, there’s hundreds of small differences in the design of user interactions on each platform.
Taking them all into account means designing apps that are intuitive to use and play well with the rest of that platform’s ecosystem. Overall, going for native apps helps you create apps that are designed to delight your users.
The main downside of a native app is that it will not work with other kinds of devices. If you write an app in Objective-C for iOS, it’s not going to run on Android without being completely re-written in Java.
When building for multiple platforms, developing a native app therefore can be quite expensive (when done from scratch), as it will require you to build and maintain multiple, separate versions of your app. It’s also common for developers to specialise in one platform, so often you’ll have to find different coders for each platform you want your app to be available for.
At the other end of the scale are mobile-optimised web apps.
If you’ve ever seen the ‘mobile version’ of a site, that’s what we’re talking about. An “app” like this loads within a mobile browser, like Safari or Chrome, like every other website. Your audience doesn’t have to install a web app.
They don’t need to have available space on their devices.
Web apps are sometimes designed to look and behave like apps and are in general ideal when the purpose is simply to make content or functionality available on mobile, but an app is either not a good fit or too expensive.
There are web app “evangelists” out there that are adamant that web apps are equal to, or even better than native apps. They argue flexibility in terms of cost and functionality. There is no dependence on having a certain type of hardware either.
Web apps are limited in what they can do effectively in terms of features and they will generally always require an Internet connection to work. They are slower and less intuitive. Web apps are designed once for every platform and therefore won’t look or behave like a real app on any of them.
If you use a web app, be warned that they are also more difficult to build a loyal user-base from. Unless the reader saves it as a bookmark, users won’t have the app’s icon on their home screen as a constant reminder. As a developer or publisher, you can’t send them notifications to bring them back to your content. It’s difficult to engage with your audience.
Furthermore, with a web app, you’re missing out on an important source of downloads/traffic. Whilst native and hybrid apps appear on the App Store and Google Play, web apps won’t. With millions of searches every day on these stores, the potential to get your app discovered is real.
Somewhere between native and web apps you’ll find hybrid apps. They are usually quicker to build (and thus cheaper) than native apps, but a step-up from what you can expect out of browser-based web apps. Is the hybrid app the best of both worlds?
For native apps, instead only native code is used. The advantage of this approach is obvious: only a portion of native code has to be re-written to make the app work on the different kinds of devices available.
An advantage that hybrid apps have over native is that it’s faster and easier to develop. It’s also easier to maintain and you can change platforms. The app itself will not be as fast as a native app as it still depends on the browser speed.
Getting your hybrid app to run appropriately on each platform generally takes substantial work. In some situations, the total cost might become comparable to that of fully native apps, rendering the cost benefits negligible. It all depends on how close you want to get to the “native user experience” or how simple your app is.
Still, there’s one big advantage in hybrid apps. Being built on one single base, you can add functionality and have multiple versions of the app all benefit from it. On the contrary, with native apps, for every new functionality you want to introduce, the feature will have to be replicated on each platform.
There’s a big caveat here: if you’re building an app for an existing site or you have a mobile web app ready that does exactly what your app should do, but only misses what a native app generally provides (app store presence, push notifications, home screen icon, offline use), then turning your site or web app into a native app can be both quick and economical.
Not only you won’t have to manage two platforms (iOS/Android) separately, you’ll have a single web app to manage that covers the mobile web and the two major mobile platforms with your apps. This is what we built our latest MobiLoud Canvas platform for!
Mobile website is a specific website designed for the screen on a smartphone. It uses a separate domain name (like m.domain.com or hosted on a different website domain altogether.)
Best practices for mobile sites were choosing just the pages that are of the utmost importance for users that are on the go instead of adding all web pages you have on your desktop site.
Because a mobile site is built to specifically fit for a mobile browser, the user does not have to squint or stretch the screen to see exactly what they are looking for (which if you have ever had to do this, you know how super frustrating this can be!).
A mobile website is also built to only have functionality that is visible on a mobile device (like not displaying Flash banner ads, etc)
With a mobile site, if you build it once, you do not need to build it separately for the different types device manufacturers. As you read more about Mobile apps, this is something you need to do to be compatible across different mobile phone carriers.
A mobile app is only available for download and use on a mobile device like a smartphone or tablet. They are downloaded and installed on the mobile device instead of being services within a web browser. The benefit to this is a person does not have to have internet access to use the app. Sometimes referred to as a native mobile app, they are used for all sorts of things: as an easy to use function of a companion desktop website, gaming, personalized reporting, etc.
To download the app, users visit device specific portals such as Android Market, Blackberry App World or Apple’s App Store in order to locate and download apps for that specific operating system. The mobile app can be paid for or free for download.
The benefit to an app is you can use certain features only available on a phone, like the mobile device’s camera and GPS. In addition, you can create push notifications, SMS, reminders and other nifty things that are only available on your mobile device.
Here is a quick summary of mobile sites, mobile apps and responsive designs:
Mobile Sites: Developed specifically for a mobile device. Uses big buttons, does not have any non-compatible features like flash, can’t be deleted, easy to create, can be housed as a sub-domain off of your own website; When best to be used: As a quick fix to get mobile-friendly if you do not have an initial budget to redesign your website as a responsive design. Negative: need to create a separate site for this; need to develop new links for the separate sub-domain; may need to change when the mobile device size changes; not all pages would be mobile friendly if you picked and chose which pages were to go on the mobile site.
Mobile Apps: Applications that are downloaded and installed on a mobile device – perfect for gaming, personalization and when you want something unique that uses your phone’s functionality like the camera or GPS. Negative: not accessed via the internet and can be deleted on a device. A separate app needs to be developed for the different devices so it can get very costly.
Responsive Websites: “One-website-fits-all” percentage based table site that can adapt to be user friendly on a multitude of different devices and screen sizes. Pro: can adapt with the changing times; do not need multiple websites for the different devices; all links go to one site.