Papercuts like this are why I moved away from macOS.

I will say, I don't love the use of LLMs to write these bug reports. It's probably fine if reviewed, but at least review for things like "worked on macOS 25", which obviously didn't exist. If that wasn't caught, how sure are you that the rest of the report is accurate? We all want the bugs fixed, but people are going to start throwing out the obviously LLM written reports rather than have to validate each claim, since the author probably didn't.

macOS 26 has to be the most breaking version so far, its problems and intended breaking changes making my app dev life so hard this year. Just to name a few:

- Reference Presets no longer allow setting arbitrary SDR nits, making it impossible to natively unlock 1600nits of brightness on MacBook Pros or 2000nits on Studio Display XDR which breaks my Lunar app [0] (this seems to be intended, no idea what hurt Apple that they had to block this under SIP)

- The orange microphone dot indicator and its very colored friends can no longer have their brightness changed for dimming them, which made my YellowDot app useless [1] (I guess this is for privacy, I still think this could have a setting guarded under TouchID like Accessibility Permissions works)

- Floating non-titled windows don't accept mouse events (thankfully this got fixed) [2]

- Gamma table changes don't work on MacBook Neo and M5 Pro/Max which breaks Sub-zero Dimming and dimming external monitors that don't support DDC (thankfully, Apple is looking into it) [3]

- The resizing area thing on very rounded windows which drives everyone nuts, I had to add custom resize handlers to some of my windows

- The `com.apple.SwiftUI.Drag-` temporary file paths that get generated for any file that gets dragged from a drag&drop handler which makes it impossible to get to the original file when dragging images from Clop [4] or file shelf apps like Yoink, Dropover etc.

- NSImage returning different pixel count for .size than what the image actually has, breaking workflows that depended on that to determine the image DPI

[0] https://lunar.fyi/#xdr

[1] https://github.com/FuzzyIdeas/YellowDot/issues/18

[2] https://developer.apple.com/forums//thread/814798

[3] https://developer.apple.com/forums/thread/819331

[4] https://lowtechguys.com/clop

Still wishing for the day apple is split into the hardware and the software company. I want their silicon, but I will never use their (arguably terrible) operating system. If I can't run my own kernel and kernel modules then it's a device that I don't own. Firmware is alright in some cases, but my laptop next to me is running core boot just to prove a point.

It's not quite the same, but I've moved to using *.localhost for all my local web dev work. All modern browsers will resolve *.localhost to 127.0.0.1 internally. No need to setup any DNS resolvers or edit your hosts file.

But that only really helps you when you're dealing with websites in a browser, and when you want the address to resolve back to your local machine. So it wont help you with other programs like python/wget/etc or any calls you make to getaddrinfo()

I run a setup like that on my (outdated) Yosemite machine to provide multiple private TLDs for local deployment/development needs.

I set that up in like 2014? Even back then it was known already that the quick /etc/resolver way was the deprecated way to do things. So I guess they finally killed that feature off?

The proper (more awkward) way is to use scutil directly (which then stores the settings in some binary plist somewhere, I assume).

Maybe try this and see if it still works afterwards?

Interesting - I run a nearly identical set, with many TLDs configured in `/etc/resolver/X` and dnsmasq handling the resolve and I have not had a single issue.

the resolver confs all contain this content:

    # /etc/resolver/example-private
    nameserver: 127.0.0.1
    domain example-private

I noticed in the author's bug report they do not include `domain`, which is documented in `man 5 resolver` as:

    # The domain directive is only necessary, if your local
    # router advertises something like localdomain and you have
    # set up your hostnames via an external domain.

In the real world though, I've found the `domain` setting to be required nearly every time. I wonder if adding it will resolve the issue?

Bit off-topic. I mostly use Linux and I'm of the opinion that it's miles better than Windows, but I don't fully understand why people say MacOS looks bad?

Ignoring the current Tahoe mess, MacOS felt relatively polished. I'm purely talking about UX here, as the OS is evidently buggy. The most popular Gnome themes are a re-impl of MacOS, so I can't be the only one.

A couple iOS versions ago, Apple broke self-signed certificates... crippling mobile development by preventing the use of HTTPS to communicate with a local server.

It makes you wonder why they were messing around in these areas at all at this point.

I don't know , I like macOS, mainly that zsh is readily available and I can (almost) do anything I can do on a linux box in a personal computer.

*.localhost works out of the box doesn’t it? You don’t need dnsmasq at all to have multiple hostnames pointing to 127.0.0.1.

I've been using macOS since OS X Tiger and I wasn't aware of this feature.

I am not familiar with dnsmasq at all (is this machine-local?), but absolutely love my PiHole hardware — you can even create rules which intercept hard-coded-IP DNS request and/or httpsDNS. You can also hard-code/intercept .TLD to local service IPs.

Programs like LittleSnitch never really seem like "enough" for me, because the computer has to boot before DNS filtering comes online. It also has the design error (IMHO) of pre-resolving IP addresses before clicking Accept/Deny(all).

A great blockrule for your personal firewalls would be to ban (at top level) icloud.com, apple.com, &c; system updates can then be performed manually using guides like <http://www.mrmacintosh.com>. Of course: this breaks everything (in exactly the way I prefer to compute).

I used to use dnsmasq and etc/resolvers for stuff like dot dev or dit whatever back in the day.

These days I’m just using Caddy to do ..localhost for my web dev and it works like a charm.

This is exceptionally sloppy on Apple’s part.

Has anyone found a working workaround yet? I use dnsmasq for .local dev routing and held off updating after seeing this but curious if there is a viable path forward short of waiting for Apple to patch it.

> The only reliable workaround is to add entries manually to /etc/hosts, which bypasses mDNSResponder entirely. This is impractical for dynamic use cases (e.g. Docker container DNS, where host entries change frequently) and requires sudo for every change.

I suppose I'm lazy - I've always used /etc/hosts, but then again, I've never had use cases like those mentioned in the linked gist.

FYI the phrase is "lo and behold"

Thank you for the heads up.

I had to abandon Apple MacOS container because it has so many issues with networking and DNS. I'm looking forward to try it again if they can get it fixed.

https://github.com/apple/container/issues?q=is%3Aissue%20sta...

I never knew about this feature but it's so cool and I wish I knew it earlier. Sadly it seems features like these are being left to rot in MacOS because it's not what the average normie uses.

Seems bad that people feel forced to use GitHub to talk about Apple's bugs.

I'm glad to find out it's not just me! My homelab has a lot of domains on .home.arpa, and I was getting issues related to this.

Another funny thing about Mac networking.

There's a game I play (Old School Runescape) that does network ticks every .6s. Mac does some sort of aggressive optimization on the network hardware/software, so network this infrequent doesn't keep the layers "hot", and you end up getting delayed ticks regularly, meaning you learn what should be happening in the game .2-.5s late. This optimization for (I assume) battery life makes the software not work as intended.

Playing anything that streams, like video, or triggering TCP connections (e.g. curl) at a more frequent clip while the game is running fixes the problem.

No way other than hacks that I've found to fix it, and I have no idea how you could report this to the right team at Apple to get it actually fixed.

If Asahi had the same battery life and performance as MacOS there is zero chance I would be running MacOS.

Afaik ".internal" isn't reserved/defined anywhere, it's just a convention some people/devices use, and doesn't have anything to do with the root cause here (a custom resolve.conf or whatever it is called in macos changing after an update), no?

> https://feedbackassistant.apple.com/feedback/22280434 (that seems to need a login?).

All Feedbacks that you file are private to your own Apple Account.

Lo and behold, just FYI. Trying to help.

I still want to believe macOS 26 was vibe coded with Apple Intelligence and siri. Makes it easier to digest daily use

> none of my dockers

Containers ran using docker are called containers, not dockers.

Apple container CLI configures internal domains (`container system dns`) by adding an internal resolver and it worked for me when I specified an actual domain previously handled by external DNS and it showed up as a custom resolver.

Here’s a GitHub comment showing someone on MacOS 26 with a `.test` domain, which you claim is broken: https://github.com/apple/container/issues/856#issuecomment-3... —- maybe you are configuring it incorrectly.

Solved this type of shenanigans some years ago with this.

New-UnboundInterface.sh - linux/rhel-like specific

    # create a bridge interface for Unbound
    # because Docker...
    IFTYPE=bridge
    IFNAME=unbound0
    IPADDR=10.53.0.1
    IPADDR6=fd53:fd53:fd53::1
    nmcli connection add type $IFTYPE ifname $IFNAME
    nmcli connection modify $IFTYPE-$IFNAME ip4 $IPADDR/32
    nmcli connection modify $IFTYPE-$IFNAME ipv4.dns $IPADDR
    nmcli connection modify $IFTYPE-$IFNAME ip6 $IPADDR6/64
    nmcli connection modify $IFTYPE-$IFNAME ipv6.dns $IPADDR6
    nmcli connection up $IFTYPE-$IFNAME

    firewall-cmd --new-zone=unbound --permanent
    firewall-cmd --zone=unbound --permanent --change-interface=$IFNAME
    firewall-cmd --zone=unbound --permanent --add-service=dns
    firewall-cmd --reload

00-localinterface.conf

    # should be placed in /etc/unbound/conf.d
    # bind to a specified IP address, allow access
    server:
            interface: 10.53.0.1
            interface: fd53:fd53:fd53::1
            access-control: 10.53.0.1/32 allow
            access-control: fd53:fd53:fd53::1/128 allow

91-allow-docker-containers.conf

    # allow queries from the Docker "bridge"
    server:
            access-control: 172.18.0.1/16 allow

Again? This happened like 6 or 7 years ago. I had so many issues with macOS in the few years I was forced to use a MacBook that I refused to use it. Not surprised to see this stuff still happening.

> Ah, the joys of waking up to find the Mac's done an overnight upgrade

Wait, it does that (from 15 to 26) without user interaction?

Before others jump in: I already use Linux (and used to run FreeBSD as my desktop operating system).

It also seemingly broke removing Safari cookies on a per website basis, something I often used to stop Google's scummy tracking across all their services if you just want to sign into YouTube.

[flagged]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

[dead]

Ah great another reason to add to the many reasons not to use this OS. Semi serious question, is Apple looking to dump its existing customer base for a new, perhaps consumer not pro-sumer one?

Honest question: How would this affect me and the vast majority of macOS users who use the device for media consumption and productivity applications?

Next question: what reason would Apple have to make a change that would interfere with developers using their operating system?

If you have ScreenTime turned on. Port :8080 is occupied and your ubuntu apt-get in a docker build gets hash mismatch because they obviously modified packets. Let alone I am having another issue of unable to delete a private key in Keychain Access.

The whole macOS thing is amateur