New Target: Q2 2022
“not ready for production”… at least they had the b*lls to admit that…
Xojo might learn something from their playbook (nah… never happen)
1 Like
It is the only professional way of behaving: not ready for production is not ready for production. I know it from Java, I know it from C++, I know it from many professional tools. It is dangerous to rely on a not ready tool.
“The .NET team has been working hard with the community in the open on its development and we are committed to its release. Unfortunately, .NET MAUI will not be ready for production with .NET 6 GA in November. We want to provide the best experience, performance, and quality on day 1 to our users and to do that, we need to slip the schedule. We are now targeting early Q2 of 2022 for .NET MAUI GA.”
Well, the keep the previews, the actually ask for feedback and listen to the comunity. A 6 month delay for a proyect that size is almost nothing.
No, Xojo do that too. However the bar is set quite low: software causes cpu to catch fire - not release ready. Software sometimes causes cpu to catch fire - ready to go. 
No, sorry but Xojo is definitely doing that. They always deliver Software which is not even a bit production ready. As a Java and C++ programmer I know what it means “production ready”. Xojo has too many workarounds for this. It has tons of Bugs and functional leaks. Try to compare Java with Xojo and tell me where Xojo has a quality like Java. If you can bring up that evidence we can speak.
(Previous post edited to add some suitable emojis)
Xojo have often said: “We’ll only release it when it’s ready”. However, that generally means “We’ll release it when it goes from pre-alpha to alpha, and fix any (many?) bugs in post”.
1 Like
If they would do what they said I would agree. But they where not doing it. Best example: Web 2.0 with the deprecation of Web 1.0. Made the effect that delivering of Web 1.0 Apps under authority of FDA for example was not possible anymore. Nice when you are ready with development. Web 2.0 had and has still a big amount of missed features they had not ready. Many came later. And you really consider to tell me that this Software was ready to deploy? It was and is nothing else then n alpha prototype. Comparing to Java or C++ Xojo had more issues than all others. And you may not even believe that Java and Xojo or C++ and Xojo are comparable. I see that Xojo has not done a good Job. Renamings for example the Idea to rename msgbox() to message box() are stupid and not helping anybody. That is Alpha stadium, nearly in development and not alpha. The features which are needed to use the Software for production should be ready wen deployment starts. That is not the case with Xojo,inc.
One interesting thing I noticed is MAUI is using Catalyst for macOS apps:
.NET MAUI is a wrapper framework and development experience in Visual Studio that abstracts native UI frameworks already available – WinUI for Windows, Mac Catalyst for macOS/iPadOS, iOS, and Android.
I.e., MAUI will produce hybrid macOS/iPadOS apps. That’s great if you’re happy with the kinds of apps and user experience you get using Catalyst, but it won’t be quite the same as an app specifically targeted to the desktop.
1 Like
Maybe needs a little more editing to be understood by everyone 
WARNING THE FOLLOWING TEXT IS INTENDED AS A JOKE:
< JOKE >
No, Xojo do that too. However the bar is set quite low: software causes cpu to catch fire - not release ready. Software sometimes causes cpu to catch fire - ready to go.
< /JOKE >
What he said…
The thing that most irritates me about reported Xojo bugs is that if there’s a workaround (even if it means standing on your head naked and whistling your national anthem twenty times*) then you can pretty much laugh off any chance of it ever being fixed.
* Let me put 
here on the offchance that this post causes an outbreak of indecent behavior around the world.
In what way?
I don’t understand the need for “Catalyst”… it is entirely possible (and quite easy) to create an app in Swift/ObjC that is one code base for every Apple Platform. Right now I have 1/2 dozen Swift projects that compile for iOS (iPhone/iPad), macOS (Desktop) AND tvOS (AppleTV). and with the exception of minor platform requirements, they look and act identical.
1 Like
Do you know what Catalyst is? It’s designed to make it easier to port an iOS app to macOS. As such, it can make an iOS app useable on macOS, but Apple doesn’t recommend starting with Catalyst if your primary target is a traditional desktop app.
It looks as though MAUI will be taking a lowest common denominator approach to desktop apps. For a large number of apps, that might be perfectly fine, but it’s something to be aware of.
I wasn’t replying to you.
then try to be more specific next time
At the top of his post it does show that he was replying to Meestor_X.
I do. I was just curious what specific differences you have seen or compromises you’ve had to make when creating a Catalyst vs MacOS App.
So Maui = fullblown windows, no linux and semi native macos?
what is the point of even waiting for maui then.
I feel a little dissapointed once I learn more about it 
I mean, how much rewriting of gui code is needed???
1 Like
That is a good question. Every programmer has to decide what to do. In case of cross platform programming there are many ways to do it. For the semi MacOS I can hear the people speaking ohhhh but it is not native from the Xojo site. The Goal is the portability of the Code like that what we have with JavaFX and Gluon for Desktop and Mobile with the difference that Gluon uses the native elements and not the Java ones for mobile. simple, quick and dirty MS tried to do the same with botnet to have this solution in a more native looking wise than Java with the old JavaFX mobile solution. I can see the goals for C# programmers which are with this solution not only more flexible but also able to work with one codebase for more platforms.