[Wowfunhappy]

I miss when apps like this were built as preference panes.

An app that does nothing but change an OS setting—and whose user interface exists purely to adjust those settings—does not belong in my applications folder, and certainly not in my menu bar. Such apps ought to live in System Preferences, alongside other, well, system preferences. And what do you know, Apple built a way for third party developers to do just that!

Preference panes used to be the norm, but that seems to have changed over the last decade. It pains me to admit that an app is probably the right approach nowadays, because when everyone else is doing things one way, users will expect you to do that too.

One more way that OS X's UI metaphors have regressed...

[aptgetrekt]

This is actually Apple's fault more than anyone. I was originally planning to release on the App Store but decided not to after thinking about the $100 a year fee to be in the developer program and the 30% cut Apple would take if it were paid, and that's assuming the app would be approved by Apple in the first place. Although I decided not to release on the App Store I want to keep the option open. Apps on the App Store need to be sandboxed, which means no preference pane.

I agree apps filling up the menu bar is annoying, so there is an option to hide it if you wish.

[Wowfunhappy]

...wait a sec. Sandboxed apps have the ability to hijack the scroll wheel when you're using other apps?

[aptgetrekt]

Looks like it, yes. I don't use any special private APIs, just the public ones that you can use in apps on the app store. They need the accessibility permission to "Control your computer". Apps like BetterSnapTool/Magnet work with the same permission. Here's the code that actually intercepts scroll events: https://github.com/ther0n/UnnaturalScrollWheels/blob/master/...

[saagarjha]

I think the accessibility API lets you do this, although you might need to explain why you're using it during app review.

[SllX]

100% agreed but I finally gave in and bought Bartender to bring sanity to my menu bar and hide all of these menu bar apps. I was able to hide Notification Center as well which was a neat and unexpected bonus, but would still be better if I didn’t really need a 3rd party app to manage all these 3rd party apps that insist on living somewhere in the foreground and it’s either the menu bar or the Dock for them.

[mikestew]

Are OS X's metaphors slipping, or are they just being folded into how developers write their apps, or consumers use them? I ask because of the iOS Settings app: it used to be that was the place one changed the settings of an app, not in the app itself. IOW, kinda like the macOS System Preferences panes...sorta.

Point is, it can appear that the OS settings pane/app/whatever is for stuff Apple controls, and the rest has to go in an app or menubar. I'm not saying it's right, I'm saying that Apple has let the messaging get really confused.

[Wowfunhappy]

> I'm not saying it's right, I'm saying that Apple has let the messaging get really confused.

Right—part of Apple's job is to create an environment where the "correct path" is clear and developers want to follow it. Either Apple used to do a better job, or else developers did.

And, consider:

• Apple encourages developers to distribute via the Mac App Store as much as possible.

• Preference Panes cannot be sold in the Mac App Store.

• In Catalina, all Safari extensions must be installed from the App Store as individual apps.

• New Notification Center widgets are always installed as applications. Old Dashboard widgets never were.

I would say that taken together, the clear implication from Apple is that apps are the way to go. And it all comes back to the Mac App Store, which Apple wants to push that at all costs. Evidently, they either actively don't want to sell non-apps in the store, or they don't care enough to build that functionality.

There are probably times when Apple's patterns are just wrong and the community coalesces on something better—I can't think of any, but it has probably happened, or will some day. But I do not think this is one of those times, because if you step back, using an app does not make objective sense.

(P.S. It's interesting to note that Apple's own iOS apps tend to have far fewer in-app preferences, in favor of sticking stuff in the Settings app.)

[naravara]

> Either Apple used to do a better job, or else developers did.

A bit of both I would think. When the Mac was a more niche platform the developer community tended to be more bought into philosophy and design sensibilities around it. And as the Mac has gotten more widespread in popularity, Apple has gotten less good at planning around power-user use cases or communicating how to handle them elegantly.

[Wowfunhappy]

> When the Mac was a more niche platform the developer community tended to be more bought into philosophy and design sensibilities around it.

I still kind of hold Apple accountable for that, though. As the platform grows, Apple has more resources they can dedicate to clarifying UI patterns, or systemic coaching via API design. But they've gone in the opposite direction.

[saagarjha]

> In Catalina, all Safari extensions must be installed from the App Store as individual apps.

Not true, you can distribute outside of the App Store as long as you sign/notarize correctly.

[Wowfunhappy]

Thanks—for some reason I thought the App Extensions were uniquely App Store-locked, but what you said makes much more sense!

I think I was getting confused with old-style extensions and the Safari Extension gallery, for which sideloading was truly blocked for around a year.

[toyg]

I agree but I think the issue here is complexity. This app is built with Swift, probably because most developers prefer high-level languages like that over system-level languages like ObjectiveC. Unfortunately, OS vendors typically don’t provide interfaces for high-level languages in their OS machinery unless strictly necessary. Can you actually write a Preferences panel in Swift? I wouldn’t be surprised if the answer were “nope, Obj-C only”.

It’s not even an Apple thing, Windows has been the same for a very long time - remember how browser extensions “exploded” when Mozilla made it possible to write them in JS? IE forced you to C++, dramatically restricting the number of developers.

[rgovostes]

I wouldn't characterize Swift as "high-level" and Objective-C as "system-level." One of Swift's stated design goals is to work at all levels of the technology stack, including system programming where you need a lot of control over struct layouts and so on.

I'd agree that most of the focus has been on app development, but I just found this toy kernel written in Swift the other day: http://si.org/projects/project1/

On the Objective-C side, sure you have access to all of the low level stuff of C, but Objective-C's message passing is probably a poor choice for very low-level system programming (in the kernel, for example). Apple uses C and C++ in the xnu kernel.

Swift was also designed to interoperate with C and Objective-C APIs, so you could certainly write a preference pane in it. It even automatically generates Swiftier interfaces for APIs that follow conventions. Here's the NSPreferencePane API: https://developer.apple.com/documentation/preferencepanes/ns...

[aptgetrekt]

I don't know much about macOS development, 72 hours ago I had never done any at all! But as far as I can tell anything you could do in Objective C you can also do in Swift. I would have made a preference pane and would prefer it myself but I explained why I didn't in another comment. Apple kind of discourages preference panes unfortunately.

[saagarjha]

Swift is largely compatible with Objective-C; for your preference pane question the answer will certainly be yes now due to ABI stability and preference panes running out-of-process. I would expect dealing with the Accessibility API to be the more annoying part, and that only because it's a C API working with function pointers, which means you can't use blocks (which is true with Objective-C as well, but generally par for the course when working with interfaces that Apple doesn't care much for).

[monadic2]

Can’t you interface natively with objective-c objects from swift? It’s a much smaller ABI to target than the C++ one and most languages I know have some decent bindings.

[Wowfunhappy]

> Can you actually write a Preferences panel in Swift? I wouldn’t be surprised if the answer were “nope, Obj-C only”.

If that was the case (I don't believe it is), it would only be because modern Apple doesn't care enough about Preference Panes to add easy support. A third party Preference Pane is not any more "OS machinery" that a third party screen saver.