Thoughts on native cross platform

SwiftUI is a new way of defining a UI
See

yes I’m very well aware of that Norman,

I meant can you - or Sam - expand on all the issues ie problems and limitations regarding using SwiftUI speficially for macOS as opposed to iOS, iPadOS, TVOS etc etc

ie “the Mac version desperately needs some serious love.”

I cant
Maybe @Stretch327 or @DaveS
I think they’ve used it

I don’t use SwiftUI, but I do and have used “Standard Swift” for many years, and written apps for macOS, iOS and tvOS. As to macOS needing “love”, I can agree with that.

macOS uses AppKit/Cocoa, white iOS and tvOS use UIKit
Since UIKit was developed long after Appkit, it obviously has some updates/new features that have not made it to AppKit, but for me the only time this is a real issue is when doing a project that encompasses all the platforms at once (as the same feature may have different syntax or requirements between the two “kits”)

However, recently I’ve been taking advantage of the ability for iOS projects to also run on M-Series desktops with ZERO required code changes.

1 Like

The Discussion around Swift UI and its open Source implementation is an old discussion. So old that on the open Source implementation nobody was working for now four years. That means in the most cases: Story ended up and not good.

The real Cross platform programming Solutions are not native. Not really. Even Xojo is not really native. And also it is a bit dangerous: nobody knows if it looks proper on all platforms. That is even a problem working with the most professional cross platform solution: QT. And while it is such a big set of problems it makes headache on all platforms.

There is no solution which can do real native cross platform without massively changed source code. That is not really cross platform development. So mostly people will have to decide if they want cross platform and therefore the most will not do that native (and there are many ideas with JavaScript based Solutions, Kotlin, C++, C# and also Java. All of them having together: they are never really platform native, java especially not. So there is a leak of technology behind. And no solution.

At least working with solutions which are not maintained anymore is dangerous.

1 Like

I’ve only been at it full time for a couple of weeks, these are the things I’ve found that I don’t consider right.

  1. Lack of macOS controls, yes it is possible to dig into AppKit, but I wasn’t expecting it to be as limited as it is.
  2. Somethings just don’t work right on Mac. For instance the sidebar, if you use the x-plat method, the default item is not highlighted, it requires some dirty hacks or using specific sidebar code for the Mac.
  3. Some layout controllers are not designed for Mac interfaces. The Grid for instance can only have a maximum of 10 hardcoded rows, but this isn’t documented anywhere. If you dynamically populate the grid from an array, that is fine. I’ve also had problems with a large layout and the Scrollview, it likes to center the view, the anchor option is only available on macOS 14, so for older OS versions, it looks shit. Again using a dynamic layout doesn’t have this problem.
  4. Searchfileds can only be presented in the sidebar or the toolbar (I’m sure tapping into the AppKit one can solve this), and if you set it be in the sidebar, it will show atop any list that has a sidebar style, but crashes on clicking in.
  5. Linking a TextField to a stepper or slider needs a workaround and apparently there’s a 3 year bug which can cause problems. Thankfully the workaround is pretty simply, but.

The only saving grace is that I fully expect it to get better, Apple’s updating SwiftUI at a rabid pace, I’d rather see them take a bit more time and ship a more reliable solution, but at least it is improving.

1 Like