An app built on web technology still has to pass Apple's own review to reach iPhone users, and an annual developer fee is due before any app is listed. Whether such an app holds up depends less on the framework than on how much of it behaves like a native app: notifications, device features such as the camera, and the way it responds to system links. This article sets out what the platform owner charges and where web-based approaches fall short of native ones.
Apple controls the gate
On iOS, the App Store is the only way for developers to offer apps to users of Apple devices. Apps downloaded from other sources do not work, or at least not as well.
Developers propose their apps, and Apple decides whether to include them in the store. Apps that are included are digitally signed by Apple. For a team building on web technology, the store is the only route to iPhone users.
What it costs to be listed
To take part in the Apple Developer Program, a developer must conclude a Developer Program License Agreement with Apple and pay an annual fee. That agreement is what grants the licences for the iOS software.
Revenue carries its own cost. As a rule, Apple deducts a 30% commission on payments made through its in-app purchase system, and 15% when the period of use of the product is extended. Developers selling paid apps must make sure users pay through that system.
Web, hybrid and wrapped apps
A plain web app gives up some ground compared with a native one. It cannot handle an Android Intent, and its notification support is weaker. In return it works across operating systems and avoids app-store bottlenecks.
Some features rule out the pure web route. Apps that need location, notifications, mapping or the camera must be developed using hybrid or native architectures. An analyst forecast predicted that by 2016 more than half of the mobile apps deployed would be hybrid.
Basecamp for iPhone shows how a hybrid split can work in practice. All content inside projects is rendered by web views, and everything else is native. The cost is in the joins: communication between the web views and the native code is not always easy.
Wrapping technologies
Wrappers that provide a remote or HTML-based web view of an enterprise service form Category 1. They produce normal platform applications, and their development requirements are identical to those of any other native platform application.
Category 2 and 3 wrappers are a different matter on iOS. They need the original developer's co-operation to wrap the application into a signed package. In practice only custom in-house apps, and sometimes business-to-business apps, can use them.
Security guidance from the UK's National Cyber Security Centre gives no assurances about Category 2 wrapping, which works post-compilation and dynamically, and does not recommend it as a security barrier. It treats wrapping in general as a less favourable alternative to building security measures natively into the app.
| Approach | Strengths | Limits |
|---|---|---|
| Web app | Works across operating systems; avoids app-store bottlenecks | Cannot handle an Android Intent; weaker notification support |
| Hybrid app | Native parts can reach location, notifications, mapping and camera | Communication between web views and native code is not always easy |
| Category 1 wrapper | Produces a normal platform application | Same development requirements as any native app |
| Category 2 and 3 wrappers | Can add controls to existing apps | On iOS, need the original developer's co-operation; mostly limited to in-house apps |
Distribution outside Apple's store
HTML5 has no large-scale app store of its own for distribution, retail and monetisation. Even so, a developer survey for Q1 2014 found that 37% of mobile developers used HTML5 as a platform, and 14% treated it as their priority platform.
There are some openings. In August 2013 the Amazon Appstore opened to web apps, including an in-app purchase API.
The main obstacle for HTML5 work is the lack of mature development tools. Performance and API reach matter less.
Testing before submission
Teams that want an independent benchmark often look to the OWASP Mobile Application Security Verification Standard (MASVS). Verifying an app against it cannot be done with automated tools alone. It needs a manual understanding of the app's architecture, its business logic and the pitfalls of the framework it is built on.
Running a scanner and listing the failures it reports is not sufficient evidence. This matters for hybrid and wrapped apps, where the framework adds its own layer of risk.
Buyers should also read vendor claims carefully. OWASP does not certify any vendors, verifiers or software, so a MASVS certification or trust mark has not been officially vetted by OWASP. The standard also covers only client-side app security, not the remote endpoints the app talks to.
Weighing the options
A web-based build can reach users on more than one operating system, but on iOS it still depends on Apple accepting it, on the annual program fee and on the in-app purchase commission. Apps that rely on location, notifications, mapping or the camera need at least a hybrid architecture, and the native parts are what close the gap with a fully native app.
Wrapping is not a shortcut to security. For most teams the sounder path is to build the needed features and protections into the app itself, then have it tested by people who understand both the code and the framework.