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

 

[Lynn Fredricks]

We use Qt for Valentina Studio. Many years ago, we used wxWidgets, but that led us into a rabbit hole of poor support for each target platform and poor performance. In 2015, we completed migration to Qt and have been very happy since.

Qt was previously only a (rather expensive) commercial product. At that time when I first encountered them in the late 90s, it was the product of TrollTech, a Finnish company. I found out about it at the time because Hitachi had thrown a lot of weight behind it, and a spent some time talking with the developers at a trade show. It really impressed me.

 

[Anic297]

For sake of completeness, I'm also going to mention Xojo. I personally use it.
Feel free to look at it if you want.

 

[DaveSanDiego]

In regards to Xojo, before you make any finanancial commitment, read entires on

If Not Nil

A place to discuss the cross platform programming in different languages

ifnotnil.com

Xojo has lost a HUGE percentage of their clients over the last few years

 

[Anic297]

In regards to Xojo, before you make any finanancial commitment, read entires on

If Not Nil

A place to discuss the cross platform programming in different languages

ifnotnil.com

Xojo has lost a HUGE percentage of their clients over the last few years

I'm aware of that. I'm just a user who still uses it and keeps being happy with it.
Beyond that, trying it is free.

 

[Lynn Fredricks]

In regards to Xojo, before you make any finanancial commitment, read entires on

Xojo has lost a HUGE percentage of their clients over the last few years

That's true, but there are also a great many that do use it. From the start, it has been delivering cross-platform compilation from a modern, polished user experience. Sometimes implementing the cross-platform has resulted in compromises that have negatively impacted some users. The If Not Nil crowd appear to be the most angry ones. For that reason, I strongly advise looking at what it can deliver on each target platform.

But if you are delivering on the Mac, the good news is that it has a very, very long history on the Mac (it was originally Mac only) and, you can reasonably expect that Mac issues are going to get a very high priority because the company has been well and truly invested in macOS for decades.

My company delivers some Xojo-compatible solutions (in addition to other language / technology platforms, C/C++, Java, Python, .net, server-side web, etc), so I am familiar with its foibles. We have customers that use Xojo to deliver some excellent standalone software as ISVs as well as corporate and academic developers that deliver solutions for their organization and clients.

 

[Cenobytez]

Here another long time supporter for Xojo. I have been working with it since it was still called Realbasic and I really like it. You can build stable, fast and extensive software with it and development is very quick: from idea to software can be literally days or weeks. I have built a CRM package our 7 person company runs on for the last 20 years and it's stable and reliable. The only area I would not recommend it for is games.