It’s not that you needed to mention it, but you said “Drop Mobile Development (iOS and Android). Swift and XCode is the standard, you cannot compete with.”, which seemed to neglect an Android replacement.
I guess I could have swallowed a clown fish, yes…
I slept on it and I’m not going forward with emailing Geoff, but I will point him here.
After reading something Bob Keeney wrote about creating ARBD years ago to achieve the same result, I really think it’s not worth the effort to help Geoff.
Geoff has to want to fix the issues. I will point Geoff to this thread. 
1 Like
As a long-term “citizen dev” I’ll kick in my thoughts. (And I’m really starting to hate that term, but since it’s in general use here I’ll allow it.) I develop an open source application that I joined after it was already started in REALbasic and that got me into the product. I’ve branched out to do some utilities that help my coworkers and me do our jobs more efficiently.
My issues are duplicates to what is mentioned above, but since Geoff seems to want to target the group of which I am considered a member, perhaps he’ll understand that there’s a large overlap between the citizen dev and professional dev groups.
-
Fix the bugs! Even those of us who are not making money from programming in Xojo get frustrated over losing sometimes hours trying to track down a bug in our code only to find out something in the framework is broken. My primary application’s code originated in about 2002-2003 and is scattered with #ifs and comments about framework issues. I just hit an issue where an XmlNode method call that had been working for years suddenly flaked out after I changed something totally unrelated in another part of the code, not even in the same function. It’s a reported bug that’s been extant and unfixed for years.
-
Focus. The comments about iOS and Android are spot on. First off, I was never considering doing Xojo for iOS or Android anyway — the license cost was out of reach for someone who is self-funded. Even web, while interesting, isn’t on my radar because a desktop license is all I can justify, especially when I have to supplement it with the MBS and Einhugur plugins.
-
Release model. I can’t decide which I hate more, the model prior to “rapid release” or the one now. What I do know is that I feel like my investment in a license for 2020 has not been returned. There’s one feature — one — in 2020r1 that’s of value to me, and no bug fixes, and it comes nine months into my license term. I don’t want half-baked releases just because three or four months have gone by, but neither do I think bugfixes (especially) and features for the targets I pay for should be held up because another target is delaying a monolithic release.
Those are my big three. There are others, but I’m going to focus on what I think are the most important to me.
3 Likes
I’ll chip in my two cents here. I know that Geoff reads this forum so perhaps there is merit in this topic. I agree with most of the points already raised above but I’ll reiterate a few of them.
1. Pick a market and do it well
This has historically been desktop development and REAL Studio was a good tool for developing for desktop.
Stop diluting the product by targeting platforms that you can’t / won’t support properly. Xojo’s iOS offering is a prime example. It is a disgrace how much they charge for iOS development for a product that is basically a lemon. It is virtually impossible to create a meaningful iOS app with Xojo without resorting to endless declares and third party (commercial) solutions. Xojo is supposed to be approachable to beginners. I’ve been coding with Xojo / RB for 16 years and when I sat down to write a simple iOS app with my 8 year old daughter I did it in Swift because it was easier.
If Xojo is trying to be a “write once, deploy anywhere” tool then they have completely mis-fired. It is simply not possible to reuse code easily between desktop and iOS without countless #If TargetBlah.... It’s been six years and I still can’t use String on iOS for goodness sake.
I’m sure there are people who are interested in developing for Android but I couldn’t care less about it. As previously mentioned, Android users are known for spending less money on the platform than iOS users and making money from an Android app is really hard. Given the neglected state of iOS for Xojo, why on Earth are they spending precious engineering resources developing Android? That is manpower that would be far better spent either resuscitating iOS or (better yet) ditching it altogether to improve the core desktop product.
2. The IDE needs love
I always thought that the IDE was pretty good especially since it makes building and debugging an app straight forward but it has really fallen behind the competition over the last few years.
The autocomplete engine is awful compared to things like Visual Studio. Improving the autocomplete is not sexy or easy to market but it is expected to be good by all developers.
Here’s a few examples of pain points with the IDE:
- Namespaces / modules are broken. Good luck getting autocomplete to work on the method or property of a class within a module unless you declare it using it’s fully qualified name. This defeats the point of namespaces entirely.
- The addition of method and property descriptions was great but if they are more than a sentence in length you can’t read them as they appear in a panel at the bottom of the IDE and that panel is not resizable.
- Xojo needs to add support for method documentation. All major languages and IDEs have an equivalent. For example, in Xcode using Swift, you can use Markdown to annotate the method and its parameters and then if you hover over the method somewhere else in your code then you get a little popover describing the properties and return values. This makes it really nice for third party controls and external libraries.
- External references are broken. The IDE does not allow you to make external a module if it contains classes or modules. What the Hell is the point of them then? Externalising classes and modules is crucial to meaningful development as it allows them to be version controlled and utilised in other projects. Most modules that I create for Xojo have dozens of internal classes but I can’t make them external. This means I need to prefix or suffix every class with a cryptic acronym which just looks rubbish.
- The debugger needs improving. At the very least we need watchpoints for variables so we know when they are changed.
3. The language needs love
I like the Xojo language. I am fluent in C# and Java and so curly braces don’t frighten me but I prefer the BASIC-like syntax that Xojo provides. With that being said, there are some language features that Xojo lacks that make it really hard to (a) implement certain algorithms, (b) difficult to port code from other languages:
- Generics. Almost every other mainstream language supports the concept of generic variables.
Variantjust doesn’t cut it. - Anonymous functions. It should be possible to pass functions to methods in a cleaner way than using a delegate. VB.NET has found a way - so can Xojo.
4. The framework needs fleshing out
I’m currently porting a physics engine to Xojo from Java. One thing that is slowing me down is that I am basically having to port the OpenJDK Math library because Xojo’s built-in maths functions are so limited. There are so many convenience functions in other runtime libraries (Java, .NET, etc) that Xojo is missing. We need fast ways to combine and slice arrays for example.
5. Geoff needs to be more tolerant
It is not OK to try to expunge paying people from your community because they make legitimate comments about the shortcomings of your product. Foul language, etc is not OK but constructive criticism needs to be allowed.
4 Likes
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?
-Karen
3 Likes
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)…
-
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.
-
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.
-
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.
-
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.
2 Likes
Multiple threads won‘t get you multi-core.
Thomas Tempelmann did multi-core with Xojo in 2013 - see Thomas Tempelmann | Multiprocessing with REALbasic
So to say Xojo has been asleep at the wheel would be a massive understatement.
2 Likes
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
2 Likes
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.
14 Likes
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!
6 Likes
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.
6 Likes
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 
1 Like
We need a +1000 emoji 
All I can think about when reading that was:
Dear RECIPIENT,
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 .
and
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, …
3 Likes