←back to thread

The Anatomy of a macOS App

(eclecticlight.co)
278 points elashri | 1 comments | 07 Dec 25 12:31 UTC | HN request time: 0.23s | source
Show context
13415 ◴[07 Dec 25 16:27 UTC] No.46182886[source]▶
No wonder everyone is building web apps. Operating systems are doing their best to make themselves obsolete.
replies(4): >>46184648 #>>46184967 #>>46186717 #>>46189793 #
mikecsh ◴[07 Dec 25 20:06 UTC] No.46184648[source]▶
I don't follow - can you elaborate?
replies(1): >>46185499 #
bigyabai ◴[07 Dec 25 21:46 UTC] No.46185499[source]▶
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.

replies(3): >>46186602 #>>46186794 #>>46186864 #
kccqzy ◴[08 Dec 25 00:08 UTC] No.46186794[source]▶
The article clearly states that Apple provides standardized locations for apps to store their dynamically linked libraries.
replies(1): >>46186882 #
ux266478 ◴[08 Dec 25 00:20 UTC] No.46186882[source]▶
one of the weirdest and most off-putting parts of macos for me was that dyld isn't aware of that standardized location. a lot of curious oversights the more you pick at it.
replies(1): >>46187205 #
dagmx ◴[08 Dec 25 01:13 UTC] No.46187205[source]▶
What do you mean? I can just tell the linker to link against something in the shared cache and it finds it. It’s been as simple as `-framework <FrameworkName>`

I’ve never had to do extra work to find a system vendored dylib in my decades of supporting cross platform apps.

replies(2): >>46191663 #>>46194275 #
eschaton ◴[08 Dec 25 12:54 UTC] No.46191663[source]▶
They probably mean that they don’t like the way the “install name” (as it’s referred to) of a shared library is embedded in the library and then copied to whatever links the library, and is then used to find the library at runtime. I suspect they’d prefer to build the shared library with an arbitrary install name and then just have it found automatically by being in the Frameworks or Libraries directory.

Most platforms don’t have a concept of “install name” distinct from the library name; the value was originally the full path to the deployment location of the library, which was revised to support meta-paths (like `@rpath/LibraryName`) in Mac OS X 10.4 and 10.5 and is what the runtime dynamic loader (dyld) uses to match a library at load time. So an application’s executable can have a set of self-relative run path search paths, which is how it can load libraries from its Frameworks and Libraries directories.

replies(1): >>46193619 #
dagmx ◴[08 Dec 25 15:45 UTC] No.46193619[source]▶
Ah fair enough. But generally an rpath is pretty good to go out of the box.

The primary binary encodes relative to the executable path and any dylib that loads from it should be able to (by default) load relative to that

replies(1): >>46199682 #
1. eschaton ◴[09 Dec 25 00:21 UTC] No.46199682[source]▶
Depends on whether you’re building with Xcode; when I worked on it, I ensured that the templates included with Xcode would have the right setup to declare appropriate run path search paths for applications, and appropriate install names for frameworks and (shared) libraries.

However when building with just command line tools and not passing all the same arguments an Xcode project and target causes to be passed, you have to do extra work to ensure the right run path search paths get into built executables and the right install names get into built libraries and frameworks.

That latter is to ensure that if you don’t pass those extra arguments, executables and shared libraries are built for Darwin-based platforms as much as reasonably possible like they are on other UNIX-like platforms.