macOS Archive

James Thomson, developer of, originally, DragThing and now PCalc, also happens to be the developer of the very first publicly shown version of the Mac OS dock. Now that it was shown to the world by Steve Jobs exactly 25 years ago, he reminisces about what it was like to create such an iconic piece of software history. The new Finder (codename “Millennium”) was at this point being written on Mac OS 9, because Mac OS X wasn’t exactly firing on all cylinders quite yet. The filesystem wasn’t working well, which is not super helpful when you are trying to write a user interface on top of it. The Dock was part of the Finder then, and could lean on all the high level C++ interfaces for dealing with disks and files that the rest of the team was working on. So, I started on Mac OS 9, working away in Metrowerks Codewarrior. The Finder was a Carbon app, so we could actually make quite a bit of early progress on 9, before the OS was ready for us. I vividly remember the first time we got the code running on Mac OS X. ↫ James Thomson I especially like the story about how Steve Jobs really demanded Thomson live in Cupertino in order to work on the dock, instead of remaining remote in Ireland. Thomson and his wife decided not to move to the United States, so he figured he’d lose his assignment, or maybe even his job altogether. Instead, his managers told him something along the lines of “don’t worry, we’ll just tell Steve you moved”. What followed were a lot of back-and-forth flights between Ireland and California, and Thomson’s colleagues telling Steve all sorts of lies and cover stories for whenever he was in Ireland and Steve noticed. Absolutely wild. The dock is one of those things from my years using Mac OS X – between roughly 2003 and 2009 or so – that has stuck around with me ever since. To this day, I have a dock at the bottom of my screen that looks and works eerily similar to the Mac OS X dock, and I doubt that’s going to change any time soon. It suits my way of using my computer incredibly well, and it’s the first thing I set up on any new installation I perform (I use Fedora KDE).

Many MacOS users are probably used by now to the annoyance that comes with unsigned applications, as they require a few extra steps to launch them. This feature is called Gatekeeper and checks for an Apple Developer ID certificate. Starting with MacOS Sequoia 15, the easy bypassing of this feature with e.g. holding Control when clicking the application icon is now no longer an option, with version 15.1 disabling ways to bypass this completely. Not unsurprisingly, this change has caught especially users of open source software like OpenSCAD by surprise, as evidenced by a range of forum posts and GitHub tickets. ↫ Maya Posch at Hackaday It seems Apple has disabled the ability for users to bypass application signing entirely, which would be just the next step in the company’s long-standing effort to turn macOS into iOS, with the same, or at least similar, lockdowns and restrictive policies. This would force everyone developing software for macOS to spend €99 per year in order to get their software signed, which may not be a realistic option for a lot of open source software. Before macOS 15.0, you could ctrl+right-click an unsigned application and force it to run. In macOS 15.0, Apple removed the ability to do this; instead, you had to try and open the application (which would fail), and then open System Settings, go to Privacy & Security, and click the “Open Anyway” button to run the application. Stupidly convoluted, but at least it was possible to run unsigned applications. In macOS 15.1, however, even this convoluted method no longer seems to be working. When you try and launch an unsigned application in macOS 15.1, you get a dialog that reads The application “Finder” does not have permission to open “(null)”, and no button to open the application anyway appears under Privacy & Security. The wording of the dialog would seem to imply this is a bug, but Apple’s lack of attention to UI detail in recent years means I wouldn’t be surprised if this is intentional. This means that the only way to run unsigned applications on macOS 15.1 is to completely disable System Integrity Protection and Gatekeeper. To do this, you have to boot into recovery mode, open the terminal, run the command sudo spctl --master-disable, reboot. However, I do not consider this a valid option for 99.9% of macOS users, and having to disable complex stuff like this through recovery mode and several reboots just to launch an application is utterly bizarre. For those of you still stuck on macOS, I can only hope this is a bug, and not a feature.

You have to wonder how meaningful this news is in 2024, but macOS 15.0 Sequoia running on either Apple Silicon or Intel processors is now UNIX 03-certified. The UNIX 03 Product Standard is the mark for systems conforming to Version 3 of the Single UNIX Specification. It is a significantly enhanced version of the UNIX 98 Product Standard. The mandatory enhancements include alignment with ISO/IEC 9989:1999 C Programming Language, IEEE Std 1003.1-2001 and ISO/IEC 9945:2002. This Product Standard includes the following mandatory Product Standards: Internationalized System Calls and Libraries Extended V3,Commands and Utilities V4, C Language V2, and Internationalized Terminal Interfaces. ↫ UNIX 03 page The questionable usefulness of this news stems from a variety of factors. The UNIX 03 specification hails from the before time of 2002, when UNIX-proper still had some footholds in the market and being a UNIX meant something to the industry. These days, Linux has pretty much taken over the traditional UNIX market, and UNIX certification seems to have all but lost its value. Only one operating system can boast to conform to the latest UNIX specification – AIX is UNIX V7 and 03-certified – while macOS and HP-UX are only UNIX 03-certified. OpenWare, UnixWare, and z/OS only conform to even older standards. On top of all this, it seems being UNIX-certified by The Open Group feels a lot like a pay-to-play scheme, making it unlikely that community efforts like, say, FreeBSD, Debian, or similarly popular server operating systems could ever achieve UNIX-certification even if they wanted to. This makes the whole UNIX-certification world feel more like the dying vestiges of a job security program than something meaningful for an operating system to aspire to. In any even, you can now write a program that compiles and runs on all two UNIX 03-certified operating systems, as long as it only uses POSIX APIs.

The widely–reported “foo is requesting to bypass the system private window picker and directly access your screen and audio” prompt in Sequoia (which Apple has moved from daily to weekly to now monthly) can be disabled by quitting the app, setting the system date far into the future, opening and using the affected app to trigger the nag, clicking “Allow For One Month”, then restoring the correct date. ↫ tinyapps.org blog Or, and this is a bit of a radical idea, you could use an operating system that doesn’t infantalise its users.

It’s one of the most pervasive common wisdoms shared all over the web, no matter where you go – it’s one of those things everybody seems to universally agree on: Chrome will absolutely devastate your battery life on the Mac, and you should really be using Safari, because Apple’s special integration magic pixie dust sprinkles ensures Safari sips instead of gulps electricity. Whether you read random forum posters, Apple PR spokespeople, or Apple’s own executives on stage during events, this wisdom is hard to escape. Is it true, though? Well, Matt Birchler decided to do something entirely revolutionary and entirely unheard of: a benchmark. Back in the olden days of yore, we would run benchmarks to test the claims from companies and their PR departments, and Birchler decided to dust off this old technique and develop a routine to put the Chrome battery claims to the test. After 3 days of continuous testing on a freshly installed 14” MacBook Pro with an M2 Pro processor and 16 GB RAM running the latest stable releases of both browsers, Birchler came to some interesting conclusions. In my 3-hour tests, Safari consumed 18.67% of my battery each time on average, and Chrome averaged 17.33% battery drain. That works out to about 9% less battery drain from Chrome than Safari. Yes, you read that right, I found Chrome was easier on my battery than Safari. While I did experience some variability in each 3 hour test run, Chrome came out on top in 5 of the 6 direct comparisons. ↫ Matt Birchler His methodology seems quite sound and a good representation of what most laptop users will use their browser for: YouTube, social media, a few news websites, and editing a Google Doc, in a 20 minute loop that was repeated for three hours per test. Multiple of these three hour tests were then ran to counter variability. I highly doubt using different websites will radically change the results, but I obviously am curious to see a similar test ran on Windows and Linux, x86 and ARM, for a more complete picture that goes beyond just the Mac. Conventional wisdom is sometimes wrong, and I think we have a classic case of that here. While there may have been a time in the past where Chrome on the Mac devastated battery life, it seems Chrome and Chromium engineers have closed the gap, and in some cases even beat Safari. Now, this doesn’t mean everybody should rush and switch to Chrome, since there are countless other reasons to use Safari over Chrome other than supposed battery life advantages. With Apple PR arguing that alternative browser engines should not be allowed on iOS because Chrome would devastate iOS’ battery life, tests like these are more important than ever, and I hope we’re going to see more of them. Tech media always just seems to copy/paste whatever manufacturers and corporations claim without so much as a hint of skepticism, and this benchmark highlights the dangers of doing so, in case you didn’t already know believing corporations was a terribly idea.

When you launch an app, macOS connects to Apple’s OCSP service to check whether the app’s Developer ID code signing certificate has been revoked by Apple. In November 2020, Apple’s OCSP service experienced a mass outage, preventing Mac users worldwide from launching apps. In response and remedy to this outage, Apple made several explicit promises to Mac users in a support document, which can still be seen in a Wayback Machine archive from September 24, 2023. ↫ Jeff Johnson One of the explicit promises Apple made was that it would allow macOS users to turn off phoning home to Cupertino every time you launch an application on macOS. It’s four years later now, and this promise has not been kept – Apple still does not allow you to turn off phoning home. In fact, it turns out that last year, Apple scrubbed this promise from all of its documentation, hoping we’re all going to forget about it. In other words, Apple is never going to allow its macOS users to stop the operating system from phoning home to Cupertino every time you launch an application. Even though the boiling frog story is nonsensical, it’s apt here. More and more Apple is limiting its users’ control over macOS, locking it down to a point where you’re not really the owner of your computer anymore. Stuff like this gives me the creeps.

With macOS Sequoia this fall, using apps that need access to screen recording permissions will become a little bit more tedious. Apple is rolling out a change that will require you to give explicit permission on a weekly basis to these types of apps, and every time you reboot your Mac. If you’ve been using the macOS Sequoia beta this summer in conjunction with a third-party screenshot or screen recording app, you’ve likely been prompted multiple times to continue allowing that app access to your screen. While many speculated this could be a bug, that’s not the case. ↫ Chance Miller Everybody is making comparisons to Windows Vista, but I don’t think that’s fair at all. Windows Vista suffered from an avelanche of permission dialogs because the wider Windows application, driver, and peripheral ecosystem was not at all used to the security boundaries present in Windows NT being enforced. Vista was the first consumer-focused version of Windows that started doing this, and after a difficult transition period, the flood of dialogs settled down, and for a long time now you can blame Windows for a lot of things, but it’s definitely not throwing up more permission dialogs than, say, an average desktop-focused Linux distribution. In other words, Vista’s UAC dialogs were a desperately necessary evil, an adjustment period the Windows ecosystem simply had to go through, and Windows as a whole is better off for it today. This, however, is different. This is Apple having such a low opinion of its users, and such a deep disregard for basic usability and computer ownership, that it feels entirely okay with bothering its users with weekly – or more, if you tend to reboot – nag dialogs for applications the user has already properly given permission to. I don’t have any real issues with a reminder or permission dialog upon first launching a newly installed screen recording application – or when an exisiting application gains this functionality in an update – but nagging users weekly is just beyond insanity. More and more it feels like macOS is becoming an operating system for toddlers – or at least, that’s how Apple seems to view its users.

The Macintosh was intended to be different in many ways. One of them was its file system, which was designed for each file to consist of two forks, one a regular data fork as in normal file systems, the other a structured database of resources, the resource fork. Resources came to be used to store a lot of standard structured data, such as the specifications for and contents of alerts and dialogs, menus, collections of text strings, keyboard definitions and layouts, icons, windows, fonts, and chunks of code to be used by apps. You could extend the types of resource supported by means of a template, itself stored as a resource, so developers could define new resource types appropriate to their own apps. ↫ Howard Oakley And using ResEdit, a tool developed by Apple, you could manipulate the various resources to your heart’s content. I never used the classic Mac OS when it was current, and only play with it as a retro platform every now and then, so I ever used ResEdit when it was the cool thing to do. Looking back, though, and learning more about it, it seems like just another awesome capability that Apple lost along the way towards modern Apple. Perhaps I should load up on my old Macs and see with my own eyes what I can do with ResEdit.

noTunes is a macOS application that will prevent iTunes or Apple Music from launching. Simply launch the noTunes app and iTunes/Music will no longer be able to launch. For example, when bluetooth headphones reconnect. You can toggle the apps functionality via the menu bar icon with a simple left click. ↫ noTunes GitHub page Apparently, this is such a common complaint that an application had to be made just to gain some semblance of control over what some people still refer to as “their” computer. For both macOS and Windows, there’s a giant industry – you can’t really call it a cottage industry anymore at this point – of tools, applications, and fixes just to deal with or avoid all the user-hostile, anti-choice garbage Apple and Microsoft shove into their respective operating systems. As a Linux user – and recent OpenBSD convert – I find this absolutely wild. Following any Apple podcast, or reading any Windows website, makes it so clear just how many hoops these people have to jump through and how many weirdly-shaped holes they have to contort into just to be able to gain some vague semblance of ownership of their own hardware. I’m not judging – we all have areas in our lives where we do this, they just differ from person to person – but it’s still confronting to see it so clearly, all the time.

After several days testing the latest Express 1M2 enclosure from OWC, I have changed my recommendations for the best external SSDs. Previously I had chosen the relatively reliable Thunderbolt 3 up to 3 GB/s, even though few drives ever seemed capable of achieving that up to. If you’re still needing good performance with an Intel Mac, that makes sense. But if you need best performance with an Apple silicon Mac, you’re far better off with a high-quality USB 40Gbps enclosure such as OWC’s Express 1M2, which should reliably return over 3 GB/s even through a compatible hub. I much prefer the word over to up to. ↫ Howard Oakley If you have an Apple Silicon Mac, and you’re looking for an external drive – this is some good advice to follow.

About a year ago I came across the Previous emulator – it appeared to be a faithful simulation of the NeXT hardware and thus capable of running NeXTStep. While including it in Infinite Mac would be scope-creep, NeXT’s legacy is in many ways more relevant to today’s macOS than classic Mac OS. It also helped that it’s under active development by its original creator (see the epic thread in the NeXT Computers forums), and thus a modern, living codebase. Previous is the fifth emulator that I’ve ported to WebAssembly/Emscripten and the Infinite Mac runtime, and it’s gotten easier. As I’m doing this work, I’m developing more and more empathy for those doing Mac game ports – some things are really easy and others become yak shaves due to the unintended consequences of choices made by the original developers. Previous is available on multiple platforms and has good abstractions, so overall it was a pretty pleasant experience. ↫ Mihai Parparita By porting previous to WebAssembly/Emscripten, Infinite Mac now offers access to a whole slew of NeXTSTEP releases, from the earliest known release to the last one from 1997. There’s also a ton of applications added to make the experience feel more realistic. This makes Infinite Mac even more useful than it already was, ensuring it’s one of the best and easiest ways to experience old macOS and now NeXTSTEP releases through virtual machines (real ones, this time), available in your browser. I’ll be spending some time with these new additions for sure, since I’ve very little experience with NeXTSTEP other than whatever I vicariously gleamed through Steven Troughton-Smith‘s toots on the subject over the years. Mihai Parparita is doing incredibly important work through Infinite Mac, and he deserves credit and praise for all he’s doing here.

Seven years ago, on 27 March 2017, Apple introduced one of the most fundamental changes in its operating systems since Mac OS X 10.0 Cheetah was released 16 years earlier. On that day, those who updated iOS to version 10.3 had their iPhone’s storage silently converted to the first release of Apple File System, APFS. Six months later, with the release of macOS 10.13 High Sierra on 25 September, Mac users followed suit. ↫ Howard Oakley The migration from HFS+ to APFS is still an amazing feat for Apple to have pulled off. Hundreds of millions devices converted from one filesystem to another, and barely anyone noticed – no matter how you look at it, that’s an impressive achievement, and the engineers who made it possible deserve all the praise they’re getting.

I recently bought a Macbook because more and more people are asking me how to use Nix in certain situations under MacOS. In this article, we walk through installing Nix on MacOS and see how pleasant the experience is these days. After that, we show how to go declarative on MacOS with nix-darwin to enable compilation for Linux and Intel Macs, as well as some other nice features. ↫ Jacek Galowicz You can’t click on a single link without tripping over people talking about nix.

We may have been using APFS for nearly seven years, but some of its features remain thoroughly opaque. On Christmas Day, I posed the puzzle of 60 TB of snapshots being removed from a 2 TB disk. While we all accept that may be “technically correct”, for ordinary users it makes no sense. Suggestions that they should be “educated” miss the point that the Finder has to be accessible to all users, whether or not they have a degree in Computer Science. If my eleven year-old granddaughter can’t make sense of it, then the Finder is a failure. Today I turn to another thorny issue raised by the ingenuity of APFS: the size of its special file types, sparse and ‘clone’ files. As usual, I start with a practical demonstration. ↫ Howard Oakley I feel like I should ring a little bell while posting a link to this article.