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

As someone coding since 1986, with experience in native and Web development, and despite earning most of my money in Web, I assert it is lazyness.

There is no Web without operating systems, or do you imagine browsers run on pixie dust?

▲

kccqzy a day ago | parent | prev | next [-]

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.

▲

lurking_swe a day ago | parent | prev | next [-]

i think you meant everyone builds web apps because they want to target all platforms / 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.

▲

mikecsh a day ago | parent | prev [-]

I don't follow - can you elaborate?

▲

bigyabai a day ago | parent [-]

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.

▲

dagmx a day ago | parent | next [-]

Why do you believe you need to static link to ship a Mac native app?

There’s no such requirement. Tons of Mac apps bundle dylibs within them.

▲

kccqzy a day ago | parent | prev | next [-]

The article clearly states that Apple provides standardized locations for apps to store their dynamically linked libraries.

▲

ux266478 a day ago | parent [-]

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.

▲

dagmx a day ago | parent [-]

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.

▲

eschaton 12 hours ago | parent | next [-]

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.

▲

dagmx 10 hours ago | parent [-]

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

	▲	eschaton an hour ago \| parent [-]
		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.

▲

ux266478 9 hours ago | parent | prev [-]

I mean I had to manually patch the rpaths of macos binaries distributed as an app bundle, because dyld didn't have the relative location of the shared libs in the app bundle in its search path. Not a huge deal, since patching rpaths was also part of the other Unix pipelines, the reasoning was just different. Patching rpaths on other platforms was because we were distributing dependencies in the base directory of the application, which isn't the standard way to do things. On mac, it was because the dynamic linker wasn't aware of app bundle structure for some reason, which is a weird disconnect between an OS standard and a basic system component.

▲

ux266478 a day ago | parent | prev [-]

statically linking dependencies is a trivial change in a build script. why are you acting like its some esoteric forbidden art?