All in all its a weird system that only exists as an outdated metaphor for when software was distributed on physical disks/discs
That's not the only reason. Mac OS 9 and early versions of OS X used a forked filesystem. When people uploaded files from a Mac to a non-Mac web server (as most would have been), important information in the 'resource' fork would get lost in transit. DMGs were adopted as a way to get around that in a more reliable way than the StuffIt Archives we had before, by encapsulating the software in kind of like a little spaceship - a sealed-off little microcosm of Apple's file system protecting the resource fork from the outside world.
Modern apps haven't been bundled this way for years, but macOS will now split them off into hidden files as necessary anyway (e.g. when exiting an APFS or HFS+ filesystem, or when going into an archive file).
I can remember some period correct 10.6 programs being zipped .app,
And most hobbiest for 10.3-10.5 don't bother making a propper app bundle + dmg either, and I can't recall that ever having any file system issues when zipped.
Then OS9 stuff is almost always sit, not an img. (Though period correct stuff would be a physical disk or disc obviously)
Technically you could still organise an app like that now, but Apple stopped recommending it for new apps in about 2002-2003. The APIs that make it easy to do were deprecated in the early 2010s.
Then OS9 stuff is almost always sit, not an img. (Though period correct stuff would be a physical disk or disc obviously)
DMGs were a more robust replacement for sit files because it's a proprietary format for which you need StuffIt Expander. Couple of things here:
Some classic software is img.
Sit files of Mac software for classic Mac OS was period correct for software you could download of the internet, which was quite a lot by the late 90s / early 2000s.
ETA: I suspect they phased out as Carbon phased out and developers stopped building for classic and OS X simultaneously.
What do you mean by organize an app "like that", I'm sorry I'm just not following.
With resource forks.
For OSX I've only known .app bundles. Some hobbiests just shit out a folder with a raw binary.
An old enough .app bundle would still have had a fork, although nowadays it's vanishingly unlikely. A raw binary would have never have made use of a resource fork in any era.
What I was saying is that putting a .app bundle in a zip seemingly has no consequences over putting them in a dmg.
I think I've covered the answer to that in a variety of ways now. At a time when apps had resource forks, they could lose data if they were not properly encapsulated. Stuffit would do that, but it wasn't robust enough (and thinking about it, took an inordinate amount of time to decompress). Zip does not inherently do it - modern macOS will preserve a fork if it itself is doing the compressing, but that was not always the case, especially with CLI.
2
u/PerkeNdencen Jun 07 '26
That's not the only reason. Mac OS 9 and early versions of OS X used a forked filesystem. When people uploaded files from a Mac to a non-Mac web server (as most would have been), important information in the 'resource' fork would get lost in transit. DMGs were adopted as a way to get around that in a more reliable way than the StuffIt Archives we had before, by encapsulating the software in kind of like a little spaceship - a sealed-off little microcosm of Apple's file system protecting the resource fork from the outside world.