Please elaborate. I’d like to know what you think that decision meant… because I was there.
There was the chance. If you even considered that I have no Idea. But the way XoJo is going at the moment isn’t a good one. And I know you where there. Why it was not considered to use Kotlin Platform with native Gui for Android and iOS. The XoJo UI Designer could handle it.
Looking on this approach I am using for many apps it ould help to build one mobile App for both platforms and compile native and use native UI on both platforms. We can discuss about it. But it could help to have a simple project for both platforms. What would make XoJo building cross platform for mobile without any problem. Only an Idea.
Which I mentioned in one of my mails to XoJo and Mr. P.
That one is fairly easy to say
In late 2011 when iOS was started Kotlin hadn’t been announced
So at that point it wasn’t a choice
Kotlin Multiplatform didn’t become stable until 2023
This is also after Xojo shipped its Android offering - such as it is
They’d literally have had to go back & start over to use Kotlin
And that’s just not viable
Hmm, today it is not too late to go that step. Would make several steps much more easy in kind of bobile platforms and also for web it is definitely interesting as a platform.
That’s kind of like asking why Google didn’t use Swift and SwiftUI.
For what it’s worth, I recently used the Skip framework to do a cross-platform iOS and Android app that does just that. Compiles swift and SwiftUI apps for Android and iOS from the same codebase. That really only gets you so far though. You’re still stuck because the way you access the hardware is still so different that you need to build custom frameworks.
Many hardware parts are available as kotlin libs. But anyway. This is ended. The entire point of one mobile project is far away.
Sure if they had infinite time, money, talent etc to make the switch it might be good
But they don’t so …
So it will stand in the situation like it is. But for sure: it is sad cause a combined mobile project for iOS and Android would be a nice Idea and would have the same functionality other languages have. So at least XoJo would deliver a table with Columns for Android 
More than just a nice idea that’s dismissible as impractical without much thought, though. It is a necessary fix, a bullet that has to be bitten, and failure to do so will not end well. It already isn’t, when you have two lone devs producing similar, semi-compatible whole ecosystems in a short period of time. Semi-compatible only because of the need to weed out bad architectural decisions.
A perfect example being multi-threading – no one is going to put forth a new platform in the name of 100% code compatibility with the miserable excuse for multi-threading that Xojo offers. Modern async/await/task metaphors are what devs expect now as a matter of course, but which Xojo apparently can’t even contemplate. Yet even Python, despite it taking years of pain and suffering, is finally divorcing itself from the Global Interpreter Lock. There just is no other way.
Simply: not worth of even thinking about, you’re right. At the end: Dotnet, Java, C++ and Python for all kinds of that what Python is best for.So long. Hot summer at the moment here so: Garden time starts now
TBH I think the notion of sunk cost applies here
As in it would be too expensive to retool iOS & Android to have a common core base (Kotlin or otherwise)
And the question of finances plays into it
Would such a move draw back enough customers to justify it ?
Somehow I doubt it
And that’s the quandary I see them facing
What, if anything, could they do to being back enough customers/grow their user base to justify the large investment it would take ?
Well it’s an accumulation of technical and social debt.
An example of technical debt is, one could argue that iOS and Android should never have been built on a non-common core base to begin with; one or both of those targets should have been postponed until there was something they could leverage (as Garry is with Avalonia and .NET, although he’s doing that out the chute with the desktop targets and has a clear path to web and mobile from there).
As for the social debt, more and more customers and former customers aren’t inclined to believe a word they say or to trust any direction they take, because they’ve seen so much disregard of customer input as well as lack of follow through and more than one example of lurching from one approach to the next (API1 / API2, two different swipes at the web target).
I’m sure they do have very concrete financial limitations now, but they are largely limitations of their own making. Besides, both of the builders of alternatives to Xojo (or must I call it X, lol) are constrained probably even more – they don’t have a team of several devs or the money to hire them – so they are working smarter rather than harder [shrug]. Even ignoring that they have hindsight of Xojo’s blunders to guide them, and the benefit of less Need To Be Right, etc., they are taking a coherent design and architectural approach that I don’t think Xojo has had in recent years, if it ever had it. I get the impression it was somewhat present with RealBasic but my personal experience doesn’t go back that far.
One other point – one of the logical fallacies IS the “sunk cost fallacy”. So unclear / motivated reasoning is in the mix as well. It’s one thing to build on the past, another to be slavishly married to it.
Imo there was… Apache Cordova. Xojo Web was generating JS so to me Cordova seemed the most obvious route to Android / iOS.
No that would be a really extremely long way to picadilly. Hence XoJo Web needs the XoJo Server for nearly all actions. JavaScript is for rendering purposes and a few timers and so on. But the biggest part of the logic is running internally.From this point to apache cordova it is a long, long way.
Maybe I should have said “until they were willing to leverage”. Xojo seems to have a bad case of NIHS (Not Invented [or Controlled] Here Syndrome). Bottom line, if there was a path to leverage the work of others and not reinvent the wheel, even if it involved licensing and giving someone else a cut of the action, it should have been up for consideration and in any case they shouldn’t have proceeded with a “strategy” that involved different code bases / frameworks per platform, even if the plan was to make that transparent to users by keeping it entirely under the hood. It is just too much work and too big of a surface for bugs and inconsistencies.