sideloading updates to mobile

[J. Landman Gay]

I've done this for several mobile apps. As long as the updates only reside 
in the app's sandboxed container, even the App Store doesn't care.

Basically, I put a short text file on the server listing the update 
version(s) of the file(s), one per line if they are all different.  Every 
stack in the app suite has a custom property named cVersion. If necessary 
you can also add the download URL to the same line. On launch, the app 
downloads and parses the text to see if the server version is different 
from the installed one. If so, it uses "put URL <serverPath> into URL <docs 
path>" to download and save the the updates to the mobile documents folder, 
overwriting the old ones.

It's pretty simple, if I understand what you need correctly. I also store 
other info in the the text file occasionally, such as a text string 
describing the updates so I can show an answer dialog if I want the user to 
agree or decline the update (which will reappear on the next launch if they 
decline.)

Sample text file is usually something like this:

   Stack 1 <tab> https://www.domain.com/updates/stack1.livecode
   Stack 2 <tab> https://www.domain.com/updates/stack2.livecode
   ..
   This update provides new functionality and bug fixes.

If you don't want to scan each stack for its cVersion, you can keep a text 
file in the mobile documents folder that lists the current versions so you 
can easily compare that to the one on the server. After updating the 
stacks, update the stored text file as well.

If updates are mandatory, just skip the comparisons entirely and 
force-download the updates. If only some of the stacks should be updated, 
omit the ones that don't need to be updated from the server file.

--
Jacqueline Landman Gay | jacque at hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On February 21, 2024 12:53:25 PM Mike Kerner via use-livecode 
<use-livecode at lists.runrev.com> wrote:

> right - no updating the engine + runtime in this scenario, just the
> stacks + scripts, and perhaps plugins.
> we are going to continue to only privately distribute to our corporate
> clients, so the app store won't be part of the equation. that does not mean
> that apple won't object, though (but, i believe the rules for privately
> distributed apps are much more lenient than for app store apps - at least,
> they have been for us, up until now)
>
> On Wed, Feb 21, 2024 at 12:53 PM Klaus major-k via use-livecode <
> use-livecode at lists.runrev.com> wrote:
>
>> Hi Mike,
>>
>> > Am 21.02.2024 um 18:47 schrieb Mike Kerner via use-livecode <
>> use-livecode at lists.runrev.com>:
>> >
>> > sorry that i was not clear. we've been using private deploys since around
>> > 2010, using airlaunch to generate the bundle, and then uploading to a
>> > private url. that's not what i meant.
>> > i'm talking about updating/patching an existing app, in place. the
>> devices
>> > are in single-app mode, so we would either have to pay for mdm and then
>> use
>> > that service to push app updates, OR, if we didn't use mdm, we could have
>> > the app pull the update and apply it.
>> > i can kind-of guess how to make it work, but i'm sure there are a couple
>> of
>> > tricks that i don't want to have to figure out, if someone else has
>> already
>> > figured it out.
>>
>> you could use the "splashscreen" approach to update one or more stacks,
>> but that will
>> of course only work if you do not want to update the actual engine/runtime.
>>
>> However I'm not sure if Apple will allow this, no problem on Android
>> however.
>>
>>
>> Best
>>
>> Klaus
>>
>> --
>> Klaus Major
>> https://www.major-k.de
>> https://www.major-k.de/bass
>> klaus at major-k.de
>>
>>
>> _______________________________________________
>> 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
>>
>
>
> --
> On the first day, God created the heavens and the Earth
> On the second day, God created the oceans.
> On the third day, God put the animals on hold for a few hours,
>   and did a little diving.
> And God said, "This is good."
> _______________________________________________
> 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