Document how to make server-driven frames, pages, and views

[brody4hire]

I think this is frequently needed, non-trivial, and not very well documented.

For example: https://github.com/apache/cordova/issues/196

[breautek]

This needs to be carefully worded, as server-driven pages have limited abilities if you still want to be compliant with Apple App Store and Google Play store policies.

We don't have any documentation on this either, but I've raised an issue on that subject at https://github.com/apache/cordova-docs/issues/1022

TL;DR; you shouldn't be accessing (or making accessible) the generated cordova.js, or gain access to any native device APIs from remote sources.

[jportoles]

Do I understand correctly that fetching static HTML off a remote source (for the purposes of templating) would not cause issues with Apple App Store/Google Play Store store policies, as long as no remote JS is downloaded/executed? That is to say, an scenario where the remote HTML contains no script tags and is fetched and consumed solely by locally available JS.

[breautek]

Do I understand correctly that fetching static HTML off a remote source (for the purposes of templating) would not cause issues with Apple App Store/Google Play Store store policies, as long as no remote JS is downloaded/executed? That is to say, an scenario where the remote HTML contains no script tags and is fetched and consumed solely by locally available JS.

None of us here are actual Apple or Google lawyers so all we can do is interpret and speculate. So if you want a definite legal answer, you should consult a lawyer.

Firstly, if you're not publishing to Apple's App Store and/or Google Play Store then this doesn't apply to you as the terms in question applies for applications being publishing to the respective app stores. I'm not aware if there are any other terms that applies when using the device SDK of either platform however.

TL;DR;

Remote JS is allowed as long as they use and can work with standard browser features and doesn't require or can gain access to the native device APIs. Apple pretty explicitly states that javascript being loaded from a remote source is not allowed to access native device APIs. Google has similar policies although their text is very vague, and I'll talk about that later.

Detailed Answer:

That is to say, an scenario where the remote HTML contains no script tags and is fetched and consumed solely by locally available JS.

That's not right. You are allowed to use Remote JS, but there are limitations to what that remote JS can do or use. Simply, it can only use the standard browser features. If you are exposing a way of accessing native device APIs, then you're exposing APIs that only paid developers that have agreed to Apple's terms of service of using XCode and the software SDK are permitted to access. Google is not as explicit as Apple and is signicantly far more vague, but if you play close attention to the text, I genuinely believe their policy is basically the same as Apple's in regards to the Google Play store.

The safest approach to this problem is to simply ensure that cordova.js file cannot be loaded in the webview because cordova.js is what contains the webview <-> native bridge that allows JS to call on native APIs through installed plugins. I'm putting emphasis on cordova.js being available because even if the remote code doesn't actually use cordova.exec method that is available from cordova.js, but the method is available to be invoked, then that privileged could extend to any other third-party JS code that happens to be loaded in the JS runtime, so you would have to vet all dependencies and sub-dependencies that could load JS into your runtime environment.

Let's break down the Apple guideline, Section 4.7 & 4.7.1

4.7 reads:

Apps may contain or run code that is not embedded in the binary (e.g. HTML5-based games, bots, etc.), as long as code distribution isn’t the main purpose of the app, the code is not offered in a store or store-like interface, and provided that the software adheres to the additional rules that follow in 4.7.1 and 4.7.2. These additional rules are important to preserve the experience that App Store customers expect, and to help ensure user safety.

So in simple terms, your native app that contains a webview may:

• Contain or run code that isn't embedded in the binary (e.g. remote code), provided that:
• • Code distribution isn't the primary purpose
• • Code doesn't resemble a store
• • Code adheres to Section 4.7.1 (See below)

So section 4.7 itself states you are allowed to run code that wasn't embedded in the binary, and doesn't dictate any restriction on the source of that code. That is you could download and store a JS executable, or simply just load it over the network on the fly. Either way, it's still code that wasn't embedded in the binary that you upload to the app store.

Section 4.7.1 reads: (Original uses bullet points, I used numbers so that I can clearly reference the text)

4.7.1 Software offered under this rule must: a. be free or purchased using in-app purchase; b. only use capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); and use WebKit and JavaScript Core to run third-party software and should not attempt to extend or expose native platform APIs to third-party software; c. be offered by developers that have joined the Apple Developer Program and signed the Apple Developer Program License Agreement; d. not provide access to real money gaming; e. adhere to the terms of these App Store Review Guidelines (e.g. do not include objectionable content); and not offer digital goods or services for sale.

The most relevant point in 4.7.1 here is point b:

only use capabilities available in a standard WebKit view (e.g. it must open and run natively in Safari without modifications or additional software); and use WebKit and JavaScript Core to run third-party software and should not attempt to extend or expose native platform APIs to third-party software;

So any JS code that was't embedded must be able to run in the native Safari browser without modifications without requiring additional software. It must also use WebKit & JavaScript Code (e.g. you cannot implement your own browser runtime such as Gecko/Firefox or Blink/Chrome), and your app must not attempt to extend or expose the native platform APIs to third-party software. Therefore having the cordova.js file even unloaded, but available to be dynamically loaded I would consider to be dangerous, if you're loading in remote JS into your webview.

Google's policy can be found at https://support.google.com/googleplay/android-developer/answer/9888379

The relevant part of their Device and Network Abuse policy is:

An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism. Likewise, an app may not download executable code (e.g., dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).

Apps or third-party code (e.g., SDKs) with interpreted languages (JavaScript, Python, Lua, etc.) loaded at run time (e.g., not packaged with the app) must not allow potential violations of Google Play policies.

Like I mentioned before, Google's text is far more vague, but if you read carefully it states:

Likewise, an app may not download executable code (e.g., dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).

I'm not interested in debating what Google's intent is, this can interpreted in many different ways. What is absolutely clear is Google disallows downloading any executable code unless if the source of that code is from Google Play itself, but offers an exception to executable code that runs in a virtual machine/interpretor such as JavaScript which must run in a V8 engine or some other JavaScript runtime engine. It explicitly states that the exception applies to code where the runtime environment only provides indirect access to android APIs.

One could definitely argue that cordova.js offers indirect access to Android APIs, so it's okay. But I genuinely believe that Google's intent is referring to indirect access in the way that JS access geolocation APIs (for example) but JS only accesses it through native browser APIs. The Cordova API isn't a native browser API, it's an extension so to speak. It provides access to native APIs through a cordova plugin. Perhaps it can still be said that this is indirect access, but I'm not sure if Google will see it this way. It's definitely a fine line to walk on, therefore I'd always take the cautious side.

On the final note... I am aware of plenty of people that appears to be breaking these rules using software that hot-fix patches by having their app JS code being downloaded from a remote server and they may have been doing it for months, years or some significant amount of time. But I think the reality needs to be understand. As much as Google or Apple reviews all app updates, I think it's realistic to assume that they do not do an actual code review and they reviewers (who may not be programmers at all) may not understand what is happening behind the scenes. It may not be immediately obvious to these reviewers that the app are breaking rules like Section 4.7.1. Doesn't mean what you're doing is completely compliant with their policies. In my experience, I've managed apps where providing a simple maintenance update causes an app review failure due an unrelated piece of the app that supposedly breaks a rule, which has been in the app for years and passed numerous of app reviews in the past.

[jportoles]

Thank you for the detailed answer! The case I was interested in personally is the scenario where there is no remote JS at all, only remote static HTML. Basically, if you have an app that does not expose cordova.js and does not run JS from any external source, but simply fetches static HTML via AJAX to be used as a template (from a server you control), with no JS code at all in said template, then I think it's reasonable to believe that that is not "remote code", right? Just for the sake of speculation, I understand we are not lawyers and this isn't legal advice.

[breautek]

Thank you for the detailed answer! The case I was interested in personally is the scenario where there is no remote JS at all, only remote static HTML. Basically, if you have an app that does not expose cordova.js and does not run JS from any external source, but simply fetches static HTML via AJAX to be used as a template (from a server you control), with no JS code at all in said template, then I think it's reasonable to believe that that is not "remote code", right? Just for the sake of speculation, I understand we are not lawyers and this isn't legal advice.

Yes, as long as nothing loads up cordova.js, then you should be fine as far as Section 4.7 is concerned. You could even ensure that cordova.js is not even packaged by removing the file from the assets, so that if something did end up executing JS, potentially maliciously, it can't even attempt to load the code by creating a script tag like:

var x = document.createElement('script');
x.src = 'path/to/cordova.js';
document.body.appendChild(x);

However, honestly if you're loading up a website as an app, you may have other issues unrelated to Section 4.7. Apple is very picky in how apps are designed, and apps that simply feels like websites can be rejected, which is detailed under Section 4.2, which the opening paragraph reads:

Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value or adequate utility, it may not be accepted. Apps that are simply a song or movie should be submitted to the iTunes Store. Apps that are simply a book or game guide should be submitted to the Apple Books Store.

So if you're just packaging up a static website, or even just using Cordova to connect to this static website remotely, that contains little to no functionality, then Apple may deem that the app is not of App quality (and instead should just be served as an actual website where users can use the Safari browser to access).

[breautek]

Closing as stale.