
Native Applications with Racket - Bogdanp
https://defn.io/2020/01/04/remember-internals/
======
JohnStrangeII
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.

~~~
saagarjha
You’d have to give them your signing certificate.

------
nixpulvis
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?

~~~
csande17
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.

------
todd3834
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.

~~~
olah_1
> 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.

~~~
todd3834
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.

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

~~~
todd3834
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.

~~~
satyenr
[https://swift.org/download/#releases](https://swift.org/download/#releases)

------
saagarjha
> 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!

~~~
Klonoar
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

~~~
catalogia
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'.

~~~
kitsunesoba
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.

------
jsjolen
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.

~~~
Bogdanp
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.

