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.
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.
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.
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!
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.
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.
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.
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.
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 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.
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.
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 love Kino! I film all my wood carving videos with it for my Instagram profile [1]. I'm so glad to hear it's getting updates this year. If you're open to feedback: I like playing with white balance a lot, and it takes just a little too many steps in the current interface. I think Kino would benefit from having a "remember/preserve white balance" setting, and a gesture for changing it without tapping.
For example, I like how we can swipe down to show the exposure slider, then swipe left/right to adjust exposure. Maybe it would make sense to have these hidden sliders on all 4 sides: right side could show a focus slider, left side could be white balance etc.
In any case, even without that, it's my most used new app of the year. Thanks for giving us such a simple way to get good looking color grading out of the iPhone!
Damn, so this is the thing that caused all the floating windows to become unclickable and impossible to interact with... I'm the creator of the apps from https://lowtechguys.com/ and I was replying to 10-15 support emails per day, all week, because of this.
It's a bit scary to see that the software we rely on every day is such a complex behemoth that even a seemingly small change can have so large repercussions.
The problem is that AI only helps add even more complexity since it's so simple to just add more code now that we don't have to write it.
It feels like Apple has gone deeper and deeper into tech debt over at least the past decade, to the point where I see little prospect of their software reaching former quality levels again.
Notarization is mostly a glorified malware scan. There's no Apple engineer auditing what's being sent for notarization. Even clever malware can evade notarization scans and be distributed as a notarized binary, it has happened in the past [0]
There's no better way for auditing such an app than having the code easily available and looking through it, and compiling it yourself. Which is already the case here.
After a different company detected it, figured out what it did, and reported it to Apple. The app was notarized on November 17, screenshots in the researchers' post are from December 16. That's a month of fully notarized distribution.
This is the hardest thing about selling wooden spoons and especially cups. Like you, most people think about the rough texture they felt when using cheap or disposable wooden utensils.
My spoons and cups feel more like warm textured ceramic. They are sanded to a high 600 grit, water popped multiple times to make sure the grain doesn't raise and the texture stays smooth, and finished with drying oils as you see in the article to keep the surface highly hydrophobic.
I really can't describe it in words, but everyone I know who tried eating with my wooden spoons and drank from my coffee cups, was pleasantly surprised of the feeling.
That's why most of my sales happen in person at local craft markets, because there, people can take the cup into their hand, they can feel the smoothness, and they can ask about the same things you are worried about.
All I can recommend is find a spoon carver in your area, or one that ships there, and try a hand carved eating spoon. I'm not saying it's better than metal, ceramic or plastic, it's just a different experience that some people enjoy.
Some people react very badly, some are immune. But to be honest I just don't like my spoons and cups to look lacquered and I don't prefer the process of application.
Nothing wrong with that though, I like reading and watching people do the process and seeing them enjoy the calmness in doing dozens of layers over multiple days. Some end up with very beautiful shimmery brown wooden pieces [0] and I would love to own some of them. It's just not my style.
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.
This could have been handled better.
reply