Archive for July 15, 2024

Monday, July 15, 2024

UTM SE Now in the App Store

Wes Davis (Hacker News, MacRumors):

Apple has approved UTM SE, an app for emulating a computer to run classic software and games, weeks after the company rejected it and barred it from being notarized for third-party app stores in the European Union. The app is now available for free for iOS, iPadOS, and visionOS.

After Apple rejected the app in June, the developer said it wasn’t going to keep trying because the app was “a subpar experience.” Today, UTM thanked the AltStore team for helping it and credited another developer “whose QEMU TCTI implementation was pivotal for this JIT-less build.”

Craig Grannell:

OK, now this is completely incoherent. UTM is on the App Store itself (not a third-party store), but iDOS isn’t. I hope the iDOS dev resubmits and points at UTM.

Apple looks ridiculous with all this app review stuff. Like it has no idea what it’s doing, what’s OK and what’s not OK. That might have been acceptable in 2008 when it was figuring things out. But not in 2024.

Jorge Salvador Caffarena:

Apple saw that they were going to be forced to notarize UTM for the EU alternative stores, AltStore, and as with Delta figured is better to allow it on the official App Store to undermine AltStore. That’s what’s happening over and over.

Riley Testut:

Thanks Apple for once again proving the best way to change the App Store rules is to submit an app to AltStore :)

Craig Grannell:

App Store review is inconsistent at the best of times, but the situation with emulation is now beyond absurd. The MAME4iOS dev says their app has been rejected multiple times for ‘spam’.

[…]

But who’s to say Apple won’t change its mind next week, depending on what it thinks it can get away with? And I do wonder what will happen if someone dares to submit an Apple II or Mac emulator for review. Perhaps they should submit it to AltStore first – that at least appears to make Apple rethink.

[…]

And Apple’s ridiculous review stance means great devs won’t bother making emulators for iPhone and iPad. Why would they? Why spend months polishing an emulator only for Apple to arbitrarily decide to reject it? (And, yes, this is the wider App Store in microcosm. Creators of other apps and games increasingly feel the same way.)

Rui Carmo:

I’m really sad Apple still forbids shipping apps with a JIT, but we are so close to having a usable Linux sandbox on an iPad that I will take whatever I can get.

Rui Carmo:

I spent a few hours trying out UTM SE (which, if you’re new here, is a just-released version of the UTM front-end for QEMU that runs on iOS) on my M1 iPad Pro, and quickly came to the conclusion that it is not really usable to do local development out of the box.

It might be great to, say, run Windows 95 or older DOS games (and I’m still sore that the Mac OS 9.2.1 image vanished), but unlike the “real” UTM, using UTM SE on iOS or an iPad is severely hobbled by the lack of a JIT.

Previously:

Update (2024-08-08): Craig Grannell:

MAME4iOS rejected for “spam” yet again, and App Store cannot explain how the folks behind it can move beyond what’s clearly an automated bottleneck.

Stack Overflow Changes Data Dump Process

Philippe (via Hacker News):

I’m going to start with an important statement: this is primarily only a change in location for where the data dump is accessed. Moving forward, we’ll be providing the data dump from a section of the site user profile on a Stack Exchange profile.

There are a number of reasons for this: first, this is an attempt to put commercial pressure on LLM manufacturers to join us and our existing partners in the “socially responsible AI“ usage that we’re advocating for - to get them to give back to the communities whose data they consume.

Second, we want to help make the process of accessing data dumps quicker and more efficient. While Archive.org has been a great partner to us, as you may know, both internally and externally, people have encountered challenges with uploading and downloading the dumps with any reasonable speed.

[…]

We are requiring that all partners in socially responsible AI comply with the CC BY-SA attribution requirements, attributing content to the community members who contributed it.

They will no longer be uploading the data dump to archive.org, reducing redundancy.

Shog9:

At best, this is extremely inconvenient; at worst, it guarantees no one will ever again have a consistent “dump”.

I’m going to guess: no one involved in making this decision has ever downloaded and worked with the full data dump. It’s already slow and fairly inconvenient; the one bright spot is that a decent torrent client lets you start it and do other stuff while waiting. Best-case, you devote a fast enough pipe to this that the hundreds of extra clicks necessary are rewarded with shorter turnaround… But somehow, I doubt it.

Restore The Data Dumps Again:

You have been engaging on this topic disingenuously for a year.

It was your intention to turn off the dumps a year ago, and now you're trying to make them as inconvenient as possible.

Andras Deak:

You are making it very easy to pull access to our own content that brings you profit. Even if we trusted the company now, this would make it not just possible, but trivial, for some future nefarious company leadership to backstab the community. And guess what: we already have the nefarious company leadership in the present.

AMtwo:

Just over a year ago when I was still staff at the company, I was personally in the unenviable position of having been instructed by the Stack Overflow CEO to disable the Data Dump, and to not re-enable it because he wanted to end the dump. That decision ultimately snowballed until Stack Overflow made commitments to continue the data dump quarterly. Data Superstar Aaron ultimately made some improvements and there was a shift made to the delivery schedule, to make it align better with quarterly boundaries. This is all excellent news for those of us who use the data dumps, and/or are proponents for equal data, and/or are defenders of the open data commitments made by and for the community.

Now, just one quarter after the company’s most recent commitment to a schedule, it’s shifting, again. For no reason. Apparently undoing the most recent schedule-shift by bumping (at least) a month.

goldPseudo:

How do you plan to enforce “I agree that I will use this file for non-commercial use. I will not use it for any other purpose, and I will not transfer it to others without permission from Stack Overflow.” when the CC BY-SA license explicitly forbids adding downstream restrictions?

Previously:

Midnight HomePod mini

Joe Rossignol:

Apple today announced that the existing HomePod mini is now available in a Midnight color option, which replaces the nearly-identical Space Gray color previously offered.

[…]

Apple first released the HomePod mini in November 2020, and it has yet to release a second-generation model of the speaker.

Caveat emptor:

Previously:

Update (2024-07-15): John Gruber:

The bigger question: is this a sign that a HomePod Mini gen 2 isn’t coming soon? The current models debuted in November 2020, and are powered by the S5 chip from Apple Watch Series 5.

[…]

Makes me wonder if Apple produced a bunch of space gray HomePod Minis all at once, when the product debuted, and has been waiting for them to sell out before switching to midnight.

NSCopying in a Swift World

Douglas Hill:

This crash happens because, behind the scenes, the Swift compiler synthesises overrides of a superclass’s designated initialisers. These overridden initialisers crash to prevent objects from being incorrectly initialised from Objective-C.

[…]

From a quick look on Stack Overflow, it seems [self.class alloc] is often a recommended way to create a copy in Objective-C. However, the problem is that the use of self.class dynamically looks up the subclass SocialDocument, but the code here in our framework has no idea that SocialDocument has changed the initialisation requirements.

[…]

If Document were a simpler type where all state that should be copied was public, then subclasses that required copying to create instances of the subclass could override copy(with:) without calling super[…]

[…]

There isn’t a nice way to make copying subclasses work while still adhering to Swift’s principle of reducing the amount of mutable state by using let to create read-only properties.

Adrian Kashivskyy:

PSA: Don’t cast values to NSCopying in Swift or you risk a crash at runtime. Learned this the hard way. 🤠

[…]

Because all values that were originally bridged from Objective-C will pass the alone NSCopying cast, even when they don’t actually conform to the protocol. Such values immediately become instances of _SwiftValue and, like trojans, they will sit there pretending to be innocent but will crash at runtime as soon as they’re accessed.

Previously:

Sequoia Beta 3 VMs Don’t Support Mac App Store

Howard Oakley:

The third developer beta of macOS 15 Sequoia finally brings support for Apple ID in macOS virtual machines (VM). As this is likely to form the first public beta-release next week, here’s a short guide to how to install a Sequoia VM, and what you can do with it.

[…]

Apple has previously stated that Sequoia “supports access to iCloud accounts and resources when running macOS in a virtual machine (VM) on Apple silicon”. However, that currently doesn’t include access to the App Store or use of apps purchased from it.

Howard Oakley:

With issues of virtualising what was needed from the host’s Secure Enclave apparently solved, some of us had come to expect that would include App Store access, which is also controlled by Apple ID. It’s now clear that Apple didn’t intend to include its App Store as a “related application”, which was implicitly excluded.

However little you might love the App Store, support in macOS VMs is essential if they are to be of any general use. VMs that can’t run all App Store apps as part of the benefits of signing in with an Apple ID are so stunted as to be of little use. Would it be that difficult to implement, now that those VMs can be signed in to all the other services that depend on an Apple ID? Did Apple really forget its own App Store when deciding what apps should be allowed to run in a VM?

Previously:

Update (2024-07-17): Howard Oakley:

If you are beta-testing macOS 15 Sequoia in a lightweight virtual machine on an Apple silicon Mac, beware that it can cause the host to suffer a kernel panic.

[…]

In Sonoma and earlier VMs, if you give the guest 16 GB of memory, it’s likely to use considerably less than that. Those betas of Sequoia will probably use a little more than is allocated to them. But that will double if you restart the VM, and if your host Mac has insufficient memory for twice that VM’s original allocation, it’s likely to suffer a kernel panic with the VM still open.

Update (2024-07-25): Matthias Gansrigler:

I read somewhere that when running macOS Sequoia in a virtual machine, I can log into my Apple account. But that does not seem to be available for Feedback Assistant, or is it? I still get the same error I used to when virtualizing earlier versions of macOS.

Previously:

Sequoia Finally Addresses Notification Center Privacy

Arin Waichulis:

The privacy implications of Notification Center popups are well-known in the security forensics community. Whether a user likes it or not, macOS temporarily keeps a log of every notification received in a single plaintext database. This can include messages from applications like iMessage, Slack, Teams, and virtually anything else.

However, it now appears Apple has moved the Notification Center database in macOS Sequoia to address concerns.

They’re moving it from the temporary items folder to a group container, which will be protected by TCC.

Previously:

Copyright © 2000–2024 Michael Tsai.