Letter to Geoff

just checked: First apperance in Feedback 2008, 12 years ago…

Lets start with Console Apps… basically nothing there except input and stdout. To get screensize I need to trigger stty… should I mention ncurses?

1 Like

I agree that it is hard to make money selling an Android app…

But because of the hurdles of having to go through apple to distribute iOS apps, supporting only iOS for mobile kind of keeps Xojo “Citizen Developers” from doing mobile solutions even for work… (and managers love cheap solutions)

I may be wrong but I see that as the only reason to have an Android target as it seem few pros want it… That said I could do without it too.

For mt the most important as always been and will always be Xplatfram desktop - Mac and Windows and I want this to be both rock solid and have things behave the same way on each platform… the alter in particular is WHY I started with RB.

How URLConnection was handled, and how it does NOT abstract the platform differences is they type of issue is exactly opposite of what Xojo should be doing…

Not doing that type of work makes the product less attractive to both citizen developers AND Pros (though the Pros can more easily work around the issues)

I am speaking of thing more generally that just URL connection…

Also backwards compatibility is a big del to me… My employers has a lot of old machines…

API 2 makes supporting them difficult… It really did make a mess for long time users… For now I think we need an option to only autocomplete API 1 code and be able to set warning for API 2 code for projects that we have to ALSO compile on older versions for those machines even if we whale to use a few #if XojoVersion statements…

Not being able to do this will stop more that a few from updating their Xojo versions… It’s why even though I have a current license I am still using 2019R1.1 And likely will continue using only that. So why should I renew?



I have been a Pro customer for as long as there has been a Pro level. Xojo has relieved me of many thousands of dollars. Yes, I do make enough money out of my products and contracting to afford it, but it has irritated me that although I have been using it for two decades (99% desktop development), I still have to pay a bunch more money to Einhugur and Monkeybread for add-on functionality that should be part of the product by now.

Then came API 2.0.

Now I’m stuck with 2019r1.1, since there’s no ways I’m gonna convert probably a million lines of code. I don’t plan on throwing any more money at Xojo, unless I’m forced to because my apps no longer run on the latest OS from Apple or Microsoft. It looks like I will be forced to stick with Catalina to run the IDE, but it looks like compiled apps still run on Big Sur. If needs be, I guess I’ll pony up for the Desktop-only version.

Anyhoo, here’s a list of my gripes (mostly, if not all, reflected in others experiences above)…

  1. All the development options other than desktop/console seem to be pathetically undernourished. iOS is a joke. No-one cares about Android. Web 1.0 was a bear to get to run smoothly and lacked so many features that it was a joke. Web 2.0 appears to be (from user’s comments) a joke too, at least currently.

  2. Every release has (usually different) show-stopper bugs. I was forced to use CURLMBS since the previously-working HTTP widgets don’t work on HTTP 1.1, and the new URLConnection stuff doesn’t work cross-platform either. They might be fixed now, but my CURLMBS-based solution works fine across three platforms.

  3. After 20 years you’d expect to be able to run apps that use more than one hardware core or thread. I spend a LOT of time fiddling about trying to get multiple threads to stop causing UI issues. Yes, I know a string-and-sealing-wax solution has been pre-announced, but I’m not holding my breath.

  4. I believe Xojo is horribly under-manned, considering the number of platforms they support (and plan to support). That’s a good enough reason to stick with desktop only and improve the language and frameworks that support it. If I want to support, say, Mac and/or iOS only, I’d use (and I do) Apple’s amazing Swift language and SwiftUI cross-Apple-platform frameworks, which are supported by a huge development team, and it shows. Sadly (sic) I have to support multiple desktop platforms, and I see little or no (usable) progress there.


Multiple threads won‘t get you multi-core.

Thomas Tempelmann did multi-core with Xojo in 2013 - see http://www.tempel.org/RB/MultiProcessing

So to say Xojo has been asleep at the wheel would be a massive understatement.


Xojo just isnt inherently preemptive thread safe no matter what

There are still gotcha’s and things that will blow your toes off

A thread calling back into Xojo CAN NOT do anything more then set an intrinsic property (like an integer, double, boolean etc) It cant use ANY objects or reference counted items (strings or arrays)

Its severely limited

The only really “safe” way to really use mutti processing in Xojo is with multiple processes (usually as helpers) and thats a bit of a pain since its not built in to Xojo to make it easy to create, start and communicate with helper applications

This should have been made possible from within the IDE long long ago - I totally agree


I’d like to chime in with some personal views as well.

You know I had been Xojo’s German Developer Evangelist for about 5 years. As such, I had been promoting Xojo to new users on one hand, and supported local users for free on the other hand. Which kept me quite lucky. I think I can say I gained a lot of programming experience and insight, and from this point of view I owe a lot to Xojo. I couldn’t have survived with my old design job where income was on a straight line downwards since early this millennium.

Nonetheless I tried to keep a critical viewpoint all the time, and I learned early that sometimes you have to go long ways to get a result that should be easy to attain, and that severe bugs and important feature requests could stay open for years. Yet, I saw impressive potential in the product and was sometimes surprised by the fast addition of new features or even whole new platforms.

Starting with iOS, that flow stopped and began to reverse. The idea of the Xojo framework, which had not been discussed with the user community, caused a lot of backfiring until years later it was deprecated. Which personally meant hundreds of hours of development time being ruined.

So, while I admired that the company is not unable to change, I had to realize they will decide things from their own viewpoint, and they don’t care much about keeping their promise to provide a RAD for their users if it dictates them so.

That viewpoint clearly shifted to new users solely a few years ago, and at the same time I felt secrecy and mistrust rise behind the scenes. Which startled me. I had gotten to know a very different, open-minded and friendly company. It was shortly after when they decided to cut down local support and let Antonio and me go. Personally, that threw me in a critical financial crisis, so in case you wonder, Xojo, Inc: I think that balances the gratitude mentioned earlier.
(I survived, and because of the skills I learnt during that time)

Don’t be alarmed: I am not mad about it and will not start another rant here!
(I recommend Ani DiFranco’s “I am not angry anymore” as soundtrack at this stage)

Still I believe you made awfully wrong decisions at that time. I am certain local sales have gone down since you cancelled translations. (And no: I do not want that job back. But I still receive phone calls and emails fro old-time users in need of assistance, which you did not want to happen anymore. I think it was an awful mistake to cancel that. You know the sales numbers, not me. But I am quite certain you can see an impact when you compare your figures to internal decisions in the past.)

Many excellent points have already been given here explaining the disappointment of long-time RB/Xojo developers. I do not think I have to stress them myself. With just a handful of dedicated developers against even more platforms to support, with ever-changing targets and a list of serious bugs growing instead of shrinking, an IDE losing features over time: How attractive do you see the product on middle terms for your target group, new developers?

Please realize we are not ranting because we turned into enemies.
We are in despair about our favourite development system going down.
It was – besides the once great and RAD IDE – the user base that made Xojo what it was.
That one feels driven away. An it’s not only a feeling. Will you suspend my forums account too for speaking out freely?
The only thing that makes me stick to Xojo is that currently there is no serious native IDE bringing the same ease of use. But how long will that be the case?
Please reconsider your steps now before it is absolutely too late.

I mean, surely you can do with your company whatever you want to.
But if you cannot explain situations like kicking out Norman, first from development team, then from the forums: Can you really justify them before yourself?

Realize we are not mad at you all. We are deeply worried about what has become of our IDE, and how that much potential can get ruined so easily because you decided to cut communications with your base. Only you have the power to change this situation.


P.S.: This might be a bit much to read, but I think it might give a good explanation for the bewilderment many of us experience(d) with Xojo framework/API/Web 2.0:
WARNING! (Mildly) offensive language!


Very interesting link. Thanks for sharing.

That’s a REALLY good article and it provides real-world reasons.

1 Like

When I replied to Geoff I said that I don’t think he really cares. Otherwise, things would change. In a prior email he gave me a list of this and that. I don’t care about reasons. I don’t care what he says. I care about a change in behavior. Geoff has a lot of trust to re-earn if he really cares. Ironically, if Geoff did his job we’d all be happy devs.


ONG that link is SO FUNNY !!!
I particularly love this part

I literally laughed out loud (my wife thought I’d lost it)

1 Like

Yep, the article is well worth a read :laughing:

1 Like

We need a +1000 emoji :stuck_out_tongue:

All I can think about when reading that was:


Fuck yooooouuuuuuuu. Fuck you, fuck you, Fuck You. Drop whatever proyect you you are doing because it’s not important. What is important is OUR time. It’s costing us time and money to barely support our shit, and we’re tired of it, so we’re not going to support it anymore.

So drop your fucking plans and go start digging through our shitty documentation, begging for scraps on forums, and oh by the way, our new shit is COMPLETELY different from the old shit, because well, we fucked that design up pretty bad, heh, but hey, that’s YOUR problem, not our problem.*

We remain committed as always to ensuring everything you write will be unusable starting now.

Please go fuck yourself,

Xojo Web 2.0 Team

For me the most relevant part was:

Google engineers pride themselves on their software engineering discipline, and that’s actually what gets them into trouble. Pride is a trap for the unwary, and it has ensnared many a Google team into thinking that their decisions are always right, and that correctness (by some vague fuzzy definition) is more important than customer focus.

I’m going to pick a few somewhat arbitrary examples from other big software systems, but hopefully you’ll be able to start spotting the pattern everywhere; that pattern being: Backwards compatibility keeps systems alive and relevant for decades .


Successful long-lived open systems owe their success to building decades-long micro-communities around extensions/plugins , also known as a marketplace .

What Bob, Hal, Tim, Charles, Thomas, Axel, etc provided …

Backwards compatibility comes with a steep cost, and Android has chosen to bear the burden of that cost, whereas Google insists that you , the paying customer, bear that burden.

API1 -> API2
Web 1 -> Web 2

Because every time you shake loose some of your developers, you’ve (a) lost them for good, because they are angry at you for breaking your contract, and (b) given them to your competitors.

ABmaterials at B4, Xanadu at PHP, …


Thom shared his post about why his app, Beacon, is not on mobile devices

I understand the concepts. I’d be happy with anything that allowed me to pass off, say, numerical computations to run on other cores. The only stuff I would be passing is plain ol’ integers and doubles, and perhaps strings and booleans, so reentrant code wouldn’t be an issue.

If that isn’t for very short computations where the communications overhead would add more than pure processing time needs, you can do so with console apps doing that stuff for you. What Xojo intends to add with their worker class is basically just a wrapper that makes their handling easier, but nothing that couldn’t be done already.
And for macOS/iOS, Thomas Tempelmann explained how to use the system’s parallel processing APIs like Markus pointed out somewhere here.

1 Like

Yeh, but I want this to be built into the language and framework, easy to use, and transparently cross-platform. In other words, it should just work. I guess I am spoiled by Swift and its easy to use parallelism.

1 Like

Agreed. It took me some time to build a solution that’s partly xplatform and extendible, meaning it works on macOS and Windows. For the Windows part I had to use MBS because of Xojo’s IPCSocket on Windows being bound to file communication caused troubles when several helpers started at the same time.
And no, I don’t see you being spoilt asking for multi-core support in 2020…

P.S.: I have to admit although I consider myself quite Apple API savvy I never understood Thomas’ approach fully. As usual he used quite sophisticated structures …