That pattern is the real problem: treating a compatibility workaround as the permanent design, then resisting the API-based fix. I’ve seen teams burn weeks chasing OS betas with string parsing when a small platform check would have done it. The lack of outside input turns one bad decision into a recurring one; users don’t just lose confidence, they lose time. Switching platforms over that is understandable.
So you left Xojo because of a bug based on System.version? Wow, people do have strange needs…
I don’t think you understand the extent of that bug, especially for iOS apps. Because of that bug, iOS apps running in certain regions in Asia wouldn’t open at all. The Xojo framework makes a call to system.version each time a modal screen is opened on iOS.
I raised the issue with Xojo and they completely ignored it saying the code they used for system.version could not be crashing an app, despite sending them crash logs and reproducible steps.
I had to raise the issue directly with Geoff by having a call with him before they took my reports seriously. In the meantime, 30% of revenue for one of my biggest apps was gone because China and Japan were big markets.
Leaving Xojo is not a decision I took lightly, 99% of the code used by my company was written in Xojo. A combination of factors made me realize that this was no longer the right tool for me and the way they handled the system.version bug is one of them.
Ah oke, no, I didn’t know that 
I never used Xojo for portable apps, so no experience with that. I hear it’s not the best development platform for that. I’m using Xojo since 2003 for Mac apps only, and since a year or three I’m developing a freeware app that 80% of the users run on Windows and that’s still very good IMHO. But I can understand the frustration with web and iPhone/Android apps.