Is there any "publishing service" for MacOS that takes a percentage of each sale and allows you to provide build scripts and source code, compiles and tests the application and distributes it on the app store?

If not, do the Apple EULAs prohibit such a service or is it not considered lucrative enough?

I used to develop for MacOS but have stopped supporting it entirely since Catalina, because I cannot be bothered with being locked into Apple's development tools, notarization, the Developer Network, and so on. It just isn't worth my time and money, but I'd still like to distribute native applications. Provided the EULA of such a service would be reasonable (e.g. good protection of the source code), I'd gladly use it, since otherwise all Apple sales are lost anyway. But there doesn't seem to be any such service, and it's IMHO weird that Apple don't offer that themselves.

You’d have to give them your signing certificate.

This notarization nonsense is being implemented very poorly it sure feels like. Shouldn't we be more focused on sand boxing and default settings for the sandboxes, vs forcing user applications to ask for everything they need? Put the burden on the runner, not the application.

Am I missing something fundamental here?

The way to think of notarization is that it's basically the same thing as Windows Defender's Automatic Sample Submission, which sends unknown executables to Microsoft for analysis. Only instead of having the end-user's machine upload the executable the first time it's run, the developer has to upload it to Apple. (This is better from a privacy/marketing standpoint.)

In this case, the user application also had to explicitly request permission to run unsigned just-in-time-compiled code. This makes sense because macOS apps are typically written in compiled languages like Objective-C or Swift, so executing unsigned code usually means someone's doing something bad like a buffer overflow attack. Also, Apple probably wants to collect metrics on how many apps use JIT (and how) so they can restrict it more in future OS releases.

I agree that a well-implemented sandbox seems like a much better solution here.

I’m working on a MacOS app and I started with a somewhat similar idea but with Go instead of Racket. I ended up ditching it for pure Swift. The main difference between myself and the author is that I ended up really liking Swift. Otherwise I would have stuck with my original approach.

> More importantly, I plan to support Windows and Linux which means that writing the core in a portable language is going to minimize the amount of work I have to do as well as the differences between the implementations on each platform.

That's the main difference between you and the author.

I plan to support those too. My hope is that some of the business logic written in Swift will be shared across platforms. So the big difference is definitely how we feel about the language. Our goals are very similar.

The last I checked, Swift is not supported on Windows — and Linux support is tentative at beat. I mean, only Ubuntu is officially supported.

I can’t find anything that suggests Ubuntu is the only officially supported distro. Can you share a reference for that?

I have seen a lot of movement for Windows but you might be right that this could be a problem. My hope is that it gets resolved before I get there. Great point though. I kind of just assumed I could ship Swift on Windows.

> it is a completely native Cocoa application whose frontend is built with Swift, the core business logic is all in Racket

This is generally the way to go if you want to be cross-platform: write your core code in the language of your choice, but make sure you use the platform frameworks for the porcelain. If you do it well, your users won’t notice the difference!

This is easy to say for Mac, where there’s a “true” platform framework. It’s not as clear cut for Windows/Linux, and hell if I’m going to spin my wheels writing UI code for ages. It’s been beaten to death relentlessly but there’s a reason nobody actually does this anymore.

It’s also seriously funny that it’s the same accounts that argue this stuff every time it comes up on this site. ;P

There's a true platform framework for Windows, and that's either WPF if you need to target Windows pre 10, and WinUI / UWP for targeting Windows 10

People do this all the time, there's native mobile applications using the true platform frameworks for both operating systems

Win32 is still the definition of native on Windows, it's used by Explorer, Paint, cmd, WinRar, Chrome, Firefox and many more applications. Most UWP applications did not succeed their Win32 counterparts (yet?), for example Edge (which is replaced by Chromium, which is built on Win32), Paint 3D (where Microsoft paddled back from their initial statement of removing the "old" mspaint.exe), Groove Music (basically on life support).

There's plenty of abstractions for Win32, too, such as Qt (see VLC for example, which feels native to Windows).

The only major consumer program written in WPF I know is Visual Studio, but I haven't heard of WPF development in a long time (except for the move to open source).

I think at this point GTK is the de-facto "native" for Linux desktops unless you've named your application something that begins with 'k'.

GTK has the advantage of having fully capable bindings for every language under the sun, so I would generally agree.

Qt is harder to create bindings for since it’s C++, meaning it’s more likely that your language of choice doesn’t have bindings, in which case if said language doesn’t have C++ interop you’re stuck.

Yeah, right. If you do that you are legally required to use Qt.

Honestly, just write the front-end in Visual Studio/C# and that should be native.

Or write it in Win32 api, in C.

For GNU/Linux, write it in GTK or QT, as appropriate.

It comes up quite often ;)

Sounds slow to use RPC with JSON for communication.

It seems that Racket does allow for C-to-Racket calls. You could write a glue program that generates C code that calls Racket functions and returns data, Swift code can then be generated to call that C code. That might be faster.

Sending/receiving (plus encoding and decoding) one payload takes less than 100 microseconds on my machine. It's far from being a problem, although you're right that linking against a shared library and making the calls that way would be faster.