Tuesday, August 25, 2020 [Tweets] [Favorites]

Potential

Francisco Tolmasky (member of the original iPhone team):

Apple’s iOS rules would not have allowed for the invention of the web browser. Let that sink in. They would have rejected one of the most important technical innovations in the history of computing. Microsoft‘s bully tactic of making IE free seems quaint in comparison.

But here’s the kicker: think of all the other amazing ideas that haven’t gotten a chance to be invented because they aren’t allowed on mobile devices. Mosaic happened less than 10 years after the Macintosh. We very well might have already had a browser-caliber invention by now.

Just for people asking: the flagrant violations of AppStore policy that web browsers would be rejected for in this hypothetical are:

1) Running outside code
2) Allowing payments that circumvent Apple’s IAP
3) Allowing access to NSFW content

Loren Brichter:

This.

And honestly the very idea of a “Web browser” needs a competitor (see: Google), but can’t happen because it wouldn’t be allowed on the computer you all already have in your pocket.

Ben Thompson:

This is the chief reason why, if I had to choose a victor in this case, I would choose Epic; Apple is a brilliant company, but they hardly have a monopoly on invention and innovation. My overriding concern is that their monopoly on iOS (and duopoly with Google, which copies many of their App Store practices) will prevent the invention and innovation of others.

Alex Hern:

One of the under-discussed downsides of Apple’s growing insistence that it take 30% of all commerce that occurs on or near iOS is that it massively entrenches the privacy-violating ad-funded business model that Apple professes to be fighting

No 30% cut for Apple if I fund my business by selling my customers’ personal data!

Rasmus Andersson:

Dropbox is an example of a product and company that would not have existed if it wasn’t for hackable OSes. Innovation inside Apple’s sandbox only allows “innovation” that Apple has already thought of and allowed. Totally fine for consumption but terrible for innovation.

And backup apps and emulators and Little Snitch.

Jason Fried:

If the [Apple-HEY] decision would have gone the other way, I was considered quitting, and basically retiring. […] Here’s why: I didn’t get into business — I didn’t start a business — to be told what to do by another business. […] We’re self-funded. We do everything our own way so that we can do it our own way. And to be in an industry where if Apple forced us to have to give them 30% of our business and not be able to interface with our customers the way we want, I don’t want to be in that industry.

Manton Reece:

Apple’s total control over iPhone app distribution and payment is preventing developers from doing their best work. The App Store started with good intentions, to help users, but the rules have become twisted, corrupted as Apple gains power.

Jason Snell:

I can’t tell you how many developers I’ve talked to who have similar stories.

Patrick Wardle:

Creating an open-source tool for macOS in 2020:

💻 Buy Mac ($1000+)
🎟️ Create Apple Dev. Account ($99/yr)
🏢 Create company (Entitlement pre-req!)
🤞 Beg for Entitlement(s)
🎫 Create/Install Signing Profile
📝 Write code (yay!)
🔐 Sign w/ Profile
📦 Notarize w/ Apple

(User) Installing an open-source tool for macOS in 2020:

⚠️ “Ok” on Gatekeeper alert
⚠️ “Ok” on System Extension Blocked alert
⚙️ Open System Preferences
🔓 Authenticate
✅ “Allow” in System Preferences
⚠️ “Allow” in Filter Network Content alert

Rosyna Keller:

For a normal open source tool/app, these additional steps aren’t needed.

It’s part of adding high-friction UX for methods that malware authors would use in the past to gather massive amounts of user/confidential information.

It’s a tradeoff because these features meant to protect users also add friction that make the products harder to use, which makes them harder to sell and more expensive to support. That, plus the delay and uncertainty of being able to get an entitlement, mean that fewer such products will be developed. We’ve come a long way from the early days of Mac OS X where the developer tools were included on the disc, and anyone could start writing code and sharing their work with people.

Various Mac operations get slower, and now I often see UI freezes and high CPU use caused by the security subsystems. There’s more potential for bugs, both because of the more complicated interaction between apps and the OS and because of problems with the OS itself. The steps Wardle describes seem obscure but straightforward enough, once you know them. But that’s the happy path. I’ve seen countless cases where a security-related file or database got messed up, and it was difficult for the user to fix it because of System Integrity Protection. Sometimes the cause of the wedging remains a mystery, and the only solution seems to be to reinstall macOS.

Development is more complicated because the security stuff is always changing and is often undocumented. New requirements are added in late August, months after the first WWDC build. One of the changes in Big Sur makes it much slower to develop my Mail plug-in. Previously, notarization was only necessary when shipping software to customers. Now, I need to notarize the plug-in each time I make a new build to test on my own Mac. In the best case, after writing some scripts to automate the process, this adds a few minutes to each build cycle. Yesterday and this morning, something was wonky with the notarization server, and notarization took almost an hour.

See also: Accidental Tech Podcast.

Previously:

Update (2020-08-26): Jeff Johnson:

Yesterday I had to reinstall the Big Sur beta (because Software Update was hosed). The installer app silently froze for a very long time on launch.

XProtect

Update (2020-08-27): Francisco Tolmasky:

One of the most troubling kinds of replies I got to this was that Apple would “of course” know how important the browser would be and make an exception. Setting aside the improbability of this, this defense of the rules is that Apple will break the rules at the right times.

This is a truly (sigh) 1984 mentality. The rules don’t even matter, why even bother arguing their logic? Apple will just make the right decision when necessary, regardless of the rules. Disregard that Apple can’t realistically spend that much time considering each submission.

Would anyone accept a bad law because they know that judges, in all their wisdom, would know when to not apply it? Do we think that AppStore reviewers are better judges of the future potential of every app they see than legal judges are of our own laws?

Ross Boucher:

I mean, they explicitly made a rule to block other browsers, so I’m not sure why anyone thinks they would have allowed the first one.

Brian Armstrong:

Apple has been very restrictive and hostile to cryptocurrency over the years. They’re still blocking some functionality right now, including the ability to earn money with cryptocurrency by completing tasks, and unrestricted dapp browsers.

Update (2020-09-14): Brian Armstrong:

I feel like Apple customers should be made aware: the crypto apps you use on iOS are not missing some features you want because the teams haven't gotten to them, those features are being censored by Apple.

UTM (via Tanner Bennett):

UTM is a full featured virtual machine host for iOS. In short, it allows you to run Windows, Android, and more on your iPhone and iPad.

But it’s not allowed in the App Store.

5 Comments

We started notarizing all our builds on our CI server around a year ago when it became a requirement. Apple said we should only have to notarize the builds we actually release, but we're not always sure ahead of time which builds will be release builds, and we wouldn't want to accidentally ship an un-notarized build. (We do test these things, but mistakes can happen.) It's also really helpful to have the builds already notarized when we distribute them for QA testing.

On average, notarization adds about three and a half minutes to our build times when the notarization server is working. Fortunately, we don't need to notarize to test on our own Macs, so it's not so bad. However, we've noticed the notarization server seems to suffer outages every few weeks. It's usually only for a couple hours, but in the year since we adopted this, an extended outage delayed a release by a day one time. The notarization status page isn't always updated to reflect this, so maybe it's just that notarization starts taking over an hour and our CI server gives up before then.

Given the somewhat regular outages, you're probably looking at a lot more disruptions to your workflow. I'm guessing that for your case, Mail.app is refusing to load un-notarized plugins, and that turning off SIP isn't sufficient to work around the problem. But if you can find any workarounds, even if they require disabling SIP, I would highly recommend it. Otehrwise you're looking at potentially days of lost productivity over the next year.

@Michael In this case, disabling SIP does help, but I don’t want to do that because a lot of the stuff I’m developing/testing these days is related to security changes Apple has made. I need to be sure that everything works with SIP enabled because that’s how my customers run their Macs.

Old Unix Geek

Cynical Thought: It's only to Apple's benefit if the App Store rules preclude new inventions. That way, people who invent cool new ideas gain little traction, because they can't do it on a platform most of the public uses. Apple can look around at third party inventions elsewhere, cherry pick them, add them to their OS, and call them "their innovations". Apple fanboys dutifully applaud, and feel so lucky to have such a great platform with such state of the art developments. Wash, rinse, repeat. E.g. most deep learning is done on NVidia GPUs, which Apple does not support, but then you can run the resulting network on Apple's "Neural Engine", and they claim the credit.

I just wanna say you've been doing a GREAT job covering all this, Michael. Thanks a lot for that!

Old Unix Geek

Here is another example. Facebook (yes, but read on) allows users to sell online events. They wanted to tell users that Apple would take 30% of the price charged on an iPhone, and the small business/user would get 70%. Facebook would get nothing. But Apple prevents them from informing their users of this. In other words, to protect their own rent-seeking, Apple actively prevents people from knowing about it, interfering in the relationship between a company and its customers.

https://arstechnica.com/tech-policy/2020/08/facebook-says-apple-vetoed-telling-users-about-30-percent-event-charge/

Stay up-to-date by subscribing to the Comments RSS Feed for this post.

Leave a Comment