The situation on Windows got remarkably better and cheaper recently-ish with the addition of Azure code signing. Instead of hundreds or thousands for a cert it’s $10&#x2F;month, if you meet the requirements (I think the business must have existed for some number of years first, and some other things).If you go this route I highly recommend this article, because navigating through Azure to actually set it up is like getting through a maze. <a href="https:&#x2F;&#x2F;melatonin.dev&#x2F;blog&#x2F;code-signing-on-windows-with-azure-trusted-signing&#x2F;" rel="nofollow">https:&#x2F;&#x2F;melatonin.dev&#x2F;blog&#x2F;code-signing-on-windows-with-azur...</a>

The EV cert system is truly terrible on Windows. Worst of all, getting an EV cert isn’t even enough to remove the scary warnings popping up for users! For that you still need to convince windows defender that you’re not a bad actor by getting installs on a large number of devices, which of course is a chicken-and-egg problem for software with a small number of users.At least paying your dues to Apple guarantees a smooth user experience.

I solved it by putting a &quot;How to install.rtf&quot; file alongside the program.Another alternative would be to bundle this app: <a href="https:&#x2F;&#x2F;github.com&#x2F;alienator88&#x2F;Sentinel" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;alienator88&#x2F;Sentinel</a>It allows to easily unlock it by drag&#x27;n&#x27;drop.

I have been trying to get people to realize that this is the same or worse for like a year now.It’s unfortunate it’s come to this but Apple is hardly the worst of the two now.

You certainly don&#x27;t need a hardware token, you can store it in any FIPS 140 Level 2+ stores. This includes stuff like Azure KeyVault and AWS KMS.Azure Trusted Signing is 100% the best choice, but if for whatever reason you cannot use it, you can still use your own cloud store and hook in the signing tools. I wrote an article on using AWS KMS earlier this year: <a href="https:&#x2F;&#x2F;moonbase.sh&#x2F;articles&#x2F;signing-windows-binaries-using-aws-kms&#x2F;" rel="nofollow">https:&#x2F;&#x2F;moonbase.sh&#x2F;articles&#x2F;signing-windows-binaries-using-...</a>TLDR: Doing this yourself requires a ~400-500$&#x2F;year EV cert and miniscule cloud costs

That&#x27;s right, there&#x27;s a similar comparison between the iOS App Store and Android Play Store. Although the annual $99 fee is indeed expensive, the Play Store requires every app to find 12 users for 14 days of internal testing before submission for review, which is utterly incomprehensible, not to mention the constant warnings about inactive accounts potentially being disabled.

I thought the macOS notarization process was annoying until we started shipping Windows releases.It’s basically pay to play to get in the good graces of Windows Defender.I think all-in it was over $1k upfront to get the various certs. The cert company has to do a pretty invasive verification process for both you and your company.Then — you are required to use a hardware token to sign the releases. This effectively means we have one team member who can publish a release currently.The cert company can lock your key as well for arbitrary reasons which prevents you from being able to make a release! Scary if the release you’re putting out is a security patch.I’ll take the macOS ecosystem any day of the week.

The signing is definitely about control, as is all things with Apple, but there are security benefits. It&#x27;s a pretty standard flow for dev tools to ad-hoc (self) sign binaries on macOS (either shelling out to codesign, or using a cross-platform tool like <a href="https:&#x2F;&#x2F;github.com&#x2F;indygreg&#x2F;apple-platform-rs" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;indygreg&#x2F;apple-platform-rs</a>). Nix handles that for me, for example.It makes it easy for tools like Santa or Little Snitch to identify binaries, and gives the kernel&#x2F;userspace a common language to chat process identity. You can configure similar for Linux: <a href="https:&#x2F;&#x2F;www.redhat.com&#x2F;en&#x2F;blog&#x2F;how-use-linux-kernels-integrity-measurement-architecture" rel="nofollow">https:&#x2F;&#x2F;www.redhat.com&#x2F;en&#x2F;blog&#x2F;how-use-linux-kernels-integri...</a>But Apple&#x27;s system is centralized. It would be nice if you could add your own root keys! They stay pretty close to standard X.509.

In my case, as a developer of a programming language that can compile to all supported platforms from any platform the signing (and notarization) is simply incompatible with the process.Not only is such signing all about control (the Epic case is a great example of misuse and a reminder that anyone can be blocked by Apple) it is also anti-competitive to other programming languages.I treat each platform as open only when it allows running unsigned binaries in a reasonable way (or self-signed, though that already has some baggage of needing to maintain the key). When it doesn&#x27;t I simply don&#x27;t support such platform.Some closed platforms (iOS and Android[1]) can be still supported pretty well using PWAs because the apps are fullscreen and self-contained unlike the desktop.[1] depending on if Google will provide a reasonable way to run self-signed apps, but the trust that it will remain open in the future is already severely damaged

The article is about macOS apps, but you&#x27;re talking about iOS apps.Apple revokes macOS Developer ID code signing certificates all the time, mostly for malware, but occasionally for goodware, e.g., Charlie Monroe and HP printer drivers.Also, infamously, Apple revoked the macOS Developer ID cert of Epic Games, as punishment for their iOS App Store dispute.

I’m only aware of two times that Apple has revoked certificates for apps distributed outside of the App Store. One was for Facebook’s Research App. The other was for Google’s Screenwise Meter. Both apps were basically spyware for young teens.In each case, Apple revoked the enterprise certificate for the company, which caused a lot of internal fallout beyond just the offending app, because internal tools were distributed the same way.Something may have changed, though, because I see Screenwise Meter listed on the App Store for iOS.<a href="https:&#x2F;&#x2F;www.wired.com&#x2F;story&#x2F;facebook-research-app-root-certificate&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.wired.com&#x2F;story&#x2F;facebook-research-app-root-certi...</a><a href="https:&#x2F;&#x2F;www.eff.org&#x2F;deeplinks&#x2F;2019&#x2F;02&#x2F;google-screenwise-unwise-trade-all-your-privacy-cash" rel="nofollow">https:&#x2F;&#x2F;www.eff.org&#x2F;deeplinks&#x2F;2019&#x2F;02&#x2F;google-screenwise-unwi...</a>

It’s a friction point for potential customers, so we do it with our Electron based app,The USD 99 annual fee is almost inconsequential, the painful part was getting a DUNS number (we’re a South African entity) and then getting it to work in a completely automated manner on our build server.Fortunately, once set up it’s been almost no work since.

It is a big deal. You can no longer just right click apps to run them, you have to take a trip to a subpanel of system settings, after clicking though two different dialogs that are designed to scare you into thinking something is wrong (one mentions malware by name).For normal users this might as well be impossible.Remember, your average user needs a shortcut to &#x2F;Applications inside the .dmg image otherwise they won’t know where to drag the app to to install it.

Maybe half of the 3rd party apps I have on my applications folder right now are not notarized. It’s really not that big of a deal.

The stapled ticket is optional beyond notarization itself. If you notarize but don’t staple the ticket, users may need an internet connection to check the notarization status.

I think the lack of any human to talk to is the worst part of modern tech. Especially for business, where your income may depend on it. It&#x27;s beyond cruel to prevent people from operating with no explanation of why and no way to find out how to fix it.

The problem is not that it’s $99&#x2F;year. The problem is that it requires strong ID, and if you are doing it as a company (ie if you don’t want Apple to publicize your ID name to everyone who uses your app) then you have to go through an invasive company verification process that you can fail for opaque reasons unrelated to fraud or anything bad.The system sucks. I’d love to be able to sign my legitimate apps with my legitimate company, but I don’t wish to put the name on my passport onto the screens of millions of people, and my company (around and operating for 20-ish years now) doesn’t pass the Apple verification for some reason.I also can’t use auto-enroll (DEP) MDM for this reason.

&gt; notarization has been a net negative for all parties involvedNotarization made it significantly harder to cross-compile apps for macOS from linux, which means people have to buy a lot of macOS hardware to run in CI instead of just using their existing linux CI to build mac binaries.You also need to pay $99&#x2F;year to notarize.As such, I believe it&#x27;s resulted in profit for Apple, so at least one of the parties involved has had some benefit from this setup.Frankly I think Apple should keep going, developer licenses should cost $99 + 15% of your app&#x27;s profit each year, and notarization should be a pro feature that requires a macbook pro or a mac pro to unlock.

&gt; while that shown in blue is the stapled notarisation ticket (optional)This is correct, but practically speaking non-notarized apps are pretty terrible to use for a user enough so that this isn&#x27;t optional and you&#x27;re going to pay your $99&#x2F;yr Apple tax.(This only applies to distributed software, if you are only building and running apps for your own personal use, its not bad because macOS lets you do that without the scary warnings)For users who aren&#x27;t aware of notarization, your app looks straight up broken. See screenshots in the Apple support site here: <a href="https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;102445" rel="nofollow">https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;102445</a>For users who are aware, you used to be able to right click and &quot;run&quot; apps and nowadays you need to actually go all the way into system settings to allow it: <a href="https:&#x2F;&#x2F;developer.apple.com&#x2F;news&#x2F;?id=saqachfa" rel="nofollow">https:&#x2F;&#x2F;developer.apple.com&#x2F;news&#x2F;?id=saqachfa</a>I&#x27;m generally a fan of what Apple does for security but I think notarization specifically for apps outside the App Store has been a net negative for all parties involved. I&#x27;d love to hear a refutation to that because I&#x27;ve tried to find concrete evidence that notarization has helped prevent real issues and haven&#x27;t been able to yet.

Seeing bureaucracy explode like this is rarely a good sign. As if I needed even more reasons to not &quot;upgrade&quot; to macOS 26.

Inspired by how NeXTSTEP bundles work.People keep missing Java&#x27;s ideas due to OpenSTEP collaboration before Java came to be.<a href="https:&#x2F;&#x2F;cs.gmu.edu&#x2F;~sean&#x2F;stuff&#x2F;java-objc.html" rel="nofollow">https:&#x2F;&#x2F;cs.gmu.edu&#x2F;~sean&#x2F;stuff&#x2F;java-objc.html</a><a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Distributed_Objects_Everywhere" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Distributed_Objects_Everywhere</a>

JAR has additional structure to it, though it&#x27;s mostly optional stuff, like metadata and code signing:<a href="https:&#x2F;&#x2F;docs.oracle.com&#x2F;en&#x2F;java&#x2F;javase&#x2F;21&#x2F;docs&#x2F;specs&#x2F;jar&#x2F;jar.html" rel="nofollow">https:&#x2F;&#x2F;docs.oracle.com&#x2F;en&#x2F;java&#x2F;javase&#x2F;21&#x2F;docs&#x2F;specs&#x2F;jar&#x2F;jar...</a>

Wait until you learn what an iOS app&#x27;s .ipa file is.

As side note, NeXTSTEP bundle system was the inspiration for Java&#x27;s JAR files.

It&#x27;s a good point, I wouldn&#x27;t have thought about it in terms of percentages, but I&#x27;d like to actually make use of the extra screen real-estate.

Count the pixels! Percentagewise, the window decorations and menu bar in that screenshot take up a lot more space than the modern equivalent does at 5K. If you&#x27;re comparing it to to the current 14&quot; Macbook Pro, it&#x27;s closer, but Macbook Pro still wins - and still continues to hold its own even if the classic Mac is producing a 1280x1024 display. And this even though the Macbook Pro is the space-constraised pocket version! (Also note: you haven&#x27;t even investigated the scaled display options yet)Disclaimer: I have a desktop Mac, and I&#x27;m assuming the pixel counts are the same for the laptops.(The window corners weren&#x27;t always round, but there was a bit of rounding to the screen corners there from day 1: <a href="https:&#x2F;&#x2F;infinitemac.org&#x2F;" rel="nofollow">https:&#x2F;&#x2F;infinitemac.org&#x2F;</a> - this really struck me when I first saw it, coming from the Atari ST.)

I&#x27;m no fan of modern macOS, but I don&#x27;t think that screenshot is great. There&#x27;s too many lines everywhere and too little color, making it unclear where to focus your eye.(What I am a fan of is Leopard-era Aqua, which is reasonably information dense but uses depth and color to help focus your attention.)

Computers are not just for business and corporate use. Believe it or not, some people use their computers for fun stuff.I do feel like we’ve gone too far from utilitarian though. I’d like to see more practical UI design.

The link tells the story how Bill Atkinson sped up drawing primitives on early Apple devices.It does not support the claim that corners are in any way special for human vision. I’m very skeptical on that. AFAIK motion is most easily perceptible.

Rounded corners are a utilitarian feature. Human vision is based on edge detection and corners unnaturally activate it more than necessary. It&#x27;s basically like being continually poked in the eye.<a href="https:&#x2F;&#x2F;folklore.org&#x2F;Round_Rects_Are_Everywhere.html" rel="nofollow">https:&#x2F;&#x2F;folklore.org&#x2F;Round_Rects_Are_Everywhere.html</a>

That first os screenshot made my heart sink; a reminder of how far we&#x27;ve fallen.How I wish our operating systems still looked like this. Utilitarian, useful. No rounded corners and bubbly icons, reducing the useful space more and more each year.The incredible quality of Mac hardware is the only thing keeping me from jumping to a thinkpad &#x2F; omarchy setup.

The old macos classic was a lot of fun, i remember using resedit on some apps at school.

A bit of a sharpshoot here, but Power Mac applications for classic Mac OS, including fat binaries, put the PPC executable code in the data fork. This was also true for CFM-68K binaries. Only old school 68K code went in CODE resources.

AFAIK, and not technically relevant, but iOS is very strict on this when submitting to the app store, and they’re not at all clear about it either, i had some very confusing and frustrating errors with self built frameworks with dynamic libraries. You also seem to be forbidden to use .dylib and must use the .framework format.It’s picked up on submission automatically and not at review, but is a completely undocumented requirement.

While this is the &quot;standard&quot; macOS App structure, it is not the only one that works.IIRC, you can put stuff in arbitrary subfolders as long as you configure the RPATHs correctly. This works and passes notarization. I came across libname.dylib in the nonstandard location AppName.App&#x2F;Contents&#x2F;Libraries . Not to be confused with &#x2F;Library or the recommended &#x2F;Frameworks location. However, there are basically no benefits compared to using the recommended directory structure, and none of the 100+ macOS apps installed in my system have a &#x2F;Libraries directory.

I’ll take this standardized directory format over the typical docker web app where there is no standardization and files can be strewn anywhere the developer wants. You `docker exec` into it and can’t find anything.

i think you meant everyone builds web apps because they want to target all platforms &#x2F; hardware, they don’t care about performance (cpu usage, memory usage, etc), and they are easier to “deploy” in many respects.Pros and cons to each. Not everything needs to be a native app. Some things SHOULD be native apps…i’m looking at you slack and friends.

If developers have to static-link all their libraries to ship a Mac-native app, you&#x27;re already doing most of the work to ship a cross-platform web runtime like Electron.Therefore it&#x27;s not super surprising that successful products like Discord&#x2F;Slack&#x2F;Spotify gave up on a good native experience decades ago.

I don&#x27;t follow - can you elaborate?

No wonder everyone is building web apps. Operating systems are doing their best to make themselves obsolete.

The Anatomy of a macOS App

Turtletoy

Emacs is my new window manager

Damn Small Linux

I failed to recreate the 1996 Space Jam website with Claude

Bag of words, have mercy on us

Dollar-stores overcharge customers while promising low prices

Mechanical power generation using Earth's ambient radiation

PDF: <a href="https:&#x2F;&#x2F;www.stroustrup.com&#x2F;JSF-AV-rules.pdf" rel="nofollow">https:&#x2F;&#x2F;www.stroustrup.com&#x2F;JSF-AV-rules.pdf</a>

The C++ standard for the F-35 Fighter Jet [video]

Google Titans architecture, helping AI have long-term memory

Work disincentives hit the near-poor hardest (2022)

Uninitialized garbage on ia64 can be deadly (2004)

An Interactive Guide to the Fourier Transform

Solving Rush Hour, the Puzzle (2018)

<a href="https:&#x2F;&#x2F;archive.is&#x2F;jEJAj" rel="nofollow">https:&#x2F;&#x2F;archive.is&#x2F;jEJAj</a>