Kuba Suder:
One of the most exciting announcements at this WWDC was the introduction of a long-awaited “dark mode” in macOS 10.14 Mojave, which lets you use a whole desktop with all the apps on it in a dark theme, instead of just the dock and the menu bar as before.
While I’m not nearly as excited about it from the user’s perspective as some others are 🙂 – I’m totally a “light side” Mac user, I’ve always used a light theme in TextMate, light theme in Xcode, white background in iTerm, and I sometimes have to use reader mode on websites with a dark background – I’m actually very curious about it as a developer. The reason is that it seems to require a lot of changes across apps to adapt them to the new appearance, or at least a lot of checking and testing, but it does so in a way that feels like “making things right” – not so much introducing complexity just for this reason, but rather enforcing some order and good practices that were earlier easy to forget about.
Supporting Dark Mode is proving to be an unexpectedly large amount of work, but it’s also brought improvements and greater consistency to the frameworks that should be good long-term. I’m finding places where I can now use the proper API and get the right result (visual consistency with Apple’s apps), rather than having to find hacks to match what everyone expects to see.
Update (2018-07-11): Kuba Suder:
This is the second part of that article – now that we have the theory behind us, let’s see how you can make your own app work with dark mode.
Update (2018-07-16): Ricky Mondello:
We’re considering adding a web-exposed media query, but it requires some more thought. Standardization is a thing, and API is forever. :)
See also: Craig Hockenberry.
Will Cosgrove:
Having worked with macOS Dark Mode for a while now it suffers the same problems as vibrant views before it. Blending random colors from the desktop into your user interface doesn’t look good. Designers can’t design for it and the end result looks messy and inconsistent.
Patrick Metcalfe:
I think it looks great when it’s used consistently. If you have a sidebar then using it looks great bc I’m used to that from other apps. Using it in other places suffers from the points you have
Update (2018-07-17): See also: the updated Human Interface Guidelines.
Update (2018-07-18): Brent Simmons:
If you’re developing a Mac app, and thinking of making it dark-mode-only, please consider that light mode is, for some people, an accessibility issue.
Though dark mode is beautiful, not everybody can use it.
Emily St:
This is absolutely true. For example, some astigmatisms make dark mode difficult to read unless the text size and weight can be adjusted. (This can break layouts, if it’s possible at all.)
Kirk McElhearn:
I have been ranting about this for years. White text on a dark background is hard to read for people with astigmatism, which is about 30% of users. Dark mode only is a big FU to nearly a third of your customers. I’ve never been able to use Spotify for this reason.
Jason Snell:
Apple took Logic dark with version X, apparently for aesthetic reasons. I hope the existence of dark mode will encourage some of these developers to build a light mode for their apps too.
Update (2018-07-19): Nadine Chahine:
Agreed! My research (along Monotype and MIT AgeLab) over several studies showed that word recognition speed drops in dark mode and especially so for older readers.
Update (2018-07-24): Brent Simmons:
Do semantic WebKit colors — -apple-system-text-background, for instance — not take Dark Mode into account? (Or is it just me and I’m doing something wrong?)
Jeff Nadeau:
My impression is that, in the absence of private API that shouldn’t be touched, WebKit resolves everything against the light appearance by default, the same way it does in Safari.
Accessibility Cocoa Dark Mode Design Mac macOS 10.14 Mojave Programming
Jesse Squires:
It is no longer the callee’s responsibility to release the object. So, all of the superfluous retains and releases go away. Ted notes in the talk that this significant reduction in retain and release traffic results in a code size reduction as well as a runtime performance improvement, because all those calls have been removed.
[…]
What’s more interesting with this change is the case of calling non-inlinable functions across module boundaries. Michael Gottesman shared this gist on Twitter to explain. I doubt many people saw that Tweet, so I wanted to highlight it.
The new convention seems more like Objective-C.
Update (2018-07-05): Joe Groff:
Still an important diff between Swift and ObjC—in Swift, the caller guarantees the validity of references, so callee never needs to retain. […]
Swift also still uses the +1 convention by default in situations where it’s most likely to be profitable, such as for the newValue in property setters or the arguments to inits, since these arguments are likely to be stored in the receiving object
Automatic Reference Counting (ARC) Compiler Language Design Memory Management Optimization Programming Swift Programming Language
Max Seelemann (tweet):
I also never set out to build a text editor. I was not even aware that creative writing is a thing — I did not come to like literature in school. I just happened to be on a mailing list for Mac users, where one day one random guy would come around and look for someone to make an app for him. I was the only one getting back, just answering “well, maybe I could do it”. This random guy happened to be Marcus, my partner and friend ever since. We started making this menu bar note-taking app called “NoteX” … nobody will remember. One day he came around again, asking if I wanted to do another app with him, a tool for creative writers. It was more a “why not”, than a deliberate decision.
[…]
Starting with this moment, Ulysses has been the most exciting project I could imagine. That’s probably due to its unique challenges and facets… The freedom of working on an independent project, the thrill of always aiming for the best possible solution, the direct impact we can have on people’s lives, the insane amount of feedback we’d get, paired with the technical and cultural challenges we had to deal with every day. Also, no app is ever done — especially not Ulysses. Someone just had to keep working on it…
[…]
We took our good old Ulysses side-project, polished it up just a little and put it on [the Mac App Store]. To our complete surprise, we sold more copies within the first week than half the year before that! That was crazy. What used to be a side project for many years was suddenly making real money. We figured it might be just enough to get both of us new Macs, and to sustain our living for three or so months. Enough time to get started, finally in full-time, and to see where it would take us.
Max Seelemann:
During the first years, I would make sure nobody would see my age.
I was 16. What sane would base her/his professional writing life on a tool hacked together by a kid? Maybe that doesn’t make sense, but it was a real concern for me.
I first encountered Seelemann when he was working on Localization Suite. Having once been a kid in tech myself, I thought I recognized him as such. But what mattered was that it was the best tool of its kind, and he was very responsive to feedback.
Previously: Congratulations, Ulysses Switches to Subscription.
Update (2018-07-06): Marco Arment:
Fun fact: When I went to work for @davidkarp at age 24, he was 19, but I didn’t learn that for years. (When we’d go out, I just thought he didn’t drink.)
[…]
It’s hard for young people to be taken seriously without everyone always just focusing on how young they are.
Anniversary Business History iOS iOS App Localization Suite Mac Mac App Mac App Store Ulysses
Steve Yegge (
Hacker News):
Why does everyone need mobile devs? Because the web is slowly dying. I have friends — well, probably ex-friends now — in just about every org at Google, who used to point me at their gloomy graphs, and it doesn’t matter how you slice it, the web’s in a steady decline as the whole world moves to mobile.
[…]
And don’t even get me started about device compatibility. I have a bunch of angry 1-star reviews in the Google Play Store because my Wyvern game app randomly didn’t work on LG devices, so I had to go on eBay and buy a crummy $60 LG device (as opposed to a crummy $600 LG device) to repro the bug and discover that hey, there are two Android APIs for getting mouse-click events on a scrolling list, but one of those APIs doesn’t work on LG.
[…]
So here’s what has happened: A bunch of competitors, big and small, have come out with their own replacement Android frameworks. I’m not just talking about support libraries for missing functionality, though those exist aplenty. No. I am talking about full-scale replacements for Google’s entire Android development stack. Microsoft has Xamarin, Adobe has Cordova, Facebook has React Native, I mean it’s crazy town.
[…]
The thing about these dev frameworks is that they make Google vulnerable. Most of them are cross-platform, which means you write a single app and it runs on both iOS and Android.
[…]
But consider: If all mobile developers were to start using a particular cross-platform framework X, then literally any other hardware/OS manufacturer or consortium could come along with their own competing hardware/OS platform (like, say, Windows) that supports that framework X directly, and all the apps would run on it (probably faster, to boot), which would cut Google out entirely.
Via
Michael Love:
This is a more realistic approach to how Microsoft or whoever might break the Google/Apple app duopoly, but still requires a lot of stuff to be rewritten that it no longer makes financial sense to rewrite.
Apple have correctly recognized cross-platform frameworks as an existential threat, which not only explains Marzipan but also why iOS 12 tries so hard to make native apps buttery-smooth / clearly-superior-to-React-et-al again.
Previously:
Airbnb Switching Away From React Native.
Advertising Android Business Catalyst (Marzipan) Facebook Google iOS iOS 12 Mac React Native Web
