there’s also option “B”, which someone will choose, at some point: doing what all of us did as children, when we got into coding and computers.
you know, we all wanted to play games, but none of us could afford them, so we, and everyone else, learned assembly language, and learned how to defeat the copy-protection. pretty soon we all had a gigantic stack of floppy disks, with every game.
runtime schemes are incredibly dumb. someone is going to reverse-engineer it, and then defeat it, and then, shortly thereafter, do the thing that all of us have not bothered doing: reverse-engineer the runtime engine (and maybe finally write a script compiler, since we haven’t had one since Compile-It! and Double-XX!)
the lc nerds who have been clinging to v. 9.6.3 (the last edition of lc community) may well have the last laugh - if there are still enough people who care, instead of moving on to KMP/Swift/Flutter
Do I like working with XCode? No. Not at all. Do I hate my days when having a project I have to write with XCode? No. Not at all. Do I love Objective-C? No. Do I hate programming objectove-C-Code? No. I don’t like it. But it is must have to reach my target of a native application for the apple platform. Do I use it if it is not mac only and no need for native UI? No. Not at all. But that makes no difference.
I like my Job as a programmer and I like to do what I am doing. That’s all of it.
Do I like working with XCode? Yes. Do I hate my days when having a project I have to write with XCode? No. Do I love Swift? Yes.
But then this is me, I used Xojo for over 10 years, then API2 came along, the quality started falling, managment didn’t care, didn’t listen, and when pressed banned me for 1000 years.
Did I cry in my beer? Not at all, I picked another option and moved on. Swift is fine for me, as I don’t have a need for windows or linux. That may not be right for others. But if you are going to be a true programmer/developer you also cannot be a one-trick pony.
For me, I had learned and used dozens of languages before Xojo (which I only started because VB wasn’t available for the mac).
to be fair, though, apple does the same thing to your ios apps. if the app is privately distributed on ios, it has to be rebuilt every year.
that does not make the behavior ok. it means that if you let your apple dev account expire, your app is dead, no matter what tools you used, and you can’t rebuild it, until you renew your dev account and recreate/re-sign the provisioning profile.
i don’t know what the rules are for the semi-private/nonpublic distribution channels (apple lets you not only distribute to specifically provisioned devices (i.e. private/corporate apps), but, more broadly, without using the app store, via your own url). that channel does not prevent your app from being publicly loaded by anyone, it just keeps it out of the app store. i would think you would still have to have an apple dev account to produce updates, but i don’t know if the provisioning profiles still expire, after a year.
That is not entiely true. Apple will force you to rebuild an app if the SDK it was built under has been superceded by a new requirement (which will most likely happen with iOS26/macOS26)
And Apple CAN (but rarely does) remotely disable an installed app if that app was deemed to be dangerous or non-compliant.
But that is a far cry from shutting down an app because the developer doesn’t pay
the only apps I have ever had expire otherwise, where ones I loaded directly from Xcode and were never published, and then only if I let my dev account lapse
Apple may disable installed apps under very specific conditions that primarily relate to security, enterprise distribution, legal compliance, device management, or critical technical issues—ordinary App Store removals or expired developer accounts do not automatically disable apps that have already been installed.
```
i don’t think that is true for corporate/privately distributed apps (i.e. apps that are provisioned to specific devices, only). we have to rebuild our apps, every single year. they literally stop launching on a certain date. without fail, every year, when that date rolls around, and for several weeks, after (because if an app is already running it won’t stop working. it just won’t launch, again), we get calls and emails from clients about their app not running. those people did not see, or they ignored, multiple warnings to install the update.
we don’t write apps for the app stores. everything we write is for ourselves or for private clients.
someone else mentioned “what happens if a server goes down, or livecode goes out of business?” that comment reminds me of another issue: if your wireless firewall has geobans on it (only allows contact with certain regions, like many corporate firewalls do), apps that must phone home will fail, if the server that the app is trying to contact is out-of-the-area. that begins a discussion with IT about the value of the app vs. competitors. IT would rather ban your app than unban a cloud datacenter that may open the firm up to baddies in the same datacenter.
Privately distributed apps do need to be renewed yearly. the certificate expires after a year, and without a valid cert, it will not run.
While they do not enforce that kind of restriction on App Store apps (certs are renewed by apple automatically), changes to the OS, devices, regressions, etc, sometimes not announced, will break older apps, and many find they need to keep on top of things to an extent that’s exhausting.
One viable laternative is OpenXtalk: this is a continuing version of the cancelled Open Source version of LiveCode. As a user of LiveCode from 2001, transitioning to OXT was a bit like a hot knife through butter.
So it is a language without compiler for the moment. Sad. Something XoJo has at least. A working compiler. And do not forget: browsing through the source code there is not that much new stuff. A few mergers and that’s it. Real work is nothing you will se there. The most of the source code is between 3 and 5 years old, some parts are ten years old. Looks much like the Repo for LiveCode in its last free version. It is rebranded and that’s it. And it is a bit modified for running on modern OS. There is no substance where I could find a good way to use that in real projects without having headache.
I misspoke. LC doesn’t have a compiler, either (don’t get me started. We funded one. We were supposedly weeks away from getting the beta). LC uses a subset of the engine and builds a runtime around it. Then your app is just interpreted by the engine. Even with that caveat, it is able to build standalones for all platforms.
OTX, imho needs the same sort of functionality, and imho, it would also benefit from a true compiler.
It’s wild to me that Heizer solved this problem thirty five years ago for HyperCard stacks. They had two products, CompileIt!, that let you compile HyperCard scripts into XCMD’s/XFCN’s (compiled libraries) and call MacOS Toolbox routines, and Double-XX!, that let you turn HyperCard stacks into double-clickable applications for Mac. If you combined the two, you got a compiled and engined application.
I use https://openxtalk.org for all of my LiveCode projects. The project they created is very helpful for maintaining code that is already running. However, I have registered on their forum several times and never received any response.
Same apply for F35 planes - Yes, when the USA sold F35 (and others I suppose), the war plane calls home on a regular basis and stop working if no answer.
And I do not talked about the anti-friends measures: a F35 cannot fight against another (probably regardless of the owning country), so no one with an F35 can destroy another F35…
When will F55 needs active GPS to fly ?
Last, but not least: USA can set down VISA to foreign countries. If done no transaction can happens in that country (or set of countries)…
But at the end: LiveCode will phone home. I have no Idea what happens if it can’t phone home. But never mind. People have to decide if this is a problem for their application or not. If it is…LiveCode is the wrong solution.