Legality of Zipline on Android/IOS

[CharlieTap]

Are you using Zipline in prod for both Android and IOS? If so have you had an friction?

Looking at the Apple's T&Cs:

2.5.2 Apps should be self-contained in their bundles, and may not read or write data outside the designated container area, nor may they download, install, or execute code which introduces or changes features or functionality of the app, including other apps.

4.7 HTML5 Games, Bots, etc.
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.

4.7.1 Software offered under this rule must:
be free or purchased using in-app purchase;
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;

It sounds like its okay if you're not drastically changing the feature set between dynamic deployments? I guess as the code has to be embedded in the binary for offline usage you still do store submissions for feature changes?

[JakeWharton]

Are you using Zipline in prod for both Android and IOS?

Yes!

If so have you had an friction?

No!

It sounds like its okay if you're not drastically changing the feature set between dynamic deployments?

That is the common interpretation by many. And actually nothing about a JS engine specifically grants your ability to do this since you can do it with normal static code in the binary.

We have driven dynamic content and structure of screens in our app for about 6 years using protos from the server and logic which is baked into the binaries. The JS engine is just an opportunity for more powerful dynamic logic.

I guess as the code has to be embedded in the binary for offline usage you still do store submissions for feature changes?

This isn't strictly required by Zipline, but it's a general best practice. If you release on a regular cadence and snapshot the latest code for offline as part of that then the review process will cover the functionality.