Signed or PWA App
While Signed Apps are the recommended way to deliver your KaiOS apps, there may be benefits to using the PWA approach. This page provides a guide to the key differences between these delivery methods and offers advice on choosing between the two.
The primary difference between Signed Apps and PWA is fairly obvious: the former delivers all its content onto a user’s device, while the latter delivers the app‘s assets on demand from a web server. However, there are many more subtle differences that you should consider when choosing between the two.
Signed and PWA compared
Let’s start by looking at key features of Signed Apps and PWA Apps and see how they differ.
Functionality
The overriding reason for creating a Signed App is the functionality it can offer to your users. Packaged Apps can use the Signed APIs, which provide apps with the ability to integrate closely with hardware and software features on a KaiOS device. If, for example, your app wanted to allow the user to select and use details of contacts stored on the device, this can only be done in a Packaged App.
| Feature | Signed Apps | PWA Apps |
|---|---|---|
| API support | All available KaiOS APIs | No access to Signed KaiOS APIs |
| Device integration | Excellent | Limited |
| Can access web resources | Yes | Yes |
Performance
In general you should expect users to observe better response from Packaged Apps, as all the app’s assets are stored locally on their device. When accessing remote data from the Internet, generally there’ll be no significant difference between the two options.
| Feature | Signed Apps | PWA Apps |
|---|---|---|
| Start-up time | Fast, all assets on the device | Network limited, all assets downloaded |
| Network impact | Remote data only | App content(unless AppCached) and remote data |
| Content optimization, e.g. screen size | Through redundant assets or multiple packages | On-the-fly |
| Impact of data plan limits | Low | High |
Availability
While KaiOS supports AppCache and local data storage, Signed Apps provide the app’s assets locally by default, removing the need to explicitly design for application caching.
Hosting
The cost and effort of hosting a server to deliver PWA Apps may be an issue for you, if it is then Packaged Apps have a clear advantage.
| Feature | Signed Apps | PWA Apps |
|---|---|---|
| Server required | No | Yes |
Discovery
| Feature | Signed Apps | PWA Apps |
|---|---|---|
| Discovery | Through Marketplace | Through Marketplace and own site |
| Direct access using a URL | No | Yes |
Delivery
All apps need to be delivered to a user’s device, which will be affected by both the network bandwidth and the available storage memory on the device. Here the overall size of your app’s assets will be the primary decision driver, the larger your app the more likely you’ll want to deliver it as a PWA App.
| Feature | Signed Apps | PWA Apps |
|---|---|---|
| Marketplace review time | Longer (when using Signed APIs) | Shorter |
| Self-publication | Yes | Yes |
| App updates | Requires a new package to be loaded onto Marketplace | Core app changes delivered on-the-fly, new install details (e.g. name, icon) require a new Marketplace package |
| App Asset/Content redundancy on device | Possible | No, only used assets/content downloaded |
| App asset limits | Practical package size limit is device memory and network dependent, generally < 50Mb, <5Mb for low memory devices | Online: No practical limit AppCached: As for Packaged Apps |
| Number of apps per device | Limited by device memory | Online: Practically unlimited AppCached: As for Packaged Apps |
| Asset extendibility | Limited, except for data from XMLHttpRequest and browser links all assets must be on the device | Unlimited, within Origin |
| Remote content | By using iframes, but that content will not have access to privileged APIs nor will it have the default CSP applied to it. | By default |
Development
| Feature | Signed Apps | PWA Apps |
|---|---|---|
| Delivery standard | Proprietary (albeit a simple ZIP) | Web standard |
| Debugging | Easier, no Origin limitations | easy, Just like normal web app debug |
| Reading JavaScript assets | Requires use of XMLHttpRequest | Direct |
| Coding challenges | OAuth functionality for Facebook, Dropbox, Twitter, etc. | |
| Manifest must specify a launch_path | Required | Optional |
| Apps per Origin | Doesn’t apply | Doesn't apply |
| CSP | Enforced | Optional |
| mozApps API install function | Apps.installPackage | apps.install |