macOS Strategies for cross platform Mac/Windows development?

[macintologist]

I want to make a desktop utility GUI application related to organizing video files. Ideally it would be cross platform Mac and windows but I want a native GUI for each because I personally hate ugly cross platform GUIs. I want the Mac interface to be first class so I want to use swiftUI or whatever UI framework for Mac that is native, and I’d want to use a native windows UI framework for the windows app.

whats a good strategy to ensure that the backend application engine logic is as cross platform as possible so I can maintain a single application backend code base and then have two different front end gui codebases.


an example of something that is cross platform where the Mac interface appears to be first class is handbrake.

 

[Bigwaff]

Handbrake is open source. Have a peek...

GitHub - HandBrake/HandBrake: HandBrake's main development repository

HandBrake's main development repository . Contribute to HandBrake/HandBrake development by creating an account on GitHub.

github.com

 

[casperes1996]

In my opinion, Qt can feel relatively native if done right.

If you really want to use a system native UI framework you have a few options. Compile the shared parts to a shared library, either static or dynamically loaded, in something that follows an ABI easily interacted with by both platforms. The C ABI is always a good candidate. Not necessarily meaning you need to write in C. For example you can tell Rust or Zig to output C ABI object files. Then you can declare the shared functions as external in Swift and probably C# or whatever Windows preference you have and call it from there.

At work we've done some work with Kotlin Multiplatform for that sort of workflow for mobile though not sure if that can work for Windows. Can certainly build both to Android JVM and an XCFramework at least

Another option would be to create independent programs. A daemon written entirely cross platform that will be launched by the program and respond to requests by the GUI frontend through XPC, sockets or any other RPC means.

 

[macintologist]

Terrific thanks for the info.

 

[Rock_Artist]

If you insist going pure native on each platform. Having a standalone backend and just making front end per each platform sounds the simplest.

As I come from audio, we use JUCE as a framework. It’s cross platform similar to QT but in lower scale and price point.

You can use its basic cross platform UI or grab the windows handlers and make native UI per each platform.

But I must say, writing UI per each platform could end up as a complex task that isn’t always worth it.

 

[john-c]

Sorry for a late reply, but maybe good for others.

Some years ago I had similar requirements. Certainly QT is good, though the license is either expensive or open-source.

Outside of QT, the best I found was wxWidgets. You write in 'C' (there are some other language options, which I can't speak to) and not surprisingly it has it's own libraries and resource format which you need to learn.

The other alternative is of course Java. If my memory serves me Java (without Swing) has a native UI, but the UI feels clunky. It also calls for an installation of Java on client machines. Actually little-known is you can create a standalone Java app. You need to examine the source code for Java to see how, but there are hooks available in the Java start-up code for this. I used this in production applications on CD-ROMs, so I know it is (or at least was) there.

 

[f54da]

You can take a look at what Transmission does: write your backend logic in c or c++, then use cocoa/obj-c for the frontend on mac since it interops nicely without any FFI needed. Nothing else really comes close to native on mac for people who pay attention to detail.

Depending on the type of app you can sort of get away with non-native and implementing the gui yourself (e.g. sublime text), but this only works for "full-content" types of applications