I’m very close to say that too, even if a month ago I renewed my Pro license for one more year.
Currently i am investing a lot of time in thinking about multi-platform instead of cross-platform. There is so much #if-Target…-code in my applications for the UI part, that I started to get interested in doing the data part (aka model) in C or C++ and the UI with the real platform libraries and tools. This would be a massive undertaking of course, as it will be crucial to get the boundaries between the platform-specific and the non-platform specific code right (and there is also the danger to develop ones own full cross-platform framework over the time).
But the lack of built-in controls in iOS for such a long time, the lack of decent controls in Web (especially a full-fledged WebListbox) for such a long time, and the status of some controls on the desktop (for example the Listbox still being non-native on OS X) are strong indications that Xojo Inc doesn’t have the capacity to work on all these issues or is not willing to. All this is somehow frightening to me.
I hope Xojo gets frightened as well, if only they realize the danger. Nature abhors a vacuum.
I think Xojo is still very relevant for OS X, even if for having a true NSTableView requires dtPlugins or NSTableViewMBS. I have every intention in the short to mid term to continue using Xojo for that platform. But chances are next year I won’t be buying into the Pro package.
Even if Windows benefited recently from 64 bit (with no manifest) and HiDPI (beta), it remains desperately Win32 and UWP Application model seems just as completely not in the stars as .NET. Heck, .NET has been released in 2002 and it is futile to continue with an old horse. I will be much better served by VB .NET to produce state of the art UWP apps for the Windows Store. And if I still need to maintain my old apps, current Xojo will do.
Xojo Web is a pet tool of mine, but as most of what I use it for being back office and web services, I don’t suffer much from the antediluvian UI. With RubberViewsWE it can do many things better, but yet, it is way behind the current web design tools in terms of aesthetics and flexibility. Same observation as for Windows : unless some revolutionary change, I can stay with current version for quite a while.
iOS is not even worth a free license, much less a paying one. XCode and Swift is quite fine until if ever Xojo gets at least on par with Desktop.
Console has not evolved for long : no need to update.
As a result, I plan next year on going for a Desktop License. I might even consider a single desktop license.
I did a pro license for this year, but if I don’t make any money off it, will lapse to a desktop or even the free license next year. In part, I paid the license fee just because I want to support this fine Austin based company.
I am really interested to see how Geoff and the crew grow Xojo over the next year. It has so much potential, even (especially?) in the iOS space. But a very great deal of that potential, most of it even, is unrealized. In any case, I support them to the tune of the cost of a Pro license, at least this year.
But the products I am putting out over the next 30-60 days? None are currently based upon Xojo, even the very simple ones. A great deal of that is on me I suppose, as I don’t know Xojo as well as I should. But some at least is on Xojo for incomplete implementations - iOS being the poster child for that.
I went with Xojo because of it’s OS X/Windows x-plat ability. If it wasn’t for x-plat, I would have gone with native tools.
There are many people using Xojo to make a living and apart from exceptions, I think it’s reasonable to say that the only money to be made is with OS X and Windows Apps.
Not with Pi, Web, Linux or iOS Apps.
If I really want to deploy iOS Apps, I don’t see the benefit of using Xojo above Xcode. Why would I? I don’t have the x-plat benefit and even if Xojo’s iOS support gets 10x better, Xcode will always win.
It seems that Xojo is so scattered with different platforms/frameworks that it hurts the development of its core platforms. With the current state of their resources, I think they should put 90% of their time into OS X and Windows and 10% in the rest.
So for me… if the next release is really going to be all about iOS and Windows stays (again) where it is right now, I’ll jump ship. Leave Xojo’s x-plat behind and use the free native tools.
I have been using Xojo Web quite a bit for backoffice. In that sense, I do make money with it. Not selling programs, but using it.
Still today I am using Xojo Web to create a system that manages the 30 days free trials, as well as serving licenses directly to the app after they buy in there. So immediately after payment, the app can poll my server and set the license automatically, like Xojo does.
I do make money with OS X and enjoy Xojo for that.
Now, where is the cross platform advantage ?
What is the main venue for Windows apps ? Shareware ? Possibly for a few. But logic would be to enter the Windows Store, especially as Windows 10 will replace 7, which did not have the store. Unfortunately, Xojo does not even seem to want to hear about .NET, and even much less AppX apps. So the only way is VB .NET in VS. Gone is the Xojo code sharing.
Xojo iOS could have been a wonderful way to easily and quickly release the same titles as the ones in the Mac App Store. Unfortunately, no code sharing, as the new-platform-only situation prevents it.
I am afraid Xojo lost its way in this brave new world they don’t seem to understand. It happens to the best companies. Pity.
[quote=269068:@Michel Bujardet]Xojo iOS could have been a wonderful way to easily and quickly release the same titles as the ones in the Mac App Store. Unfortunately, no code sharing, as the new-platform-only situation prevents it.
I am afraid Xojo lost its way in this brave new world they don’t seem to understand. It happens to the best companies. Pity.[/quote]
Outside of the lack of controls, not making iOS code compatible with the desktop (and web) framework off the bat was a huge mistake IMO.
It seems like it will be a long while before that happens because of the new framework which as a LONg way to go to match the existing one in functionality, and when it does our existing codebases will need o be rewritten.
The old framework while not perfect is reasonable. In this case it seems seems like the perfect was the enemy of the good enough. I do hope they have not shot themselves (and so us too) in the foot.
That said I think the best use for Xojo desktop and web is for in-house stuff where the latest OS features and UI glitz are not as important and speed of Xplatform development it. For that IMO it is hard to beat (at least for Xplatform desktop and web).
Commercial apps that need more polish with up to date features and controls, need a lot more work often with with declares (when it can be done at all) to be competitive, and Xojo is less RAD for them IMO.
You cannot use Strings, Variants, Dates, Dictionaries (to name a few) in iOS. You must use Text, Auto, Xojo.Core Date, and Xojo.Core.Dictionary. Add in things like TCP and HTTP sockets and it’s highly unlikely you’ll be able to simply reuse your desktop classes in your iOS project.
I think if you stick within the new framework for everything it’s not so bad. My experience with mixing it in with old framework has been a less than stellar experience.
This is part of what makes NO SENSE to me. WHY?
All of those things are supported in iOS with syntax almost 100% identical in function to the “OLD FRAMEWORK”…
while I’ve never been a fan of “variants”, nor am I a fan of “optionals” (ie. Swift)
But Strings are strings, and work the same as XOJO strings
Dates are well not exactly the same, but its a piece of cake to write a wrapper that makes it so… (I know, Ive done it)
Dictionaries, Collections are actually more functional in iOS that what XOJO currently supports
My opinion, it would have been better to make the iOS version more “transparent”, did the underpinnings need to change, probably, but the syntax exposed to the developer didn’t
I know this is the iOS channel but do you mean for Desktop Apps?
To do the same thing, I find the new framework a lot(!) more complicated compared to the old one. But is it even possible? How do I work with shells, threads, regex, databases etc etc?
And what are the benefits of making the switch?
I would understand if the new framework would give me all kind of new features that aren’t possible in the old one (like with json or httpsocket) but other than using a few things from the new framework, I don’t see a reason to switch.
Now if it was complete so it could fully replace the old one and it would give full up to date OSX and Windows features, that would be a good reason.
String and Text are different even if we cannot really see the difference. Joe would have to give the official definitions but I do know that Text cleared up some long standing issues with String encodings. From that aspect Text is great even if not always straightforward.
Decisions were made to move forward and implement a new framework with iOS. The real question is whether or not it’s wise to move the desktop and web to the newer style. Based on my, albeit, limited knowledge of the new framework it’s not nearly as fleshed out as it needs to be and has some rather large bugs and gaps to fill.
No, I meant iOS apps. If you’re using nothing but the new framework you don’t have a choice and you just have to deal with it. Desktop apps you have a choice still, and (see above) it’s not good enough yet to replace the global framework.
I am not insinuating. In practice, to reuse code, you cannot escape the new framework. Which means you have to refactor code in no innocent manner.
The app I have currently in the MAS is typical of the issue. I had code from an OS X app I wanted to reuse. Since the new framework has vastly different methods for most everything, I started to wrap these into familiar classic methods, such as str(), val(), MsgBox and so on. The result is XojoiOSWrapper I placed on Github.
But yet, there are things that cannot be wrapped so simply. For instance, Xojo.Net.HTTPSocket has no synchronous mode. No way to wrap that, refactoring is necessary.
I am picking up this last example because all is not Xojo’s fault. The iOS framework does not permit synchronous HTTPSocket at all.
However, my wrapper shows how, if they had wanted, Xojo could have avoided brutalizing users with a new framework which sole justification seems to be blatant disregard for whomever has been faithfully following them for over a decade.
I could also point out that Xojo iOS is an epitome of unfinished business (or lack of ambition). Instead of providing the familiar set of events and properties one has considered normal in desktop and web for so many years, all the sudden no more MouseDown/MouseUp in any control but Canvas. For instance, buttons only have Open, Close and Action. TextArea has Open, Close, Selchange and TextChange. When Keydown is so widely used in Desktop. The list is endless.
Most shocking to me is that almost no love went into Xojo iOS in now one year and a half. Let them eat cake…
I hope my latest post clarifies it. Between Web and desktop, you can pass modules and methods pretty much unchanged. Of course, the platform prevents sharing controls, so logic must be placed separately. If Xojo iOS had kept the same philosophy, it could have been a splendid platform. We will probably never know why, but I suspect whoever was in charge did not feel like spending the extra time needed to correctly implement the language. This new framework business when it comes to most methods and properties sounds to much like a clever excuse for laziness.
The almost total lack of hardware support looks very much like a premature, negligent release as well.
