Everyone knows that consumer devices are now in the hands of everyone from toddlers to your grandparents, and your information when designed for mobile, can reach more individuals than ever before. You may know that you need a mobile strategy, but you might not be sure which strategy (web, hybrid, or native) to pursue.
This post is intended to help you choose between web, hybrid, and native strategies when targeting Android, iOS, and Windows Phone consumer mobile devices. This post doesn’t cover solutions that target ruggedized hardware (laptops or non-consumer devices). For information on using ruggedized hardware with Windows Mobile, see Esri’s Windows Mobile home page. In a future post we will look into mobile workflow scenarios for targeting Android, iOS, and Windows Phone.
A few key comparison points
The most important goal is to deliver the best experience and functionality for the audience of your mobile application. Below are questions to ask yourself to help you achieve this.
- How widespread of a mobile audience must you reach?
- Do you know what regions of the world you are trying to target? Do you know what devices they’ll have?
- Who is the target audience (internal app or consumer public) and what functionality (mapping, advanced analysis, and so on) is required to support the application?
- Are your users sometimes disconnected and need the app to run offline?
- What skill set does your current development team possess?
- What data and web services are required to support the application?
- Who is the steward of the data behind the web services? Do you have access to the data if necessary (for example, ability to create offline data sources)?
- Are there requirements for device integration, such as use of the device’s GPS, compass, media, calendar, contacts, text messaging (SMS), notifications, etc?
Strategies summarized
- Native — The native strategy offers the best device integration and the most out-of-the-box functionality for offline workflows, but it requires native development skill sets. You can use Esri’s Runtime SDKs (Android, iOS, and Windows Phone) to create native apps.
- Hybrid — Hybrid strategies use a mixture of native components and web app content (HTML, JavaScript and CSS) to build native applications and there are many different ways that this can be achieved. The simplest approach is to embed a web control into a native app and load web content, more advanced approaches include using frameworks (for example, PhoneGap or Appcelerator Titanium) which allow richer integration with the native platform. You can use Esri’s JavaScript API and Esri’s Runtime SDKs in hybrid strategies. The Wikipedia topic on hybrids might help you better understand hybrid strategies. These articles may also help provide context: Inside Facebook’s mobile strategy by Kurt Wagner, Mashable, and Mobile: Native Apps, Web Apps, and Hybrid Apps, by Raluca Budiu of Nielsen Norman Group.
- Web — A web strategy is where HTML, JavaScript, and CSS is hosted on a web server and delivered to the user’s device using its mobile web browser. This strategy is best if you don’t know which devices your users will have and you need to reach a wide audience. You can use Esri’s JavaScript API in a web strategy.
The table below provides a detailed look at these and additional comparison points.
A closer look at mobile strategy differences (generic)
| Consideration | Web strategy | Hybrid strategy | Native strategy | Notes |
| Understanding your users and which devices they prefer | Target the device’s browser (a single hosted web app used by all) | Target each specific device OS, but leverage existing web content and native APIs (an app for each device OS) | Target each specific device OS, and deliver the best native experience (an app for each device OS) | Device popularity varies geographically (North America, Europe, Asia) |
| What skill sets do your developers have? | Requires HTML, JavaScript, and CSS | Requires HTML, JavaScript, and CSS, and knowledge about compiling the hybrid framework | Requires skills developing on each native platform (for example, Objective-C for iOS, Java for Android, and .NET for Windows Phone) | |
| Do you want to distribute the app through a store (App Store and/or Google Play)? | Distribution through a store is not supported | Distribution through a store is supported | Distribution through a store is supported | |
| Access to device utilities | Limited to HTML5 mobile features | Limited based on the development approach, and frameworks used | Access to all device utilities (GPS, compass, calendar, media, contacts, camera, and so on) | Some hybrid strategies (frameworks) provide wrapper calls to underlying native API technology |
| Maintenance on multiple devices | When you update your app, it is immediately available to all devices | When you update your app, you must update it for each device type | When you update your app, you must update it for each device type |
A closer look at mobile strategy differences (ArcGIS)
| Consideration | Web strategy | Hybrid strategy | Native strategy | Notes |
| Will users need to use the app and data offline? | Some local storage is possible with HTML5, offline GIS also possible but involved** | Offline app use is possible through the hybrid framework’s local storage mechanism. Offline GIS also possible but involved** | Offline app use is built into the native platforms. Offline GIS possible allowing for offline map viewing, editing with sync, geocoding, routing, and analysis*** | Hybrid offline workflows using PhoneGap or Titanium are not straightforward and simple as compared to building native apps |
| Routing and geocoding | Online only* | Online only* | Online and offline are supported*** Requires ArcGIS Desktop to author offline data sources | |
| GeoEnrichment | Online only* | Online only* | Online only** | GeoEnrichment lets you add a variety of demographic and landscape variables |
| Analysis (geometry operations) | Online only* | Online only* | Supported online** and offline through local analysis*** | Operations such as clip, buffer, and intersect. Editing workflows such as simplify, densify, union, merge, split, and so on |
| Model-based analysis (geoprocessing) | Online only* | Online only* | Supported online***, offline also available on Windows and Linux*** | Build models in ArcGIS Desktop, then provide mobile clients analysis through geoprocessing services |
| Geometric network tracing | Online only* | Online only* | Supported online***, offline also available on Windows and Linux*** | Supported through model-based analysis (geoprocessing service) Example: valve isolation trace. |
| Advanced cartography and symbology | Online only* | Online only* | Supported online and offline*** | Includes support for rotation, offset, geodesic symbols, and military symbology, such as 2525C and APP-6B |
| Display/animate large numbers of features | Not recommended | Not recommended | Once you have the features, you can animate their graphics and maintain smooth/fast map navigation*** | A native app can support millions of features. For web and hybrid, the number of features you can have before performance degrades depends on several factors, such as the browser, but generally 10,000 – 100,000 is the maximum |
| Local file based data (shapefiles and imagery) offline | Not available | Not available | Offline and local access to shapefiles and imagery is built into the native platforms.*** | Planned for this summer |
* Using ArcGIS API for JavaScript out of the box API components
** Using ArcGIS REST API and developer has to send requests and process responses
*** Using ArcGIS Runtime SDKs out of the box API components
ArcGIS Platform
No matter which strategy (web, hybrid, or native) you choose, the power of the ArcGIS Platform is what drives the web services used by the Esri APIs mentioned. ArcGIS API for JavaScript and the ArcGIS Runtime SDKs deliver advanced mapping and visualization, web based editing, powerful analysis capabilities, location analytics, geocoding, directions and routing, and geoenrichment (via demographic and landscape variables). Developers can also extend the ArcGIS Platform by writing custom web services through developer server object extensions to perform custom business logic and advertise that functionality to mobile client applications. For more information visit the Esri developer’s site and the ArcGIS REST API documentation.
The software development patterns are very similar at a high level regardless of which API you choose. As you can see there are many decisions involved when choosing your mobile strategy. Hopefully this information will make the process more straightforward and save you time when making decisions about your next mobile application.