Archive for March 6, 2024

Wednesday, March 6, 2024

Apple Terminates Epic Games’ Developer Account Again

Epic Games (Hacker News):

We recently announced that Apple approved our Epic Games Sweden AB developer account. We intended to use that account to bring the Epic Games Store and Fortnite to iOS devices in Europe thanks to the Digital Markets Act (DMA). To our surprise, Apple has terminated that account and now we cannot develop the Epic Games Store for iOS. This is a serious violation of the DMA and shows Apple has no intention of allowing true competition on iOS devices.

[…]

Apple said one of the reasons they terminated our developer account only a few weeks after approving it was because we publicly criticized their proposed DMA compliance plan. Apple cited this X post from this thread written by Tim Sweeney. Apple is retaliating against Epic for speaking out against Apple’s unfair and illegal practices, just as they’ve done to other developers time and time again.

Phil Schiller:

We welcome all developers to the Developer Program so long as they follow the rules. Those rules, including the DPLA and the App Store Review Guidelines, are intended to protect the integrity of the ecosystem, developers large and small, and - most importantly-users. Accordingly, developers who are unable or unwilling to keep their promises can’t continue to participate in the Developer Program.

In the past, Epic has entered into agreements with Apple and then broken them. For example, you testified that Epic Games, Inc. entered into the Developer Program with full understanding of its terms, and then chose to intentionally breach the agreement with Apple. You also testified that Epic deliberately violated Apple’s rules, to make a point and for financial gain. More recently, you have described our DMA compliance plan as “hot garbage,” a “horror show,” and a “devious new instance of Malicious Compliance.” And you have complained about what you called “Junk Fees” and “Apple taxes.”

Your colorful criticism of our DMA compliance plan, coupled with Epic’s past practice of intentionally violating contractual provisions with which it disagrees, strongly suggest that Epic Sweden does not intend to follow the rules. Another intentional breach could threaten the integrity of the iOS platform, as well as the security and privacy of users.

You have stated that allowing enrollment of Epic Games Sweden in the Developer Program is “a good faith move by Apple.” We invite you to provide us with written assurance that you are also acting in good faith, and that Epic Games Sweden will, despite your public actions and rhetoric, honor all of its commitments. In plain, unqualified terms, please tell us why we should trust Epic this time.

Tim Sweeney:

Epic and its subsidiaries are acting in good faith and will comply with all terms of current and future agreements with Apple, and we’ll be glad to provide Apple with any specific further assurances on the topic that you’d like.

Mark A. Perry:

Apple recently reached out directly to Mr. Sweeney to give him an opportunity to explain why Apple should trust Epic this time and allow Epic Games Sweden AB to become an active developer.

Mr. Sweeney’s response to that request was wholly insufficient and not credible. It boiled down to an unsupported “trust us.” History shows, however, that Epic is verifiably untrustworthy, hence the request for meaningful commitments.

[…]

Given the past and current conduct of Epic, Apple cannot allow Epic Games Sweden AB to be part of its ecosystem.

Please be advised that Apple has, effective immediately, terminated the Developer Program membership of Epic Games Sweden AB.

This is now the second time Apple has said they would let Epic have their account back if they agreed to follow the rules, Epic agreed, and Apple reneged, saying it didn’t believe Epic. In this case, it seems like Apple ignored Sweeney’s offer to provide “specific further assurances,” so unless there are key parts of the communication omitted it seems like Apple’s offer was not made in good faith. There is nothing in the rules saying that you can’t criticize Apple.

Joe Rossignol:

Apple shared the following statement with MacRumors:

Epic’s egregious breach of its contractual obligations to Apple led courts to determine that Apple has the right to terminate “any or all of Epic Games’ wholly owned subsidiaries, affiliates, and/or other entities under Epic Games’ control at any time and at Apple’s sole discretion.” In light of Epic’s past and ongoing behavior, Apple chose to exercise that right.

Zac Hall:

In short, Apple is leaning on a court ruling from 2021 that upholds its ability to terminate developer accounts that violate its guidelines. That’s the legal basis for which Apple is relying upon globally — not just in the EU. As recently as last month, Epic Games accepted existing rules of the Apple Developer Program like all other developers.

Note that this ruling was in the US, and the Swedish account had not violated the guidelines.

Michael Love:

If Apple doesn’t want to have to have a business relationship with Epic, a great way to achieve that would be to do what every other platform maker has done for decades, and allow companies to distribute apps without going through Apple.

But if you insist that everything go through you then you’re obligated to treat everyone equally, even those that criticize you.

Steve Troughton-Smith:

Putting Phil Schiller in charge of the App Store is going to be a hundred billion dollar mistake that all-told leaves Apple with a pile of legal, perhaps criminal, liability and a raft of draconian regulations around the world that massively compromise the iOS experience. This was clear years ago; it is unimaginable that he’s still calling the shots.

Previously:

Update (2024-03-07): Kyle Orland:

Apple told Ars that Epic Games Sweden’s access to a developer account was granted through a “click through” agreement that was not evaluated by Apple management. Now that Apple management is aware of that approval, the company says it has terminated that agreement following the same logic that led the company to deny a 2021 request by Epic for reinstatement to the iOS developer program.

Gergely Orosz:

Dare criticize Apple and they can (and, sometimes, will!) remove you from their platform as a developer. They just did this w Epic!

I cannot remember even Microsoft being this much of a bully back in the 90s.

Apple became the very thing they fought against in 1984.

Gergely Orosz:

Apple’s explanation: Epic broke rules before. Apple gave back Epic’s dev account. But then Sweeney tweeted something. So now they are taking it back.

This is the type of reasoning I see children apply. Waiting for when the adult steps in (aka regulator).

Steve Troughton-Smith:

“But Epic broke the rules” is not a defense of Apple’s behavior. As per the EC, Apple’s developer agreement contains clauses that are now and always have been illegal. Epic ‘broke’ the terms of an illegal contract in order to, among other things, test its legality in court and in regulation. We have our answer now: Apple’s terms were illegal. Epic was right to break them. I care nothing for how much money Epic makes, how its leadership tweets, or how Epic’s deals with console makers are worded.

We are all, as developers, signed up to and subject to Apple’s illegal agreement, to the detriment of us, our families, our products and our users. And almost none of us have the resources to challenge any part of that developer agreement without risking all of the above.

Peter van Broekhoven:

Seems more like, “But Epic might break the rules in the future.”

Which is bonkers. Did we stumble into the Minority Report universe? Wait until they do, then react.

Damien Petrilli:

Apple leadership is so untrustworthy that I am starting to think that making native App is dangerous.

If Apple can kill your business for a tweet, they went from mafia level to dictatorship level.

George Broussard:

It’s clear that Apple’s actions against Epic are punitive and meant to make an example of Epic. Apple moves from benevolent overlord to Tyrant. By stepping on Epic, Apple is saying “You could be next. You will be next.” therefore silencing developers and any form of dissent.

Agence France Presse (MacRumors, Hacker News):

Apple must explain its decision to halt Epic Games’ effort to develop a competing app store for its devices, EU regulators said Thursday, as they consider whether the iPhone-maker violated any laws.

[…]

The spokesperson for the commission said it was “also evaluating whether Apple’s actions raise doubts on their compliance” with two other EU laws regulating digital players.

[…]

Apple compliance with the DSA -- a content moderation law -- means any decisions to suspend or terminate accounts must be “proportionate and in due regard to fundamental rights,” the spokesperson said.

James Thomson:

Can I simultaneously think that Epic are a bunch of chancers, while also really disliking Apple’s handling of them? Yes.

John Gruber (Mastodon):

That Tim Sweeney tweet cited as an example doesn’t seem out of line to me. It’s strident, to be sure, but we know Sweeney endorses a regulatory structure that would legally require Apple to treat the iPhone as a platform more or less as open as the Mac. We know Apple disagrees, vehemently, with that — but I don’t see how stating that viewpoint ought to disqualify Epic from obtaining a developer account.

[…]

Citing recent tweets, like Sweeney’s, that are simply critical — even scathingly critical (or to borrow Schiller’s term, “colorful”) — just makes it look like Apple’s policy is that if a developer criticizes the App Store’s rules, Apple will punish them for speaking out. I don’t think that’s Apple’s policy at all, but some people think it is, and this situation with Epic just reinforces that.

[…]

But why not take an opportunity to look magnanimous? Apple shouldn’t be expected to grovel, but this looks like they’re going out of their way to look vindictive. I really thought it would be a clever bit of public relations jujitsu to make nice with Epic, even if, in Cupertino, it was through gritted teeth.

Francisco Tolmasky:

Something missing in the Apple vs. Epic discourse is the actual customer perspective. I’m sure you don’t play Fortnite (I don’t either), but apparently it’s… pretty popular. So what matters really isn’t whether you’d “also tell them to fuck off,” but whether you want an ecosystem where what seem to be increasingly personal disputes result in products not appearing in markets. I don’t want to not be able to use Procreate if they get into a fight with Apple, regardless of who’s “right.”

Update (2024-03-08): See also: Accidental Tech Podcast.

Zac Hall (Hacker News):

After a whirlwind of events, Epic Games says Apple has reinstated their App Store developer account. The move clears the way for Epic to bring its Epic Games Store to the EU, avoiding the App Store structure altogether.

Dan Moren:

Apple, for its part, issued a terse statement, saying only, “Following conversations with Epic, they have committed to follow the rules, including our DMA policies. As a result, Epic Sweden AB has been permitted to re-sign the developer agreement and accepted into the Apple Developer Program.”

Khaos Tian:

Yeah it definitely has nothing to do with the Commission’s inquiry 😛

John Gruber (Mastodon):

Theory B: Apple is flailing erratically trying to deal with their loss of autonomy.

I vote B, because to me the real win for Apple would have been just let Epic use their Swedish subsidiary to open an iOS games store without the back-and-forth. If Apple had gone that route, the European Commission could still have taken credit for proof of the DMA’s effectiveness, and Apple would look like they’re complying graciously with the law. But the way things actually played out makes clear they’re complying begrudgingly, and, worse, plays into the worst assumptions about Apple’s institutional arrogance and vindictiveness.

[…]

How was a “priority” investigation by the EC not going to happen the way Apple played this? If Apple had just let Epic proceed from the start, they’d have looked magnanimous. They even had Tim Sweeney calling it “a good faith move”. But as it stands, Apple looks bitter, and from the EC’s perspective, in need of close policing.

Steve Troughton-Smith:

Apple’s reversal on the Epic situation is all well and good, but it doesn’t prevent this kind of thing from happening again to a smaller developer who doesn’t have a ton of PR or the ear of the EC. And it does highlight that Apple still has all the control to do whatever it wants, with little oversight, under its proposed DMA plan. They have forcibly inserted themselves in between third party app stores/payment providers and those services’ users, free to turn the screws as they wish

Update (2024-03-14): Tim Sweeney:

There weren’t any other communications on the topic between Epic and Apple either directly or thru counsel during this episode, nor between then and when Apple notified the commission they were relenting.

John Gruber:

Per Sweeney, responding to a question from me tonight on Twitter/X, that was Friday, February 9, and their account was approved on the following Monday, February 12. Epic made their public announcement that they intended to create an Epic Games Store for iOS in the EU on Friday, February 16.

That announcement, seemingly, was in fact the first time Epic’s plans came to the attention of Apple’s leadership.

[…]

The “colorful” tweets Schiller quoted and which Apple’s attorney cited were mentioned as proof that Epic hadn’t changed, not as the reason for revoking the new account.

[…]

The bottom line remains as I concluded Friday: Apple played this whole thing terribly. The automated developer program enrollment form — the one that gave Epic the impression they’d been granted express permission to proceed with building an iOS marketplace for the EU — is Apple’s. The whole App Store bureaucracy is Apple’s. (Or as Sweeney aptly called it tonight, “Apple’s App DMV”.)

Update (2024-03-17): Francisco Tolmasky:

So let me get this straight, Apple, the company that “simply didn’t realize Epic had made a new account,” is supposed to keep us safe on the AppStore?… Apple’s not even trying to pretend to be the vigilant protector of the end user anymore, huh? Once again proving that the AppStore is as “curated” and “safe” as a strip mall dollar store.

ToothFairy 2.8.4

ToothFairy 2.8.4 is a maintenance update of my Bluetooth menu bar utility. The focus is on better handling of a variety of edge cases to improve the battery level, sound quality, and connection features. The macOS Bluetooth APIs don’t always correctly connect a device (e.g. may not update the sound output device), so ToothFairy will detect this and try to fix things for you. Sometimes this can take a while, and this version improves the way the app works during the fixing process. Also, you’ve long been able to set ToothFairy to run a script when a device is connected or disconnected, and the documentation now includes an example of how you can use this to run a shortcut, so you can automate things without writing any code.

HP All-In Plan

Scharon Harding:

HP launched a subscription service today that rents people a printer, allots them a specific amount of printed pages, and sends them ink for a monthly fee. HP is framing its service as a way to simplify printing for families and small businesses, but the deal also comes with monitoring and a years-long commitment.

[…]

But HP enforces an Internet connection by having its TOS also state that HP may disrupt the service—and continue to charge you for it—if your printer is not online.

The All-In-Plan privacy policy also says that HP may “transfer information about you to advertising partners” so that they can “recognize your devices,” perform targeted advertising, and, potentially, “combine information about you with information from other companies in data sharing cooperatives” that HP participates in. The policy says that users can opt out of sharing personal data.

Wes Davis (Hacker News):

Which printer you get depends on the plan you choose. They start at $6.99 per month for 20 pages’ worth of prints and whatever the current HP Envy model is, and go all the way up to a $35.99-a-month affair that gets you an OfficeJet Pro and 700 pages. If you go over your page allotment, HP will add more for a dollar per block of 10–15 pages.

[…]

The subscription, like HP’s recent ad campaign promoting its printers as “made to be less hated,” trades on the idea that printers are frustrating commodities. The company’s configurator page mentions bonuses like “continuous printer coverage” and “next-business-day printer replacement,” for instance. That way, if a firmware upgrade blue-screens your printer, at least you have some recourse that doesn’t involve driving to a store to buy a whole new one.

Previously:

Update (2024-03-07): Karl Bode (Hacker News):

Paying for the same several-hundred dollar printer for all eternity is precisely the sort of concept Lores has been pushing for a while. The problem is it’s not clear that anybody actually wants this. It’s also not really clear that paying up to $36 for a printer you never really own makes much value sense. Printers inherently aren’t that expensive. And ink isn’t either, if companies aren’t being restrictive tyrants.

[…]

Once they’ve established renting a printer as a norm, they’ll just steadily jack the rental price skyward as they make the underlying value proposition steadily worse. Ultimately the business becomes less and less about making popular quality products, and more and more about making unnecessarily convoluted subscriptions with creative restrictions and ever-skyrocketing monthly prices.

Update (2024-03-25): Wendigoon8 (2022):

Our HP printer hasn’t been working for a month and every manner of troubleshooting, resets, changing ink cartridges, didn’t seem to work. After calling HP, they said the debit card on file had expired so they manually disabled our printer.

Swift 5.10

Holly Borla (Mastodon):

Swift 5.10 accomplishes full data isolation in the concurrency language model. This important milestone has taken years of active development over many releases. The concurrency model was introduced in Swift 5.5 including async/await, actors, and structured concurrency. Swift 5.7 introduced Sendable as the fundamental concept for thread-safe types whose values can be shared across arbitrary concurrent contexts without introducing a risk of data races. And now, in Swift 5.10, full data isolation is enforced at compile time in all areas of the language when the complete concurrency checking option is enabled.

Full data isolation in Swift 5.10 sets the stage for the next major release, Swift 6. The Swift 6.0 compiler will offer a new, opt-in Swift 6 language mode that will enforce full data isolation by default, and we will embark upon the transition to eliminate data races across all software written in Swift.

[…]

When building code with the compiler flag -strict-concurrency=complete, Swift 5.10 will diagnose the potential for data races at compile time except where an explicit unsafe opt-out, such as nonisolated(unsafe) or @unchecked Sendable, is used.

[…]

Previously:

Update (2024-03-07): Rob Jonson:

Swift 5.10 with full concurrency checking warns for most of the @MainActor failures I have found in the past.

But you can still accidentally call a @MainActor function from a background thread if you use ObjectiveC or Framework code like Notifications.

Jesse Squires:

Swift classes with isolation annotations behave differently when inheriting from an ObjC superclass.

Donny Wals:

With Swift 5.10, Apple has managed to close some large gaps that existed in Swift Concurrency’s data safety features. In short, this means that the compiler will be able to catch more possible thread safety issue by enforcing actor isolation and Sendability in more places.

Let’s take a look at the two features that make this possible.

Wade Tregaskis:

I really wish Swift releases would stop having major regressions in the ability to parse non-trivial expressions. The installation of a new version of Xcode – with a corresponding new Swift version & toolchain – should be a joyous occasion, not one I increasingly dread.

Update (2024-03-08): Rob Napier (Mastodon):

In the following simplified code, we’re getting stuck with MainActor being both forbidden and required. We have a ViewModifier that observes a ObservableObject. Therefore it must be MainActor (and in fact, becomes MainActor automatically due to the ObservedObject wrapper).

However, it is used within a ButtonStyle. ButtonStyle requires a non-isololated makeBody method. But if it’s nonisolated, then it can’t access the ViewModifier. Under “complete” concurrency, the following either generates “Call to main actor-isolated initializer ‘init()’ in a synchronous nonisolated context” or “Main actor-isolated instance method ‘makeBody(configuration:)’ cannot be used to satisfy nonisolated protocol requirement.”

Holly Borla:

Yeah, the recommended way to do this is using MainActor.assumeIsolated.

Xcode 15.3

Apple (direct download):

Xcode 15.3 includes SDKs for iOS 17.4, iPadOS 17.4, tvOS 17.4, watchOS 10.4, macOS Sonoma 14.4, and visionOS 1.1. The Xcode 15.3 release supports on-device debugging in iOS 12 and later, tvOS 12 and later, watchOS 4 and later, and visionOS. Xcode 15.3 requires a Mac running macOS Sonoma 14 or later.

[…]

You can now use API Notes to add attributes to C++ APIs declared in a C++ namespace.

[…]

Schemes provide a new “Override Architectures” build option, which controls the set of architectures that will be built for all targets in the workspace, including Swift packages. The recommended option (and default for new schemes) is “Match Run Destination”. Full details are available by clicking the information icon next to the “Override Architectures” setting on the scheme build options sheet in Xcode.

[…]

If an Objective-C or C++ exception is thrown on a background thread, including those owned by the Swift runtime, it will now be recorded as a test failure before the test process terminates.

Previously:

Update (2024-03-08): Scott Anguish:

Xcode 15.3 seems like a backslide in a bunch of cases.

I’m seeing lots of “Build service could not create build operation: unknown error while handling message: unknownSession(handle: "S0")” failures that require closing and reopening the project.

And Previews in SPMs no longer actually preview (Update Failed)

Jonathan Wight:

Yeah I am getting a ton of random failures ("please try compiling again) with 15.3 too.

Update (2024-03-15): Damien Petrilli:

March 2024 and the replace container feature of Xcode 15 which has been broken since the first beta is still NOT fixed despite being acknowledged by Apple.

Update (2024-03-20): Cesare Forelli:

In GlanceCam for iOS beta, if I start VLCKit playback of a camera in the simulator running iOS 17.4, I consistently get the attached crash.

Xcode 15.2, iOS 17.2 sim -> no crash
Xcode 15.2, iOS 17.4 sim -> 💥

Xcode 15.3, iOS 17.2 sim -> no crash
Xcode 15.3, iOS 17.4 sim -> 💥

Update (2024-03-25): Frank A. Krueger:

Xcode 15.3 broke* a feature I rely on daily** and I really want it fixed.

* Dear Apple devs: asserts are not the right way to do error checking/handling.

** CoreML performance reports

Update (2024-04-12): jayMcBee:

Same bug here with Xcode 15.2/15.3 - app crashing on customer systems with 10.13 and 10.14 due to SwiftUI being referenced.

The app uses AppKit, Obj-C, and Swift. No SwiftUI whatsoever. Referenced nowhere, imported nowhere, nothing in the build log… Still it’s randomly referenced in the binary according to otool -L

The asset symbol workaround appears to work - so far…

I don’t understand why this widely publicized bug that dates back to August isn’t fixed yet.

Update (2024-04-29): Norbert Doerner:

Wow, #Xcode 15.3 and #macOS 14.4.1 are such a weird dumpster fire of strange bugs and problems.

Merging the AppKit and UIKit low-level system frameworks is not going all too well, obviously.

That error message in Xcode is catastrophically ridiculous, really.

It indicates yet another serious bug in Apples own private frameworks.

I have been seeing errors like that for several releases now.

Update (2024-05-07): See also: Der Teilweise.

Scorpius:

After some more testing XCode seems to be gagging on my SVG files now, SVGs had been working well up to 15.3!