Archive for September 8, 2020

Tuesday, September 8, 2020

Screen Recording in Big Sur Requires Admin Account

Nathaniel Strauss (tweet):

Two months into the beta cycle, Big Sur is still not education ready. Today marks the release of beta 5 and Apple has not implemented a way for standard users to enable screen recording. As a result they can’t share their screen with common video conferencing solutions like Webex, Zoom, Google Meet, and others. Imagine an online class where the teacher isn’t able to display a presentation or a student can’t show their work. During the largest shift to remote learning ever, that’s the future Apple delivered in beta 1, entirely missing the mark when it comes to how a large majority of their education customers use Macs. Apple has said they have plans to introduce ways for standard users to enable screen sharing, but as of beta 5 that’s not the case.

[…]

[July 22 was] the last time Apple has commented on screen recording access in Big Sur. No response through feedback assistant, enterprise support cases, or other community channels.

[…]

The general wisdom I always hear is filing feedback early in the beta cycle is better. My concern with screen recording in particular is we’ll get a solution in a late beta, it won’t meet the real needs of the user base, and then we’ll be stuck with it. If the solution ships in beta 6, there’s no time to provide feedback to improve the feature before GM. Considering Apple didn’t even realize this was a problem before we filed feedback, I can’t say I’m confident in them developing a solution internally with no feedback from K12 or other education institutions.

I don’t understand what problem Apple is solving by not allowing standard users to consent to record their screen.

Previously:

Update (2020-09-11): Alex Brooks:

I should start an ongoing thread of all the basic things that macOS Catalina makes impossible.

Today’s doozy: Go to present in meeting, cannot share screen in Google Meet because it requires local admin approval. Fab.

Nathaniel Strauss:

Screen recording access can be allowed by a standard user in Catalina. Problem is the setting is mixed in with admin only privileges and so confusing people think they can’t. The design is poorly laid out.

Applebot

Apple (via Hacker News):

Applebot is the web crawler for Apple. Products like Siri and Spotlight Suggestions use Applebot.

Traffic coming from Applebot is identified by its user agent, and reverse DNS shows it in the *.applebot.apple.com domain, originating from the 17.0.0.0 net block.

jd20:

Some fun facts:

  • Applebot was originally written in Go (and uncovered a user agent bug on redirects, revealing it’s Go origins to the world, which Russ Cox fixed the next day).
  • Up until the release of iOS 9, Applebot ran entirely on four Mac Pro’s in an office. Those four Mac Pro’s could crawl close to 1B web pages a day.
  • In it’s first week of existence, it nearly took Apple’s internal DNS servers offline. It was then modified to do it’s own DNS resolution and caching, fond memories…

Previously:

Swift Runtime Heap Objects and Type Layout

Jordan Rose:

The way Swift’s flavor of automatic reference counting works is that destruction of the object happens synchronously when the last reference goes away. So while swift_retain ends after updating the reference count, swift_release has to check to see if the object should be destroyed. If the old reference count representation was 0 (remember, it’s a biased representation), then this release is for the last reference, and it’s time to destroy the object. As mentioned above, this information is stored relative to the class metadata, whose address we get by loading the first field of the object.

[…]

The first field of a closure is a function pointer with a special calling convention: it takes the arguments of the closure as well as an additional argument for accessing any captured bindings (parameters, variables, or constants, or explicitly-specified bindings from a capture list). This additional argument is loaded from the second field, and you can think of it as a sort of “anonymous class” that stores the captures. Passing around a closure means retaining and releasing this “captures object”, and it’s destroyed when the reference count hits 0 like any other object.

Jordan Rose:

So what does Swift do? For now, it just does the simple thing: lay the fields out in order, rounding up to alignment boundaries. (This means you can actually save on memory by carefully ordering your fields, although this probably only matters if you have many many instances of your structs.)

[…]

The “Product” example I showed above was a struct that could be laid out completely at compile time. However, that’s not always possible. If the types of First and Second aren’t known at compile time, it’s up to the runtime to figure it out. […] So not only does the runtime need to do type layout, but now you know why it has to be consistent with how the compiler does it.

Previously:

Update (2020-10-16): Jordan Rose:

In Swift, types are represented by unique pointers to structured data, which can be statically or dynamically allocated. This data has a different representation based on what kind of type we’re talking about, so if we’re not sure what kind of type we have, there are only two fields we can access safely: a kind field at offset 0, and a value witness table pointer just before the start of the type metadata. To get at any other information, we have to check the kind first and then cast to the appropriate type.

Jordan Rose:

This time we’re going to be talking about the caches used to unique type metadata (and other things that need uniquing).

Jordan Rose:

Honestly this tour of class metadata is probably more informative than the runtime functions associated with classes, but we’ll go through those too.

Jordan Rose:

With this, we’ve now seen the entire process of creating and initializing class metadata, just like we did with structs. Of course, in many cases the compiler will be able to do much of this work at compile time, but in case it can’t, the Swift runtime is powerful enough to do it all itself.

See also: Swift Unwrapped.

Update (2020-10-23): Jordan Rose:

There’s one other twist on no-payload enums compared to C enums: if you use Swift’s “raw value” support, the representation in memory might still be different from the raw value[…]

[…]

If an enum only has one case that has a payload, the compiler and the runtime conspire collaborate to pick the most efficient layout based on the type of the payload and the number of non-payload cases.

[…]

As quoted above, extra inhabitants are memory representations that are never used for a particular type. The most common of these is “0 will never be a valid pointer”, but there are a few others we can think of, like “100 does not represent a valid Multiplier value” from the enum above. The Swift compiler and runtime are smart enough to use these extra “bit patterns” to represent non-payload cases in a single-payload enum.

Epic Banned From Apple Development for a Year

Tim Cook, in July:

We want to get every app we can on the Store, not keep them off.

Apple, August 13:

We will make every effort to work with Epic to resolve these violations so they can return Fortnite to the App Store.

But I missed, when writing yesterday’s post, that Apple’s position has changed. Epic’s motion includes this e-mail from Apple:

This letter serves as notice of termination of the Apple Developer Program License Agreement (the “ADP Agreement”) and the Apple Developer Agreement (the “Developer Agreement”) between Epic Games, Inc. (“you”) and Apple effective immediately[…]

[…]

Finally, please note that we will deny your reapplication to the Apple Developer Program for at least a year considering the nature of your acts.

Since it’s no longer possible for Epic to resubmit and comply with the rules for now, working out the financial settlement later, I now think that Epic is the more harmed party in the current situation. Perhaps that increases its odds in the September 28 preliminary injunction hearing. Otherwise, it would be banned from development and sales at least until the trial, which is nearly a year away.

The continued loss of Fortnite as a gathering place for users on all platforms will lead Epic’s customers to defect. Epic may never see these users again. It will also be denied the opportunity to access even a single new user among the one-billion-plus iOS users for at least the next year. The removal of Fortnite from iOS also substantially impedes a major Epic initiative—evolving Fortnite into a full-fledged “metaverse”, a multi-purpose, persistent, interactive virtual space. Harm like this to Epic’s flagship app cannot be calculated in damages.

Stephen Warwick:

New estimates from Buy Shares have revealed that Epic Games’ spat with Apple could cost it in the region of $26 million a month in lost revenue whilst Fortnite is banned from iOS.

Previously:

Apple Antitrust Investigations in Italy and Australia

Ben Lovejoy:

Today has seen the announcement of the second Apple antitrust investigation in two days. Just one day after Italy announced that it was investigating the fairness of iCloud terms and conditions, Australia says that it is launching a broad investigation into both Apple’s App Store and Google’s Play Store.

Michael Love:

The geopolitical aspects of Apple antitrust are going to get very interesting next year - seems inevitable that if nothing else, App Store developer rules are going to become a lot more regionalized.

[…]

So you could end up with developers actually shopping around for which region to incorporate in based on how well it fits their business model; if, for example, the EU mandates sideloading (a very EU-ish solution), a lot of F2P game companies probably set up shop there.

Previously:

Copyright © 2000–2024 Michael Tsai.