To me it doesn’t make sense to spend a dime or make either my business or myself by any means depended on closed-source software. This is a strong factor, which should be considered and added to the long list of issues mentioned above.
3 Likes
To me the most disappointing thing is perhaps that Geoff might read this and think “well I can just ignore those whiners since they are cheering for Xojo’s demise”
I’m not
I WISH, really truly wish, they could & would fulfill the ambitious idea of being a great x-platform tool
And I’d love it IF they would seriously listen to the criticisms and complaints and rather than just ignore them actually DO something to correct them & get better at doing what they do.
And make a great tool for professional developers, and hobbyists, citizens alike.
I do not believe those goals are mutually exclusive.
For many many years I truly thought this was possible.
But the longer I worked there the more it became clear there was no intention of doing that.
15+ years of the same complaints over & over says they just dont, cant, or wont
I dont know which
5 Likes
I’ve been finding myself thinking that too. Using PHP has been delightful.
Yep. We all wish. But eventually after being worn down by all the bugs and watching how Xojo behaves tyou end up realizing things are not likely to get better.
I’d pay more for Xojo but it’s gotta work. That’s the ironic part of the Xojo price hike. I mean 50% or even 30% markups would be fine but OMG fix the bugs.
1 Like
Actions speak louder than words
2 Likes
We see this everywhere, look at all the changes in Swift and AppKit API for Swift over the pass years. Engineers love to throw the “Modern” moniker into all of these rewrites.
But in the case of XOJO having such as small team I never understood why they insisted in mapping the code to the actual framework implementations, since they could easily hide all the refactoring behind the scenes without having to mess much with the actual API and language.
You leave out the important information that Swift was considered “in development” and “not API complete or stable” - basically a beta version (though a very impressive one) until version 5 (and open source since version 3):
Swift 5, released in March 2019, introduced a stable binary interface on Apple platforms, allowing the Swift runtime to be incorporated into Apple operating systems. It is source compatible with Swift 4.
Swift 5.1 was officially released in September 2019. Swift 5.1 builds on the previous version of Swift 5 by extending the stable features of the language to compile-time with the introduction of module stability. The introduction of module stability makes it possible to create and share binary frameworks that will work with future releases of Swift.
2 Likes
This has being asked many times. Their common aswer is “it cant be done, that is not how things work”, so they break some part of the api on almost every release.
Poor sight maybe?
2 Likes
Agree, but my point here is that when I look at many of the changes in AppKit (ObjC/Swift) over one SDK (and I know changes do actually break your app) you tend to see there is this bit of disregard for compatibility for sake of the “modern”. I see it in Node and so many libraries. Not that Im comparing Apple or anybody to Xojo, but just wondering about Xojo’s rationale. When the first “Xojo” Framework appeared with iOS for me was the lets map all of these iOS requirements and JAVAisms into this whole “modern” framework, then you look at Web 2.0, DesktopControls, and you start thinking that some of these misguided decisions were maybe more influenced by taste and opinions of a developer than Geoff himself.
I always said that the beauty of the compiler /IDE is that they could have disconnected the language types/constructs from what actually gets compiled and the underlying framework implementation. A lot of the languages features and types could be transpiled/faked, but they insist that why I code has a 1-1 equivalence to the framework, and I doubt that that’s a deficiency of the compiler.
The Xojo framework was a different beast from the renaming of everything
Even when it rolled out there are/were several advantages - many even listed at various events like XDC
- it would allow for much more extensive stripping of the framework itself - something that can’t happen with one giant global namespace
- you could use it side by side with the old api’s so there was no impetus to rewrite everything immediately (something that is increasingly difficult as Xojo disables showing API 1.0 tips & docs)
There were some thing that didn’t happen - like rapidly expanding it
And the IDE needed a bunch more work to handle the autocompleting of namespaces better
But, detractors convinced the powers that be that all this wasn’t worth it
And so now we have API 2 
1 Like
I love to hear stories like this, I could only speculate in my mind of what sort of monster Xojo is behind the scenes. I haven’t used Xojo for any paid job in ages, I use it randomly and yet still renew my license almost every year. I really like its idea and potential, it is sort of the dream tool you hope you had…
Yet some times you get really frustrated trying to understand the why of things, the energy and effort they put into these strategies are extremely valuable. I don’t see how they can keep up with all of these targets, and mature the product, for me is beyond the bugs.
If I was Geoff what would I do? I don’t think they have the capital to expand the engineering team, nor he can afford to loose sales. Then he seats on what I can only imagine as a gigantic monster/monolith product that I don’t see how it can be improved and made sustainable in the long run.
I look at how MS have all of these 1-1 API in Xamarin for MacOS and IOS, or even Google’s Flutter/Dart implementations and just wonder how is Xojo gonna compete with that.
I don’t know but sometimes I think is probably best if they fork some effort into a new product. Like others said go back to desktop and start fresh. Build a new tool-chain, separate the IDE and the compiler, etc…
Define what “native” and “cross-platform” really means for Mobile, here I can only imagine starting with an abstraction of generic features and expose important native features here and there. Specially because the identity/look of what makes a native mobile app is quite irrelevant in mobile applications now days. As long as the expected features and behaviors are there the look of a mobile app becomes a thing of ascetics and usability and not much of what is “native” and what is not.
(If I want the latest bell and whistles you will go to Kotlin and Swift or endup with declares and plugins, so why bother)
1 Like
Nothing will change at Xojo until there is a new leader which isn’t likely.
3 Likes
A new leader at Xojo is as likely as them fixing all the bugs 
2 Likes
Which really should be called API 3.
3 Likes
For those that want to force the API 1 to always show in the AutoComplete open the Xojo prefs file and make sure the key “Show Deprecated Autocomplete Items” is set to true. That should allow you to continue seeing API1 calls in autocomplete in newer versions of Xojo. This isn’t exposed in the IDE preferences.
16 Likes
Sneaky. So that’s how the Xojo engineers don’t suffer the same inconvenience.
1 Like
where can I find this Xojo prefs file?
~/Library/Preferences/com.xojo.xojo.plist
3 Likes
This prefs file holds some interesting settings. Thanks for sharing this.
1 Like
I saw some interest stuff too… but not sure how to make use of it
Simply look at the number of post in the forum for this month as “web” vs the number of posts for at any point in time prior to today. The activity ids going down, despite the fact that questions about switching to a new API would suggest it should be going up.