Our take on native, shell and mobile web apps

At Shape we aim at building quality mobile apps. Always. Our products should not only be good looking but also provide our partners with solid business cases and our users with both seamless and smooth experiences. In short, we seek excellence, and this is the main reason why we craft native apps.

However, app development is a complex field of technology and there are many aspects to take into account. So we understand why the alternative options to building native apps, i.e. making web or shell apps, might seem attractive from a first glance, as these technologies often appear to be easier and cheaper in terms of development cost and release pace. Therefore, to explain why we prefer the native solution, we will try to map out some of the major differences between building web, shell and native apps.

Mobile web apps
In short, mobile web apps (also sometimes called html5 apps) are based on web technologies such as JavaScript, HTML and CSS. Thereby, merely web knowledge is required, which is widely available. One main advantage is that all devices support standard web technologies so in theory you only need to develop one version of your app to support all mobile devices. In reality that is not always true as there are some differences in the features supported by different mobile browsers. Another advantage (but also disadvantage) is that mobile web apps are not distributed through curated platforms as the iOS App Store and the Google Play Store. This means you don’t need to wait for the app to be reviewed and risk it being rejected, but in return it can be harder for users to find and discover the app. But as mobile web apps are basically web pages for mobile devices, they offer limited possibilities in terms of utilizing the specific software and hardware features of a device. Some functionally, is simply not possible to imitate with a web app. This is due to the fact that a web app does not have direct access to the operating system’s (OS) native APIs. It has to go through the browser, which interfaces with the OS. A native app on the other hand has direct access to the OS’s native APIs. This difference is the main reason that a web app never will deliver the same speed, polish and reliability as a native app. As a consequence mobile web apps are most suitable for prototyping and as a way to circumvent restrictions in the App Store.


  1. The lowest barrier to get started.
  2. Simple apps can sometimes be developed quickly.
  3. Not dependent on the App Store review process.
  4. Very fast deployment is possible.
  5. Will perform on most smartphones.
  6. Unrestricted distribution via the web without anyone censoring content.
  7. Content is automatically indexed by search engines like Google.
  8. Web development skills are widely available.

  1. Hard to implement native app experience, i.e. animations and look and feel.
  2. Hard to deliver good performance.
  3. Doesn’t incorporate all smartphone features, camera, GPS, gyroscope, phone, etc. or features are hard to get working on all devices and operating system versions.
  4. Web apps are generally slower. Especially with bad mobile connections.
  5. It's very hard to make the app work offline.
  6. Still requires work to test and optimize for each smartphone and browser combination.

Shell apps
Shell apps combine the technology of native apps with web technologies. The development of shell apps allows the developer to ditch the web techonologies for critical features and implement those parts using native code to get better performance. For projects bigger than the most trivial case the development time and cost will often be higher than for a similar app developed using native technologies. This is mainly due to the added complexities in the interface between the web and the native world and the lack of good debugging tools for this sort of mixed environment development. Unlike the web solution, shell apps can work offline and to a certain extent they might fulfil users’ expectations to the functions and “feel” of a native app, because they, to a certain degree, can perform like native apps. The use of native technology leaves more room for complex features and the use of web technologies enable some code re-use between platforms. This means that at low to medium complexities (see graph), developing shell apps can require less work than it does to build a native one. However, the performance is still not on par with native apps and, as shown below, if you add complexity, the total cost of developing a shell app might very well higher than developing a truly native app, because the workload increases exponentially as complexity rises.


  1. Most hybrid development tools enable some level of code re-use on several platforms.
  2. In some cases acceptable user experience.
  3. Allows use of most native APIs.
  4. At low complexities it may be cheaper than native development.
  5. Enables more maintainable code through code re-use between platforms.
  6. Distributed via the app stores.
  7. Offline mode is easier to support than pure web apps.
  8. Full app store monetization (in-app purchases, platform-native ads and app premiums).

  1. Users downloading an app from the App Store expect a native experience and often get disappointed with the inferior user experience.
  2. Many features will have worse performace than on native apps.
  3. Updates are distributed through the App Store and have to go through the review process.
  4. Already at modest complexity levels the cost will be the same or more as developing a native app.
  5. Hybrid tools require extra development skills on top of html skills.
  6. The available tools are not on par with those for pure web development or native development.
  7. Publishing iOS apps in the App Store require an Apple review. This also goes for updates.
  8. Requires users’ to actively download and install.
  9. Still needs to stay up-to-date with major platform updates.
  10. Generally not recommended when app performance and user experience are critical components.
  11. Often depending on proprietary 3rd party shell providers. If they disappear your investment may be wasted.

Native apps
As native apps are developed for a particular platform or device, the development is comprehensive if more platforms are to be included. This means the costs can be significant if multiple platforms needs to be supported (for example Android, iPhone, and Windows Phone). Also, native apps are distributed through the App Store and Google Play, which might slow down both the release process and the following updates. Native apps require a well-planned deployment and release strategy as the deployment time (imposed by the App Store review process) is much longer (typically a week) than for web apps. In return, native apps perform better than both web and shell apps both in terms of response time and general user experience. But as opposed to both web and shell, going native also enables developers to make full use of a device’s specific hardware and software features such as camera, GPS and accelerometer. Going Native will still allow the developers to take advantage of web technologies for what it is best for; such as displaying rich content with inline media. User experience is key in the current market. Since users are very selective, an app that does not act like expected or that does not “feel right” will be forgotten or even deleted from a device as quickly as it got there. Native features and design polish are the details that make an app feel like an app, and not like a website.


  1. Most popular among the users due to superior user experience (feels better).
  2. Fastest and most responsive option.
  3. Accommodates users’ expectations in terms of features and functions.
  4. Benefits from the App Store brands; ‘Available on the Apple App Store’, ‘Android app on Google Play’, etc.
  5. Enables real push notifications, i.e. contextual user activation.
  6. Can easily take advantage of smartphone features such as camera, GPS, accelerometer, etc.
  7. Does not require an Internet connection to work, i.e. provide value even when offline.
  8. Full monetization (in-app purchases, platform-native ads and app premiums).

  1. OS-specific; usually no code re-use between iOS, Android and Windows Mobile, i.e. an app for each platform is needed.
  2. Entry barriers and initial costs are relatively high.
  3. Development requires highly specialized coding skills with extensive knowledge of the native frameworks (ie. Cocoa Touch, Android SDK, and Windows Phone SDK) and programming languages (Objective-C, Swift, Java, and C#).
  4. Publishing iOS apps in the App Store require an Apple review. This also goes for updates.
  5. Needs to stay up-to-date with major platform updates.

To sum up: The more complex functionality one plan to add, the stronger the argument is to go native. And since the app projects we engage in are often ambitious and innovative and closely connected to our clients’ business strategies, it means that the degree of complexity is equally high. Web or shell apps might be the right choice for some special use cases and also for prototypes and hobby projects. But for almost any serious use case, native apps are the only technology we can recommend in order to get the superior user experience and thus maximize the chances of reaching business goals. Technology leaders such as Facebook and LinkedIn, who have enormous development budgets and hundreds of skilled developers inhouse, have realized that web or shell apps are not the ways to go. They tried and failed; simply concluding that the effort of cross platform technologies does not pay off. That being said it is always important to remember that the world is not only black or white, and the right choice of technology will depend on many factors. For example, the new RedBull.com app › uses web technologies to render stories. This choice allowed us to more easily support a wide range of content types without compromising the native feel of the app.


19 Aug 2015