Wait, so.. how are we supposed to test Intel builds of our macOS apps from now on?
I get it that macOS has to evolve, but that doesn't mean all apps have to drop Intel support at the same time.
On hardware-level apps like my Lunar app I have plenty #if arch(arm64) because some features like reading the brightness nits or reading ambient light is different or completely missing based on the architecture. I need to test the UI differences based on what features are available.
I don't see it viable to stay on macOS 26 for this, especially if we're going to see breaking changes again with the display and window server subsystem like we did with Tahoe. M5 support for Gamma table changes is still broken after so many months [0]
> Wait, so.. how are we supposed to test Intel builds of our macOS apps from now on?
You don't. You could stay on an old MacOS. Apple would prefer that you tell your customers to stop being poor and buy a new computer. They will make your situation increasingly unbearable until you do.
The overwhelming majority of people haven't needed a new computer since 2016. The current economic situation makes a new computer a worse value proposition than it's been in 35 years. Vendors are responding to this situation by manufacturing obsolescence. Microsoft pulled the same stunt with Windows 11's TPM 2.0 requirement.
I think it's a stretch to call Apple's ARM transition "planned obsolescence". The M-series chips are very clear improvements on what came before and there is a clear rationale for that transition.
We're talking here about an OS that hasn't even come out yet, that will get years of security support, for computers that Apple hasn't been selling for several years now. Seems pretty reasonable.
I said "manufactured," not "planned." I don't think Apple intended to do this at the outset. Tim Cook wasn't leaned back in an office chair, twirling a moustache saying "yes, let's make every mac made before 2019 SUCK!"
If it was planned, Rosetta 2 would have never existed in the first place. It would have been a qemu fork haphazardly crammed into Xcode.
There was no "planning" here. Here's how I imagine it went: a developer whined about tech debt, management seized an opportunity to generate revenue, neither party considered, yknow, humans, and now we're here.
The average user cares about their fans going full-blast when running some garbage electron app and their battery life being shit. You're just being dense.
Back when these machines were released they were hallowed as being the ultimate in mobile computing. What happened here what did not happen to other Intel-based machines from that era?
For developers, the difference is like night and day.
My 2019 MacBook Pro used to sound like a jet plane taking off whenever I did any sort of build. On a bad day, I could've baked some cookies on it. Admittedly, the corporate spyware that was constantly scanning every single file didn't help matters.
Eerily similar story here. My wife was using her 2017 MBP (the one they got sued over) and she adored it until Tahoe suddenly caused Chrome to run like hot garbage. I bought her an open-box M3 Air. She likes the color. It doesn't provide any more value to her life than her 2017 MBP did, and yet we're out $1000 because Apple said so.
So on the one hand you are so much aware of the obsolescence issue and on the other hand you just decided that upgrading a 2017 MBP to Tahoe is a good idea? I am on a M4 Pro Mac mini and it is still running Sequoia.
> Apple would prefer that you tell your customers to stop being poor and buy a new computer.
This is certainly an interesting way to characterize dropping support for old hardware. What is a reasonable way to go about hardware deprecation in your view?
When a company obsoletes a hardware platform, as Apple will do with this update, it is their moral duty to open the platform. Release the necessary source code, blobs, and docs to allow independent actors maintain their equipment, or maintain that equipment on behalf of its owner.
Apple won't. We all know that. The Broadcom wi-fi chips and the subtle differences in their embedded architecture vs. conventional PCs means x86 Macs will never be adequately supported without Apple's stewardship.
I think one thing that rubs people the wrong way is that Apple has basically infinite money at this point. They're not dropping support for old hardware because they don't have the resources to maintain the support. They're just doing it because they want to, and that's kinda lame.
Especially when I can keep getting both feature and security updates for Windows on hardware that's the same age (or older) as the EOL Apple hardware.
This isn't even just an Apple attitude. The whole macOS and iOS software ecosystem has this "nothing before the prior two OS releases exists anymore" attitude, and it is absolutely infuriating. It is absolutely possible and not a huge lift to support prior operating systems, but Mac developers just don't tend to care or do it.
The reasonable way to go about hardware deprecation is to not do it until that hardware is Truly Gone™, buy some actual definition of Gone that isn't an arbitrary number of years or versions.
That's overly dramatic. I don't think a new Macbook Air today is a worse value proposition than some Mac from 35 years ago. I just checked Apple prices from 1991:
- Mac Classic II, the slowest of the bunch, $1.900, or about $4.661 today
- Quadra 900, the fastest model in 1991, was $7.200 ($17.663 today)
- PowerBook 170 was $4600 ($11.285)
"Value" and "price" aren't the same thing. A new computer in 1991 cost more, but it also covered a vastly increased set of use cases versus a machine from 5 years prior (assuming the hypothetical 1991 computer buyer had even owned a computer before). Today, you can buy a used MBP with an M1 and it will do everything a new MBP can do, and the differences compared to a new machine will be imperceptible to most users.
Plenty of people would even be perfectly happy on an x86 Mac, too. Sure, there would be a perceptible difference compared to a new machine, but not enough to justify the price. That's what obsoleting Rosetta is about, it's about artifically making x86 Macs so unbearable that would-be happy users have no choice but to buy something else.
Continue to upgrade to the latest macOS on your host system, use something that leverages Apple's Virtualized.framework to run any version of macOS you want.
Oh hey! Thanks for making this. I've been running this app for a while now, between one and two years. Very much something that I rely on and appreciate.
You are trying to emulate x86 to test those builds.
Rosetta doesn't emulate x86 hardware, but translates x86 instructions into ARM. The only thing your solution would get you is verification that the Intel build can work on Apple Silicon with Rosetta.
If testing on an Intel Mac is unacceptable, and testing on an ARM Mac using Rosetta is also unacceptable, then there was no reason to complain about Rosetta being deprecated in the first place.
IIRC Apple supported 10.5 extra long because of it being the last PowerPC MacOS. I wouldn't be surprised if they do something similar here. Keep an intel mac around, and you should be fine
Arguably if you're shipping new fat binary code today, you should already have an Intel Mac around to test, because there might be subtle differences between Intel-on-Rosetta2 and Intel-on-Intel.
When the bad guys are too impatient to wait until you leave the computer but not fast enough to stop you before 30 degrees while keeping the convenience of life.
Not sure if it's exactly the same, but I had to add a When notification arrives with <message>, do <action> event trigger in my Crank macOS app (https://lowtechguys.com/crank) so I can show you how to do it on macOS:
HOURS=6
EPOCH_DIFF=978307200
SINCE=$(echo "$(date +%s) - $EPOCH_DIFF - $HOURS * 3600" | bc)
sqlite3 ~/Library/Group\ Containers/group.com.apple.usernoted/db2/db \
"SELECT r.delivered_date, COALESCE(a.identifier, 'unknown'), hex(r.data)
FROM record r
LEFT JOIN app a ON r.app_id = a.app_id
WHERE r.delivered_date > $SINCE
ORDER BY r.delivered_date ASC;" \
| while IFS='|' read -r cfdate bundle hexdata; do
date -r $(echo "$cfdate + $EPOCH_DIFF" | bc | cut -d. -f1) '+%Y-%m-%d %H:%M:%S'
echo " app: $bundle"
echo "$hexdata" | xxd -r -p > /tmp/notif.plist
plutil -p /tmp/notif.plist 2>/dev/null \
| grep -E '"(titl|title|subt|subtitle|body|message)"' \
| sed 's/^ */ /'
echo "---"
done
Basically, notifications are in an sqlite db at ~/Library/Group Containers/group.com.apple.usernoted/db2/db and are stored as plist blobs.
In recent years, filesystem paths for system services have started to converge for both macOS and iOS so I'm thinking with jailbreak you could get read access to that database and get the same data out of it.
Am I in the minority for thinking ScreenStudio is actually worth the money?
The recent video I did for Cling for example (https://lowtechguys.com/cling) I’ve had many people ask about how I did it because it has just the right amount of motion and highlighting. I did it in a few minutes of editing in the ScreenStudio UI.
I’m not saying it’s a great video, but people say it conveys the info well enough and that’s what matters. It would have taken me days to do the same with DaVinci Resolve because of my inexperience with complex editors.
A $30/month subscription is indeed too much, but I see it as a one time payment for that month when I release something, then I pause the subscription. I need it rarely, very few videos need zooming and motion.
Anyway I love to see alternatives like OpenScreen! What I would miss the most would be presets, not sure if it’s already there, but it’s a nice quality of life feature to have a consistent look to the motion effects between videos.
I think it's mostly just that a subscription seems weird for a tool like this. Most users would probably only need it occasionally, and with a subscription you can't just add it to your toolbox to grab when that time comes.
IMO a big disservice to the universe has been done with the recurring revenue drive. Many services could/should offer a one-shot option, with the highest margin. Somehow the world got stuck on SaaS model so hard that one off is completely ignored.
I know why the capital class loves MRR I'm just mad that OTC is ignored.
I am struggling with finding a good model for desktop apps. The subscription model always seems to yield the most money, but I too dislike subscriptions.
One-shot option seems attractive, but the desktop (MacOS at least) app market is actually so niche that the SAM is somewhere in the low thousands. So, if I would offer a one-time 100$ app, I'd have 100k$ before taxes. And for that revenue, there's developing, marketing, plus support and maintenance. So to match a dev's salary, I'd need to make 2-3 successful apps a year, that I'd also have to maintain for a long time.
I think maybe there's a mid-ground with buy forever, 1 year updates, so people get the product they paid for, and if they want updates or support the development they can re-buy, however I'm yet to hear opinions on this model.
> I think maybe there's a mid-ground with buy forever, 1 year updates, so people get the product they paid for, and if they want updates or support the development they can re-buy, however I'm yet to hear opinions on this model.
As far as desktop software is concerned, I think this a commonly accepted approach. Sublime Text is probably the most notable example.
Isn't that just how most software used to be sold? If you buy Photoshop CS5 or MS Office 2023 you get the product as it's released and maybe a year of bugfix releases (but no new features). If you want the new features buy Photopshop CS6 or MS Office 2024
Personally I like the model, as long as old versions stay truly static and don't get enshittification updates. It aligns incentives on feature development far better than subscription models: if you make genuine improvements you get recurring sales, if you don't then existing users will just stay on the old version. And existing users are protected from features or UI changes they disagree with
For me it would make more sense to have something like “unlock for a week” if the dev wants to keep the ongoing revenue model. Of course a lifetime purchase is even better, not sure why that’s not an option.
I would be happy to pay $100 for unlimited access and be locked into the current version of the app, maybe only have minor version updates free so you don’t get locked into a buggy version.
But that’s a more complicated licensing model to implement I guess.
If you only need it occasionally doesn’t subscription make sense? Just pay for the months you need it.
I’m cautious of adding subscription products i would depend on to my tools but if it’s something I definitely only need once a year I just buy a month of it.
Although $30/mo is a bit much for what it does. So if they did go one off presumably it would be about $500 a license.
I must be in the minority but I find that constant panning/zooming to be very distracting and almost dizzying. The sharp start of the easing curves is pretty awful too. I'm surprised people like it.
I'd probably do it with arrows or fading out parts of the screen instead.
A lot of the time it is, I agree. I would love the ability to do more highlighting and less panning. But in a small 700px wide video, zooming is kind of necessary to make it clear where the action is coming from. Because the app window is so large and packed.
And these recording editors don’t have arrows and callouts, not even a freeze frame. I have to plan the recording to the letter and after 10 frustrating takes I just say fk it and try to polish the least confusing take
Maybe I should start contributing to openscreen to get the ideal recording editor people are looking for instead of paying and complaining.
> A $30/month subscription is indeed too much, but I see it as a one time payment for that month when I release something, then I pause the subscription. I need it rarely, very few videos need zooming and motion.
If I think something is worth the money, I typically don't need to actively decide to pause the subscription each time I use it.
Right, it’s not worth $30/month all year for me because I don’t use it past demo videos for when I publish a new app or large update. Which happens rarely.
But if I was that kind of user who did demos monthly, the time saved on one or two videos that month is worth $30.
The commenter you're replying to said he needs it only occasionally. It makes perfect sense to pause a subscription if you don't use it. Not doing so would be a waste of money. How can you critisise that, don't be ridiculous
I created QuickScre because I wanted a no editing way of recording polished screen recordings for Slack etc. Free to try https://www.appblit.com/quickscreen
The subscription model for an app I'm running on my desktop is taking the piss a bit. I'm fine paying for stuff I use, but I miss buying apps once and either using them as much as I want, or paying to upgrade.
Now I'm both locked in to paying every month, and can't keep using the app as it was when I bought it, because it auto updates and most apps will invariably have a server component that will quickly become incompatible with old app versions.
I hate the direction of "we'll force you to update even if you don't like the new direction, and we'll force you to pay for the privilege", so I'm voting with my wallet on this.
You can fabricate a professional business image in a few days with AI now. It's going to be hard to build an honest brand when everyone is going to point and say "vibe coded slop" because of examples like this website.
I'm already seeing such comments whenever someone posts an app on /r/macapps and it's really discouraging for beginners. If I would have met that resistance and amount of mean comments when I launched Lunar, I would have probably never put in that amount of effort.
The notch hiding menubar icons is such a stupid problem to have. I waste hours every week trying to help people who send me frustrated emails because they bought one of my apps and they say: "it doesn't launch" or "why doesn't it have any interface??"
No amount of FAQ will help these people. And this also results in hasty refund requests and even worse, chargebacks that take 2x the amount the users paid out of my pocket.
I recently helped my brother launch a simple app for making any window a PiP window (https://lowtechguys.com/pipiri) and in the first two days, half of the sales turned into refunds exactly because of this issue. People had so many menubar icons that they thought the app just doesn't work. Not an encouraging launch for his first app.
Not to mention the fact that the best solution that helped alleviate this, the Bartender app, was completely broken by Apple's internal API changes in macOS Tahoe.
The reason things are this way is that in Apple’s view, third party devs are effectively misusing menu items.
Originally it wasn’t even possible for third parties to add new menu extras using public APIs. That was something reserved for Apple. Third party devs had to use a tool called MenuCracker.
When Apple finally added the API used now, the intention for it was for full fat GUI programs to provide ephemeral menu item companions that disappear when the host app is quit. It was never intended to facilitate persistent third party menu extras.
So the issue hasn’t been fixed because in Apple’s view it’s a problem of third party devs’ own creation. If all third party menu items were ephemeral nobody would have enough for them to overflow into the notch area.
——
Personally I think they should offer a way to extend the Control Center and push devs who want persistence towards that. That would afford better organization for users and allow them to better control which are immediately visible (since some apps don’t offer an option to hide their menu item).
It's also abused by soo many devs, just wanting there app to be seen 24/7 by the users, regardless if there app gains anything from being in the menu bar. That's why many users run out of space.
Most people don't look at settings or ways to remove them (if they even give an option), so they quickly fill up the menu bar. Back in the day without a notch, people would have so many that some menu items would disappear too.
A couple of my colleagues have so many applications running at the menu bar, so they have to use Bartender to be able to have anything resembling a functional menu bar.
I understand power users, but I don't understand these users.
Try a corporate laptop. Every stupid thing you don’t need except to know it’s running is there, but you don’t know it’s running because they may just be hidden.
Jamf, zscaler, virus checkers, etc. need to all go to hell with this crap. I’m glad Tailscale are removing theirs.
They don't have to be one of my colleagues to share their own perspective and experience. We're a rather large band of computer using people here, and it's good to share experiences and viewpoints.
I haven’t looked into it, but does it allow arbitrary UI? It sounds like they’re just buttons that trigger a single action, which isn’t sufficient for replacing menu items.
That's not really defensible as an excuse, especially considering Apple's grooming of users to believe that they never need to quit applications.
All Apple had to do was add a "more" indicator at the end of the area, at the very least. Or... to give all applications' entries equal footing, collapse them all into a disclosure control once there are too many to show.
But no... once again, a simple and fair solution eludes Apple's "designers."
If the “simple and fair solution” makes it so lazy developers lose money over putting things in the menu bar where they most definitely should not be putting anything, then so be it.
Yes, the number of apps that actually deserve space up there is rather small. The last thing Apple should do is enable a Windows tray style free for all.
There’s no statement or action (such as banning menu-bar-only apps from the Store or even changing the APIs) supporting that Apple still wants menu bar items to be ephemeral.
It's such a simple problem to solve too: when there are too many menu bar icons, put them in an overflow menu. A single icon which contains a list of icons. And let me arrange which icons go into the top bar and which go into the overflow menu.
Windows solved this many many decades ago with their system tray overflow menu. Browsers solved it too, by letting you put extension icons in an overflow menu. It's not hard.
But nooo, macOS just silently hides applications from you, with no visible indication that there's anything hidden.
Even if they didn't want to have an overflow menu for some reason there it boggles my mind why the menu bar isn't just aware of what portion is covered and should be skipped (file menus or icons) in the first place!
Well there's effectively no space on the lefthand side of the notch. You must assume that side is going to be completely consumed by actual menu items.
Side note: If you want to check what icons might be buried by the notch, you can Cmd + Drag any icon from the menu bar to rearrange them. If you drag an icon through the notch, the other items will pop into view, if any are hidden.
One of the first things I tasked to do as a junior web developer at my first job was to make a horizontal nav menu that was responsive such that when the screen shrinks any overflow items go into a drop-down.
Baffling that a trillion dollar company can't do this.
Edit: apparently i don't know the difference between vertical and horizontal :)
It's true this is a mess, but no application should have a menu by icon as its only means of access. It's OK to offer that as an option, but all applications should be capable of presenting a user interface when launched from the Applications directory (or (rarely) ~/Applications, etc).
There's really no exception to this rule. For an (tiny) minority of applications, it makes sense to hide the dock icon, and to typically access the app via hotkey or menu bar widget. But those apps should still have an icon and should still be able to be invoked by opening it using any of the standard ways to do that. That's just how the Mac works.
I never understood the logic behind the thinking there. Why would you ever want to place menubar items UNDER the notch, if you know it's there and they won't be visible?
It's such an easy problem to fix, with such incredible usability consequences, I just don't get the thinking.
The notch itself is probably considered temporary internally. If you code a rule for the notch, then you're going to have to consider which hardware OSX is running on in order to determine if the notch is present or not for your "notch width calculation."
The truth is most apps have no business having a menubar icon, but many of them cannot even be disabled out of the box. There's a number of third-party tools that help with the issue, but really this should be handled at the OS level. I want a permission similar to notifications to control whether an app can litter the menubar or not.
One thing's for sure: No application should be allowed to have a menubar item without a ToolTip. WTF, that should have been obvious from day one.
At the moment, I have 11 of them on my system (not counting the clock), a mix of third-party and Apple ones. NOT ONE of them has a ToolTip.
Even worse, if you click on them, the resulting menu does not show the name of the owning application. This too should be forced. For example, I unfortunately have to run Microsoft Teams, and its toolbar menu gives you no indication of what application it belongs to.
I'm curious if people even cared about the half-centimeter extra screen space they got when Apple introduced the notch into MacBooks. Arguably it makes a bigger difference in iPhones so I'll grant them that, even if it does hide half of the top bar of the iPhone. But did people hate the half centimeter bezel on macs that much that they wanted to lose an inch of their task bar? Genuinely curious how we got here!
I mean, I don't love large bezels, but I dislike less screen real estate even more. Are the bezel nerds happy with where are now??
My android phone (OnePlus 11) has a hole punch front camera so I don't lose too much screen real estate. It's annoying sometimes but I prefer it to my mom's iPhone's giant notch.
The hole punch design absolutely horrendous. It makes everything uneven visually speaking and it just looks like - screen defect. The notch is fine, not perfect, but fine, and leagues above that stupidity of the hole punch.
I don’t work at the fruit co but since you asked for speculations. Mine: the fruit co designers are still designing a nice interface to show the overflow, because they obviously think that the Windows tray overflow looked inelegant and are still searching for the ideal UI. But the designers themselves don’t have a lot of menu bar apps so they don’t think it’s a priority.
Windows has always baffled me with the system tray icons it is too cluttered. I grew up with a tricked out Linux desktop so I understand the need to customize. But most of the time you do not need that.
I believe a VPN should stay hidden if it works, no need to have it visible.
> I believe a VPN should stay hidden if it works, no need to have it visible.
Which is fine if you only have one VPN client or one VPN network and you don't need to turn it on/off or change it regularly.
My current day job has one VPN client but five different networks.
At a previous job I had two different clients I would need to switch on and off.
It is very on-brand with Apple though that there is one right way to do things, and everyone else either needs to change the way they do things or go elsewhere.
That’s the company response but I’m definitely not the only long-term Apple user whose go-to response is a sympathetic nod followed by a long rant about Tim Cook and his contempt for software engineering.
TBF, there isn't a computer on earth that will solve that problem perfectly. At some point, "you shouldn't have so many utilities running" is perfectly acceptable advice.
That's the standard apologist response to ANY defect you point out in anything, or any question they don't know the answer to but still want to bloviate about.
It‘s reasonable to assume that menu bar items will be rendered differently as well, to accommodate for Dynamic Island (which changes its width as needed).
Well I mean, recently because they have no idea how to make good UIs, and have not read their own enormously detailed (and excellent) Human Interface Guidelines tomes from 10, 20, and probably 30 years go, and have basically regressed to barbarism.
But before that relatively recent fall-off-a-cliff event (whatever it was that caused it, most of us will never know), it was pretty clear that they didn't want to implicitly endorse the lazy/anti-user/Windows-equivalent-UX antipattern of having apps that intentionally made themselves accessible only from a menu bar icon.
I hate the App Store shite that goes wildly too far the other way, but I don't quite understand wwhy they couldn't figure out a way to enable the menu bar widget API in a way that failed if your app didn't also have a way to open via all the normal ways (double-clicking the icon in /Applications, asking Siri to launch it, etc)
> they didn't want to implicitly endorse the lazy/anti-user/Windows-equivalent-UX antipattern of having apps that intentionally made themselves accessible only from a menu bar icon.
The single biggest complaint I had when I switched it to Mac was lack of this feature. Still miss it. .
It's annoying for end-users (and you), but why not display a window with a SUPERSHORT message explaining that MacBooks with a notch might hide the icon on the first launch? Have a button or link to explain more for people who want it.
Shouldn't have to, but it might mitigate some of the stuff a FAQ won't catch.
I forgot such messages directly. Then when It realize I saw an important message tens seconds ago I have no way of going back. I can not press undo and get that message again.
Error messages are a bad design. Error logs are ok. Global undo would be king like the undo close tab feature in browsers.
There is no reason for apps to be in the menubar. Either they should have a dock icon or be hidden completely. And open a window with functions and settings when opened by spotlight.
Perhaps people who have many menubar icons are hare-brained and you should check to see how many icons they’ve got before you price your product for them to account for the support overhead.
Of course you are gonna get more complains from people who struggle more with technology, this does not mean these are the only ones with menu bar icons hidden behind the notch.
There are some things that are only available in Shortcuts because Apple gave the app entitlements to communicate with parts of the system that an AppleScript or other apps can't. Things like setting/getting the Focus Mode, changing some system settings like Airdrop Receiving, Color Filters, Background Sounds etc.
Also some apps export Shortcut actions that can run in-app code: for example my Lunar app has an action that can help fixing arrangement when monitors flip around [1]
It's much easier to implement a struct for a Shortcut, than exporting AppleScript sdef files or creating IPC command-line tools, so a lot of apps take this route for code that needs access to the memory of the running app.
Thank you for the kind words! Love to hear from people that were helped by my work!
That was also my pain point with Lunar, working on a small balcony in a small apartment where the light from the window was constantly changing and the monitor always being way too bright or way too dim.
I broke one of those LG monitor joystick OSD buttons before I got to building Lunar.
You can definitely have Claude work with cherri files.
Jelly was a confusing experience for me, with JellyCuts becoming closed source and focusing on advertising, then Open-Jellycore branching out but not actually keeping up with the latest shortcut actions.
Cherri has almost every action you can find in the Shortcuts app, easy to use, and easy to create Shortcuts that can accept input and output so that they can be automated or scripted further.
I've just used this extensively to build 200 Shortcuts for my event-based automation app on macOS [0], because some actions you simply can't do without Shortcuts: changing Focus Mode, toggling Accessibility functions like Color Filters, accessing the Private Cloud Compute model etc.
I also wrote about how Claude was able to basically learn the language from scratch and write those fully compilable Shortcuts for me [1] because it was mind boggling to me that an LLM can do that. Curiously, this is becoming more and more normal in my mind.
When you say Claude learned it. That's in the current context window it is able to do that, right? Or is there a more permanent way to make it learn something?
Cool to hear Claude was able to learn it. I was planning on leveraging it in a future version of this project I was hacking on that lets you execute shortcut actions as tools (without creating actual shortcuts): https://tarq.net/posts/action-relay-shortcut-actions-mcp/
Well, that’s a domain that has caught my attention so I’ll give this more weight (ltg). I recall novel Mac apps that weren’t quite right for me but seemed thoughtful.
are you certain that it wasn't included in the training data?
I saw someone do this awhile ago with a low resource language (I think it might've been Abkhaz?) with seemingly-incredible results, and eventually everyone came to understood that, even though it wasn't officially supported, Abkhaz materials had been in the training data
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
> 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
It absolutely is for privacy, to stop malware or trojan programs from obscuring their accessing the camera or microphone.
> 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)
OLED displays are widely expected this year. Not wanting to have to deal with "my battery life is an hour and a half instead of 10, what's going on!? Replace my battery!" nonsense is probably the remainder.
As a hobbyist music producer with an interface always connected, that microphone indicator is so annoying and unnecessary. I can't believe it can't just be disabled outright. I like macOS but it's too opinionated and some of those opinions SUCK.
Yeah I can see that being a source of annoyance for situations like yours. However, I welcome it from a privacy perspective. The indicator alerts the user if some nefarious application covertly enables the microphone.
I had a nice wrapper on blueutil so I could do “hp” and “btoff” which meant turn on bluetooth and connect my headphones, or shut off bluetooth. I used this 5x a day. They just decided to randomly remove that API which was me fixing their clunky horrible bluetooth workflow.
Re: Yellowdot, have you considered setting a LUT to the display that maps the color of the recording dot to black, then setting a LUT to every other window that maps the same color to a nearby similar color?
Not a macOS user, but I feel like that might still work.
I get it that macOS has to evolve, but that doesn't mean all apps have to drop Intel support at the same time.
On hardware-level apps like my Lunar app I have plenty #if arch(arm64) because some features like reading the brightness nits or reading ambient light is different or completely missing based on the architecture. I need to test the UI differences based on what features are available.
I don't see it viable to stay on macOS 26 for this, especially if we're going to see breaking changes again with the display and window server subsystem like we did with Tahoe. M5 support for Gamma table changes is still broken after so many months [0]
[0] https://developer.apple.com/forums/thread/819331#819331021
reply