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.
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.
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.
> 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
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.
[+] [-] JohnStrangeII|6 years ago|reply
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|6 years ago|reply
[+] [-] nixpulvis|6 years ago|reply
Am I missing something fundamental here?
[+] [-] csande17|6 years ago|reply
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|6 years ago|reply
[+] [-] olah_1|6 years ago|reply
That's the main difference between you and the author.
[+] [-] saagarjha|6 years ago|reply
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|6 years ago|reply
It’s also seriously funny that it’s the same accounts that argue this stuff every time it comes up on this site. ;P
[+] [-] jsjolen|6 years ago|reply
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|6 years ago|reply