Requirements for publishing a mobile app

[harrison at all-auctions.com]

An alternative. is to just make a website with a database
using LC Server and Apache 2.x.x. You can give the 
link to whoever you want. You don’t have to deal with 
Apple’s App Store at all. If you need your user’s to
pay you, you could consider using PayPal for a one
time payment, or set it up as a subscription based
service.

Apple keeps changing the rules all the time for
Apps in the App Store, and I’ve mostly given up
on them for that reason.

Good luck with whatever direction you go!

Rick



> On Aug 8, 2025, at 11:14 AM, Bob Sneidar via use-livecode <use-livecode at lists.runrev.com> wrote:
> 
> Wait, I reread what Jacque posted. Is the data being saved in the web app itself?? Is that a good idea? 
> 
> Bob S
> 
> 
>> On Aug 8, 2025, at 8:03 AM, Bob Sneidar via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>> Race conditions can be worse than that. Person A makes changes, person B also makes changes, person B saves his changes before person A, person A saves his changes overwriting person B changes, person B does not know about it. The solution to that is to set a counter that gets read when starting an edit, then check to ensure the counter is the same before saving. Upon saving increment counter by 1 with a rollover at max value. Another thing that can be done is to set the counter to the maximum when starting an edit, so that subsequent edits will know the form has been locked.
>> 
>> Bob S
>> 
>> 
>> On Aug 7, 2025, at 3:31 PM, J. Landman Gay via use-livecode <use-livecode at lists.runrev.com> wrote:
>> 
>> A web app runs in a browser; that's the main difference. LC Create makes web apps.
>> 
>> It occurred to me that you will need to deal with race conditions, whether the app is a web app or a standalone that reads a stack from a server. A race condition is when more than one person is using the app at the same time. One person saves changes and it is uploaded to the server. If another person is using the app simultaneously and then saves their own changes, it will overwrite the first person's changes. To deal with that you'll need to set some sort of flag that the standalone checks before sending changes to the server. Usually the flag is just a plain text file. If the flag is set to true, the app needs to wait until the flag is false before redownloading the changed stack, applying the second user's changes, and then uploading the revised stack to the server again.
>> 
>> I've never had to deal with that since all my own work has been static and the working stack has always been read-only (mostly educational materials.) I remember that Andre was very cautious about race conditions and posted his technique on the mailing list some years ago but unfortunately I didn't save it.
>> 
>> --
>> Jacqueline Landman Gay | jacque at hyperactivesw.com<mailto:jacque at hyperactivesw.com>
>> HyperActive Software | http://www.hyperactivesw.com<http://www.hyperactivesw.com/>
>> On August 7, 2025 4:12:28 PM Craig Newman via use-livecode <use-livecode at lists.runrev.com<mailto:use-livecode at lists.runrev.com>> wrote:
>> 
>> _______________________________________________
>> 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
> 
> 
> _______________________________________________
> 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