I’m interested in purchasing a Xojo license. Does anyone here have experience with Xojo?
With LiveCode/RunRev, I can build macOS applications directly from Windows without code signing. Does Xojo support cross-compilation as well, so I wouldn’t need to buy a Mac just to build macOS applications? In other words, can I build macOS apps from Windows or Linux?
I could be wrong and it’s been a while since I gave up on xojo, but from what I recall most of the pieces are there to allow building macOS apps from Windows, or wherever - but Apple’s Xcode needs to be installed in the tool chain to complete the build.
So, given that Xcode is not available for Windows, then I think the answer is no.
I think this is xojo’s one big limitation when it calls itself cross-platform. It can build Windows apps from Mac, but not the other way around.
I was always a Mac person, so never had an issue that way.
You can build them
But you cant sign or notarize them on Windows for distribution
Thats an Apple restriction since their signing tools etc only run on macOS
Thank you Norman, I knew it was something like that.
The inverse is possible, though 
You can have a Mac to build, sign, and notarize the Mac build. Then use a Windows VM on the Mac to build and codesign an installer. Alternatively, @jotter has some magic Docker thing that I’m pinging him to tell you about.
But, ultimately, you do need a Mac to do anything useful with a Mac build.
So… I recently found a project that claims to make this possible.
Thank you for your response. Your input is very helpful and will be an important factor in my decision to purchase a Xojo license.
You might want to give Objo a try. It’s pretty much how Xojo SHOULD have been and run. See the relevant thread.
I’ve already tried Objo, but I need a single codebase that works across all platforms, similar to Flutter.
Just to be clear, I’m not saying you should start paying into the Xojo ecosystem. Eventually you’ll outgrow it, there will be no where to go and you’ll end up having to convert to something else anyway. I don’t think I’d be out of turn saying that most of the people here experienced that very same thing.
You could wait till Sunday and give tsbRapitFX a try. Runs over all platforms: Windows, Mac, Linux, as a WebPage and mobile (Android and iOS). I will release on Sunday around 8 pm MESZ.
Objo developer here.
You can build for Mac, windows and Linux desktop and the web from the same codebase. I would argue it’s easier to share code between different targets in Objo than it is with Xojo.
Obviously, I’m a little biased however.
Yes, you’re right. However, objo.dev doesn’t support Android and iOS yet. If objo could support both Android and iOS, it would be a major step toward success.
iOS is in active development (the runtime has been working for weeks - just the IDE needs work).It will come before Android simply because it is my preferred platform. No timeline yet but it will arrive.
Have you tried Buoy yet?
I can only recommend to give the runtime with a small app an appstore check cause otherwise it could end up with much work. Apple does not really like runtimes and I don’t know if there is a use of jit compilation in your runtime or under the hood. The simulator and your phone will not reject this with an error message but appstore rejects it immediately. That’s because it is possible to ude jit but forbidden by apple and only rejected in Appstore.
Buoy doesn’t do mobile yet either.
Thanks @thorstenstueker - I’d definitely second the advice of pushing a minimal app through the App Store before betting months of work on a runtime. That’s cheap insurance whatever tool you use and I will do that.
A couple of details on the mechanics are worth adding, though, because the trap works slightly differently from how it’s usually described.
The reason JIT code slips through development isn’t that the phone tolerates it, it’s that development builds get special treatment: the debugger can enable JIT for a process running under a development provisioning profile, and the simulator does no code-signing enforcement at all. A distribution-signed build doesn’t get any of that, so the moment the runtime asks iOS for writable-and-executable memory the OS simply refuses and the app crashes.
On “Apple is unfriendly toward runtimes”, I’d gently push back on that one. I’ve read the guidelines (a lot!) a specifically guideline 2.5.2 forbids downloading executable code after install; it doesn’t forbid shipping an interpreter with all of its scripts or bytecode bundled in the app. Pythonista, a-Shell, every Lua-scripted game and so on all ship that way and pass review routinely. What Apple genuinely doesn’t allow is JIT without an entitlement they never grant for distribution.
And in Xojo’s case the concern is probably moot anyway: I’m almost certain that Xojo compiles to native code ahead of time on the build machine (Greg will know for sure), so a shipped iOS app contains no on-device JIT and Xojo-built apps have been getting through review for years.
So yes, absolutely I’ll do the early check but the specific things to look for are anything that writes executable memory at runtime or downloads code after install, not the presence of a runtime as such.
it depends. Jit compilation isnt allowed. The interpreter may be no problem. I have also no problem with my GC runtime on apple iOS appstore. So there may be a problem why I would try a small app to get the knowledge about this situatiuon. Better to change before release than after.
It does compile to native code so no JIT etc is involved