Frankly, I’m not sure I trust Apple to support this appearance API over time. They’ve been down this road before.
It’s kind of funny/sad to see how Apple operates with APIs. None of these concepts are really “new”: they were there, in Carbon, prior to Mac OS 8, in the days when that OS was meant to support really elaborate themes.
The original theme APIs were huge, and 3rd parties were expected to adopt them as needed (e.g. using appropriate theme selectors for fonts and background patterns). For about a year, things looked really cool: you could create a great Platinum-esque UI for any custom control, and it would fit right in.
Then, they threw it ALL away for Mac OS X, ironically right about the time when an appearance-agnostic API would make a lot of sense. They didn’t even bother to update their API implementation to ease migration: really trivial changes that would have been helpful, like “update the damned font/color/pattern value returned for X to resemble Aqua”, were not done. This meant that an app full of seemingly-appearance-agnostic code would look like crap under Aqua, and you had to rip it all out.
And it’s not like Mac OS X didn’t change its look. Heck, for a long time you could find 3rd party app bundles chock full of images that were there just to implement the Apple-Look-and-Feel-of-the-Week, because the SDK didn’t offer any reasonable way to do half of what they came up with.
So yeah, 14 versions later, the Mac wants to be appearance-agnostic again. Sounds great. My advice: always have the option of doing your own UI as a backup.
>Then, they threw it ALL away for Mac OS X, ironically right about the time when an appearance-agnostic API would make a lot of sense.
That's almost 20 years ago, and for very good reasons: moving to a whole new OS, with a new graphics pipeline and UI engine, and one they especially wanted to tout.
If that's the reason you don't trust Apple to support the "dark mode" APIs going forward, then that's bogus.
>So yeah, 14 versions later, the Mac wants to be appearance-agnostic again.
Were "the Mac" is a very different OS (the legacy Mac OS vs NeXT based OS X), by an almost totally different company compared to the one that created the original Mac OS 6, 7, 8, 9 and co. And 14 versions later is 18+ years on.
At which point do you draw the line?
Should we also be concerned for what Sculley era Apple did to some APIs?
At the time, the APIs were not that old and not deprecated. It simply became clear that the theme stuff wasn’t updated for Aqua and was a liability.
Furthermore, an awful lot from those days had recently been touted as “the future”, encouraging developers to invest more heavily than they might have otherwise. It would have been more future-proof to not to adopt the API wholesale and just hack in fonts and metrics everywhere but no one knew it at the time.
Had they simply kept using the API, it would have naturally evolved over 20 years. It wouldn’t look the same today (it would probably be way more powerful than NSAppearance) and developers wouldn’t feel like time was wasted.
They could have even created an immediate NS-wrapper for the older API back then (as they did for certain things), if supporting C long-term wasn’t palatable.
>At the time, the APIs were not that old and not deprecated
No, but they were also created for the previous OS. Not merely the previous release of the OS, a totally different OS.
>Furthermore, an awful lot from those days had recently been touted as “the future”, encouraging developers to invest more heavily than they might have otherwise
Sure, that was bad. But that was the last steps of a dying company, and probably touted as such before Jobs and co took the helms. The decision to drop lots of existing stuff and focus on a totally new platform is what turned the fate of the company around. At least in retrospect we can say it worked great, even if there were some casualties along the way.
Compared to the theme API, I'd more lament Yellow Box (which was a NeXT based technology anyway), and perhaps WebObjects (ditto, and ahead of its time).
That said, I really liked the "Platinum" (I think was the name) OS 8 look, and used to mimic it on Linux through cheapo wm themes.
Windows also lost the ability to have multiple UI styles after Windows XP -> Vista, and has yet to recover it as far as I know. Microsoft also never officially exposed the API so you had to use performance-degrading hacks like WindowBlinds.
In my experience as a Mac + iOS user and developer for the past 8 years, and for the rest of my life before that on Microsoft platforms, Apple's record has been much better compared to Microsoft re: abandoning APIs or pulling the rug out from under devs.
Take NSDocument for example. It has been around for almost 20 years. All you usually needed to do was inherit from it and adopt its interface and your app would often get new features for free with each release of macOS, like autosaving and version histories.
The foundations for multiple UI appearances have been there since macOS 10.10 Yosemite, 4 years ago. They were hard not to notice.
As a user and developer I'm glad they took the time to work out a sensible implementation that is very easy to adopt now and makes good sense for the future. It definitely seems to be in a better spot than Windows' support for multiple appearances currently, if it has any.
If you see the WWDC sessions on Dark Mode, you might come to appreciate the thought and effort they've put into it:
You can say a lot of things about windows but abandoning apis isn't one of them. Windows is the king of backwards compatibility, for better or for worse.
And in some cases, like their speech synthesis and recognition APIs, Windows has been pretty darn good about having the APIs in the first place, maintaining and improving them over more than a couple decades, with the APIs being quite rich and supporting third party components like voices, synthesizers and recognizers.
While Apple's speech APIs, for all their huff and puff and other legitimate work on accessibility, are totally lacking, way behind, locked away from third party developers, and sadly deficient for application developers who need more than the most basic off-the-shelf features.
For example, SAPI has for decades been able to a send mouth positions (visemes) synchronized with the speech, to animate the lips of the Wizard or Rover the Dog or Clippy (or whatever a paperclip uses to articulate), which is proven to improve speech understanding. But not a peep from Apple's speech API -- their lips are sealed.
DirectInput -> XInput, which dumbed down many of the advanced Force-Feedback features to the level that the simple Xbox gamepads could support, compared to the original Sidewinder line of awesome joysticks (another victim of Microsoft abandonment.)
Often not making many APIs available in their latest programming technologies like .NET/C# (at least initially.)
WPF, Silverlight, the "Metro" experiment that lasted for a single (!) version of Windows (8), and great discontinued apps like PhotoDraw, are some of the other cases that personally affected me.
WPF has had a major release not a year ago and is actively updated alongside .net framework updates[1]. It is featured prominently in all visual studio products.
For that matter even winforms is still available.
The Metro UI evolved into windows 10 UWP, and practically everything that was in Metro UI can be transferred to UWP, down to the homescreen widgets.
Silverlight and DirectInput are still available, though they are deprecated they haven't been removed. Silverlight even had security updates released as late as a year ago [2]even though it has been deprecated since 2015
They changed the name to Modern UI, some reported [1] because it clashed with their German partner Metro AG. In any case Modern UI started with Zune and you could get for the time nifty looking media player for it on XP [2]. You can still see it in newer parts of Windows 10 with its aversion to skeuomorphic design, preferring text and minimalist 1 color icons.
I was referring to that crippled subsystem with the fullscreen Start Menu/Screen and the touchscreen-compatible apps that launched from it, separate from the "full" "desktop" experience, where you had two versions of IE, Outlook, Skype etc. It was also all you could access on the now-abandoned Windows RT.
Is that dichotomy still present in Windows 10?
See, it's a confusing exercise to even figure out what their sub-platforms are supposed to be called. Apparently they are now "Universal Windows Platform (UWP) apps (formerly Windows Store apps and Metro-style apps)" [0]
Do they have access to the full feature set of DirectX etc.? Do they have support for multiple appearances, Dark Mode, etc.?
UWP is what was WinRT on Windows 8, they have just been improving it all these years.
Of course they have access to full DirectX 11 and 12.
All new APIs are UWP based, and with they learned with the Desktop Bridge for Win32, they changed their strategy and are now merging UWP and Wi32 into a single container/store model.
Some of the talks related with it were done at MSBUILD 2018, check MSIX, .NET Core 3.0 roadmap, XAML Islands, XAML Direct.
If they don't change direction, in a couple of Windows releases they will be merged, with UWP continuously taking over Win32, like Win32 did before to Win16.
As for Apple, I can quickly refer to Object Pascal, Quickdraw 3D, JavaBridge, Quickdraw Java APIs, A/UX, Dylan, Newton, MCL, Hypercard....
If this is to be a simple listout of products and services that were superseded or discontinued because it made no sense to continue them (as opposed to breaking promises or replacing them with inferior counterparts), then on the MS side we have:
Active Desktop, Briefcase, CardSpace, Meeting Space, NetMeeting, Windows Sidebar, Desktop Gadgets and Windows SideShow (which displayed gadgets in a secondary screen on laptop lids etc., kinda cool at the time but I never saw an implementation in the wild), Office Assistant (Clippy in the File Explorer), Encarta and the rest of the edutainment product line (which were actually great and often used as a selling point for PCs at the time), XP themes, HTML thumbnails, the Comic Chat IRC client (my first gateway to social interaction on the internet), the SideWinder game controllers for PC (including the Dual Strike [0] which was way ahead of its time), MSN/Live Messenger, Photo Gallery, Movie Maker, Visual Basic, FoxPro and many others... :)
One question: After being exposed to Comic Chat as your first chat client, do you now visualize everyone you chat with and your online environment as if they were drawn by Jim Woodring?
I'm sure the end of Visual Basic (before the .NET impostor) was as much of a big if not bigger deal for many people as HyperCard. :p
The discontinuation of many of those things personally affected or disappointed me at the time. I distinctly remember mourning some of them:
- Losing people who only ever used Comic Chat and didn't make the migration to other services.
- The end of offline Encarta at a time when my internet wasn't very cheap, fast or reliable.
- Owning some great PC joysticks but not being able to utilize their full haptic features with newer APIs, before the joysticks themselves went out of production, when Microsoft's console division cannibalized their PC gaming division.
- A cool vector graphics editor [0] that worked better for me than Adobe or Corel getting discontinued after 2 versions.
The point of this whole thread is developer confidence, and I have felt betrayed and abandoned by Microsoft many times but I have yet to experience that during my time on Apple platforms.
Apple's current APIs are impressive and very forward-looking, and the only times I felt that optimistic about Microsoft was just before they broke their promises.
Cool link by the way, I hadn't known of Jim Woodring before today!
Both HyperCard and VB were really great for personal computing because they made it relatively easy for people to start making their own tools.
I made my first game with HyperCard, sadly lost to time unless the floppy is still sitting in some middle-school computing lab's storage room and hasn't degraded beyond readability.
Even recently I had a hobby project where VB 1.0 for DOS was a quick and easy way to hack together a GUI.
I'm saddened by the fact that "modern" desktops are increasingly becoming consumption-only devices. Personal computing is near death and no one seems to care much.
I do a lot of freelance working with small companies / non-profits. The people there typically need what are programmatically simple tasks done: converting fields of a CSV to some other format, adjusting the appearance of only certain Excel sheets in a folder of files, etc. But they are not what today we call "programmers," and there are no good tools anymore for them to easily build things that accomplish these theoretically simple tasks.
What's worse, it's even more difficult for me to build them a solution. If these systems came with something as powerful as Hypercard was on Macs in the early 90s, I could make them something they could maintain themselves, and it would have a GUI and everything. Today I have to go through an enormous build process and all kinds of hoops just to wrap simple tasks in a usable UI. This is NOT personal computing!
I think one part of the issue is that an entire generation or two of personal computing users has now grown up with only this "consumer" mentality and they have no idea what they're missing, what was abandoned more or less in the 90s. It's a very frustrating and sad state of affairs — but also one primed for a change.
> I'm saddened by the fact that "modern" desktops are increasingly becoming consumption-only devices.
I have been lamenting the loss of the ability to code as soon as you switched on a computer, ever since I moved from a Commodore 64 to an IBM PC clone. :)
You can’t even use $500+ devices as a simple calculator without an “app.”
We need more stuff like Swift Playgrounds, preinstalled on operating systems, but would people care?
The first thing almost everyone wants to do is open a browser and log on Facebook etc.
Maybe those people are the majority of the market, but that market will be served by tablets, phones and desktop web kiosks. The market for actual personal computers still exists, it's just being ignored by everyone because it is relatively small, like it was before the web made computers interesting to the current majority user base.
Not sure if WPF is a good fit for this this discussion about abandoning APIs especially not in the way as mentioned by the OP (i.e. ditching it all together): as fas as I'm aware it is still supported in the very latest versions of the build tools and the applications built with it just run on the supported OS for those tools (didn't check recently but about a year ago I could still get a newly built WPF application running on Windows XP). Sure it's not actively being developped anymore, but it's still there and still works.
WPF has only been tweaked a little here and there since around 2010 or 2012. Then they started pushing Silverlight and WinRT. I remember distinctly the moment around 2012 when we realized that WPF is pretty much dead in the sense that nothing new will be coming..
I'm aware it was used in Visual Studio, and oh, the Expression Studio suite [0] – another discontinued line of great products, for making stuff with WPF – but that's all I can remember.
Not even Calculator or Notepad used WPF as far as I know, which would have been the simplest apps to port and could have bolstered developer confidence in the technology (the point of this whole discussion.)
Correction: Apparently most parts of Expression Studio have been assimilated into Visual Studio, but the point remains: It decreased developer confidence when it was discontinued and nothing was immediately announced as a replacement.
>You can say a lot of things about windows but abandoning apis isn't one of them.
Actually abandoning APIs is very much one of them.
While programs written in older API still work, MS is notorious for abandoning APIs (as opposed to removing them) and asking developers to support its new shiny thing even faster than Apple changes frameworks (heck, you could still compile NeXT apps 30+ years later, and the frameworks where still supported, albeit with some alterations).
MS always invents new frameworks and APIs every 2-3 years for the same thing, e.g. GUI programming (or at least used to, haven't followed for the last several years).
Compared to what? Apple or the mobile OS du jour? Most other operating systems in commercial use, and we can look both at the commercial unices and the embedded stuff, supports APIs much older than Windows itself.
Support for the Win16 API has been abysmal recently. My limited experience of old DOS and Windows applications is that they often run better under dosbox or wine than native.
>It definitely seems to be in a better spot than Windows' support for multiple appearances currently, if it has any.
It has had pretty much what Apple are implementing since Windows 10. Dark mode and a custom highlight colour that gets applied across the OS.
Of course like on MacOS developers have to be using the latest UI framework to take advantage of this which unfortunately on Windows developers are a fair bit slower on the uptake than on MacOS.
Then again, I don't expect to see much uptake on the Mac side either considering I can't remember the last time I installed a new app and it was a native AppKit(?) UI and not just an Electron app.
> It has had pretty much what Apple are implementing since Windows 10.
The last time I checked Windows 10 did not support Dark Mode across all apps, not even its own File Explorer (unlike Finder and almost all other apps and applets that come with macOS Mojave.)
Has that changed? Do many third-party Windows apps support Dark Mode by now?
> Of course like on MacOS developers have to be using the latest UI framework
From what I remember from the WWDC sessions, I think you can choose to target the second-last macOS release (10.13 High Sierra) and still opt-into Dark Mode support on 10.14 Mojave.
> Then again, I don't expect to see much uptake on the Mac side
Pretty much all "heavy editing" apps like Final Cut, Affinity, Pixelmator Pro or even players like VLC use native AppKit and already offer an option for a custom dark mode or the official limited opt-in version that has been available since macOS 10.10 Yosemite.
These transitions are never fun but they happen sometimes. No API is eternal and it seems a little overwrought to be 'not trusting' Apple because they ditched an API (and entire OS) once, nearly 20 years ago.
I think you have to see before you raise and each of these APIs has changed in incompatible ways over its lifetime. With the possible exception of POSIX which is more of a standard/serving suggestion of slightly-incompatible implementations to begin with.
We can argue how useful those versions of Wordpad and Paint are, especially with modern file formats, but they are usable. I won't blame you for disagreeing with xterm, but over 30 after it was first shipped it's still the closest thing to a standard terminal, and the UI is decent once you get used to it (and much like emacs, it's partially jarring at first because it predates some expectations).
I haven't tried the latest macOS beta yet, but I remember a few years back finding a minor bug related this: neither Chrome nor Safari handled appearance / highlight color changes correctly. If I remember correctly, I think changing the value wouldn't be completely reflected on any open page until you either refreshed the page or restarted the app; it was one of those two, but I don't remember which. Funny enough, I think some colors did change correctly, but not all. Admittedly, I tested this out using CSS System Colors, which is sadly deprecated.
I vaguely recall finding a few bugs with Finder as well, where if you switched back and forth it wouldn't update all colors correctly. Of course, it worked fine after restarting the app... But if Apple's own apps have bugs relating to this, it wouldn't surprise me if it's a common problem for other third-party apps.
Another thing people might wanna try out relating to macOS appearance is going to System Preferences -> Accessibility -> Display, and enabling "Increase contrast". It makes some colors look a bit uglier, but I really love how it makes all UI elements stand out. For anyone that doesn't have macOS, or is too lazy to try it out, here's two comparison pictures:
A bit tangential... I'm hoping that at some point you can use a media query on the browser to test for this value. For example, there's already prefers-reduced-motion [0] on WebKit. I've definitely seen a GitHub issue at some point suggesting that a similar media query be added for users that prefer higher contrast interfaces, but I can't find it at the moment. Unfortunately when I last checked it didn't seem like there was much interest; as usual, accessibility features seem to take a backseat with many browser vendors.
> Another thing people might wanna try out relating to macOS appearance is going to System Preferences -> Accessibility -> Display, and enabling "Increase contrast".
You can also try increasing the "Display contrast" slider (to around the 3rd notch) while in Mojave Dark Mode, to remove the soft gray from the window chrome and replace it with truer black.
It affects all other colors of course, but it can improve reading/writing for those of us burning the midnight oil.
When you do finally try macOS 10.14 you'll find that Apple has done an excellent job in ensuring that apps respond immediately to appearance changes. Dark Mode would be complete crap without that ability.
"Kaleidoscope" [1] needs to be mentioned here as well. A brilliant shareware to apply a "scheme" (graphical theme) to classic MacOS. Wanted your UI to look like Windows, Copland [2] or BeOS? Kaleidoscope allowed you to do that.
There should be a dumbed down version of this page to explain designers (and sometimes managers...) why the app is not using the exact #353535 grey they’ve specified in Sketch.
It’s kind of funny/sad to see how Apple operates with APIs. None of these concepts are really “new”: they were there, in Carbon, prior to Mac OS 8, in the days when that OS was meant to support really elaborate themes.
The original theme APIs were huge, and 3rd parties were expected to adopt them as needed (e.g. using appropriate theme selectors for fonts and background patterns). For about a year, things looked really cool: you could create a great Platinum-esque UI for any custom control, and it would fit right in.
Then, they threw it ALL away for Mac OS X, ironically right about the time when an appearance-agnostic API would make a lot of sense. They didn’t even bother to update their API implementation to ease migration: really trivial changes that would have been helpful, like “update the damned font/color/pattern value returned for X to resemble Aqua”, were not done. This meant that an app full of seemingly-appearance-agnostic code would look like crap under Aqua, and you had to rip it all out.
And it’s not like Mac OS X didn’t change its look. Heck, for a long time you could find 3rd party app bundles chock full of images that were there just to implement the Apple-Look-and-Feel-of-the-Week, because the SDK didn’t offer any reasonable way to do half of what they came up with.
So yeah, 14 versions later, the Mac wants to be appearance-agnostic again. Sounds great. My advice: always have the option of doing your own UI as a backup.