I want Xojo to succeed. My living relies on it. This is the same for others I talk with. We all NEED Xojo to succeed. For us it needs to do more than just survive from day to day. We need it to grow. Our businesses depend on Xojo. We need it to be stable. We need it to be dependable.
The recent API changes seem to ignore the concerns of those businesses that need to support customers that may be using legacy OS versions and legacy hardware. Some of the API changes have spawned their own new bugs that make adopting it problematic.
2019r2 makes it harder to go back and forth between versions. We all realize that Xojo never guaranteed that this would work well; but until now Xojo never deliberately made changes they knew would break this ability. We dont do this because its fun. We do it because our customers demand it as they run older versions of Windows & macOS. Xojo used to make this a simple matter. Now its not so simple.
We’re put in the position of either rewriting code or leaving it with tons of deprecation warnings for no gain in functionality*.
Some of the changes may silently break existing code. A third party supplying a control to a customer can be broken when that customer simply adds the Opening event. This may silently render the control non-functional. This is a support headache for all vendors of third party controls with no real means to fix the problem AND still attract and sell to a wide audience of Xojo users; some of whom are still using older versions. It would be nice if Xojo’s third party market was large enough to not have to cater to old versions; but it’s not.
Many of us are very OCD and all those warnings drive us all crazy as something really important could be hiding in there. So we examine all this code and IF we rewrite it we can’t go back to old versions at all. Certainly not if we use the renamed events. Thats a problem.
In some cases the code that now has deprecation warnings may be many years old. In some cases more than a decade. And if we have to rewrite it there’s no reason not to look at other tools and technologies for those rewrites. I’m not saying that this is what we want to do. We’d rather not. We like Xojo which is why we have used it – but the issues going back and forth between versions make it sufficiently difficult that if we’re going to have to rewrite we might as well look at what other tools exist.
What I’m hoping for is for Xojo to give me, us, a reason NOT to have to even think about such a move. More a direction that says “we value these full time developers” as that seems to have been missing lately which is why I’m even writing this. Full time developers feel like they are simply ignored, their concerns not understood, and generally that we’re just around to pay for Pro licenses and nothing more.
More targets isnt what many of us are looking for. We need a tool that is reliable, eminently capable on the targets it has now & in the projects we use it for, and mostly bug free. We need targets that are capable of taking on real world significant applications on the day we get them. Not ones that require a significant number of declares for basic functionality. And ones that can scale well and handle many users without having to resort to some of the issues that arise with web apps.
Professional level features will retain existing users and still help the citizen developers that find Xojo. A better reporting tool, PDF export, built-in Date and Date Time controls, and a better grid component, are just a few of the items that would add real value to the product that everyone can use today and keep users from outgrowing Xojo.
There are a number of existing users that are already phasing Xojo out of their businesses and some are actively looking at alternatives to Xojo. Many of us feel that our needs are being purposely ignored.
If we knew that Xojo was intent on becoming more than a middle tier tool and dedicated to being a truly professional tool we’d be happy to pay more. A lot more.
Our livelihoods depend on Xojo and if that meant we all bought Pro+ licenses I doubt any of us would lose much sleep over that price tag. Its the price of doing business.
Please give us that reason.
*Most of 2019r2 did not improve functionality. macOS for folderitems got warranted updates along with fixes for the the select color panel. Generate and parse json were added and a few url connection fixes. But most of API 2.0 made few other must have changes.
Update Oct 29, 2019 : I made this post available to Xojo Inc prior to removing the password protection. So far I have had no reply or comments.
I couldn’t agree more, Norman. It’s really sad that all API2.0 did was introduce a completely new way of doing things that is not backwards compatible. It fixed nothing really. A serial control bug I found 6 years ago is still there. Just new methods to access that bug now I supposed. I think your best statement is:
“We need targets that are capable of taking on real world significant applications on the day we get them. Not ones that require a significant number of declares for basic functionality.”
If I need a declare to do basic functionality (that everyone also uses), why can’t Xojo just build that into the code themselves.
I get the feeling they are more driven by a cult of personality (ie: “we have to have cool things like VAR instead of DIM) than by really any real sort of improvement. Who cares that other languages use VAR and we don’t?
I find zero benefit to this new API. Oh we are told we can now have truly cross platform code that works across desktop, web, iOS, etc. Oh really? Hmmm. One fact alone is that web apps have an event for one the page is built on a server and another for when it is displayed on the browser. That there will destroy all sense or true cross platform ability. The second is iOS. I can create a TCP socket in a desktop app and set it to listen on port 23. I don’t think Apple allows an iPhone or iPad to effectively have a telnet server on it. So again, my code for the desktop won’t work on iOS.
I would rather have had Xojo fixing issues with controls that are years old and creating a truly usable iOS target instead of creating this fantasy of API2.0. They are forcing us to use it because their last great thing, XojoCode or whatever you’d call it with all the name spaces was a miserable failure and no one used it. Now they are forcing us.
So yeah, it’s a joke and I am contemplating NOT upgrading and not renewing.
Hear, hear!
I have to say I’m in the looking elsewhere camp but have so much invested in Xojo that I feel trapped – into doing work with no payoff for changes that are frankly stupid.
So, do I bite the bullet and fix 30k warnings, which isn’t a trivial exercise – a project with 155 warnings took 3 hours to fix, test and deploy, so not looking forward to the lost development time reworking old projects? Or, do I invest that time in a marketable skill with a new stack and make my business saleable too?
Most of the api2 stuff is of no benefit! Mostly change for change sake.
Sure, there’s some good stuff – prepared SQL for one, but I can’t think of anything else that couldn’t really have been included in the existing framework that couldn’t have been enhanced rather than deprecated. And immutable dates – what! Xojo can’t be *all languages* – stop it, stop it right now!
A much better and easier solution to “index” issues would have been to name parameters tips properly!
Silently breaking folderitems caused chaos in what appeared to be a good compile (and no exceptions appeared in logs) is just unforgivable – so much for “you don’t need to change anything right now”. Bull!
I by no means use the entire toolset (almost all web now), so there will be bits that may have improved life for other developers (and hobbyists I guess), but from my POV this release is a disaster and I reckon most of it should be rolled back.
Almost all my work now is web, so desktop, iOS, Pi, Android (whenever) and console are pretty low priorities. But these projects are HUGE with dependencies on plugins (MBS, GraffitiSuite and a few others) that if I change to API 2 may cause even more issues, and if they change then I’m forced to API 2 anyway! Argh!
I’d rather see web 2.0 and be able to have more than one session per instance of the application (more than 2 or 3 users sharing an instance is dangerous…despite those who swear otherwise – we run zillions of instances of the app with haproxy dishing out connections just to avoid that situation and have zero issues)
I love working with Xojo generally – but this unfolding disaster may be a straw too much.
Matt Gardner
These changes have prompted me to exit the paid third-party market. There’s no way to support 2019r2+ at the same time as older versions. Either it doesn’t compile in old versions, or triggers warnings and potential misbehaviors in new versions. Considering how small the market is, there’s no point.
As for my own projects, I’ve been seriously considering porting my main project to a Vue.js web app. While 2019r2 doesn’t directly play into that, it does paint a picture of Xojo’s priorities. It was decided that these changes – most of them functionally neutral – were prioritized over features that Xojo is behind the curve on, like iOS 13 dark mode support.
I’m very thankful for the improvements to things like JSON and FolderItem. But those didn’t need to go hand-in-hand with renaming everything. I was on board when the changes were just for things that needed changing. I’m less convinced now.
Xojo’s disinterest in the professional market is why I’m considering moving on.
I fully agree and couldn’t have written it better.
So i’d like to add another aspect. Have a look at Feedback Case #51602.
Date.ShortTime (API 1) won’t get fixed. It’s deprecated. One can use DateTime (API 2) instead.
Sure we can/will/have-to, but…
Fact is: we – and a lot of Xojo’s customers will be (or have to be) using/maintaining code containing API 1 for many years to come.
Is Xojo going to support us or not? It will take months/years to completely rewrite existing large codebase (and it doesn’t make quite sense to do changes of proven and tested code just for the sake of a nicer syntax with different behavior, unless being forced to – but then again: why not just do it in some other development tool…)
We already have a workaround in place for Date.ShortTime: if Linux (Bug 49502) or XojoVersion DateTime).
Look at that again: It’s a workaround. And the list of workarounds get bigger with every new Xojo version. Even the workarounds themselves get more complicated and tricky with that kind of suggestions (fixes only available in different/new classes).
Our codebase is huge (and shared among various projects) – we can’t just switch from Date -> DateTime. And mixing the two is also not a very good idea.
Is this what Xojo wants their Customers/Developers to do (all of them need these pile of workarounds, but first have to stumble upon it – more likely: their customers reporting bugs -> resulting in even more bad reputation for the state of Xojo’s Framework)?
Is this good for Xojo’s reputation? (buggy framework, no fixes for years for “trivial” functionality, …. much more – just read the forums…)
Is Xojo interested in supporting their long term customers with existing codebase? Or do they just try to force everyone to use API 2 asap (even if not realistic to do so immediately in some situations)? Does Xojo just want to introduce new/shiny stuff to attract “newbies” and “hobbyists”? Or does Xojo want to be a tool for commercial companies, too? It doesn’t look like that recently… and 2019r2 looks like yet another waste of time (and money) to Xojo’s existing customers needing a stable and reliable framework to improve their existing commercial products.
By the time I have written this, Xojo engineers would probably have fixed this particular Date.ShortTime case (they could just do that suggested workaround in their Framework… 🙂 for the benefit of all their long time end users / developers…
And just to make sure: this is not about “bashing API 2”. That’s a good foundation for the long-term future. We appreciate it! Congrats to Xojo to finally have delivered it!
It’s just that we need quite some things for a long time already (Windows HiDPI improvements, Windows Graphics Rendering issues, Linux/RasPi: print crashes still!, better macOS support for current OS versions – such as monospacedDigitSystemFont, quite some reported bugs that might bite us/our-customers sometime, …)
And what do we get instead? Features we don’t need “right now” and don’t help us to make our products better “now”. But we get to do more workarounds in our codebases.
Not to mention all the “producitivity issues” that have been reported (and Norman has explained nicely, since migrating big projects will need switching between XojoVersions for quite some time) – productivity hasn’t been improved for our needs/situation at all recently, on the contrary.
Is Xojo the right tool for our future? I don’t know. What’s been delivered with 2019r2 certainly isn’t and leads to question that in more detail. But then again: that’s just one release – and the question might be answered better with what’s coming next. Xojo can give us all a reason wanting to continue our existing work with their product.
when I first started reading this post, I thought that it was going to be non “level headed” as this topic has been a “hot topic” or issue for several people lately. I was wrong. I am glad I was wrong and I was very wrong. this is very “level headed” and very well written.
I agree with Norm. I have left Xojo for new development (have well over a decade of legacy code to still support in Xojo) and moved on to “other platforms”. I rather stay with Xojo. I much rather stay with Xojo. but I can not dependent on the platform right now for my business.
things like the paragraph that starts “Professional level features will retain existing users….” spell out the items that anyone that makes money off of Xojo needs/wants. please help us with that.
please give us more bug fixes to make the framework/platform more stable.
if Xojo addressed the topics within this post, I would renew my Pro license today. the only delay would be me finding my wallet to get my credit card out. and if Xojo would give us those items that I referenced earlier (like grid, PDF, etc) I would upgrade to Pro+ just as fast. not only would I renew/upgrade immediately I would stop my development on other tools/frameworks and use Xojo (almost) exclusively.
I wish the best for Xojo (the company), Xojo (the framework/language) and Xojo (the platform).
In my case, there are still a number of issues in both the framework and IDE that exist in 2019r1.1 and earlier which will never be fixed unless I move 14 rather sizable commercial projects to API 2.0. I know that the claim of moving forward to 19r2 doesn’t “demand” that I move to API 2.0, but the simple act of loading and saving an existing project with absolutely NO changes results in modification to every code file in a VCS project. This, in turn, completely hoses our version control for absolutely no reason.
If I’m so foolish as to actively use “Save As …” and save an API 2.0 version, I run into a multitude of errors that are simply related to the use of variable names that are now reserved/keywords in the new language. Add to that that one of my mid-sized tools has over 11K deprecation warnings (which my coding OCD does demand that I fix), and there is no way that I’m going to move that project forward. I’m not even going to try to examine my larger projects under these conditions.
If long term bugs and performance issues are never going to be fixed in the API 1.0 branch, and moving forward to API 2.0 breaks functioning code in completely unnecessary ways, I would be insane to continue investing in the Xojo platform. I stated it multiple times in the Alpha/Beta testing cycle – API 2.0 should have been handled very differently. The creation of a complete spec which would be submitted to the core developers for discussion and comment, treating the release in a manner similar to the Cocoa shift which would mean that we could continue using API 1.0 safely while continuing to receive bug fixes and IDE improvements while API 2.0 was ironed out, and actually LISTENING to the pro-level users of the tool chain during this period, should have been paramount in Perlman’s management of the process.
TOLIS Group chose REALbasic back in 2003 because we needed a development platform that would allow us to create OS X applications that had a proper look and feel that we could not achieve with other development platforms such as Java Swing. TCL/TK, or Python and Tkinter. Now that we have updated toolkits in the form of JavaFX and wxPython which do allow the creation of UI’s that feel native on the pkatforms, that reason is no longer valid. We can leverage our existing deep knowledge of both Java and Python to create applications on all of the platforms we support – many of which Xojo does not support – with no further financial or training investment (I was the Xojo coder in my engineering team).
For TOLIS Group Inc., 2019 will be our final update renewal unless something really amazing changes in Xojo. The really sad side-effect of this, and one that many have not even considered, is that it also means that we will no longer be renewing our support for things like MBS Plugins, Einhugur Plugins, AppWrapper, ArBed, RegExExpress, and probably a few other Xojo-related tools that I can’t remember at the moment.
So, Xojo’s choice in this move not only affects their revenue from my team, but it also affects the business models and revenue streams of many very useful and important partner organizations.
Are a few newbie users – that the new API 2.0 seems to be specifically aimed at – worth the loss of your core professional developer base?
I don’t think anyone can disagree with your commentary here. If this is a “call to action” I don’t know what the goal is. The ship has sailed.
I find it amusing personally that the Xojo community by and large distrusts/dislikes open source software yet finds themselves continuously displaced by Geoff and company. Fool me once, shame on you…
This is why free and open source software exists. Tim Jones makes excellent points that the technology has progressed, the markets have shifted, and for his company he does not really need Xojo. So be it.
These threats of long time members leaving the community do not impact Xojo. They were never concerned with the third party market or past revenue. They know if you have enough production code in play you will eventually have to renew or spend 10-1000x more hours migrating to a new platform completely.
What we see here with API 2.0 *is* the course correction. I can only conclude Xojo/Geoff do not want to be dependent on long standing members with influential opinions and feedback. They should go ahead and lock the beta forums because outside of spending time creating tickets they have no desire for a meaningful feedback loop.
There is a possibility that Geoff is right and this will help them long term. I remain optimistic but so long as they have no regard for the third party market a platform they will never become.
And I think that’s okay. I am nostalgic mostly for Xojo but let’s be honest it is not really that great of a tool anymore. It lacks every consideration of a new language or platform in 2019+.
Strategically a private investment firm would say squeeze every dollar out of your user base you can. Geoff has decided to be courageous and do the exact opposite. Let us hope he is right.
“There is a possibility that Geoff is right and this will help them long term.”
Every semester here in Phoenix, I offer an after school program aimed and middle-school kids where I used REALStudio/Xojo. However, the confusion caused by the changes in r2 mean that I’d need to reinvent my classes, and I’d rather do that in Python and wxPython since the Idle/Glade combo gives me the right combination of design and code capability and I know more about Python than Xojo. So students who were downloading Xojo and using it in the free mode are now getting a command for installing wxPython with pip on their Chromebooks …
I’ve never really understood why Xojo is so focused on citizen devs… they are not (typically) earning a full-time income by using Xojo, so the value proposition to them is not nearly as high as it is to full time professional developers. People who depend on Xojo to pay their mortgage, employ a dozen people, etc… those are the folks who are a) willing to pay just about whatever Xojo is asking for a license, and b) are technically competent enough to be productive users without a HUGE technical support load.
By the same token, Xojo has never really been able to compete with the big boys as a development environment. XCode is far more capable for building stuff for Apple. Visual Studio has far better tools for building for Windows. So pros focused on just one platform are not likely to even want to mess with Xojo, because it is seen as a toy. I think that Xojo management realizes this, thus the focus on the hobbyists, etc…. they lack the technical skill to jump into Objective-C, Swift, C#, Java, PHP, C, C++ and the like, and Xojo is just approachable enough for novices to actually be productive.
As a result, Xojo is trying to be usable for All The Things™ to attract as many citizen programmers as possible, and has stretched their development team WAY too thin. As a result they are under-delivering rather severely for the professional users. Hobbyists may think it’s great, but the warts all over the product really get in the way of professional adoption.
API2 is just another example that demonstrates this continuing trend. Xojo clearly does not seek to attract and retain professional developers any longer…. so the professionals will leave.
To be perfectly clear: I *really* want to keep using Xojo. I develop and sell desktop applications, and there is not currently any other development tool that I’ve found which can compile native binaries for Windows and Mac from a single source base with the same level of capability and usability.
But several have been announced, and will be hitting the market in 2020. Since I have to re-work all my existing legacy Xojo projects in order to reliably move up to 2019R2+, you can bet I am going to aggressively look at converting all my Xojo projects to a completely new ecosystem as soon as something viable becomes available.
“We need a tool that is reliable, eminently capable on the targets it has now & in the projects we use it for, and mostly bug free.”
Have been saying that for years. Will be interesting to see what is being said at the MBS conference – isn’t Xojo (Geoff?) attending via video?
As for those moving on to other tools, I’d be curious as to what you chose and why?
Geoff and Dana are attending in person as far as I know
For TOLIS Group’s efforts, I’ve already started shifting 3 of my primary Xojo UIs to wxPython and will eventually shift them all over. We use Python for so much of our core tools and we already have 4 very capable Python designers on staff. Adding the wxWidgets toolkit is very easy in that case. And, the Glade layout editor is almost as easy to use as Xojo, but far more consistent.
I’m also doing this in my after school sessions for mid-teens.
I’ve been using Xojo since it was called CrossBasic, but I stepped away from Xojo for the most part from about mid-2016 through mid-2019. When I returned, not much had changed. And that is *not* a good thing. I found almost nothing new or noteworthy in any aspect of Xojo. The forum was still 95% the same old-timers who’ve been around forever. This is clearly not a thriving ecosystem. Self-sustaining, maybe, but hardly growing. Is it a lack of resources?
About a decade ago, I wrote a long letter to Geoff Perlman explaining why I thought REAL Software should go open source, the gist of my argument being that going open source would greatly expand the user base and also bring in some investment capital for hiring additional staff. He wrote a long letter back which I would summarize thusly: “Blah, blah, blah, I don’t wanna.” Since then, we’ve seen *many* companies with open source development tools (in some cases mere JavaScript frameworks) raise tens of millions of dollars each in funding. Even from a purely selfish standpoint, I am fairly certain the founders of most of those companies have pocketed more money than Geoff ever will. To take one extreme example, Xamarin, a tool roughly in the same cross-platform kind of space as Xojo, raised over $80M in six years before being acquired by Microsoft for more than $400M. But the more important point is that these companies have been able to use their funding to build *large* development teams as well as benefit from bug fixes and other contributions from outside developers. The contrast with the extremely resource-starved Xojo is stark. Even more stark when you consider the monumental ambitions of Xojo. Xojo’s ambitions in the development tool arena are greater than anything even companies like Microsoft, Apple, or Google have ever attempted. And they think they can do it with five engineers? It’s ludicrous.
When Xojo’s iOS support shipped, it struck me as somewhere between anemic and pathetic. It let you develop an iOS application in almost exactly the same way REALbasic 1.0 in 1998 let you develop a Mac application. How much better is it 5+ years later? My impression is progress has been scant (although I’ll be delighted if someone can counter that impression). At any rate, would anyone really advise a newcomer who doesn’t know either Xojo or Swift to choose Xojo for iOS development? Why would anyone choose Xojo? Is Xojo more RAD than Swift? With all of its limitations, workarounds, delays, bugs that never get fixed, almost no third-party help or tutorials or books available, etc? Or perhaps you want to use the same code to target both iOS and Android? Well, I wouldn’t get your hopes up about Android, and your code *won’t* be the same, not by a long shot. If you’re only focused on iOS, I can’t see too many compelling advantages to Xojo compared to Swift. If your highest priority is to target both iOS and Android with the same code base, there are alternatives like React, Flutter, or Qt that aren’t nearly as easy to grasp as Xojo, but you’ll have a ton of help along the way from a huge, active ecosystem.
All of these questions or issues confronting an individual newcomer are even more acute for companies choosing what technology to bank their critical applications on.
For me, I still love Xojo. The language and the all-in-one-place project environment just give me a kind of joy that I have found in very few other languages/tools. I take pride in writing efficient and elegant code, and the Xojo language makes it easy. I would *love* to be able to make a living with Xojo and I’m quite envious of those who do. Unfortunately, I’ve never been able to find more than one random contract gig every year or two, and even though people are consistently happy with my deliverables and I do get some follow-on maintenance work, these gigs are with companies who just have one or two specific applications done in Xojo and it’s not worth it to them to have a full-time staff person for it.
There just aren’t many Xojo jobs to be had. Even compared to other development tools that you might consider “niche” tools, like FileMaker or Qt, the lack of Xojo jobs is depressing. I’ve been working the past couple of months for a company that contacted me out of the blue on Upwork, but in general a search on Upwork for Xojo jobs will almost always yield 0 results. FileMaker or Qt/QML usually has at least 40 or 50. Or on Indeed.com — only two jobs listed for Xojo, nationwide. And neither one of these is actually a Xojo job; Xojo is just one of many desirable skills listed. Compare to FileMaker with 760 jobs listed, or Qt/QML with over a thousand.
I really want Xojo to survive, and preferably not just merely ambulating along in an undead zombie-like state. I’d really like to continue using Xojo, and preferably without feeling like I’m an idiot for wasting my time. But since I’m primarily interested in macOS and iOS development these days, it’s getting harder and harder for me to justify continuing with Xojo, when there are still so many gaps in functionality and there’s so very little chance of making a living with it, as opposed to just jumping to Swift full-time, which comes with no real limitations on what I can accomplish and also (and perhaps most importantly) allows me to tap into the huge and growing number of available Swift jobs. That’s the calculation I’m wrestling with as someone with 20+ years of Xojo knowledge; for the newcomer who doesn’t know either Xojo or Swift and is trying to decide which one would be the best to learn, I can’t imagine the calculation would take very long at all.
Xojo wasting their ridiculously small amount of engineering resources on something like API 2.0 just makes me feel like throwing in the towel. Not because it’s going to require a ton of work from me (though I sympathize with others facing that), but because it just highlights the apparent futility of the whole enterprise.
Unfortunately, for me the ship sailed long ago. I currently refer to my large library of Xojo applications as legacy code. All new development is elsewhere using open source tools.
I love Xojo. I really want to keep using it, but there are a few over arching issues that hurt professional developers.
1. While I appreciate having a Roadmap, even without dates, it would be better to have estimated times, even if somewhat vague like what year/release Xojo intends to ship the feature. It’s cool if it slips, but knowing intentions are critical to make high level decisions. I know Web 2.0 is #2 on the Road Map list, but will that be this year? I have no idea. I know Xojo gets grief for slipping dates, but we’re professionals and understand. My expectations are more communication from Xojo.
2. Features tend to die on the vine like Xojo Reports, Xojo DataControl, Web 1.0, and iOS. I’m sure there are others. Like Norm stated, why doesn’t Xojo have Date, Time, and DateTime picker controls? I’d expect that a development tool have controls for each database data type. Xojo Containers are extremely powerful, but I can’t place them in ListBoxes without hacks. I worry that When Web 2.0 ships it will languish as well. My expectations are for Xojo to keep features updated and add to them over time.
3. Getting bugs fixed are a challenge. Xojo doesn’t communicate well to let us know if something will be fixed soon or at all. I don’t want to have to make a stink or lobby to get something fixed. It should be fixed in a reasonable amount of time once reported and verified. It’s at the point where I don’t even feel like reporting bugs helps anymore. Reporting a bug and having it closed with out a discussion is defeating. My expectations are that bug being fixed in a timely manner and having a discussion before closed.
Regarding API 2.0, I loved that inconsistencies in the language would be fixed. So I reported that RowSet should really be DatabaseRowSet and MySQLCommunityServer should be MySQLCommunityServerDatabase. Both of these stand out as they are named differently from the other keywords. Also, DatabaseRow.Column and DatabaseRow.ColumnAt work differently than RowSet.Column and RowSet.ColumnAt. That confusing. I really don’t like exceptions. My app should almost NEVER crash. FileMaker and PHP rarely crash. I get checking for errors. I don’t understand why Xojo didn’t come to the community with an API 2.0 spec to get feedback.
Xojo NEEDS someone on the forums that can be on point to communicate. It’s incredibly frustrating when we get a perceived silent treatment. I know that’s not the intention.
All I know is that Xojo can’t seem to keep up with the massive list of what needs to be accomplished. That makes it hard to use as a professional development tool.
My plan is see what I can do with Bootstrap and PHP until Xojo Web 2.0 ships. I have a working prototype that already does much of what Xanadu does. When Web 2.0 ships, I’ll seriously evaluate it, hopefully ‘soon’.
I forgot to comment on this:
“Our livelihoods depend on Xojo and if that meant we all bought Pro+ licenses I doubt any of us would lose much sleep over that price tag. Its the price of doing business.”
I previously had 2 pro licenses for TOLIS Group; not really needed, but it made it more “legal” for Andy and I to pound on code simultaneously. When I saw the shambles that Web 1.0 and iOS 1.0 were, and how little real support they were receiving, I eventually cut that down to 1 Desktop-only license since neither Web nor iOS were of any value to our business efforts.
Now, I’m down to 0 license renewals – after 16 years. But, it doesn’t look like Perlman cares about wallet-based voters, so while I’ll be very happily surprised if he does a turnaround on this, I’m placing my budgeting bets on other options.
I’ve given this a lot of thought and boiled it down to a bunch of things.
1. For me personally, I already have to spend too much of my time replacing things because Apple’s almost needless changes. Now having to rewrite my code because Xojo changed their language, doesn’t make me happy.
2. If there were immediate obvious improvements; we wouldn’t be having this conversation.
3. There are so many things that I would like to see improved in Xojo. Multi-core processing is a must, the controller / helper solution is unpractical, meanwhile GCD is shockingly easy & provides instant speed improvements. Support for thread reentry on non-primary threads. There are many controls in Xojo that are outdated, like really outdated. It appears to me, that Xojo need at least one dev, whose sole job is to stay up to date with Apple, and adopting the missing controls, i.e. Scrollview, Popovers, Color selectors, Searchfield, Tokenfield, VisualEffectViews. I appreciate that Declares exist, but I should be able to create a fairly convincing native app using the built-in tools.
4. I’m probably not going to change languages & tools because of these changes to the language. The limitations of what can be done in Xojo would most likely be a deciding factor on what tools I use in the future.
5. How does this affect the upcoming change in requirements for macOS apps? While it’s not official; I suspect that going forwards most Mac apps will need to be iPad apps. Even if this doesn’t materialize, it would benefit me more (and I’m sure many others) if I could build one project in Xojo, that could spit out a Mac app and an iPad app (that gets accepted by Apple), and Windows and Linux.
6. What percentage of Xojo users are we? I often hear that you only need to focus on 80% of your market to remain profitable, are we actually the minority? While the majority are actually excited for these changes? Personally I would have expected the constant changes to Swift, to have dampened it’s appeal, it’s almost comprehensiveness that it has become. Yet I am only aware of a handful of devs that have actually gone back to Objective-C, because of this.