I have high hopes that this might be like the “Definitive” guides of yore, at the very least it should be learn the basics much quicker than I could on my own.
I am also hoping that it might help to choose between Swift and Objective-C (which I have a lot more experience). Objective-C is more powerful, but I get the feeling that Swift is where it’s going to be in the future.
I’d say that Swift currently blows Objective C out of the water in terms of power and expressiveness (having developed apps in both). I am also interested in that book in order to get into SwiftUI. However, finding time is an issue: I’m retired
At this year’s WWDC improved integration of C++ code into Swift projects has been announced. I haven’t tried since I have no experience in C++ but it may be a way to use existing C++ code in Swift projects.
Learning about SwiftUI from that book and holy shit… Xojo really fucked up with their “2.0 All The Things” it isn’t even funny. I’ve only read half the book (just reading) and wow… just wow… I look forward to actually building the demo app in the book.
I’m already thinking about how I can convert some of my smaller apps over.
pretty much the same for JavaFX for cross platform. It is somehow fascinating how things are just working as described in the documentation and on all platforms. Originally I thought that at least Xojo’s Layout Manager might be more powerful. It isn’t - it takes a bit of time to get used to the Scene Builder, but it is far more powerful and accurate than the layout manager.
That’s why I had never the Idea even to think about a Xojo Desktop application. That is in my case no option. And Web…also not while I have the best solution with JPro.One for Web with JavaFX. That is the best way to do an implementation. While I can also do mobile Apps with it can do styling even outside the Scenebuilder with JavaFX when a more “mobile” deisgn ist needed. When and if it is only a bit css change I can do even that inside of the scenebuilder. That is a powerful solution and the apps are running on all platforms as it is to expect. While also the documentation is correct I would not like to miss JavaFX for my Toolchain. Xojo? Not even a bit comparable with the precision, sustainability, reliablity and stability. But everybody has to look which toolchain fits best for the needs. So their will always be a group that loves Xojo. I am sure.
and if not you can even load your own CSS to Scenebuilder and test/apply different layouts. Not only light and dark, but you could create a monkey or banana theme.
No monkey nor bananas were killed in my JavaFX app and looking the same on Windows, macOS, Linux and each platform with its own installer (no need for the end user to install anything from Java). And the app works dynamically for all csv files, no matter if a column contains a date, any kind of numbers, string, formula, etc.). It will even detect the chosen delimiter automatically.
IMHO declarative UI is the future. Think of a simplified HTML/CSS. It’s possible to write out a single UI and voila, it looks, smells and works like a native Mac app, but the same code (and in the future the same executable) will look, smell and operate like a native mobile application.
Meanwhile, Xojo has decided to go in the opposite direction, instead of making it easier to build x-plat, they decided that further separating the platforms was the “right thing to do”.
I was thinking, if we hadn’t gone through “2.0 All The Things”, I might invest some time to prototype a declarative UI in Xojo to demo to Xojo how I believe it is the future. Then again, if they hadn’t embarked on such a dumb ass quest in the first place, I probably wouldn’t even be looking at Swift and SwiftUI.
Yes, there are many ways to create a JavaFX UI. You can exclusively use a declarative approach, or you can use SceneBuilder without worrying too much about the details. In addition to SceneBuilder, there are other Layout Managers available (although in beta, they are far more stable than anything from the green company).
I use SceneBuilder, which generates an FXML file. If I want, I can modify that file as well (for minor changes or fine-tuning, for example). I think it’s fair to conclude that the JavaFX approach is declarative, with UI builders serving only as helpful tools to simplify the initial heavy lifting.
However, if I need to copy elements to a different app or another screen, I wouldn’t bother with any layout manager. Instead, I would simply copy the relevant FXML parts - and that’s it.
You can change the layout with CSS to whatever you desire (JavaFX is like a blank canvas, allowing you to design anything you want). If you want buttons to resemble bananas, it’s up to you and your CSS, and as such, it is completely independent of your UI layout. Yes, as a result, you have of course access to all the animations that CSS can provide, and so on.
For me, this isn’t a debate that Java is the best, but it’s astonishing how many tools are available today to help us get the job done more easily than the outdated Xojo concepts.
What helps Xojo is that many users don’t spend the effort to investigate into alternatives. I don’t blame those people, it is a lot of work, but IMHO it is worth every second.
rings a bell. I still think it is funny, that the needed work with TypeScript for writing Xojo Plugins was my trigger to finally leave and give up with the green software.
I give it a 10 out of 10. It does what I expected, providing a crash course on making Mac apps with Swift and SwiftUI. It also covers building Mac apps with Swift and App Kit, because… well…
The author points out bugs in SwiftUI and limitations. She even says for some kinds of apps, you want to use Swift + AppKit, because SwiftUI isn’t suited to that kind of task.
She also shows you how you can access AppKit from a SwiftUI application, for instance there is no web viewer in SwiftUI (on Mac), so to display web content, you need this workaround.
So when Apple says “Swift & SwiftUI is the best way to make an application” it needs a huge * next to it!
I loved the paragraph on concurrency, okay, maybe a sentence or two. She makes it seem so easy compared to you-know-what
If anyone is considering learning Swift to make Mac apps, I highly recommend this book. That’s without even trying to make the demo applications!
For me personally, I’m going to try my best to port some apps and new ideas in Swift + SwiftUI. I feel this is where Apple is going, and confident that this is a long term goal, not an immediate one.
Persoanlly I have never broached SwittUI, for two reasons…
it didn’t exist until I was already comfortable with Swift (with either UIKit or AppKit), At which point I already had a design paradiagm to create code for both using one code base
The limitations that Sam eluded to. I don’t recall exactly what there were, but at the time it wasn’t worth the extra effort to learn SwiftUI AND figure out workarounds at the same time. Hopefully by now (or soon) those will be eliminated
For those of you interested. Using Swift (AppKit/UIkit) is it possible to write ONE code base that can be compiled for macOS, iOS (iPhone/iPad) and tvOS
When Swift first came out I tried to port some simple Xojo apps to it at the time, and I couldn’t. On top of that the Swift libraries were massive.
But over the last 10 years, it’s gotten better, right?
I don’t feel like I’m yet in a rush, so Imma take my time and as SwiftUI evolves, hopefully I’ll be able to get more and more moved over, once I can get Sleep Aid fully working in Swift & SwiftUI, I think I’m done.
Take a look at the tutorial series I’ve posted on here. There may be some updates required since then, but if so, Xcode will problably tell you what they are. If you have any questions, feel free to ask.
My current project is a Graph/Chart package for Swift. Right now it is for iOS only, but I’m keeping macOS in mind during the design, and will make if work for both by the time I’m done. (and in my opinion it will put Xojo Graph to shame [not that is necessarialy hard to do ] )