Day: 4 November 2019

David Heinemeier Hansson Gives Windows Another Try After Twenty Years ⇥ m.signalvnoise.com

David Heinemeier Hansson has become exasperated with Apple’s four-year laptop keyboard experiment, so he bought one of Microsoft’s third-generation Surface Laptops. He has many positive things to say about it; for example:

The buying experience was great. There was nobody in the store, so with four sales people just standing around, I got immediate attention, and typed away a few quick sentences on the keyboard. It felt good. Nice travel, slim chassis, sleek design. SOLD!

The initial setup experience was another pleasant surprise. The Cortana-narrated process felt like someone from the Xbox team had done the design. Fresh, modern, fun, and reassuring. Apple could take some notes on that.

I accept that there are tradeoffs between ease of setup and full disclosure of user options — counting the number of screens during setup is one way to visualize this — but I wish some of these screens were consolidated on iOS and MacOS alike.

Also, and I’m not sure if this is just nostalgia, but I miss those first run videos in pre-Lion versions of Mac OS X.

Anyway, there are two things I want to touch on from this review:

But ultimately we got to the meat of this experience, and unfortunately the first bite didn’t quite match the sizzle. The font rendering in Windows remains excruciatingly poor to my eyes. It just looks bad. It reminded me of my number one grief with Android back in the 5.0 or whenever days, before someone at Google decided to do font rendering right (these days it’s great!). Ugh.

I accept that this is a personal failure of sorts. The Windows font rendering does not prevent you from using the device. It’s not like you can’t read the text. It’s just that I don’t enjoy it, and I don’t want to. So that was strike one.

For what it’s worth, I use a Windows 10 computer for eight hours a day, Monday through Friday. Windows has never had nice text rendering. I feel like anyone who thinks the antialiasing used in Windows 10 looks nice should, upon the conclusion of their hopefully long and healthy life, donate their eyes to science for further examination. It is both brittle and coarse, and entirely unsatisfying.

One more thing:

[…] Want to run Docker for Windows on your brand new Surface Laptop 3? Sorry, can’t do that without buying an upgrade to Windows Pro (the $1800 Surface Laptop 3 apparently wasn’t expensive enough to warrant that designation, so it ships with the Home edition. Okay, sheesh).

Microsoft’s continued insistence on shipping myriad editions of Windows with different capabilities will never stop being frustrating to me.

Earlier this year, I was trying to open some Premiere projects created by another person in the office and was prompted to update Creative Cloud. I hit the button and was told that the version of Windows 10 on my machine was too old and needed to be updated first. That surprised me because I knew I had installed an update not too long before, and I’m pretty sure the company’s admin policy mandates system updates anyhow. So I looked up the version I was running to find that it was: a) several years old, and b) was an edition of Windows 10 I’d never heard of called “LTSC”.

It turns out that there are more than just “Home” and “Professional” versions of Windows 10 — there are, like, a dozen. LTSC stands for “Long-Term Servicing Channel”. As far as I can tell, it’s an edition of Windows 10 that’s supposed to be used in instances where it’s critical that no features get updated, but proven security patches are installed, so it’s used in places like digital signage, ATMs, vending machines, and medical applications. And there’s no upgrade path for LTSC to a mainstream version of Windows 10 aside from a clean install.

This is all a very long way of saying that the myriad editions of Windows 10 remain confusing and silly to me.

Apps Built With Electron 6 and 7 Are Currently Being Rejected From the Mac App Store ⇥ david.dev

“David Dev” (sic):

Allright, as a follow up to the previous chapter in this odyssey I can now state that, apparently, you cannot submit an electron 6 or 7 app to the apple store:

The first refusal from apple states:

Your app app links against the following non-public framework(s):

CAContext

CALayerHost

NSAccessibilityRemoteUIElement

NSNextStepFrame

NSThemeFrame

NSURLFileTypeMappings

I am not the only one having this issue and I did write back to Apple trying to explain that I am using Electron and I can’t really change any of these public-framework usage (I assume is something from Chromium) […]

I’m seeing a lot of anger directed at Apple over this, including accusations of monopoly practices and allegations that this is some sort of plot to neuter computing except for the ways in which Apple says you can use your Mac. This is ridiculous. These apps are being rejected from the Mac App Store, but can be distributed elsewhere; the Mac is not a closed platform. I get why this is frustrating: the lack of communication by Apple when changes are made to the App Review process may come as a surprise, and Electron is a popular framework upon which entire apps rest, so changing it would require a lot of work.

If anything, though, the main culprit here is whichever part of Electron — either Electron itself, or Chromium, upon which it is based — decided to use private APIs in the app. Apple has been wildly inconsistent with many aspects of its App Stores, but on private APIs the company has stood firm: they may not be used. It would have been useful for Apple to announce this change if it knew the revised App Review process would prevent Electron apps from being accepted into the Mac App Store, but it is by no means a death sentence for these apps, nor is it their responsibility to ensure that every intermediate app layer made by a third-party is compliant.

Update: Michael Tsai:

So there are a multiple problems here:

  1. It’s (apparently) impossible for Chromium to get competitive performance and battery life without using private API, which Safari freely uses.

  2. Apple probably has good reasons for keeping these APIs private.

  3. Private API has always been banned, but Apple has been accepting these apps for years and then abruptly stopped without any notice.

  4. Apps using Electron probably didn’t know that they were even using private API. Neither Xcode nor Application Loader reports this, and App Review was accepting the apps.

  5. The rule is not being enforced equally.

The first point is relevant, but does not make a difference in whether the apps should be approved, hence Tsai’s second point. The third and fifth points are yet another entry in Apple’s biggest problem with the App Review process, which is its inconsistency and opacity.

But the fourth argument here is critical: private APIs are risky to use in any case, but it’s absurd to use them in a software platform. In this case, it’s layers of dependencies failing developers: apps are built on top of Electron, which is built on Chromium, which uses private APIs to help its atrocious battery and CPU consumption. It isn’t as though Slack — to use a notorious example — actually needs a 200 MB app to run its glorified IRC client.