I’m someone who comes and goes from the Xojo scene for extended periods. You might imagine my surprise 6 months ago after dusting off an old project and checking out the forum for the first time in about 2 years. Things had definitely changed.
There’s various discussions about API1 and API2. But I’m thinking back to when Xojo.whatever was introduced. There was all this talk about “String is bad. Text is good. You should only use text.” (Or Xojo.IO, or Xojo.core, etc.) All having now been deprecated.
So was Xojo.xyz considered part of API1 or was it just something in between, unloved and forgotten by its creator?
The “Xojo framework” was supposed to be a transitional framework first introduced in iOS that everything would eventually adopt
It got a TON of pushback from several users, complaints about the “wall of code”
And so it was left unloved and never expanded across to other project types like it was intended to despite the fact it was 100% optional and you could use it side by side with existing code (although you would have to convert between string & text) and it had several other benefits (like NOT stealing class & method names from the global name space, being able to be stripped much more extensively than the current API 1 or API 2 frameworks and a few others
Now it, or the C++ code under it, forms the basis of DateTime, URLConnection and several other “API 2” changes
It was the effort to make it possible to modernize Xojo without breaking everything everyone had written over the last 20 years
That was goal #1 - it was basically optional
And there were other benefits
So much so that bits of it are being repurposed for new capabilities
URLConnection I think
Some of strings newfound abilities
DateTime that is more locale aware
And I suspect others
Instead now every time Xojo adds something its in the global namespace so if they add something chances are it could collide with something you already wrote
One of the most notable of these was when StaticText was renamed “Label” and so many people had used that name for a static text on a layout
And now all the sudden it was a control name so everyone that did that had to fix their code
Thats one of the issues with everything in the global namespace
I was also never bitten by this. I have however been bitten by the new event name changes. I have an app with a tonne of custom controls and I’d used some of Xojo’s new event names for events within my custom controls. When the new names were added to the IDE (I forget which version now), rather than any sort of warning, the IDE just hid any code I had in those events. It still showed them in the sidebar as if they were used, but they were completely empty. Any code I’d put in the custom events I had for my controls was hidden. That was a fun few hours of complete confusion I can tell you!
It’s all in the past for me now though. I’m currently rewriting my main app in Swift and adding iOS as a target. It’s slow going, but it feels rewarding and I’m enjoying the complete control it gives me. SwiftUI can be a bit restrictive at times, but there are ways around that.
I’ve been using SWIFT for years now, more so since I dumped Xojo, and have frameworks to help with both macOS, iOS and even tvOS apps. But I have avoided SwiftUI because it is somewhat restrictive. Swift is about the only dev tool I use anymore (fyi… I have 14 tutorials on this site)
Ha! Yeah I know what you mean. But in my defence, I’ve been meaning to get an iOS version out for ages, so it was a case of either waiting for Xojo to get to the point where it’s usable for my purposes (never gonna happen - I need too many niche things), or go with Swift. MBS very nearly got Xojo iOS there, with access to the AVKit framework, but there were still too many things I just couldn’t do.
It was going to have to be a rewrite for iOS anyway, even if I had stuck with Xojo, so I thought it a wiser move to go over to Swift. I’ve created it in Xcode as a multi-platform app, but am only concentrating on iOS for now. The Xojo MacOS version is still for sale, so there is no real rush to get the desktop replacement done. I’ll probably release the Swift MacOS app as a major new version sometime in the future. So hopefully I’ve not fallen into the ‘rewrite from scratch’ trap that Joel Spolsky spoke of. The work is first and foremost creating an additional product.
It doesn’t seem too bad now. I’m targeting iOS 15+, so I have access to SwiftUI 3, which has addressed many of the shortcomings of the initial SwiftUI releases. So far, reading around, the only big issues I’ve had would have been a pain in UIKit too. Some things could definitely be better and I’ve had to use a UIKit wrapper for a couple of things (which are actually now included in SwiftUI 4 for iOS 16), but overall, no showstoppers yet. Frankly, Storyboards and UIKit were the things that put me off using Swift for years. Loved the language, but I found UIKit and Storyboards to be clunky as hell.
And I have to say, I love the declarative paradigm used in SwiftUI. Being able to create your UI, point it at an environment object, and let it automatically handle UI updates itself based on the data in the object is excellent. No calls to make on data changes, no messages to send, no manually changing or redrawing the UI, it’s all handled automatically. I am really enjoying it.
