Thoughts on native cross platform

General Programming
1

I’m sure you’re aware I’ve been getting into SwiftUI this year, after my last interaction with the Xojo CEO, I decided to truly dedicate a block of time to accelerating my transition.

I truly believe that SwiftUI is the future.

If you have hand coded web pages, you already understand the concept behind it. Electron (good or bad) clearly paved the way by leveraging HTML/CSS to create adaptable UIs.

SwiftUI takes that concept but uses native UI elements. With platform conditions you can tweak (within reason) the UI for different devices, yes you can create Mac, iPad, iOS & watchOS apps from one single project. Apple even show you how to do it.

There is an open source project for SwiftUI to bring it to other platforms also.

Seeing that dumb thread about not only control names being different per target with Xojo, but even function or event names too… Along with having to have separate projects per platform. It really feels like Xojo was out chasing fairies rather than playing the game.

Bindings are awesome. Add a property to the view class, binding it to a control and when it is updated from whereever, it auto updates that control for you. That’s low code.

The most incredible thing about SwiftUI, is using live data in the UI designer. Yes you heard me, I made a Permissions Reset example, which the UI preview actually pulled file meta data, spotlight data and bundle data into the preview. With Xojo, we have to do the “loop until happy { tweak UI; run project; quit demo app }”

It’s not all awesome in SwiftUI world

It is not without its faults. SwiftUI on the Mac really feels like an afterthought not a primary target. Some things don’t work, some things don’t work right and some things are weirdly blocked from the macOS, like the ability to tint a Gauge with a gradient.

The AppKit team recently added NSComboButton NSComboButton | Apple Developer Documentation But SwiftUI doesn’t even support the age old NSComboBox, let along something added to the Mac in 2022. To me it shows how disorganized or how little Apple’s leadership care about the platform.

I pointed out how easy it was to embed views into a scrollview, but setting the anchor of a scrollview, only works on macOS 14 Sonoma or higher.

Then there’s the UI paradigm, it works very differently to how you handle UI with Xojo, to the point that you have to start thinking differently, not just in layout terms, but interaction terms as well. I’m slowly pushing myself to overcome “that’s how I’ve done it for 25 years”.

I also want to say that several people had warned me that SwiftUI is not really ready for Mac use, not just a Xojo MVP, but also an ex-Xojo employee. I 100% agree with both of them. I’m going to ride it out a little while longer, because I believe it is the future (that and I don’t want to have to learn something else).

It is more clear to me than ever that Xojo is on the wrong path, and you know what… I think the CEO has known that for a long time.

5 Likes
2

thanks for sharing positive feedback

3

They are actually aware of the fact that not everything could be implemented in SwiftUI from the start. UIKit and AppKit views can be integrated in SwiftUI views and vice versa. This should help transitioning.

Addendum: the above video is about integrating SwiftUI views in other frameworks.
Here is documentation about the other way round.
https://developer.apple.com/documentation/swiftui/appkit-integration

4

@samRowlands
In your title, you mention “native cross-platform”. Do you mean SwiftUI can also be used on Windows? I mean not creating Windows apps on Mac but using SwiftUI on a Windows machine.

If that is not possible, do you know if there are plans to bring a Windows version?

Thank you in advance. I sympathize with you and other people impacted so heavily by the short sighting of one man.

Have a great day!

5

SwiftUI is currently not available on other platforms, but there are people in the Swift community who asked for this.

https://swift.org/platform-support/

Currently, Swift is not ready for GUI apps on other platforms.

6

Thank you, Torsten, for your reply. I read your link, and it seems in the future, SwiftUI will also become available for Windows.

If that would happen, it would be great!

I wish you a great day!

Chris

1 Like
7

It is x-plat in the sense that you can create Mac, iPad, iOS & watchOS apps from one single project. With one primary UI declaration and then conditions for specific targets.

As for it coming to Windows and other platforms, I don’t think Apple will do that, but Swift is open source.

It would have been nice to see Xojo explore solutions like this.

1 Like
8

Thank you for your reply.

I agree that Xojo should explore solutions like Swift, but they will not. That is their downfall, regretfully.

I wish you a great day.

Chris

1 Like
9

don’t forget tvOS

While SwiftUI is most likely the “future”, in my opinion, “Standard Swift” (for lack of a better term) is (my opinion) more flexible and exposes more function, features and parameters.
It also seems that you don’t use AUTO layout , but some sort of HSTACK/VSTACK paradighm, which for lack of better examples seems even more difficult to produce dynamic layouts

1 Like
10

This sounds like Apples version of MS “cross platform” where it meant Windows CE, ME, NT, etc etc
All variations of Windows

And not what you and I think of (Mac Windows Linux)

3 Likes
11

Actually MSFT is finally coming around … MAUI = Windows, MacOS, Linux, Mobile, Web

But yeah until the past couple of years MSFT’s version was “any OS so long as it’s Windows”. FoxPro’s DOS/Windows/Xenix/ OS9 strategy became, within a year of acquisition, Win16/Win32s/Win32 and that has been symbolically what they did for all their products until MAUI.

Bad case of either “not invented here” or “my universe is only proprietary to me”. Or possibly both.

12

Yes - MS has a better handle on what cross platform means now than they used to

1 Like
13

I always do, and watchOS. Sometimes I even forget iOS exists, and then get a rude awakening when I find something on ARM Macs now uses iOS values instead of macOS :slight_smile:

You are quite correct. App Kit (or UIKit with Catalyst) is way more mature with way more controls and customization. Then again App Kit is 30 odd years old and SwiftUI is only 4 or 5.
Yes SwiftUI uses a markup language to describe the UI, HStack, VStack, ZStack, List, NavigationSplitView, Grid & Table are a few layout structures. The principle is that you the developer don’t need to worry about platform specifics, you let Swift do it (I still haven’t figured out if it is at runtime or compile time). The downside is that you do lose precision. For instance you don’t set the width of a button, you set the content and padding on the label.

While I absolutely believe it is the future, I can already admit, the Mac version desperately needs some serious love.

1 Like
14

I would say “Declarative UI”.

SwiftUI is just the Apple take on the model.

After the model took off with React(web), Google created the project Sky later known as Flutter (multiplatform), and then Jetpack Compose (Android) that appeared almost at the same time as SwiftUI (Apple). So we are since around 2013 evolving into this kind of approach and we see no signs of moving away to some new (or older) way yet.

3 Likes
15

Nah man, you’re correct. I’d forgotten the term. Declarative UI is the future.

1 Like
16

Thougths on Flutter anyone?

17

there are some members here who have moved to it
I have toyed with it but haven’t built anything significant yet
What I liked is that if you start a project in android studio you can select EVERY output type (android, iOS, web, desktop, and build for all from a single project)

1 Like
18

Too bad Xojo cannot do that although the marketing implies you can.

1 Like
19

yeah we wont go there
The guy who was working on that was let go :stuck_out_tongue:

20

can you expand most on this SwiftUI on Mac business please?