iPadOS 16’s marquee feature is Stage Manager, which adds Mac-like windowing to the iPad, but controversially, Apple requires an M1 iPad to use it. Josh Centers explores Apple’s reasoning and suggests how the company could calm the waters. Adam Engst tells the strange story of how Citibank wouldn’t process TidBITS membership payments because it erroneously thought we were selling cryptocurrency. Finally, Adam explains why a triumvirate of interlocking Apple privacy features—iCloud Private Relay, Limit IP Address Tracking, and Hide IP Address—can cause unusual connection problems. Notable Mac app releases this week include BusyCal 2022.2.3, Camo Studio 1.7, and Evernote 10.39.
It has been one of those weeks where I was busy the entire time, but seemingly not all that much came of it. A good chunk of my week went to resolving a curious problem affecting a handful of TidBITS members. While the initial days of the problem were quite frustrating, the resolution was both gratifying and a testament to how wonderfully helpful TidBITS readers can be.
The first indication we had a problem came from our support wiz, Lauri Reinhardt. She was helping a TidBITS member whose renewal was declined by the bank. He had contacted Citibank, and the customer service rep said the transaction had failed because it was being put through as cryptocurrency. (This was patently ridiculous, especially given our public distrust of the entire field—see “Understand Cryptocurrency, but Don’t Invest in It,” 20 April 2022.) His protestations fell on deaf ears, so he wrote to Lauri. She looked through the Stripe transaction logs but could find no indication of anything related to cryptocurrency. But she did notice an uptick in subscription renewal failures.
When she reported this, our developer Eli looked also and discovered that most of the failed transactions had a
transaction_not_allowed decline code, and all of those had come from Citibank. Simultaneously, I heard from one of my TidBITS Content Network subscribers about a failed renewal, and it turned out that he was using a Citibank credit card, too.
It was time to contact Stripe support. The problem might be affecting only 10 people so far this month, but it was just going to get worse, and not everyone can switch to another credit card from a different bank. At the time, I also thought it might be a more general Stripe problem, though that turned out not to be the case.
To make a long story shorter, Stripe’s email support, in the person of a guy named Tristan, was sympathetic but insistent that Stripe wasn’t doing anything wrong. During this time, more TidBITS members were having conversations with Citibank, all of which devolved to Citibank claiming that we were selling cryptocurrency, which Citibank and other credit card companies haven’t allowed for years. (I suspect this may be related to the volatility of cryptocurrency in various ways.) No one was able to get Citibank to back down and approve the transaction, with reader Brian Stone saying that he might as well have been talking to his neighbor’s dog.
I couldn’t find any way to call Citibank myself, not being a customer, so I kept asking Tristan to escalate. Eventually, I used Stripe’s support option to request a phone call and, amusingly, got a call a few minutes later from Tristan, who was on phone support that day but wasn’t expecting to talk to me. He had a strong Irish accent and was very nice, and while he continued to reiterate that he could find no indication that Stripe was doing anything wrong (which I agreed with), he did understand my point that only Stripe was in a position to resolve the problem. He promised to see if he could find someone else who could help. Next, I heard from Tony, and then from Charles, who held the party line in the face of my persistent requests to have someone at Stripe call Citibank. But when I mentioned that I’d be writing about my experience in TidBITS, Charles brought in Matt.
I don’t know if there was background communication that resulted in Matt helping me, but he was a longtime TidBITS reader who knew full well that TidBITS had nothing to do with cryptocurrency. He promised to look for contacts within Stripe who could call Citibank, but before that, he introduced something new to the discussion, the Merchant Category Code. He noted that changes to the MCC can sometimes cause problems like this, but since ours hadn’t changed recently, he didn’t think that was it.
“Hold on a moment!” I thought. I didn’t even know we had an MCC, but if ours wasn’t accurate, perhaps Citibank had changed something on their end such that they had started misidentifying our transactions. According to Matt, our MCCs had evolved through:
- Computer Software Stores (February 2018 to July 2018)
- Computer Programming (July 2018 to August 2018)
- Computers, Peripherals, and Software (August 2018 to October 2020)
- Computer Programming (October 2020 to present)
Those changes had all been made by Stripe algorithms, and none described what we do well. Noting that sometimes human intervention was necessary to get an accurate MCC, Matt provided me with a list of them. For TidBITS memberships, I chose “Miscellaneous Publishing and Printing” and (the next day, since I missed it the first time) “Digital Goods Media: Books, Movies, Music” for TidBITS Content Network. Matt changed those codes for me, after which retries of the payment requests worked instantly. Finally!
All’s well that ends well, and although I had to be pushier than I prefer, persistence paid off. By getting to a TidBITS reader in Stripe who was willing to share more of what happens behind the scenes, I finally found the key to solving the problem.
In fact, that’s the second time in the past month that a TidBITS reader has helped out. When I wrote about issues associated with Cloudflare’s Automatic Platform Optimization service in “LittleBITS: Website Changes for Speed and Security” (6 June 2022), a TidBITS reader named Jonas, who works on the tech side of Cloudflare, emailed me with some welcome advice. Thanks to both Matt and Jonas! As Eli drily noted afterward, one way to get great support is to spend 32 years building a loyal following. I like to think of it as good karma.
iPadOS 16 offers a mix of long-awaited features (see “Ten “It’s About Time” Features from WWDC 2022,” 6 June 2022), as well as others that left us scratching our heads (“Seven Head-Scratching Features from WWDC 2022,” 13 June 2022). In many ways, its marquee feature is Stage Manager, which adds a more familiar, albeit somewhat limited, windowing system to the iPad.
There’s just one problem: it requires a high-end iPad with an M1 chip (“The Real System Requirements for Apple’s 2022 Operating Systems,” 9 June 2022). That includes just three current models: the fifth-generation Pad Air, the fifth-generation 12.9-inch iPad Pro, and the third-generation 11-inch iPad Pro. (Stage Manager also works on all Macs that can run macOS 13 Ventura, but even Apple expects the vast majority of Mac users will stick with years of working habits over Stage Manager’s new paradigm.)
Many users, especially those with recent non-M1 iPads, aren’t happy, and Apple has been on a damage control tour explaining its rationale.
Apple’s Explanation: Stage Manager Needs M1 Performance
Apple first responded to the controversy in a statement to YouTuber and veteran Apple commentator Rene Ritchie:
Stage Manager is a fully integrated experience that provides all-new windowing experience that is incredibly fast and responsive and allow users to run 8 apps simultaneously across iPad and an external display with up to 6K resolution. Delivering this experience with the immediacy users expect from iPad’s touch-first experience requires large internal memory, incredibly fast storage, and flexible external display I/O, all of which are delivered by iPads with the M1 chip.
In short, Apple says that Stage Manager won’t run on a non-M1 Apple chip. Or at least run well, as Apple’s Craig Federighi explained to Forbes:
We began some of our prototyping involving those systems and it became apparent early on that we couldn’t deliver the experience that that we were designing toward with them. Certainly, we would love to bring any new experience to every device we can, but we also don’t want to hold back the definition of a new experience and not create the best foundation for the future in that experience. And we really could only do that by building on the M1.
Building to M1 was critical as well. From the start, the iPad has always maintained this extremely high standard for responsiveness and interactivity. That directness of interaction in that every app can respond to every touch instantaneously, as if you are touching the real thing underneath the screen. And I think it’s hard sometimes for people to appreciate the technical constraints involved in achieving that.
In short: while Macs can get away with being a little laggy at times, there are no such affordances on the iPad, where the touch interface requires instantaneous response to maintain the illusion that you’re interacting with real objects rather than virtual representations. We’re used to the occasional beachball or pointer stutter on the Mac, but Apple has worked hard to eliminate such issues from the iPad experience. Federighi said that Apple struggled to maintain that level of responsiveness with multiple onscreen apps:
And as you add multiple apps into play, and large amounts of screen real estate, you have to make sure that any one of those apps can respond instantaneously to touch in a way that you don’t have that expectation with a desktop app. Indirect manipulation gives you some slack there, so it’s a different set of constraints.
On a more technical level, he noted:
It’s only the M1 iPads that combined the high DRAM capacity with very high capacity, high performance NAND that allows our virtual memory swap to be super fast. Now that we’re letting you have up to four apps on a panel plus another four — up to eight apps to be instantaneously responsive and have plenty of memory, we just don’t have that ability on the other systems.
Stage Manager allows up to four open apps on an iPad at once, but it also allows you to extend that desktop to another four apps on an external display. Theoretically, Apple could remove that external display support from Stage Manager on lower-powered iPads, but Apple considers it an essential core of Stage Manager. Federighi continued:
We also view Stage Manager as a total experience that involves external display connectivity. And the IO on the M1 supports connectivity that our previous iPads don’t, it can drive 4K, 5K, 6K displays, it can drive them at scaled resolutions. We can’t do that on other iPads.
Finally, you can partially blame the requirement on what the venerable email client Eudora called “trendy 3D junk,” though Federighi couched it in different terms:
We really designed Stage Manager to take full advantage [of the M1]. If you look at the way the apps tilt and shadow and how they animate in and out. To do that at super high frame rates, across very large displays and multiple displays, requires the peak of graphics performance that no one else can deliver.
Could Apple Have Designed Stage Manager to Work on Lesser iPads?
There has been a debate in Apple enthusiast circles about whether Stage Manager truly wouldn’t work on non-M1 iPads or if Apple designed it partly to sell more high-end iPads. Carefully reading Federighi’s statements, I believe both are true. In his TechCrunch interview, Federighi made it clear that Apple didn’t want to limit the feature in any way and is aiming at the future instead of the past:
When you put all this together, we can’t deliver the full Stage Manager experience on any lesser system. I mean, we would love to make it available everywhere we can. But this is what it requires. This is the experience we’re going to carry into the future. We didn’t want to constrain our design to something lesser, we’re setting the benchmark for the future.
In the bluntest terms: Apple could have engineered Stage Manager to work on non-M1 iPads; it just didn’t want to degrade the overall experience to make that happen. This isn’t necessarily nefarious plotting on Apple’s part but rather the standard way Apple makes business decisions. From Apple’s perspective, it’s a total win. Stage Manager:
- Provides a rich multitasking experience that makes people want iPads
- Encourages users with non-M1 iPads to upgrade
- Justifies the purchase of customers who already own M1 iPads
Apple uses this line of thinking in many areas. For example, its App Tracking Transparency feature, which lets users prevent apps from tracking their behaviors, is a huge privacy win and a strong selling point for the Apple ecosystem. It also happens to weaken competitors like Facebook and strengthen Apple’s own advertising business.
How Apple Could Soothe Developers (And Beleaguered Tech Authors)
Most iPad users aren’t aware of the controversy and will never miss Stage Manager. The iPad gives non-technical users a simple, capable computing device. On the other hand, power users may already own a high-end iPad or do much of their work on a full-featured Mac. Stage Manager is a premium feature aimed at iPad power users, and those who lack an M1 iPad now have reason to invest in one for their next upgrade.
However, developers may resent the M1 requirement even more than users. Developer Steve Troughton-Smith points out that most developers do not own an M1 iPad and the iOS Simulator doesn’t officially support Stage Manager, which will make it hard to optimize apps for Stage Manager. M1 iPad owners may be disappointed to find that Stage Manager doesn’t immediately work as expected with their favorite third-party apps.
Flipside of the Stage Manager/M1 iPad situation: your favorite app dev probably doesn’t have one, either. And, right now, the iOS Simulator doesn’t officially support Stage Manager — so not unreasonable to expect the vast majority of third-party apps won’t, come September, either
— Steve Troughton-Smith (@stroughtonsmith) June 13, 2022
Troughton-Smith suggests that Apple should let beta testers enable Stage Manager on non-M1 iPads. I fully support that idea for several reasons:
- More developers would be able to optimize their apps to work well with Stage Manager, which would mean happier M1 iPad owners.
- Assuming Apple is being truthful about Stage Manager’s performance needs, it would demonstrate that Stage Manager truly requires an M1 chip.
- Beta testers on unsupported iPads will understand if it works poorly because it’s a beta.
- It would let poor, beleaguered tech authors like me document the feature.
Of course, Apple doesn’t care about the last point and often seems to see independent writers as unwelcome competition. But as it stands, I’m in a sticky spot with my follow-up to Take Control of iOS 15 and iPadOS 15, as I only have a base-model iPad from last year, which I bought to test features that required an A12 Bionic. I don’t use my iPad for much apart from testing, so I’m torn as to whether to upgrade, guess how it works based on videos, buy and return an M1 iPad within the 14-day window, or camp out at a distant Apple Store for an afternoon.
Stage Manager’s Origins
Amusingly, it turns out that Stage Manager was originally conceived back in 2006 as a prototype called “shrinkydink,” as documented by a former Apple developer who posted screenshots to show how little it has changed from its initial design. The original post has been taken down (presumably at the behest of Apple Legal), but you can still view an archived version.
Complaints about website loading have been trickling in of late, and while the details vary, the commonality has been that the problems started with macOS 12.4 Monterey. Sometimes the problem was just with Safari; other times, it affected Chrome and other browsers too. In some cases, the entire page would refuse to load; in others, only portions of the page would fail.
The solution to the problems I’ve seen so far is simple: in System Preferences > Network, turn off Limit IP Address Tracking for each network adapter you use (Ethernet and Wi-Fi below—they look surprisingly different).
For some people, the problems have extended to iOS 15 and iPadOS 15. Apple provides the same Limit IP Address Tracking option in Settings > Wi-Fi > YourNetwork and Settings > Cellular > Cellular Data Options.
If you read the fine print underneath the iPhone screenshots above, you’ll notice that it says, “When this is turned off, iCloud Private Relay will also be turned off for this network.” That message appears on my iPhone because I do have iCloud Private Relay enabled for the iPhone, whereas I turned it off on my Mac.
I wish I better understood what’s happening here, but it’s devilishly difficult to test a feature that prevents tracking by malicious actors, given that I’m neither malicious nor an actor. Clouding the situation even further is the fact that features that say they’ll limit IP address tracking or hide your IP address exist in three completely separate places:
- iCloud Private Relay: This overarching privacy feature routes all your traffic through two separate Internet relays to hide your IP address from the site to which you’re connecting. You can turn it on and off in System Preferences > Apple ID on the Mac and Settings > YourName in iOS and iPadOS.
- Limit IP Address Tracking: This option is either enabled or disabled for each network you use, whether Wi-Fi, Ethernet, or cellular. As noted above, its description changes depending on whether iCloud Privacy Relay is on or off.
- Hide IP Address: Safari and Mail both offer this option in their preferences but say little about how it relates to iCloud Private Relay.
Here’s what I think is going on and where I’m unsure. I hope you can use this information to walk the fine line between increased privacy and more frequent connection problems.
iCloud Private Relay
The first thing to check if you experience sporadic networking failures is iCloud Private Relay. This feature, available only to iCloud+ subscribers who pay Apple for additional storage space, routes all your traffic through two Internet relays, one run by Apple and another run by a major content-delivery network like Akamai, Cloudflare, or Fastly. Apple has a white paper that explains it in detail, but here are the basics.
The privacy win is that only your ISP and Apple know your IP address because your ISP and the first relay (called the “ingress proxy”) have to associate the connection with you to send the response back to you. The address of the website you want to load is encrypted, however, so neither your ISP nor Apple knows where you’re going.
The second relay (known as the “egress proxy”) assigns a new, temporary IP address to the request, decrypts the address of the destination website, and completes the connection to the remote site. In other words, the egress proxy doesn’t know your IP address—it gets only enough information to locate you in roughly the right region of the world so geolocation isn’t a problem.
Apple acknowledges that iCloud Private Relay can cause problems, in part due to the new transport protocols it uses. iCloud Private Relay also takes over from your DNS servers, which may account for some of the problems; at least one user had a Pi-hole ad blocker installed. macOS tells you this when you specify DNS servers in System Preferences > Network > YourNetwork > Advanced > DNS.
As a user, however, if you have problems, there are only two things you need to try, as described above:
- Disable iCloud Private Relay entirely. It’s easily turned on and off, so there’s no harm in flipping that switch as needed.
- Disable Limit IP Address Tracking for a particular network. That would let you, for instance, disable it on your iPhone for your home Wi-Fi network while leaving it on for your cellular data connection.
You wouldn’t necessarily guess that Limit IP Address tracking would disable iCloud Private Relay for a particular network, and Apple mentions it only once in its documentation of iCloud Private Relay, saying:
Private Relay can be turned on or off just for a specific network using the Limit IP Address Tracking preference.*
The asterisk points to a footnote that says:
* In earlier versions of iOS, iPadOS, and macOS, this preference is called iCloud Private Relay.
So why did Apple rename that option? Here’s where things get murky. I think it has to do with Limit IP Address Tracking doing more than just disabling iCloud Private Relay.
Limit IP Address Tracking
Apple has said that disabling Limit IP Address Tracking turns iCloud Private Relay off for a particular network. And I think it’s safe to say that if you disable both iCloud Private Relay and Limit IP Address Tracking, traffic will flow normally to and from your ISP and destination sites.
But what about the remaining possibility, where iCloud Private Relay is turned off, but Limit IP Address Tracking is turned on? Here’s where that fine print comes into play. When iCloud Private Relay is turned on, the fine print reads:
Limit IP address tracking by hiding your IP address from known trackers in Mail and Safari. When this is turned off, iCloud Private Relay will also be turned off for this network.
With iCloud Private Relay turned off, the fine print shrinks to:
Limit IP address tracking by hiding your IP address from known trackers in Mail and Safari.
I haven’t been able to find any Apple documentation of what this means, but my guess is that Apple has essentially embedded the iCloud Private Relay approach of routing traffic through two Internet relays into Mail and Safari, such that it affects only requests from those apps. What I don’t understand is what “hiding your IP address from known trackers” means and how it differs from hiding your IP address in general. Let’s investigate.
Hide IP Address
On the Mac, you can go to Safari > Preferences > Privacy to find another Hide IP Address setting. In Mail, look in Mail > Preferences > Privacy, though you must disable Protect Mail Activity to manage the Hide IP Address option separately. (Generally speaking, leave Protect Mail Activity enabled if you can.)
In iOS and iPadOS, you’ll find the equivalent options in Settings > Safari > Hide IP Address and Settings > Mail > Privacy Protection. In Mail, again, you must turn off Protect Mail Activity if you want to control Hide IP Address on its own.
So what do these Hide IP Address features do? With Safari, it’s difficult to know. If you click or tap the Learn More link on either the Mac or iPhone, it takes you to an explanatory page about iCloud Private Relay that offers no insight into the link to Safari.
Mail, however, is more forthcoming. Click or tap its Learn More link, and you’ll get quite a bit of information about how Protect Mail Activity uses a two-hop system that sounds nearly identical to iCloud Private Relay. It even clarifies that if you turn off Protect Mail Activity and leave Hide IP Address enabled, it will continue to “mask your IP address using the same two-separate-internet-relays design.”
In addition, Protect Mail Activity routes all remote content downloaded by Mail through two separate relays operated by different entities. The first knows your IP address, but not the remote Mail content you receive. The second knows the remote Mail content you receive, but not your IP address, instead providing a generalized identity to the destination. This way, no single entity has the information to identify both you and the remote Mail content you receive. Senders can’t use your IP address as a unique identifier to connect your activity across websites or apps to build a profile about you. … If you choose to disable Protect Mail Activity, the Hide IP Address feature will still mask your IP address using the same two-separate-internet-relays design.
I suspect that it’s iCloud Private Relay all the way down.
Putting It All Together
Here’s how I believe we should think about these interlocking settings.
- iCloud Private Relay: At the top level is iCloud Private Relay. Turn it on, and it runs all your traffic through the ingress and egress proxies, providing the highest level of privacy. However, it’s entirely likely that iCloud Private Relay will cause problems, so Apple lets users drop down to a lower level of privacy.
- Limit IP Address Tracking: That’s where the Limit IP Address Tracking option at the network level comes in. You can disable it to turn off iCloud Private Relay selectively or enable it (with iCloud Private Relay disabled) to apply iCloud Private Relay-like traffic routing to traffic from Safari and Mail. But since those apps are quite different—Safari needs to be able to connect to a far more varied set of servers than Mail—Apple separated them as well.
- Hide IP Address: That’s why each app has its own Hide IP Address setting. You might need to turn off iCloud Private Relay, turn off Limit IP Address Tracking, and turn off Safari’s Hide IP Address setting but still want to keep Mail’s Hide IP Address option enabled. It’s conceivable you’d want to disable Mail’s tracking protection and enable Safari’s, but that seems less likely.
Lending support to my theory is that if you disable Hide IP Address for Safari and Limit IP Address Tracking for your network and then turn on iCloud Private Relay, it first prompts you to turn on Safari’s Hide IP Address setting (below left) and then alerts you that it’s disabled for your network (below right).
Again, I don’t know what Apple means when it specifies that Limit IP Address Tracking and Hide IP Address affect only “known trackers.” The Hide IP Address screen in Safari makes the distinction clear—as long as iCloud Private Relay is enabled, you can choose from either Trackers and Websites or just Trackers. Without iCloud Private Relay turned on, you can only choose to hide your IP address from Trackers.
I’ve been unable to find any Apple documentation of how the company identifies known trackers and massages Safari and Mail traffic to protect your IP address from them. What happens when you connect to a remote site that’s not a known tracker? Does Apple send your IP address through in the clear? Perhaps someone who knows how to analyze network traffic could find out, but that’s beyond my skill set.
Realistically, however, what’s important is that if you’re having problems, you can turn off iCloud Private Relay first, and if that doesn’t resolve the issue, turn off Limit IP Address Tracking. If even that’s not enough, turn off Hide IP Address for Safari or Mail.
Otherwise, just leave them all on and enjoy whatever level of additional privacy they provide.