There seems to be nothing on an iOS build (not very surprisingly).
On Android there is one:
gitter Sat, Apr 22, 2017
HedgeHao (Josh Chiu) tries to build for Android
Fri, May 5, 2017
maybe some hints by livecodeali (Ali Lloyd) on this
Tue, May 9, 2017
final resolution (?) by runrevmark (runrevmark)
I’ve taken out all support for mobile platforms as they don’t allow GPL software in their stores.
Yes that is necessary but also a strategic issue to think about.
I think with the old support that we had for mobile, and the fact that I have no idea what I’m doing 
it was best to strip it out, hopefully not too many people are upset about it.
We can simply postpone the question till we have a reliable compilation pipeline for the three desktop platforms from the GitHub repo. This is hard enough. After that, the question of mobile runtimes of course cannot be ignored. I have ideas for workarounds, but that’s for later please.
I have Android/emscripten/iOS working here. Issuing PRs will need to be done piecemeal since some binary stacks will be affected. Let me know when you’re ready.
I dumped Android, iOS and Emscripten for a reason. Sorry, I don’t want them in HyperXTalk 
Obviously we could talk about this at length, but if GPL is your Rubicon here, I don’t think (I am not a lawyer) that GPL3 is a restriction. For Android at any rate. I think having a plurality of development targets would be good for getting people interested. My two cents.
Mark, great to hear about your three builds!
Emily is the maintainer and has the say what goes in and what not regarding her GitHub repo. This is crystal clear.
As stated above, the question of having mobile builds is a strategic issue. Beyond 60% of all computing/media consumption (call it whatever you like) is done on mobile devices now. I would say that a platform that shuts itself off from mobile indefinitely can not gain traction anymore.
Anybody interested should discuss here what shall be done and can be done, trying to keep a solution within reach and eventually find a workable path for some or all mobile builds.
I think the situation is different for Android, iOS and Emscripten, so we best would have three topics on this.
Probably it is only two topics, as the Emscripten version might be a curiosity that can be shelved in the software museum. Last serious discussion on what can be achieved with it happened in 2019, there are unpredictable (or consistently high) lags for initial (and also recurrent) loading, its looks are Motif, and the strategic argument does not apply for it as xTalk builds in browser runtime environments can never win a battle against native code and controls. Playful idea, lost case.
@mwieder If you disagree, we can open a topic on Emscripten as well of course. I cannot contribute much there though. I would try to concentrate on the two mobile platforms and also the GPL solution needed for each of them. I would support this in any way possible. Should we start work on this?
As you said, Emily’s the maintainer here and what she says goes. I’m down with that. I’ll put up an argument, but at the end of the day it’s not my call.
@Emily-Elizabeth a modest proposal: would you be up for PRs that add the mobile deployment code but don’t surface anything to the IDE level? That shouldn’t interfere with any other code and a separate optional plugin could provide the interface. I’m quite willing to drop the emscripten branch - that does seem like it was an LC dead-end.
But it would only be available on the Linux IDE as it’s be removed from macOS and Windows
The standalone and deploy libraries are host-agnostic. Somewhere down the road I can make you a PR and you can decide about it then. Other more pressing tasks right now.
I was not aware that mobile builds were getting pulled. I was actually excited that maybe building for Android would finally get some love and stop being such a PITA.
That is going to be a showstopper for me, as literally everything we build is for mobile. I think we have two apps that we build for M$. The rest run on iOS, first, and Android, second.
Maybe “pulled” is less precise than “not added”. Each contributor scratches their own itch.
Mobile in this FOSS fork is limited anyway, because the copyright holder has stated that they view the restrictions in Apple’s app store as noncomformant with the terms of GPLv3, so that one’s been a nonstarter from the first FOSS release way back when.
Android might be nice, but if I’m doing mobile I need full platform coverage.
And in the frenzied gold rush when mobile premiered, the form factor growth rate was mistaken for market share, prompting dozens of mobile-only solutions.
Where xTalks have shined most brightly is on the desktop, where even to this day we see little in the way of competitors across all three OS families.
The workflows that make this xTalk so fluid for desktop development never really carried over to the mobile implementation, resulting in a dev experience that felt more like building a ship in a bottle, so far removed from the simultaneous dev-at-runtime that distinguishes this tool family.
In another time I was more concerned about using the same code everywhere because I was making thorough use of LSON (encoded arrays) as a more performant, robust, and lean alternative to JSON.
But that ship has sailed. JSON support in xTalk is good enough, and the interoperability is vast, these days far outweighing xTalk-specific formats.
So the only remaining hurdle is having to become proficient in JS. But the rise of the browser answered that question long ago, by removing choice altogether: if you need web implementations, there’s only one scripting language built into every browser. Takes that long first step of a project, deciding which language to use, off the table.
And once you have a web implementation, with the right tool chain you’re not far from a mobile-native app packager.
TL;DR: Without iOS, mobile deployment would already be forever compromised.
I’m grateful Emily is devoting the time to build out on the form factor where xTalks strut their stuff.
And if another contributor comes along and wants to tackle Android, it just gets better.
this is another opportunity, just like with a script compiler, to add something external that can be a (probably small) revenue generator (but i would want the source, somewhere, to guard against the feature being locked away/ransomed/discontinued with no recourse).
the same could be said about a WASM generator.
the project literally trends the direction that LCC did - a core that’s OSS, and extra features that are premium. just like the early days of HC, there’s money to be made bolting things onto the core.
the tool can be whatever ee decides it can be. limiting it will limit the audience even more than it would be limited, otherwise.
Ok guys,
beautiful interaction that alltogether describes what our task would be, in fact it is threefold:
Just because only parts of this program have been provided in the past does not mean it is impossible to do. Great opportunity, zero risk involved. If we fail, the situation just stays the same as it is now.
Everyone present here knows perfectly well that browser + JS + JSON (etc) is the mainstream way to go, but this is not why we are here, right? I am here to improve on the xTalk situation. I still am happy to hear that Mark can do something on the binaries question. First big step to tackle the whole thing.
With one exception: given the stance of the copyright holder for the original code base with regard to iOS, any FOSS deployment to that platform would have to be compromised of entirely new code.
So where you have “mobile”, that would be “Android”, unless someone wants to take on a LOT of work to produce an iOS engine from scratch.
Hi all,
I realise that I am out of my depth here but may I request that in future posts that abbreviations are written out in full when they are first introduced into a thread ? Otherwise those readers who are not in the know are left both scratching our heads and force to conduct multiple searches.
For example based on the contents of this thread:
GPL : General Public License
emscripten : embedded tool that converts C code into script that runs in browsers.
PRs : Oh there is fun to be had with this one, for example my wife who is a retired doctor would read it as “per rectum”. Other readers may interpret it as “press release” or “proportional representation”. I worked in software testing and PR was “Problem Report”. I’m guessing but in this thread it probably means “Pull Request”. Unfortunately, I have no idea what the implications are of a PR in the context of this thread.
WASM : WebAssembly ?
Unfortunately it is in the nature of experts to create their own list of acronyms and I am as guilty as anyone.
“May your terminal accept its load and your PPLIs be always received and your TQ and PQ remain high.”
best wishes
S
You got all of them right so you’re an expert too. 
For documentation I agree wholeheartedly that the common guideline to define the first use of an acronym in a document is good practice.
But in a forum, sometimes in very fluid discussions and typed with thumbs, as long as we’re welcoming of questions about any terms or processes that aren’t clear I think we’ll be okay.
Please do feel free to ask anything related to project here. Emily is the consummate host, and the rest of the crew are very welcoming too.
I totally agree 
I’m not entirely sure if some parts of the world are just out there casually speaking in abbreviations like it’s a secret code, but here in Europe we tend to spell things out - we’re not that rushed.
That said, there are definitely some abbreviations that have made it into the global hall of fame, and the two you mentioned probably belong in that category.