Encrypted standalones

[J. Landman Gay]

Apparently my theory of why we can't do it in the standalone builder was 
wrong, and encrypted scripts don't matter in the app stores. So I'm 
still wondering what the reason is for disabling it in the SB.

I knew how to set a password on a stack, but if you do that then you 
have to enter the password every time you open the stack during 
development. The nice thing about using the SB to set a password is that 
it only applies to the built app and you don't need to mess with it 
during development.

I can just set a password before I build I guess. A 
savingMobileStandalone handler would work for that, followed by a 
mobileStandaloneSaved to remove the password.


On 4/18/19 11:30 AM, JJS via use-livecode wrote:
> If you use this sentence in the message box (which i got from another 
> fine member here) the stack is encrypted, and when turned into an APK is 
> well accepted by Google Play Store:
> 
> *set*thepasswordofstack"beststackever"to"mostdifficultpasswordofalltimes"
> 
> 
> Op 18-4-2019 om 02:33 schreef Richard Gaskin via use-livecode:
>> J. Landman Gay wrote:
>>
>> > Finally got to this. The password is saved in the standalone custom
>> > property set, but when testing on a trial standalone it isn't actually
>> > being used. So the answer is "no, you can't set a password on a mobile
>> > app via the standalone builder."
>> >
>> > After thinking about this, I realized that since none of the three
>> > major app stores will accept an encrypted app, that's why it's
>> > disabled.
>>
>> That seems a strangely LiveCode-specific policy.  It would be cool if 
>> Apple, Google, and Amazon were so impressed with LC that they felt the 
>> need to write policies just for it, but I suspect I merely don't 
>> understand.
>>
>> If the policy prohibits encrypting compiled machine code, I can 
>> understand it.  All three use automated processes to review code for 
>> inappropriate symbols, and encryption would thwart those good efforts.
>>
>> But LC standalones don't encrypt the engine, only the scripts. The 
>> compiled machine code remains available for automated review, while 
>> the it's just scripts that operate within the constraints imposed on 
>> that engine sandbox that are protected. In that sense they're not much 
>> different from tokenized bytecode used in many game engines.
>>
>> Unless this policy is oddly LiveCode-specific, I suspect you've 
>> discovered a regression, one worth reporting.
>>
> 
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode


-- 
Jacqueline Landman Gay         |     jacque at hyperactivesw.com
HyperActive Software           |     http://www.hyperactivesw.com