[HN Gopher] The Anatomy of a macOS App
___________________________________________________________________
The Anatomy of a macOS App
Author : elashri
Score : 165 points
Date : 2025-12-07 12:31 UTC (10 hours ago)
(HTM) web link (eclecticlight.co)
(TXT) w3m dump (eclecticlight.co)
| mitchellh wrote:
| > 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't
| optional and you're going to pay your $99/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't aware of notarization, your app looks
| straight up broken. See screenshots in the Apple support site
| here: https://support.apple.com/en-us/102445
|
| For users who are aware, you used to be able to right click and
| "run" apps and nowadays you need to actually go all the way into
| system settings to allow it:
| https://developer.apple.com/news/?id=saqachfa
|
| I'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'd love to hear a
| refutation to that because I've tried to find concrete evidence
| that notarization has helped prevent real issues and haven't been
| able to yet.
| jclay wrote:
| 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.
| deltaknight wrote:
| 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.
| ryandrake wrote:
| Wow. I haven't written software for Windows in over a
| decade. I always thought Apple was alone in its invasive
| treatment of developers on their platform. Windows used to
| be "just post the exe on your web site, and you're good to
| go." I guess Microsoft has finally managed to aggressively
| insert themselves into the distribution process there, too.
| Sad to see.
| jonathanlydall wrote:
| No, this information is wrong (unless it's changed in the
| last 7 years). EV code signing certs are instantly trusted
| by Windows Defender.
|
| Source: We tried a non-EV code signing certificate for our
| product used by only dozens of users at the time, never
| stopped showing scary warnings. When we got an EV, no more
| issues.
|
| In case it makes a difference, we use DigiCert.
| dceddia wrote:
| 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/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. https://melatonin.dev/blog/code-
| signing-on-windows-with-azur...
| jonathanlydall wrote:
| Thanks for the link, I see only available to basically US,
| Canada and EU though.
| TobbenTM wrote:
| You certainly don'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:
| https://moonbase.sh/articles/signing-windows-binaries-
| using-...
|
| TLDR: Doing this yourself requires a ~400-500$/year EV cert
| and miniscule cloud costs
| jonathanlydall wrote:
| Can confirm this, we use Azure KeyVault and are able to
| have Azure Pipelines use it to sign our release builds.
|
| We're (for the moment) a South African entity, so can't use
| Azure Trusted Signing, but DigiCert has no issue with us
| using Azure KeyVault for our EV code signing certificate.
|
| I had ours renewed just this week as it happens. Cost
| something like USD 840 before tax, don't have a choice
| though and in the grand scheme of things it's not a huge
| expense for a company.
| jezek2 wrote:
| I solved it by putting a "How to install.rtf" file alongside
| the program.
|
| Another alternative would be to bundle this app:
| https://github.com/alienator88/Sentinel
|
| It allows to easily unlock it by drag'n'drop.
| tyre wrote:
| What is the subset of users who are going to investigate
| and read an rtf file but don't know how to approve an
| application via system settings (or google to do so)?
| Klonoar wrote:
| 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.
| TheDong wrote:
| > notarization has been a net negative for all parties involved
|
| Notarization 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/year to notarize.
|
| As such, I believe it'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's profit each year, and
| notarization should be a pro feature that requires a macbook
| pro or a mac pro to unlock.
| mrpippy wrote:
| 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.
| sholladay wrote:
| 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.
|
| https://www.wired.com/story/facebook-research-app-root-certi...
|
| https://www.eff.org/deeplinks/2019/02/google-screenwise-unwi...
| lapcat wrote:
| The article is about macOS apps, but you'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.
| internet2000 wrote:
| 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.
| jonathanlydall wrote:
| 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.
| sneak wrote:
| 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 /Applications
| inside the .dmg image otherwise they won't know where to drag
| the app to to install it.
| sneak wrote:
| The problem is not that it's $99/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.
| pjmlp wrote:
| As side note, NeXTSTEP bundle system was the inspiration for
| Java's JAR files.
| dana321 wrote:
| jars are just zip files renamed
| pjmlp wrote:
| Inspired by how NeXTSTEP bundles work.
|
| People keep missing Java's ideas due to OpenSTEP
| collaboration before Java came to be.
|
| https://cs.gmu.edu/~sean/stuff/java-objc.html
|
| https://en.wikipedia.org/wiki/Distributed_Objects_Everywhere
| steve1977 wrote:
| I guess there's a reason that Cocoa was called Cocoa...
| it's also a hot beverage like Java, just sweeter ;)
| kbolino wrote:
| JAR has additional structure to it, though it's mostly
| optional stuff, like metadata and code signing:
|
| https://docs.oracle.com/en/java/javase/21/docs/specs/jar/jar.
| ..
| LoganDark wrote:
| Don't forget to delete META-INF!
| favorited wrote:
| Wait until you learn what an iOS app's .ipa file is.
| 13415 wrote:
| No wonder everyone is building web apps. Operating systems are
| doing their best to make themselves obsolete.
| mikecsh wrote:
| I don't follow - can you elaborate?
| bigyabai wrote:
| If developers have to static-link all their libraries to ship
| a Mac-native app, you're already doing most of the work to
| ship a cross-platform web runtime like Electron.
|
| Therefore it's not super surprising that successful products
| like Discord/Slack/Spotify gave up on a good native
| experience decades ago.
| kccqzy wrote:
| 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.
| dana321 wrote:
| The old macos classic was a lot of fun, i remember using resedit
| on some apps at school.
| mvkel wrote:
| That first os screenshot made my heart sink; a reminder of how
| far we'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 / omarchy setup.
| Wowfunhappy wrote:
| I'm no fan of modern macOS, but I don't think that screenshot
| is great. There'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.)
| astrange wrote:
| Rounded corners are a utilitarian feature. Human vision is
| based on edge detection and corners unnaturally activate it
| more than necessary. It's basically like being continually
| poked in the eye.
|
| https://folklore.org/Round_Rects_Are_Everywhere.html
| cachius wrote:
| 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.
| astrange wrote:
| Ah well, the evidence for my claim is that I just told you.
| This particular claim is not a Steve Jobs story, but he
| would agree I think.
|
| I did tell a true and previously unreported Steve Jobs
| story on reddit the other day and was voted to -10 and
| someone told me I was off my meds. In conclusion, Steve
| Jobs is a land of contrasts.
|
| > AFAIK motion is most easily perceptible.
|
| That's how it works for predators, but you can see things
| that are still if you're focusing on them. It's important
| to see corners in real life because they actually can poke
| you. Like a paper cut.
| Archit3ch wrote:
| While this is the "standard" 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/Contents/Libraries . Not to be confused with
| /Library or the recommended /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 /Libraries directory.
| secretsatan wrote:
| 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.
| classichasclass wrote:
| 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.
___________________________________________________________________
(page generated 2025-12-07 23:00 UTC)