Websites are still capable of detecting when a visitor is using Chrome's incognito (private browsing) mode, despite Google's efforts last year to disrupt the practice. From a report: It is still possible to detect incognito mode in Chrome, and all the other Chromium-based browsers, such as Edge, Opera, Vivaldi, and Brave, all of which share the core of Chrome's codebase. Furthermore, developers have taken the scripts shared last year and have expanded support to non-Chrome browsers, such as Firefox and Safari, allowing sites to block users in incognito mode across the board. Currently, there is no deadline for a new Chrome update to block incognito mode detections, however, today, Google might be interested more than ever in fixing this issue.

wiredmikey writes: An abundance of iOS exploits being submitted to be sold should alarm iPhone/iPad users, according to the CEO of exploit acquisition firm Zerodium. The company announced that it was no longer buying certain types of iOS exploits in the next two to three months [including local privilege escalation, Safari remote code execution, and sandbox escape exploits] due to a surplus. And the company expects prices to drop in the near future.

"iOS Security is fucked," Chaouki Bekrar, CEO of Zerodium said on Twitter, noting that they are already seeing many exploits designed to bypass pointer authentication codes and a few zero-day exploits that can help an attacker achieve persistence on all iPhones and iPads. "Let's hope iOS 14 will be better," he added.

Bekrar said that only pointer authentication codes — which provide protection against unexpected changes to pointers in memory — and the difficulty to achieve persistence "are holding [iOS security] from going to zero."

Apple is working on a new way to offer specific parts of third-party apps across the system without needing to have them installed, 9to5Mac has learned based on an early build of iOS 14. From a report: The feature would allow users to experience parts of an app's functionality by scanning a QR Code. If you open a link or scan a QR code today from an app that you haven't installed on your iPhone or iPad, it will open that link in Safari. Apps can provide universal links, which open the app instead of Safari when the app is installed. But that could change in the near future with a new API internally referred to as "Clips" found on iOS 14 code. As 9to5Mac has analyzed this new API, we can say that it allows developers to offer interactive and dynamic content from their apps even if you haven't installed them. The Clips API is directly related to the QR Code reader in the build we have access to, so the user can scan a code linked to an app and then interact with it directly from a card that will appear on the screen.

Google is now backing a standard proposed by Apple engineers in January to create a default format for one-time passcodes (OTP) sent via SMS to users during the two-factor authentication (2FA) process. From a report: The standard, proposed by Apple engineers working on the Safari WebKit project, has now reached the status of official Web Platform Incubator Community Group (WICG) specification draft. "We've moved 'Origin-bound one-time codes delivered via SMS' to @wicg_, where we're working on a shared spec with our collaborators at Google. Please take a look! Updated explainer, and specification," wrote Apple's Ricky Mondello. The proposal aims to fix some issues with the current state of SMS 2FA/OTP codes, all of which have different formats, unique per the websites sending the codes.

An anonymous reader quotes a report from Wired: Apple has a well-earned reputation for security, but in recent years its Safari browser has had its share of missteps. This week, a security researcher publicly shared new findings about vulnerabilities that would have allowed an attacker to exploit three Safari bugs in succession and take over a target's webcam and microphone on iOS and macOS devices. Apple patched the vulnerabilities in January and March updates. But before the fixes, all a victim would have needed to do is click one malicious link and an attacker would have been able to spy on them remotely.

The bugs Pickren found all stem from seemingly minor oversights. For example, he discovered that Safari's list of the permissions a user has granted to websites treated all sorts of URL variations as being part of the same site, like https://www.example.com, http://example.com and fake://example.com. By "wiggling around," as Pickren puts it, he was able to generate specially crafted URLs that could work with scripts embedded in a malicious site to launch the bait-and-switch that would trick Safari. A hacker who tricked a victim into clicking their malicious link would be able to quietly launch the target's webcam and microphone to capture video, take photos, or record audio. And the attack would work on iPhones, iPads, and Macs alike. None of the flaws are in Apple's microphone and webcam protections themselves, or even in Safari's defenses that keep malicious sites from accessing the sensors. Instead, the attack surmounts all of these barriers just by generating a convincing disguise.

The former editor-in-chief of the Linux Journal just published an annotated version of Zoom's privacy policy. Searls calls it "creepily chummy with the tracking-based advertising biz (also called adtech). I'll narrow my inquiry down to the "Does Zoom sell Personal Data?" section of the privacy policy, which was last updated on March 18. The section runs two paragraphs, and I'll comment on the second one, starting here:

Zoom does use certain standard advertising tools which require Personal Data ...

What they mean by that is adtech. What they're also saying here is that Zoom is in the advertising business, and in the worst end of it: the one that lives off harvested personal data. What makes this extra creepy is that Zoom is in a position to gather plenty of personal data, some of it very intimate (for example with a shrink talking to a patient) without anyone in the conversation knowing about it. (Unless, of course, they see an ad somewhere that looks like it was informed by a private conversation on Zoom.)

A person whose personal data is being shed on Zoom doesn't know that's happening because Zoom doesn't tell them. There's no red light, like the one you see when a session is being recorded. If you were in a browser instead of an app, an extension such as Privacy Badger could tell you there are trackers sniffing your ass. And, if your browser is one that cares about privacy, such as Brave, Firefox or Safari, there's a good chance it would be blocking trackers as well. But in the Zoom app, you can't tell if or how your personal data is being harvested.

(think, for example, Google Ads and Google Analytics).

There's no need to think about those, because both are widely known for compromising personal privacy. (See here. And here. Also Brett Frischmann and Evan Selinger's Re-Engineering Humanity and Shoshana Zuboff's In the Age of Surveillance Capitalism.)
Zoom claims it needs personal data to "improve" its users "experience" with ads -- though Searls isn't satisfied. ("Nobody goes to Zoom for an 'advertising experience,' personalized or not. And nobody wants ads aimed at their eyeballs elsewhere on the Net by third parties using personal information leaked out through Zoom.") His conclusion?

"What Zoom's current privacy policy says is worse than 'You don't have any privacy here.' It says, 'We expose your virtual necks to data vampires who can do what they will with it.'"

Starting this week, with the release of Safari 13.1 and through updates to the Intelligent Tracking Prevention (ITP) privacy feature, Apple now blocks all third-party cookies in Safari by default. From a report: The company's move means that online advertisers and analytics firms cannot use browser cookie files anymore to track users as they visit different sites across the internet. But Apple says the move isn't actually a big deal, since they were already blocking most third-party cookies used for tracking anyway. "It might seem like a bigger change than it is," said John Wilander, an Apple software engineer. "But we've added so many restrictions to ITP since its initial release in 2017 that we are now at a place where most third-party cookies are already blocked in Safari."

The 2020 spring edition of the Pwn2Own hacking contest has come to a close today. This year's winner is Team Fluoroacetate -- made up of security researchers Amat Cama and Richard Zhu -- who won the contest after accumulating nine points across the two-day competition, which was just enough to extend their dominance and win their fourth tournament in a row. From a report: But this year's edition was a notable event for another reason. While the spring edition of the Pwn2Own hacking contest takes place at the CanSecWest cyber-security conference, held each spring in Vancouver, Canada, this year was different. Due to the ongoing coronavirus (COVID-19) outbreak and travel restrictions imposed in many countries around the globe, many security researchers couldn't attend or weren't willing to travel to Vancouver and potentially put their health at risk. Instead, this year's Pwn2Own edition has become the first-ever hacking contest that has been hosted in a virtual setting. Participants sent exploits to Pwn2Own organizers in advance, who ran the code during a live stream with all participants present. During the competition's two-day schedule, six teams managed to hack apps and operating systems like Windows, macOS, Ubuntu, Safari, Adobe Reader, and Oracle VirtualBox. All bugs exploited during the contest were immediately reported to their respective companies.

"New academic research published last month looked at the phone-home [telemetry] features of six of today's most popular browsers and found that the Brave browser sent the smallest amount of data about its users back to the browser maker's servers," reports ZDNet: The research, conducted by Douglas J. Leith, a professor at Trinity College at the University of Dublin, looked at Google Chrome, Mozilla Firefox, Apple Safari, Brave, Microsoft Edge (the new Chromium-based version), and the Yandex Browser.

"In the first (most private) group lies Brave, in the second Chrome, Firefox, and Safari, and in the third (least private) group lie Edge and Yandex...." [T]he professor found evidence that Chrome, Firefox, and Safari all tagged telemetry data with identifiers that were linked to each browser instance. These identifiers allowed Google, Mozilla, and Apple to track users across browser restarts, but also across browser reinstalls...

[T]he most intrusive phoning-home features were found in the new version of Microsoft Edge and the official Yandex Browser. According to Prof. Leith, both used unique identifiers that were linked to the device's hardware, rather than the browser installation. Tracking users by hardware allows Microsoft and Yandex to follow users across installations and potentially link browser installs with other apps and online identities. The professor said that Edge collected the hardware UUID of the user's computer, an identifier that cannot be easily changed or deleted without altering a computer's hardware. Similarly, Prof. Leith also found that Yandex transmitted a hash of the hardware serial number and MAC address to its backend servers.

"As far as we can tell this behaviour [in Edge and Yandex] cannot be disabled by users," the professor said.
The article also points out that Brave was the only browser that didn't use search autocomplete functionality to collect and send back information on a user's visited web pages. (Even though this can be disabled in Firefox, Chrome, and Safari, it's on by default.)

But Edge and Yandex "also sent back information about visited web pages that did not appear to be related to the search autocomplete feature, suggesting the browsers had other ways to track users' browsing habits."

"Safari will, later this year, no longer accept new HTTPS certificates that expire more than 13 months from their creation date..." writes the Register.

Long-time Slashdot reader nimbius shares their report: The policy was unveiled by the iGiant at a Certification Authority Browser Forum (CA/Browser) meeting on Wednesday. Specifically, according to those present at the confab, from September 1, any new website cert valid for more than 398 days will not be trusted by the Safari browser and instead rejected.

Older certs, issued prior to the deadline, are unaffected by this rule.

By implementing the policy in Safari, Apple will, by extension, enforce it on all iOS and macOS devices. This will put pressure on website admins and developers to make sure their certs meet Apple's requirements — or risk breaking pages on a billion-plus devices and computers... The aim of the move is to improve website security by making sure devs use certs with the latest cryptographic standards, and to reduce the number of old, neglected certificates that could potentially be stolen and re-used for phishing and drive-by malware attacks... We note Let's Encrypt issues free HTTPS certificates that expire after 90 days, and provides tools to automate renewals.

Apple is considering giving rival apps more prominence on iPhones and iPads and opening its HomePod speaker to third-party music services after criticism the company provides an unfair advantage to its in-house products. From a report: The technology giant is discussing whether to let users choose third-party web browser and mail applications as their default options on Apple's mobile devices, replacing the company's Safari browser and Mail app, according to people familiar with the matter. Since launching the App Store in 2008, Apple hasn't allowed users to replace pre-installed apps such as these with third-party services. That has made it difficult for some developers to compete, and has raised concerns from lawmakers probing potential antitrust violations in the technology industry.

The web browser and mail are two of the most-used apps on the iPhone and iPad. To date, rival browsers like Google Chrome and Firefox and mail apps like Gmail and Microsoft Outlook have lacked the status of Apple's products. For instance, if a user clicks a web link sent to them on an iPhone, it will automatically open in Safari. Similarly, if a user taps an email address -- say, from a text message or a website -- they'll be sent to the Apple Mail app with no option to switch to another email program. The Cupertino, California-based company also is considering loosening restrictions on third-party music apps, including its top streaming rival Spotify, on HomePods, said the people, who asked not to be named discussing internal company deliberations.

Waterfox is an open-source web browser for x64, ARM64, and PPC64LE systems, "intended to be speedy and ethical, and maintain support for legacy extensions dropped by Firefox, from which it is forked," according to Wikipedia. (Its tabs also still have angled sides with rounded corners.)

Friday Waterfox's original creator, 24-year-old Alexandros Kontos, announced that the browser "now has funding and a development team, so Waterfox can finally start to grow!" after its acquisition by a company called System1. I started Waterfox when I was 16. It was a way for me to understand how large software projects worked and the Mozilla documentation was a great introduction... I've touted Waterfox as an ethical and privacy friendly browser... I never wanted Waterfox to be a part of the hyper-privacy community. It would just feel like standards that would be impossible to uphold, especially for something such as a web browser on the internet. Throughout the years people have always asked about Waterfox and privacy, and if they've ever wanted more than it can afford, I've always pushed them to use Tor. Waterfox was here for customisations and speed, with a good level of privacy...

I wasn't doing anything with Waterfox except developing it and making some money via search. Why I kept going throughout the years, I'll never know... System1 has been to Waterfox a search syndication partner. Essentially a way to have a search engine partnership (such as Bing) is through them, because companies such as Microsoft are too big and too busy to talk to small players such as Waterfox... It's probably the one easy way a browser can make money without doing anything dodgy, and it's a way I've been happy to do it without having to compromise Waterfox (and will be the same way System1 makes money from Waterfox -- nothing else). People also don't seem to understand what System1 does...
"Now I can finally focus on making Waterfox into a viable alternative to the big browsers," Kontos concludes.

Long-time Slashdot reader Freshly Exhumed contextualized the news with this brief history of the alternate browser ecosystem: As the usage share of web browsers continues to show a lopsideded dominance by Google Chrome, many previously-independent browsers have fallen by the wayside or have been reinvented as Chrome variants (i.e. Opera, Edge, Brave). Apple forges on with its Safari browser while other, smaller projects tend to be quite limited for multi-platform users, such as Dolphin and Bromite.

Mozilla continues independently with Firefox for almost every platform, while variants such as Pale Moon and Sea Monkey have attempted to provide products that avoid drastic and/or controversial changes made by Mozilla but sometimes do not match the multi-platform support of Firefox. Let us not forget Tor, the Firefox-based anonymity-focused browser.

Alex Kontos is a developer who attempted to provide continuity with dropped Firefox capabilities in his multi-platform Waterfox browser, proudly declaring that Firefox's user data sharing and telemetry collection was not included. For that privacy focus a certain popularity of Waterfox occurred. Now Kontos has revealed that his Waterfox project has been sold to System1, a company describing itself as "a consumer internet and applications company with the most powerful audience expansion platform in the industry."

An anonymous reader quotes the Verge: In December, online coding bootcamp Lambda School quietly partnered with Edly, a digital marketplace that helps schools sell income-sharing agreements (ISAs) to accredited investors. The arrangement allows Lambda to receive money from the ISAs upfront, rather than waiting for students to find jobs. But it also flies in the face of the values Lambda typically espouses: namely, that ISAs align its incentives with the goals and aspirations of the students...

Lambda's ISAs promise an alternative to traditional student loans by allowing students to defer tuition until they've landed a job that pays $50,000 a year or more. When that happens, they hand over 17 percent of their income until the $30,000 tuition is paid off. If students don't find work within five years of completing the program, the ISA is automatically dissolved. It's a business model that allows Lambda to brag about investing in students — which, in many ways, it still does. The school provides living stipends and even housing to some students who need it. But reselling ISAs muddies the narrative a bit since Lambda can make money long before students find jobs...

Shortly after the arrangement was called out on Twitter, following a report by The Verge about some students' disappointment with the curriculum, Edly began taking down pages that referenced the Lambda partnership. Edly did not immediately respond to a request for comment about why these pages were taken down, and Lambda declined to comment on the nature of the partnership at all.
"I wonder why Lambda isn't so keen on seeing discussions about how students are being packed into the same kind of CDOs that brought us the financial crisis," tweeted David Heinemeier Hansson, the creator of Ruby on Rails, who's been tweeting screenshots of Edly's past statements about their ambitions as well as links to Google's cache of Edly's pitches to investors.

Last year Wired reported that nearly half of Lambda's ISAs had at least partly been sold off to investors. They also note that in January of 2019, Lambda "received $30 million from investors including Google Ventures, Y Combinator, and Ashton Kutcher."

Apple engineers have put forward a proposal today to standardize the format of the SMS messages containing one-time passcodes (OTP) that users receive during the two-factor authentication (2FA) login process. From a report: The proposal comes from Apple engineers working on WebKit, the core component of the Safari web browser. The proposal has two goals. The first is to introduce a way that OTP SMS messages can be associated with an URL. This is done by adding the login URL inside the SMS itself. The second goal is to standardize the format of 2FA/OTP SMS messages, so browsers and other mobile apps can easily detect the incoming SMS, recognize web domain inside the message, and then automatically extract the OTP code and complete the login operation without further user interaction. By doing this, the process of receiving and entering a one-time passcode could be automated, eliminating the risk of a user falling for a scam and entering an OTP code on a phishing site, with the wrong URL.

John Gruber: Ten years ago today, Steve Jobs introduced the iPad on stage at the Yerba Buena theater in San Francisco. [...] Ten years later, though, I don't think the iPad has come close to living up to its potential. [...] Software is where the iPad has gotten lost. iPadOS's "multitasking" model is far more capable than the iPhone's, yes, but somehow Apple has painted it into a corner in which it is far less consistent and coherent than the Mac's, while also being far less capable. iPad multitasking: more complex, less powerful. That's quite a combination.

Consider the basic task of putting two apps on screen at the same time, the basic definition of "multitasking" in the UI sense. To launch the first app, you tap its icon on the homescreen, just like on the iPhone, and just like on the iPad before split-screen multitasking. Tapping an icon to open an app is natural and intuitive. But to get a second app on the same screen, you cannot tap its icon. You must first slide up from the bottom of the screen to reveal the Dock. Then you must tap and hold on an app icon in the Dock. Then you drag the app icon out of the Dock to launch it in a way that it will become the second app splitting the display. But isn't dragging an icon out of the Dock the way that you remove apps from the Dock? Yes, it is -- when you do it from the homescreen.

So the way you launch an app in the Dock for split-screen mode is identical to the way you remove that app from the Dock. Oh, and apps that aren't in the Dock can't become the second app in split screen mode. What sense does that limitation make? On the iPhone you can only have one app on screen at a time. The screen is the app; the app is the screen. This is limiting but trivial to understand. [...] On iPad you can only have two apps on screen at the same time, and you must launch them in entirely different ways -- one of them intuitive (tap any app icon), one of them inscrutable (drag one of the handful of apps you've placed in your Dock). And if you don't quite drag the app from the Dock far enough to the side of the screen, it launches in "Slide Over", an entirely different shared-screen rather than split-screen mode. The whole concept is not merely inconsistent, it's incoherent. How would anyone ever figure out how to split-screen multitask on the iPad if they didn't already know how to do it?

[...] As things stand today, I get a phone call from my mom once a month or so because she's accidentally gotten Safari into split-screen mode when tapping links in Mail or Messages and can't get out. I like my iPad very much, and use it almost every day. But if I could go back to the pre-split-screen, pre-drag-and-drop interface I would. Which is to say, now that iPadOS has its own name, I wish I could install the iPhone's one-app-on-screen-at-a-time, no-drag-and-drop iOS on my iPad Pro. I'd do it in a heartbeat and be much happier for it. The iPad at 10 is, to me, a grave disappointment. Not because it's "bad", because it's not bad -- it's great even -- but because great though it is in so many ways, overall it has fallen so far short of the grand potential it showed on day one. To reach that potential, Apple needs to recognize they have made profound conceptual mistakes in the iPad user interface, mistakes that need to be scrapped and replaced, not polished and refined. I worry that iPadOS 13 suggests the opposite -- that Apple is steering the iPad full speed ahead down a blind alley. Further reading: The iPad's original software designer and program lead look back on the device's first 10 years.

Google researchers have exposed details of multiple security flaws in its rival Apple's Safari web browser that allowed users' browsing behavior to be tracked [Editor's note: the link may be paywalled; alternative source], despite the fact that the affected tool was specifically designed to protect their privacy. From a report: The flaws, which were ironically found in an anti-tracking feature known as Intelligent Tracking Prevention, were first disclosed by Google to Apple in August last year. In a soon-to-be published paper seen by the Financial Times, researchers in Google's cloud team have since identified five different types of potential attack that could have resulted from the vulnerabilities, allowing third parties to obtain "sensitive private information about the user's browsing habits." "You would not expect privacy-enhancing technologies to introduce privacy risks," said Lukasz Olejnik, an independent security researcher who has seen the paper. "If exploited or used, [these vulnerabilities] would allow unsanctioned and uncontrollable user tracking. Apple rolled out Intelligent Tracking Prevention in 2017, with the specific aim of protecting Safari browser users from being tracked around the web by advertisers' and other third-parties' cookies.

The Verge argues that the browser wars "are back, but it's different this time."
The mobile web is broken and unfettered tracking and data sharing have made visiting websites feel toxic, but since the ecosystem of websites and ad companies can't fix it through collective action, it falls on browser makers to use technological innovations to limit that surveillance, however each company that makes a browser is taking a different approach to creating those innovations, and everybody distrusts everybody else to act in the best interest of the web instead of the best interest of their employers' profits... I've been avoiding getting into the precise details of the proposals out there to fix the tracking problem because things are changing so quickly across so many different tracks... Until then, know that there are two important things to know.

First: there are new browser technologies and limits coming that could radically change how ads work and could make it easier for you to protect your privacy no matter what browser you use. Since this is the web, it'll take time, but everybody seems committed. Second: the way many of us think about a Browser War is in terms of marketshare -- and that is the wrong metric this time. There is a browser war, but it won't be won or lost based on who can convince the most people to switch to their browser. Because most people can't or won't switch on the platform that matters: mobile.

In 2020, the desktop is a minor skirmish compared to browsers on phones. On phones, many people aren't really free to choose their browser. That's literally true on the iPhone, which Apple locks down so apps can only use its web rendering technology. And it's for-intents-and-purposes true on Android, where the vast majority of browsers just use Chromium. Yes, there is an Android browser ballot happening in Europe, but it's much too early to know what its effects will be....

The new Browser Wars aren't about who makes the fastest or best browser, they're about whose services you want and whose data policies you trust.

Apple's initiatives to minimize tracking by marketers is continuing to make life harder for the advertising industry, forcing advertisers to use inefficient data sources to pinpoint users. AppleInsider reports: Over the years, Apple has enhanced how it protects the privacy of its users online, typically by limiting what data can be seen by advertisers tracking different data points. Initiatives such as Intelligent Tracking Protection in Safari has helped secure more privacy by making it harder to track individual users, which advertising executives in December admitted has been "stunningly effective." While ITP and other improvements have helped to minimize the tracking of users, marketers are also being affected by another element of iOS 13, one where users are regularly notified of apps that are capturing their location in the background. The warning gives options for users to allow an app to continue to track all the time or to do so when it is open, with users often selecting the latter.

According to data from verification firm Location Sciences seen by DigiDay, approximately seven in ten iPhone users tracked by the company downloaded iOS 13 in its first six weeks of availability. Of those tracked users who installed the update, around 80% of them stopped all background tracking by apps. Ad tracking company Teemo suggests the opt-in rates to share data with apps when not in use are often below 50%, whereas three years ago, the same rates were close to 100%. The higher rates were due to it being a time when users were largely unaware there were options to disable tracking in the first place.

Mac developer Michael Tsai reports that Apple News no longer supports RSS. The news comes from user David A. Desrosiers, who writes: Apple News on iOS and macOS no longer supports adding RSS or ATOM feeds from anywhere. Full-stop, period. It will immediately fetch, then reject those feeds and fail to display them, silently without any message or error. I can see in my own server's log that they make the request using the correct app on iOS and macOS, but then ignore the feed completely; a validated, clean feed. They ONLY support their own, hand-picked, curated feeds now. You can visit a feed in Safari, and it will prompt you to open the feed in Apple News, then silently ignore that request, after fetching the full feed content from the remote site. Simon Willison, creator of Datasette and co-creator of Django, points out that Apple News still hijacks links to Atom/RSS feeds -- "so if you click on one of those links in Mobile Safari you'll be bounced to the News app, which will then display an error."

At its developer conference in June this year, Apple introduced Project Catalyst that aims to help developers swiftly bring their iOS apps to Macs. Developers have had more than half a year to play with Catalyst. Here's where things stand currently: The crux of the issue in my mind is that iOS and Mac OS are so fundamentally different that the whole notion of getting a cohesive experience through porting apps with minimal effort becomes absurd. The problem goes beyond touch vs pointer UX into how apps exist and interact within their wider OSes. While both Mac OS and iOS are easy to use, their ease stem from very different conventions. The more complicated Mac builds ease almost entirely through cohesion. Wherever possible, Mac applications are expected to share the same shortcuts, controls, windowing behavior, etc... so users can immediately find their bearings regardless of the application. This also means that several applications existing in the same space largely share the same visual and UX language. Having Finder, Safari, BBEdit and Transmit open on the same desktop looks and feels natural.

By comparison, the bulk of iOS's simplicity stems from a single app paradigm. Tap an icon on the home screen to enter an app that takes over the entire user experience until exited. Cohesion exists and is still important, but its surface area is much smaller because most iOS users only ever see and use a single app at a time. For better and worse, the single app paradigm allows for more diverse conventions within apps. Having different conventions for doing the same thing across multiple full screen apps is not an issue because users only have to ever deal with one of those conventions at a given time. That innocuous diversity becomes incongruous once those same apps have to live side-by-side. Columnist John Gruber of DaringFireball adds: I think part of the problem is Catalyst itself -- it just doesn't feel like nearly a full-fledged framework for creating proper Mac apps yet. But I think another problem is the culture of doing a lot of nonstandard custom UI on iOS. As Wellborn points out, that flies on iOS -- we UI curmudgeons may not like it, but it flies -- because you're only ever using one app at a time on iOS. It cracks a bit with split-screen multitasking on iPadOS, but I've found that a lot of the iPad apps with the least-standard UIs don't even support split-screen multitasking on iPadOS, so the incongruities -- or incoherences, to borrow Wellborn's well-chosen word -- don't matter as much. But try moving these apps to the Mac and the nonstandard UIs stick out like a sore thumb, and whatever work the Catalyst frameworks do to support Mac conventions automatically doesn't kick in if the apps aren't even using the standard UIKit controls to start with. E.g. scrolling a view with Page Up, Page Down, Home, and End. Further reading: Apple's Merged iPad, Mac Apps Leave Developers Uneasy, Users Paying Twice (October 2019).