{"id":29878,"date":"2020-08-25T16:28:07","date_gmt":"2020-08-25T20:28:07","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=29878"},"modified":"2023-12-06T14:23:24","modified_gmt":"2023-12-06T19:23:24","slug":"potential","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/08\/25\/potential\/","title":{"rendered":"Potential"},"content":{"rendered":"

Francisco Tolmasky<\/a> (member of the original iPhone team):<\/p>\n

\n

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.<\/p>\n

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.<\/p>\n

Just for people asking: the flagrant violations of AppStore policy that web browsers would be rejected for in this hypothetical are:<\/p>\n

1) Running outside code
\n2) Allowing payments that circumvent Apple’s IAP
\n3) Allowing access to NSFW content<\/p>\n<\/blockquote>\n\n

Loren Brichter<\/a>:<\/p>\n

\n

This.<\/p>\n

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.<\/p>\n<\/blockquote>\n\n

Ben Thompson<\/a>:<\/p>\n

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.<\/p><\/blockquote>\n\n

Alex Hern<\/a>:<\/p>\n

\n

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<\/p>\n

No 30% cut for Apple if I fund my business by selling my customers’ personal data!<\/p>\n<\/blockquote>\n\n

Rasmus Andersson<\/a>:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n\n

And backup apps<\/a> and emulators and Little Snitch<\/a>.<\/p>\n\n

Jason Fried<\/a>:<\/p>\n

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.\n<\/p><\/blockquote>\n\n

Manton Reece<\/a>:<\/p>\n

\n

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.<\/p>\n<\/blockquote>\n\n

Jason Snell<\/a>:<\/p>\n

I can’t tell you how many developers I’ve talked to who have similar stories.<\/p><\/blockquote>\n\n

Patrick Wardle<\/a>:<\/p>\n

Creating an open-source tool for macOS in 2020:<\/p>

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

(User) Installing an open-source tool for macOS in 2020:<\/p>

⚠️ “Ok” on Gatekeeper alert
\n⚠️ “Ok” on System Extension Blocked alert
\n⚙️ Open System Preferences
\n🔓 Authenticate
\n✅ “Allow” in System Preferences
\n⚠️ “Allow” in Filter Network Content alert<\/p><\/blockquote>\n\n

Rosyna Keller<\/a>:<\/p>\n

\n

For a normal open source tool\/app, these additional steps aren’t needed.<\/p>\n

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.<\/p>\n<\/blockquote>\n\n

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.<\/p>\n\n

Various Mac operations get slower<\/a>, 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.<\/p>\n\n

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<\/a>. 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.<\/p>\n\n

See also: Accidental Tech Podcast<\/a>.<\/p>\n\n

Previously:<\/p>\n