Getting HTML5 going

Mark Waddingham mark at
Wed Mar 25 16:58:43 EDT 2020

On 2020-03-25 19:31, Pi Digital via use-livecode wrote:
> In an app on the AppStore this is definitely a security risk from
> Apple’s point of view. Devs could insert any nefarious code into their
> app. This has been true from iOS2.  Only content like video and
> images, maybe some animation data and so on is deemed ok and
> encouraged.

This was once very much the case for the iOS AppStore - as those of you 
who were with us around 2010/11 will probably remember...

However now it isn't any longer true (I did post relatively recent about 
the most recent app store agreements for both Google and Apple but I 
couldn't find it when searching just now).

Essentially both Google and Apple's restrictions on what you can do in 
terms of downloadable code are essentially the same these days in both.

Obviously both explicitly disallow any sort or malware or nefarious code 
of *any* sort.

However, you are allowed to download code which runs in some sort of 
interpreter - i.e. the binary/text being downloaded which you are going 
to run is not in any way related to the actual instructions which run on 
the local CPU (so classic interpreters are fine, as are JITs - 
downloading machine code blobs is not).

However there are two rules which must be followed:

   1) Downloaded code must not allow the app to access any more system 
provided APIs that it could before.

   2) Downloaded code must not allow the app to 'morph' (as Richard put 
it) into something even slightly unrelated to what it was at the point 
of review; nor should it add significantly different features 
(particularly in terms of UI).

In practice conforming to (1) is easy - you aren't allowed to download 
LCB extensions, loading them at runtime, which use FFI to access system 

Conforming to (2) might sound like it is too fuzzy to really know what 
you are allowed to do, but it isn't really. It is one of those cases 
where if you really have to ask yourself whether the bit of script or 
stack you want to download might be seen as extending the app 
significantly or morphing the app into something other than what it was 
when it was reviewed - then it probably is!

Some examples:

Additional game levels (which often have 'code' in them of some sort) in 
the spirit of those already offered are fine; 'levels' which turn s 
puzzle game into a first-person shooter probably are not; adding a 
level-editor to your game probably would not be.

Additional music-related interactive content in a sheet music related 
app would be fine; interactive recipe-related interactive content being 
downloaded into a sheet music related app would probably not be fine; 
adding the ability for a user to add and share comments with others on 
the original content probably would not be.

Replacement business rules required to provide new and updated tax rules 
in an accounting app would be fine; a module which turns an accounting 
app into a point-of-sale system would probably not be fine.

These two rules are there for very different reasons.

Rule (1) is there so both Google and Apple 'know' the surface area of 
attack on their OSes will not increase. Its important to remember that 
OSes have bugs too, and bugs sometimes enable exploits - these always 
come about due to bugs in system APIs enabling something to be done 
which shouldn't be allowed.

Rule (2) is there for more social/business/marketing reasons - they 
don't want consumers duped, they want to have some idea of what the app 
is meant to be and they want to try to (at least minimally) provide a 
reasonably cohesive 'store' environment.

At the end of the day, these two rules are really easy to keep within. 
If you need to make substantial functional changes to your app then you 
need to get it re-reviewed, but if you are merely extending what was 
already there before in any sort of 'reasonable' way (particularly by 
providing extra content incremental to what was there) then you will 
have no problem at all.

Hope this helps!

Warmest Regards,


Mark Waddingham ~ mark at ~
LiveCode: Everyone can create apps

More information about the use-livecode mailing list