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@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@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@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 | >> jac...@hyperactivesw.com<mailto:jac...@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@lists.runrev.com<mailto:use-livecode@lists.runrev.com>> wrote: >> >> _______________________________________________ >> use-livecode mailing list >> use-livecode@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@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@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode
