skrrtww

It's a treasure. I understand why most people don't do this, but I will probably forever.

A really significant amount of it isn't otherwise available on streaming services. While I'm an Apple Music subscriber, I still acquire my own mp3s for most of the new music I listen to.

iCloud Music Library is an immense value here as well. Rarely it will sync the wrong version of something in my library, but usually it's on the money. The fact that it doesn't cost anything extra on top of an Apple Music subscription is a huge boon, and it doesn't count against my iCloud data either.

In Chrome I get "Failed to start: Failed to create State. Caused by: failed to find GPU adapter."

So I guess it runs on "some" GPUs, in "some" browsers!

edit: According to the author in a reply, the double entendre was in fact not intentional.

I have heard stories of people in 2025 creating a fat macOS binary containing arm64, x86_64, x86, and ppc slices.

I hope that we can get virtualization of x86_64 macOS on arm64 hosts. It would be really cool to be able to do such a thing solely on a modern machine!

More context on how this value affects (at least one) DS game- see post from December 27th, 2019.

Any material use of ScreenCaptureKit that doesn't involve that content sharing picker specifically will trigger this prompt. That means asking for SCShareableContent, or a couple other generic uses I forget.

The prompt is also not even tied to the application bundle's code signature; tampering with the signature will not re-trigger the prompt. Nor will the prompt be re-triggered even if the application's entire bundle ID (com.example.example) changes.

No; the only way to re-trigger this prompt for an application is to rename the app bundle itself. That's right. Renaming Test.app to Test-dumb.app will trigger the prompt when nothing else will.

This isn't really worth criticizing that much because the prompt I think is designed as purely like a "don't forget about this" type of measure, and not one tied into actual security. But also that speaks greatly to the design challenges facing the TCC system more broadly, that this type of thing is seen as necessary.

> You can use a copyable anywhere you’d use a non-copyable since there is no restriction.

Effectively copyable always conforms to non-copyable, just not the other way around.

And the compiler effectively automatically notates literally everything with Copyable, so you need the explicit (& ~Copyable) in the function definition so you're still able to define functions within a ~Copyable protocol that have Copyable semantics.

It's very in the weeds, and I still don't like it (I would have preferred NotCopyable since the ~, especially next to the &, directly implies something like bitwise operators), but I guess custom ownership is itself very in the weeds and you will have to think about it hard no matter what approach is taken. I would have expected custom ownership to be fundamentally incompatible with Swift, but clearly it's here; I should probably read about it more so I have a more clear understanding.

(I also didn't realize & was extant syntax).

The provided `drinkable` example I think is pretty bad and it's very surprising to me that this is a headline feature.

  protocol Drinkable: ~Copyable {
    consuming func use()
  }

  struct Coffee: Drinkable, ~Copyable { /\* ... */ }
  struct Water: Drinkable { /* ... \*/ }

  func drink(item: consuming some Drinkable & ~Copyable) {
    item.use()
  }

  drink(item: Coffee())
  drink(item: Water())

The syntax for representing this complex and weird concept of "maybe consuming" being `consuming some Drinkable & ~Copyable` is also just totally gross. Why are we using bitwise operation syntax for some weird and logically incoherent kludge? We cannot apply these & and ~ operators indiscriminately, and they do not mean the same thing that they logically mean in any other context, but this function definition definitely implies that they do.

I also wish people would post the FB numbers and the details of their report when they say they've reported things like this.

This is the case for building and running things with restricted entitlements and system extensions.

Unless you disable system integrity protection entirely, which locks you out of your purchased App Store software, DRM content, etc.

It does not. All it does is what it says on the tin- open System Settings.

In a vacuum, I don't consider this to be an extremely poor decision; the system picker has a mostly-sane interface. Apps that capture the screen currently have an extremely long leash, and the hole for an app that decided to become malicious and start (for example) exfiltrating capture data is... extremely wide.

However, for apps that took pains prior to macOS Sequoia in offering a reasonable and privacy-focused consent interface for screen capture (that doesn't use the picker, that is), this prompt is insulting and a slap in the face. Apple did not do a good job with its developers with the introduction of this 'feature'.

Furthermore, the system picker lacks important functionality (can't capture apps without currently visible windows, can't do 'everything-except-these-apps' captures) and its configurations have no time-to-live, meaning an app would have to use the picker every single time it starts up, or else get this prompt. This really undermines the picker and the prompt's effectiveness, and it's disappointing to see something well-intentioned be self-defeating in this way.

In general, ScreenCaptureKit is one of the most poorly managed and poorly functioning APIs Apple has introduced in recent years. It offers solid functionality, but every release introduces a legion of new bugs and performance regressions. I dunno if someone key to this APIs success quit or what, but it really needs to be fixed up by someone with actual care for the details.

I had about 50GB free on my (1 TB M1 Max) machine at the time of the update, and the App Store told me I didn't have enough free space to update. I balked and looked at the update description, which was just "Various minor bug fixes." The update size was...75 GB. They expect me to re-download the entire game for various minor bug fixes.

(I would "just blame the developer" here, but Apple clearly invested a lot into having this game available on macOS, in the App Store, and got Hideo Kojima to show up at WWDC (a full year ago, remember) and brag about how nice the entire experience is. Some of Apple's engineers probably worked directly on this port.)

It then sunk in that I didn't just need 75 GB of free space. I needed 150 GB. The App Store will completely download and completely decompress the entire game before replacing it. That is the patching process for the game. You need 231 GB free at all times on your machine to have and update a 77GB game.

This is completely insulting given Apple's storage prices, and the fact that the App Store does not let you install apps on an external drive.

Apple clearly doesn't get it. They act like they're nominally putting in the effort, but then it's still just completely half-assed even when things are played exactly like they want.

The goal of N64 emulators (generally) is to accurately recreate the behavior of the original console.

Conversely, there is a large crowd of people who just want to play SM64, OOT and MM with a bevy of "graphical enhancements" like 60fps, widescreen, texture packs, randomizers, etc.

For these people, the fact that these games originally ran on the N64 is practically irrelevant. In fact, it's a hindrance; The N64's graphical pipeline is cumbersome to emulate and actively stands in the way of modern 'enhancements.'

This project is more aimed at giving the games themselves modern treatments, removing the N64-centric aspects of the games from the equation entirely.

There are also inconsistent stutters throughout songs.

iPhone 13 and 2nd gen AirPods Pro, if it's relevant.

I've filed a feedback but Apple feedback is a black hole these days.

Method swizzling is also an important tool for any aspiring macOS developer, unavailable/onerously painful in Swift.

All in all, I don't think there's anything wrong with continuing to write new things in modern Obj-C as long as you're conscious of the tradeoffs and interoperability is a concern.

The rule of thumb is generally that for Windows games pre-2008ish, Parallels is a better choice, since they tend to rely on weird corners of Windows compatibility and 32-bit performance in Wine is still not always great. DXVK + MoltenVK is generally the best choice for anything post-2000s, pre-DX11, and GPT/D3DM is generally the best choice for anything DX11/DX12.

edit: Here it is. This looks like a good place to work from: https://github.com/MacSourcePorts/xash3d-fwgs

Looks like the main annoyance is no resolution scaling; the game always renders at the size of the window, which at high pixel densities is a problem for the text rendering (it's tiny). Should be solvable for someone motivated though.

Side note, I think HL2 does for physics, or something; fast moving objects and explosions cause drastic frame drops via Rosetta. I haven't been able to look into it in detail to confirm the cause.

Edit: The best "official" way to play Half-Life on an Apple Silicon machine is through Parallels, which uses WoW64's x87 translation instead of Rosetta. I've also heard you can compile Half-Life yourself using the leaked Source Engine code, but I haven't tried it myself.

Don't get me wrong, I'm very happy with my 16" Max display, but the dimming zones are quite visible, especially with poorly brightness-mastered content (some of which is on Apple TV+!).

I can't watch the whole event, but the continued complete lack of marketing toward gamers I must say is also a bit disappointing. You have these fancy GPUs, Apple; go for the jugular!