MacOS 10.14 Mojave Reviewed | Hacker News Reader

MacOS 10.14 Mojave Reviewed

arstechnica.com

210 pointsfeross130 comments

Obviously too late for this article, but here's a general tip: if you're going to show a bunch of comparison screen grabs, or before/after screen shots, and the like - e.g., https://arstechnica.com/features/2018/09/macos-10-14-mojave-... - don't put a scroll effect in. Don't put a fade down then fade up effect in. It makes it too hard to see the difference. Just flick instantly between one and the next.

That reminds me of something that happened when I was working at Adobe around 2002. A coworker saw me using PaintShop Pro to sort through a few photos, and he said, "But... What? You work for Adobe!"

I explained, "I'd love to use Photoshop, but it fails to do the very first thing I need when I look at a batch of photos I shot in burst mode: flip back and forth between them to see which is best."

PSP let me flip between two photos instantly so I could see which I liked; Photoshop couldn't do that. Every time I used Ctrl+Tab to switch photos, it first drew a placeholder checkerboard across the entire screen, and then it slowly pulled in the new photo block by block.

Of course, there was probably some good technical reason for this: maybe some legacy Photoshop code designed for even older computers with little memory. But that didn't help me.

The funny thing about your (valid!) complaint is that browsers are perfectly capable of doing the right thing for you when you replace one image with another - an instant visual swap. But instead, people add scrolling and fading and other effects just to show off how "designy" their site is.

If you want a webby award, that’s what is needed.

Like iOS 12 very promising overall from the sound of it, and a genuine step forward from previous years in the fundamentals of speed and stability just as they promised to work towards. One continuing (though not new at all to the release) disappointment I have with Apple though:

>The end of OpenGL and OpenCL on the Mac

A solid summary of the situation, but to me where Apple really deserves blame there is not having MoltenGL and MoltenVK (and perhaps some theoretical MoltenCL too) as 1st party projects. I completely understand them wanting their own directly writable and controlled low level graphics language and having that be the interface layer. They are pretty vertically integrated and are now even doing their own GPUs, but even before that on the Mac they have long built the OS very strongly around GPU capabilities (for better and for worse, basic VM experience is very mediocre if you don't have a hardware GPU to passthrough). If anything I'm mildly surprised in retrospect Metal wasn't done earlier, OpenGL wasn't working for them and it's that big a deal. Microsoft invested in their own graphics layer for Windows ages earlier.

But controlling their own low level layer doesn't mean that higher level non-proprietary interfaces shouldn't still be supported on top. Part of the point should be to enable abstraction there. Apple is a big enough player and platform that this shouldn't be a zero-sum game, and their perfectly understandable strategic concerns addressed by Metal don't preclude OpenGL continuing to be officially supported as a layer on top of Metal. Apple could have even done it as another open source project of which they were the primary sponsor even if they wanted to manage it that way.

This may be just another symptom of their unusual startup-type culture which lets them hyperfocus on specific products but reduces their corporate ability to multitask, but it's still a shame. It could have been just about supporting newer and better stuff going forward, not taking something away. Even if MolenVK/MoltenGL ultimately fill some of that void I don't think that should have been relegated to 3rd party only.

I don't blame them for this. They want to get out of OpenGL because how much of a maintenance nightmare it has become due to non technical concerns. To ship top end OpenGL (and DirectX) drivers these days, it's more or less required that you write tons of code that recognizes the application that's calling your driver and fixes bugs in their code. Nvidia starting doing this, and now all end users see is that programs work on Nvidia and not AMD (or Apple as they write their own drivers), and blame everyone other than Nvidia. The switch to these new Mantle derived APIs is as much if not more about resetting those expectations of responsibilities than the technical benefits that these APIs provide (which AZDO 80/20 ruled most of the way to anyway).

Supporting a MoltenGL as a first class item defeats the whole purpose of moving away from OpenGL to begin with from their perspective. OpenCL never got the critical mass in their eyes, and someone else is already taking on MoltenVK.

Wait a sec... My gaming PC (2x AMD R9 290X, 8 GB video memory) is absolutely awful with a lot of (esp. Ubisoft) games like Assassins Creed or Watch_Dogs. I just assumed the games weren't optimized for AMD hardware. That is based partly off the Nvidia logos that are shown during startup and in the graphical settings menu.

There's also graphical issues at high resolutions. I've been planning on buying an Nvidia GPU so I can actually play games at a decent frame rate.

Are you telling me part (or all?) of the problem is bad drivers? I got the drivers from Windows Update rather than from AMD so they would just update themselves and be the correct ones.

Not bad drivers, bad game code.

Or AMD drivers that are not adding "do what I mean" hacks to work around bad game code? Sounds like AMD and Nvidia took different approaches to Postel's Law ("Be conservative in what you send, be liberal in what you accept").

IMO, there's a practical upper limit to how liberal you can be.

There are some games that straight up don't call endscene and present and crap like that in DirectX land. Or have bugs in their shaders, expecting the driver ISVs to just completely rewrite them by hand anyway. Nvidia can get away with this because they have something like 10x the engineering staff as AMD's on the GPU sides of their companies. Apple never had a hope of competing in this space at the same level.

If Nvidia is adding workarounds in their drivers for crappy game code, how did those games work before Nvidia added the workaround for their crappy code? :)

In my mind, the problem is bad code from developers like Ubisoft, and the willingness of Nvidia to expend tons of engineering effort to hack around them on a case by case basis. It's not really fair to call standards compliant drivers "bad" in my mind.

AMD pushed Vulkan (and Mantle previously) hard because it lets them break the cycle due to the layering concept in the driver stack. Intrinsic in how those drivers work is allowing end users to stick API verification layers in at load time. This will allow AMD to go to the press and say "see, it's not us, it's the application developer that wrote terrible code" without leaking any internal IP of those other shops.

That is one of the reason why I think Metal is the right way to go. I can't understand how we will be able to sustain the current development of GPU, when more than half of the cost are in software drivers development and cost % is constantly moving up. Another reason why the Desktop GPU market is so hard to break in, as have we seen times and times again, from 3Dfx with poor Direct X Drivers, S3, 3D Labs, Matrox, PowerVR etc. But I tried making this point with an Intel GPU engineers and he said my point is moot. May be he knows something I don't.

Due to the windows certification process, the drivers from windows update are always six months to a year out of date. Or at least that's how it used to be, I haven't checked in years.

It's always better to get graphics drivers from the chipmaker directly for both Nvidia and AMD cards.

I wouldn't be surprised if certified drivers have some of the more egregious hacks disabled too.

The fact that the drivers aren't special cased to compensate for Ubisoft's buggy code doesn't make the drivers bad. The games are bad.

Don't they need some kind of OpenGL support anyway, for WebGL? (Okay, that's OpenGL ES, but it's very similar.)

Why can't they continue to support OpenGL at least to the level required by WebGL? And if they want to switch out the backend to some kind of GL-to-Metal translation layer, so be it.

I don't care whether it's a native driver or a compatibility layer. If I do care, for performance reasons, I should be using Metal, sure.

Because once they open that can of worms they're on the hook for supporting it. Additionally, there isn't a good way out on the browser side, as Vulkan/DX12/Metal style APIs would pretty trivially allow JS code to escape whatever sandbox it's in. So the obvious answer is to keep their OpenGL implementation internal to Safari, and only support one of the new APIs (obvs Metal in this case) for native apps.

Why would the web need Vulkan-style APIs? It just needs WebGL (so far).

I still don’t see why that Safari implementation of OpenGL would have to stay internal.

> Why would the web need Vulkan-style APIs

For the record, there is an Apple-led initiative to bring a modern GPU interface standard to the browser:

https://webkit.org/blog/7380/next-generation-3d-graphics-on-...

I hope there’s no plan to drop WebGL. Although it wouldn’t surprise me. Really the only question is when -- years or decades?

They are all (Apple, Mozilla, Google, Microsoft) collaborating on the WebGLNext design, as Khronos decided to leave it up to W3C.

https://www.w3.org/community/gpu/

No, you can just implement WebGL on top of Metal/DirectX/Vulkan, but WebGL is a subset of OpenGL.

No, WebGL specification does not require the underlying implementation to be OpenGL ES.

Also the APIs do not map 1:1 to OpenGL ES anyway due to security constraints.

As someone who works on a game that is pretty popular I'm not sure I buy this.

I'm certainly not aware of nVidia doing anything special for our game, and honestly, they haven't really been super easy to get help from when we have attempted to ask them questions about problems that are nVidia specific that we run into.

Since we are not a big publisher, it's super difficult to maintain a relationship. We will get assigned someone to talk to, and next time we actually have a problem that person will have quit / moved to a different department / stopped caring about us.

Our game is in top 10 on steam right now, and is typically in the top 20 even during low periods, so I would have thought we would be somewhat higher up the priority list for specific attention if that was going to happen.

So all of that is to say, we pretty much have to deal with the problems ourselves, not rely on nVidia to fix them for us.

That being said, people complain about problems on AMD in our game all the time. So why is that?

Forget game specific optimisations, I think it's just that nVidia has just plain better drivers in general.

When we are developing new engine features, the difference is pretty clear. If you naively implement a shader, it often runs faster on nVidia initially. It's usually possible to persuade the AMD drivers to run things just as fast, but it's totally non-obvious how.

> Since we are not a big publisher

That's the thing. Ubisoft, EA, etc. get special treatment that happens before release. If you've released and it works without custom drivers, then obviously you don't need that special treatment.

Is the game Toxikk?

Per their profile page, most likely it's Path of Exile.

Sounds like Nvidia understood what Microsoft understood. An operating system is really only useful in that it allows you to run the software that you use. Because of this Microsoft went to extreme efforts to make sure when you upgraded your OS, your programs ran.

Nvidia understands that you gamers buy graphics cards to run games on them. They just want their game to run and look good on the graphics card. They don't really care about how bad the game developers are and want efforts Nvidia had to take to get the game to run. At the end of the day, games running good means happy customers.

”but to me where Apple really deserves blame there is not having MoltenGL and MoltenVK (and perhaps some theoretical MoltenCL too) as 1st party projects”

Yeah, they should have learned from OS/2 and that other graphics subsystem it supported for compatibility (sorry, forgot what it was called)

Foo on top of bar will always have incompatibilities and performance problems compared to foo on bare metal, but third parties will develop for it anyways if it gives them an easy path to a larger market, and the risk is that bar will become an implementation detail, rather than a competitive advantage.

Electron apps are a good recent example. I bet all major OS manufacturers would like to get rid of them, if it meant those applications ran on their OS and not on others.

Game consoles and Windows have done just fine with their own APIs, and OpenGL specific talks usually don't win time slots at Game Developers Conference sessions, outside Khronos parallel talks.

AAA studios are quite comfortable writing multi-plaform game engines since the 80's.

>ending support for 32 bit apps >deprecating openGL

My opinion on APIs have gone from new and bleeding edge to 'support it till the sun burns out'. Computers and meant to work. on linux or mac, no executable over 5 years old seems to work. But if download a .exe from the early 90's on a PC, it often just works.

In 100 years, the windows API and .exe are going to be the lingua franca of programs. there are many indications this is happening, valve baking WINE into steam, the fragmented package managers on linux, and no common runtime environment taking off.

Why would that be the case instead of programs following power/popularity like natural languages do? After all the lingua Franca of the world isn’t French anymore, despite its romance origins and therefore high “backwards compatibility” with Latin.

Curiously enough, “Lingua Franca” doesn’t refer to French.

Windows is a desktop OS, and the desktop is dying. In 100 years I’d say the chance of anything running Windows would be about the same as the likelihood of it running VMS.

Laptops and 2-1 are the new desktop, and the large majority runs Windows.

I love my MacBook Pro. Really, I do. And chances are, I'll probably use some iteration of a PC (in this case, I use an eGPU so I could replace my desktop entirely) until I, well, stop using hardware. I also use macOS and Windows on it.

That being said, I will eventually die. Now, the question becomes what are the people that follow after me going to be using. I have kids in school: both use Chromebooks for school work, in one case a PS4 for gaming, and hand-me-down iPhones/iPhone SEs for social, gaming, and the like. Could they eventually need a PC? Possibly, depending on their career path/interests and the level of support for iPads, Chromebooks, etc. at the time. But they don't need it now. And I know people who are my age and older who limit themselves to iPhones/iPads for technology beyond the TV. None of these things are running Windows.

Chromebooks are an US school phenomenon, hardly spotted anywhere else.

I can only speak for the US market I guess, but they haven't found a real need for a PC/Mac outside of what a Chromebook can do, so at the end of the day, I don't feel it bodes well for PC/Mac long term.

I'm a developer at work for internal applications (and some external). All of my non-server running things are web applications. They could be accessed by Chromebooks instead of the hp Windows 7 laptops we use now. I doubt we'd switch off PCs due to familiarity at the very least, but we don't need them.

Even including laptops, sales are declining.

https://www.statista.com/statistics/272595/global-shipments-...

Of course they are declining, nowadays I can keep a laptop for 10 years and still be productive as on the day I bought it.

The day of replacing a PC tower every 3 years are gone.

The sales of smartphones on the countries where pre-pay is the way to go are also declining.

In 100 years, the chance of anything running any contemporary software is zero (outside of museums). Except, maybe, for some old piece of Cobol on a banking mainframe.

and lisp code, don't forget that decades old lisp code (sometimes) runs with no changes on current lisp implementations.

Dark mode is really refreshing for the eyes.

Tab completion now shows dot files as well; ".DS_Store" is there everywhere. I wonder if they have a plan to do away with the .DS_Store anytime soon.

I've never owned an Apple anything and yet I swear I still find .DS_Store files on my Windows/Linux machines from time to time.

Assuming you deal with software, I'd guess that's because someone has committed them to a repo. It's one of the reasons Mac-based devs should always have a global .gitignore file.

Maybe a shared directory someone has browsed from their macOS box?

I see them on my CentOS servers.

But then I also see tons of Thumbs.db

I miss Asepsis. It was a daemon/dynamic library that would redirect the .DS_Store file location. Unfortunately, it can't run on modern Macs due to System Integrity Protection.

Dark mode is darker than what I had expected. Only the focussed window looks good. Background windows are black.

Question for anyone who knows: is there a reason .DS_Store files cannot instead be stored as xattrs on the directory inode they’re “for”?

In the old days, that's exactly what Apple did with HFS. The issue there is that other filesystems, and notably remote filesystems such as one might access with FTP or NFS or whatnot, did not support that. For portability across filesystems, Apple started using .DS_Store files.

> But Core Storage, the technology responsible for keeping the most frequently accessed files on the SSD, can only see data on your drive at the block level, not the file level. It can’t tell the difference between an app that needs to be launched quickly or a document that doesn’t need a lot of extra speed; all it can see is how frequently blocks are accessed. APFS changes that. Fusion Drives can now move files to the SSD based not just on how frequently they’re accessed, but also based on how much the type of file will benefit from an SSD. APFS will store all file metadata on your SSD, too, speeding up Spotlight searches and metadata lookups in the Get Info window.

Can someone more knowledgeable than me explain how in the world this is an improvement? The old Core Storage model perfectly makes sense to me: it strictly operates beneath the level of a file system, combining multiple physical volumes into a logical volume family which contains a logical volume. It moves blocks between SSD and HDD using frequency of access. Now, why should we suddenly need to look at the type of file to determine which block device to store the data? Even if it's an application, but if it's not frequently used, why should we keep it on SSD?

And filesystem metadata should be even more obvious. Since basically all file operations need the directory entries and the inode information, the old Core Storage-based system will automatically move them to the SSD. Why do we need to explicitly tell the filesystem to do this?

Overall this feels like a step backward to me. I like systems that are dynamic and self-adjusting, not those with hard-coded rules and heuristics.

Also I'm a bit disappointed as the author, while producing a fine review to read, didn't quite do the deep-dive I had expected for a system that's arguably the most important in an OS—a system in charge of storing user data.

Just in general, when optimizing for different latency use cases, looking at averages falls flat in a lot of cases. For instance you probably want fast startup, but how often does the startup code get executed?

>Now, why should we suddenly need to look at the type of file to determine which block device to store the data?

We don't "need" to, it's an extra optimization.

>Even if it's an application, but if it's not frequently used, why should we keep it on SSD?

Because if we have the space to spare on the SSD, we'd appreciate the faster launch when we do try to use that app. And for other types of files it can now decide to move them or not move them based on the benefit from the faster load, not just the frequency of access (and thus optimize the SSD use).

Maybe because performance analysis showed that it was better to do it the new way.

> Let’s talk Gatekeeper first. In High Sierra, Gatekeeper controls access to Location Services, Contacts, Calendars, Reminders, and Photos—any app that wants access to any of that data needs to ask for it and be granted permission first, and the app should fail over gracefully (i.e. not crash) when that permission is denied.

This is just wrong. Gatekeeper is not the iOS-like privacy controls. It's about enforcing apps to be from the MAS or identified developers. https://support.apple.com/en-us/HT202491

Technically, Andrew's still in the clear as Gatekeeper is a system facility for controlling what can be installed and run on your machine. Permissions for access to system services and app databases is the only thing that's changed.

TCC, which manages this access, is not a public-facing feature. Hence the reuse of GateKeeper.

Is the reworked App Store faster? I always wonder how they could make it so slow without any feedback while it navigates between pages.

Subjectively, yes, I think it is.

It's faster, but still incredulously slow. For example, when you launch it it's just a black rectangle for 3-5 seconds (2018 Macbook Pro). And the UX is all over the place, with 3-4 different ways to go back/close whatever you're looking at. The way you navigate reviews with side-swipes might sense on a phone but makes no sense whatsoever on the Mac.

You can tell it's made to spec and with zero developer love softening the rough corners, because no developer who cares would make a full-screen screenshot view mode you cannot exit with Esc.

>The way you navigate reviews with side-swipes might sense on a phone but makes no sense whatsoever on the Mac.

it makes complete sense, I switched over to mac in 2017 and as I got used to the gestures I tried them everywhere. if i'd found one place where they didn't work I would have abandoned them. the side swipes also work in Netflix on chrome on Mac. I really LOVE this aspect of the mac. gestures are functionally useless on windows coz of the uber patchy support for them....

Looking at the recent news about Marzipan, I'm fairly certain the App Store we got is actually the iOS App Store. There's so many iOS design motif quirks.

The pop-up permission boxes don’t make a great first impression since I saw at least 5 of them within 2 minutes and they tended to have really obscure descriptions like access to “System Events”.

While probably technically much more difficult, maybe they could have the first Mojave launch of every app occur in a separate and invisible “everything allowed” area, where the system just pretends to allow things and tracks everything that the app did on launch that would require permission. And then, it can display one box with a summary of features that seem to be required for that app, relaunching the app in the real system sandbox if approved.

How would the system simulate user interaction required to get to a point where the popup would be necessary?

An application could access the protected APIs it needs during a first run in order to force the authorization dialogs. If I were designing an API for that, I'd allow a single call to declare as many permissions as needed, so all authorization dialogs would be triggered at once.

But then you just have a model where an app asks for a dozen permissions upfront, which may not even make sense in context. For example, should your bank's app (assuming it had one) get camera access? On the surface this seems a bit strange, until you realize that it has check scanning functionality.

You could pop up a box that says "Bank of America is asking for access to the following parts of your Mac:"

Followed by a table with the function (I.e Camera, mic), a description from the developer about why, and a checkbox to accept or deny.

You are more likely to understand the reason an app wants a permission if it is requested the moment it tries to use it.

The behavior you describe is the old Android take it or leave it approach. It doesn’t work because then all apps refuse to work if they don’t get ridiculous permissions.

iOS has permission explanations. I imagine this should probably carry over to macOS.

It does. The issue is that even with a permission explanation, it can be hard to see what the reason for a certain permission is if it’s asked out of context.

On iOS users have selectable permissions control; I could allow an app to access my location but not the camera or microphone, and the apps are expected to even work with no permissions granted.

That all depends on context, if an app asks for all the permissions on first run, the user doesn't have any context to help him/her deny access.

I suppose this would be less of an issue if the first launch didn't try to open every single app/service that was running before the reboot all at the same time.

This is frustrating behaviour in general when you have a bunch of apps open at work. Slack will repeatedly attempt to steal focus on launch as it displays a splash screen and then the real app (a chat client requires a splash screen now!?), most apps using Sparkle for auto-updating will throw more prompts at you as new versions roll in, a different updater from Microsoft or Adobe will boot up to check on those installs...meanwhile all of them are trying to resize to full screen or appearing in some next-best position, because they're all competing for the foreground.

You can't do shit until you're sure the computer's settled down. And that's before you get the extra permission prompts.

What are the pros and cons of upgrading to Mojave for a hacker using a Mid-2013 MacBook Air?

Is that true that Mojave looks ugly on non-retina displays, won't allow your scripts to access some stuff previous versions allowed, integrates with Apple's internet services and DRMs more tightly and can have problems with playing old Windows games like Fallout 3 with Wine?

You can preview "ugly" by turning off "Use LCD font smoothing where available" and restarting any app to check it out. It's subjective, lots of folks complained about subpixel being ugly when it was first introduced.

The Apple iCloud stuff is still optional. A "hacker" should have no trouble with the Terminal commands necessary to disable SIP.

Dunno about Fallout but Boot Camp and VMWare are still around.

Thanks.

> Boot Camp and VMWare are still around

At least it's too space-consuming to maintain a separate Windows system on a 128 GiB SSD, Wine/CrossOver feels a better solution in the cases where it can manage.

Better yet, use SteamPlay

https://github.com/ValveSoftware/Proton/

The ugly font issue for non-retina displays is real, luckily there's a workaround to revert it how it used to be:

defaults -currentHost write -globalDomain AppleFontSmoothing -int 3

defaults write -g CGFontRenderingFontSmoothingDisabled -bool false

I've installed mojave on that same computer model and the font smoothing switch is there, and the pixels look the same as before, which is great. Nothing has changed.

Maybe they only removed the switch on retina macs.

Direct download link: https://itunes.apple.com/us/app/macos-mojave/id1398502828?mt...

2FA with SMS was a standout weird choice from Apple. I hope they discourage that quickly with a better alternative.

Yeah, maybe it's just a bow to practicality but if anything mildly surprised regardless because they've gotten quite serious about their own HSM implementation which is slowly starting to spread to more and more new Macs, and it's effectively universal under iOS. I sort of expected given initial thrusts like Apple Pay that they'd push hardware token usage way harder, with either direct support for Macs with T-series chips already or else some tie-in to iDevices. Ideally NitroStick/Yubikey/etc would come along for the ride and Apple would work towards a framework that could be used with other HSMs beyond their own, but at this point I'd take any major platform trying to move crypto auth forward over passwords/sms/anything else at all.

I think your first instinct is correct, here. While they probably would feel safer if everybody was using Google Auth, Authy, or a physical device, it gets around people having to explicitly copy tokens around which, IIRC has been abused a fair bit in order to steal credentials.

They do 2FA for iCloud sign-in through an vanilla iOS prompt, not SMS afaik.

Still using El Capitan on my iMac. Should I upgrade directly to Mojave, or wait a bit?

Also still using El Capitan, and wondering the same.

The rule has always been to wait for the first point update.

Same boat. I'm still on Sierra and still have concerns as a colleague on High Sierra almost hosed his system with APFS. Any stability issues on the new file system?

It's been mostly fine on High Sierra, but I did have one instance where my inodes went wonky. Had to restore from backups as Disk Utility couldn't do anything with it.

HFS+ was terrible, but at least I knew most of the ways in which it was terrible.

People bitch and moan about HFS+ but I've never found anything particularly objectionable about it, even after writing several filesystem utilities on top of it.

I've always found Spotlight to be utter garbage, but that's not the fault of HFS+.

OK, so you're not just spewing nonsense, but it bears repeating that the internals of HFS+ were horribly dated towards the end of its life. This prevented them from adding features or fixing bugs in a way that would be forward looking.

The system requirements for HFS and HFS+ reflected this and partially explain why there was little progress for literally years at a time.

https://arstechnica.com/gadgets/2011/07/mac-os-x-10-7/12/#hf...

Eventually, you have to start over.

Fair enough; thanks for educating me.

Wait a bit more and you can buy a new iMac directly!

Wait.

I'm on High Sierra, but still waiting as I have huge issues with deprecating the old Safari Extensions API. I really don't want everything to be an app, and the uninstall procedure on the Mac has always felt weird - coming from Windows - so I'm thinking about how I could run Safari with no extensions and instead use equivalents in Chrome to compensate.

> don't want everything to be an app, and the uninstall procedure on the Mac has always felt weird

Drag the app to the trash?

You really have to run something like AppCleaner because just about every vendor throws files around in /Library and ~/Library, which aren't deleted with the bundle being put in the trash.

This is no different from any other OS

Does that actually matter in practice? I don't remember the last time those files actually caused problems, other than the fact that they take non-zero disk space.

The same behavior may be present on Windows for all I know. I've used Win7 a handful of times and Win 10 once or twice, so I don't have a good handle on how the Registry deals with uninstalls these days.

My complaints re disk space are mostly still around because SSD prices are still not cheap compared to spinning disks. For example, I went from 80 GB (2005 Dell Latitude) to 120 GB (2007 MBP) to 256 GB (2013 MBP). Desktop drives at the time were probably triple to quadruple the storage at half the price, so it's still an issue.

To migrate everything to an SSD in my next machine will take somewhere between 1-2 TB, and last I checked, the 1 TB option on a MacBook Pro was $600.

True. But it can be a non-trivial amount of space, and (especially on SSD) that can matter.

The first review I see for AppCleaner on the MAS right now is from a very happy user who just reclaimed 19 GB on their MacBook Air after a first run on a 4 year old machine.

For that user, hard not to disagree that that matters.

Also: 7 GB was from AirMail not deleting its 'junk'. If that junk was in fact its internal cache of emails then that user has thought that those emails had gone with the app, while in fact they were still carrying them around. Now that could be a very big deal. (Unfair to assume, but a reasonable scenario).

When Apple bought Test Flight, I can remember hearing the ATP guys talk about it and come to the conclusion that Apple probably hates when a 3rd party service exists to cover some corner case that they don't do themselves.

The fact that the Installers don't do well with this kind of situation is probably an indication they should survey the landscape and buy one of them so it can be integrated.

It’s really a shame; Apple has produced a number of tools (XCode.appp, Server.app, Install macOS.app) that demonstrate how you’re supposed to handle the placement of support files like this. Delete any of those apps, and their entire footprint on the system is gone.

There’s also things like Garage Band’s downloaded instrument files, which do stick around... but only because other apps (e.g. Logic) can also use them.

Are you on an SSD? APFS is more efficient than HFS+, and I expect eventually some core apps you use will require an update (though this is dumb). I can't use Davinci Resolve on my '07 Mac Pro anymore because it requires 10.12.

This is a very good review, but it still makes me miss the ones John Siracusa wrote.

He was(is!) a great writer, programmer, and colleague (separately, of course). Hope he's up to something fun!

If you're into podcasting, give ATP[1] a shot: John is one of the three hosts. The other hosts are Casey Liss and Marco Arment (developer of Overcast).

John also has some other podcasts like Robot or Not[2] and Reconcilable Differences[3], but ATP is by far my personal favorite.

[1] http://atp.fm/ [2] https://www.theincomparable.com/robot/ [3] https://www.relay.fm/rd

Does it fix the hard crash/freeze issues around hibernation and FileVault? That's pretty much all I care about; I _really do not like_ having to choose between running a laptop without FDE and having to spend ten minutes going from zero to usable every time I stick the stupid thing in my backpack for more than fifteen minutes.

I run with full disk encryption and have never had this issue. I've never heard of this issue either.

So, it just happens when your laptop goes into hibernation with FileVault enabled?

Yeah. Two laptops, actually, one whose FileVault activation preceded the upgrade, one whose did not. Doesn’t matter which hibernation mode I use, 3 or 25 - either way, it reliably fails to either sleep or awaken cleanly; not sure which, but the wake is a cold boot with no state restoration.

I had something similar, and IIRC it was fixed by reformatting the drive. Tedious, but Time Machine helps.

> I wish the easy-to-use app icon wasn’t tucked away in the Utilities folder, but it does do a considerably better job of exposing screenshot and screen recording options that have been a part of the Mac for years.

Command+Shift+5?

> The way the Kids These Days are customizing their email is with emoji

Kids These Days don't use email. Or at least, often, that is.

The screenshot annotation UI is an abomination. It’s some weird mish-mash of buttons that feels like a word processor instead of a really simple tool that’s just an arrow + text with a white outline (like Skitch). I really hope this gets fixed.

Anyone else find dark mode stark? It was a bit shocking to see it and very jarring after almost 2 decades of looking at various shades of sliver/gray menubar and dock.

I now kind of miss the ability to have only dock, menubar, notifications side bar, spotlight and HUD for brightness, volume be black.

This mode offered a great balance between classic window chrome and the too much brightness you now get in "light" appearance mode.

I find I can't work in dark mode during daytime. Way too many reflections and reading mail and PDFs in preview are too jarring. Black, beside white makes each other stand out so much.

I think macOS is now least polished it has ever been.

Is this the new El Capitan, which was the new Snow Leopard?

It’s very stable, if that’s what you’re asking.

Is it possible to upgrade without upgrading the boot filesystem to APFS? I have a Fusion Drive, and don't have high confidence Apple got this right.

Probably not. I wouldn't be too concerned, I've heard that the file system engineering team at Apple is extremely good. For example, they pulled off the conversion from HFS to APFS in iOS without a hitch.

> don't have high confidence Apple got this right

I'd love to know why. The transition to APFS for all other devices has been utterly seamless. Apple probably has a whole filesystem team. I wonder if you have any special qualifications to justify why you think you know better?

>for all other devices

Yes, the solid state storage for which it is designed. The Fusion Drive by definition includes rotating media and compounds this problem by involving 2 devices in a common logical storage device.

The APFS support for Fusion Drives was pulled from High Sierra for reasons that were never explained so there were apparently issues, and without knowing what those were it is impossible to evaluate how likely it is that these were all resolved now.

They could have pulled it from Mojave too if they felt there were still issues.

Well, took a backup and decided to go for it. You don't get a choice, it converts the boot filesystem to APFS. Took about 3 hours on a very full 1.5 TB Fusion Drive, but converted successfully. We'll see how it goes.

If you use AppleScript to automate your finder, then I would wait a bit until you have a really good idea how much work it is going to be to change things to meet the new security changes. It is a non-trivial operation. Also, I should probably give up any hope of Apple fixing any scripting errors in the Finder since its still broken since Mavericks.

On my MBP 2012 on every boot up the screen will flicker and I guess this is just old age and normal? I guess this is the last update on 2012 model.

Also noticed the resolution is a little bit brighter and nicer for an old MBP.

Having an older Mac Pro, I saw that it Mojave will do a firmware upgrade. I won't be using MacOs, but will be running the installer for that. Thank you Apple!

How's battery life on Mojave? My 2014 MBPro is still on El Capitan and doing well, so not sure I'd upgrade if there's a battery hit.

I haven’t noticed any with the betas, nor seen anyone talking about it, but my battery isn’t especially happy anyway on my 2012 Macbook Air so I’m used to not expecting much.

I'm surprised that MacOS 10.14 release came almost unnoticed on HN.

Does APFS still run like dog feces on a spinning platter drive in 10.13?

I have a bunch of older iMacs I have stuck at 10.12 for this reason.

There's no reason to stay on 10.12 to avoid APFS. I tried a fresh install of 10.13 with APFS on a hard drive. I wasn't happy at all with the performance especially at boot (for some reason). So I started over and went with HFS+.

I have no idea if APFS on Mojave behaves better but if it doesn't force the file system upgrade (didn't check this yet) I see no reason to avoid Mojave. APFS would make a lot more sense on an SSD but even with 0 improvement (excluding visible performance drops here) at storage level the other features alone should make the upgrade worth it.

Reply on news.ycombinator.com