Falling out of Love with Apple, Part 1

In this first post of a three-part series, we discuss how Apple's approach to software and services curtails innovation and human creativity.

State of Hardware is a new weekly newsletter by Zach Herbert of Foundation Devices that evaluates hardware’s impact on our society through the lenses of privacy, sovereignty, and freedom. Subscribe below and read on!


I fell in love with Apple in 2008, from the day I ditched my Palm Treo 680 for an iPhone 3G. The iPhone was made of glass and shiny black curved plastic. It perfectly fit in my hand. It came with a revolutionary App Store. It made my Treo feel like an antiquated brick.

Sure, I had owned several iPods. But I was never interested in Apple computers. I and so many others mocked the Mac for being closed off, restrictive, and cultish.

The iPhone changed my view of Apple and of Macs. I soon built a Hackintosh on a Dell Mini 10v netbook. Before I knew it, I was working in my local Apple store after graduating high school. I arrived at 5am to work the exhilarating iPhone 4 launch. I greeted customers with a first-gen iPad in hand. I bought my first of many Macbooks. I joined the cult.

It’s dangerous to fall in love with a company. When Steve passed in 2011, Apple’s culture and leadership began to change. Instead of a relentless focus on product innovation and customer delight, priorities shifted to maximizing growth and extracting more revenue per user.

Apple has morphed into what it once opposed. Apple is now the Goliath, the new Big Blue, the monopoly.

Much has been written about Apple’s anti-competitive, walled garden, and monopolistic tendencies. My first instinct was always to jump to Apple’s defense. But lately I’ve been thinking about the big picture, about what our world today would look like if Apple behaved different.

I’ve ultimately concluded that Apple is strangling hardware and software innovation and stifling human creativity. This is why I am falling out of love with Apple.

This post is the first in a three-part series. This week, we will discuss software and services. Next week, hardware and accessories. And the week after, content and conclusions.

Part 1: Software and Services

Apple’s 30% App Store tax is well documented and discussed. Coalition for App Fairness estimates that Apple generates over $15B per year in revenue from fees on app purchases and in-app payments. We can argue that this fee is too high and we can argue that developers should be allowed to implement alternative purchase methods. We can file antitrust cases against Apple and we can publicly pressure them to reduce this fee. Some of these efforts may be successful. But does this address the true problem?

I believe the Apple tax distracts us from the major issue: the harsh technical restrictions that Apple places on third party apps and services. These restrictions make it difficult for entrepreneurs to compete with Apple’s native offerings, ensuring that their apps will always be handicapped.

These technical restrictions are more than merely anticompetitive; they are anti-innovation. Below are some examples.

Restricting Default Apps

With the recent introduction of iOS 14, Apple now allows users to change their default email and browser apps. For example, users can now set Gmail as their default email client and Chrome as their default web browser.

But all other app categories are straight outta luck. Messaging apps like Telegram and Signal cannot replace Apple’s Messages. Calendar apps like Fantastical cannot replace Apple’s Calendar. Camera apps like Halide cannot replace Apple’s Camera. Music apps like Spotify and Pandora cannot replace Apple Music.

If an entrepreneur creates an incredibly powerful Siri competitor, she cannot set it as the default virtual assistant. The app would be crippled before it even launches, as the only way to access it would be via a workaround through a widget, shortcut, or – amusingly – via Siri.

I believe this is one of the reasons we’ve seen little innovation in certain app categories like virtual assistants and no innovation in prohibited app categories like phone-app alternatives. Why should Apple decide what categories of apps are allowed to succeed?

Crippling Competing Technologies

When Apple effectively cripples technologies that might compete with its core offerings, Apple is hampering innovation and harming entire industries.

One clear example is Apple’s policies towards Bitcoin and cryptocurrencies. Apple currently allows wallets and exchanges in the App Store, but prevents most other use cases.

Coinbase’s Brian Armstrong posted a tweetstorm back in September about the company’s run-ins with Apple. Highlights below:

Even if you don’t like Coinbase as a company, think Bitcoin is akin to tulips, or think DeFi and Dapps are scammy, you must recognize that if Apple can do this to Coinbase, it can do this to any app.

Allowing people to earn money via Bitcoin or cryptocurrencies could circumvent Apple’s 30% App Store tax. And allowing access to decentralized applications could allow the App Store to be circumvented entirely. In this instance, Apple’s policies threaten an emerging industry. What other industries are affected?

Prohibiting Desktop-Class Features

The latest iPhones and iPads possess desktop-class processing power, but restrict developers from implementing desktop-class features. This has ruined my ideal future of mobile-desktop convergence.

I dream of a day where my phone is my primary computer, and I can simply pair it throughout the day with various peripherals. I’d connect it to a 27-inch 5k display with external mouse and keyboard for work, and then to an 11-inch touchscreen display while reading in a coffee shop. I’d connect to a VR headset for some weekend gaming, and then to a 60-inch TV for movie night.

This idyllic future is impossible because iOS restricts desktop-class features.

No Background Tasks

It’s common knowledge that most apps on iOS are prohibited from running in the background. There are partial exceptions for audio apps, location-aware apps, and apps that communicate with bluetooth accessories.

This restricts entire categories of apps that require background functionality to be useful. For example, I’ve experimented with replacing iCloud with Resilio, a peer-to-peer file sharing app (spun out of BitTorrent) that allows users to mirror their files across multiple devices. I envisioned a setup where my iMac, Macbook, iPad, and iPhone all stored redundant copies of my data – and anytime a change was made on once device, it would instantly sync to the others.

Resilio makes this possible on desktop OS’s and on Android; it works incredibly well! But on iOS background syncing is not allowed. While Apple makes it relatively straightforward to integrate Resilio with the Files app, Resilio will not automatically update and download my latest data unless manually opened. This is unusable.

What other categories of apps are disqualified because they rely on background tasks? An intriguing example is Bitcoin nodes, which must be online and syncing with peers 24/7. Bitcoin wallets must also be online in order to notify users of incoming transactions. Due to iOS’s restrictions, the excellent BlueWallet was forced to develop a hosted push notifications server, rather than allowing the app itself to remain online and aware in the background.

No Software Development

A key missing desktop-class feature is the ability to write software on an iOS device. For example, Apple has always banned fully functional terminal environments from the App Store. If developers are prohibited from developing software on iOS devices, then iOS devices will forever be crippled.

This reminds me of a fantastic essay from Paul Graham over a decade ago:

How could you make a device programmers liked better than the iPhone? It's unlikely you could make something better designed. Apple leaves no room there. So this alternative device probably couldn't win on general appeal. It would have to win by virtue of some appeal it had to programmers specifically.

One way to appeal to programmers is with software. If you could think of an application programmers had to have, but that would be impossible in the circumscribed world of the iPhone, you could presumably get them to switch.

That would definitely happen if programmers started to use handhelds as development machines—if handhelds displaced laptops the way laptops displaced desktops. You need more control of a development machine than Apple will let you have over an iPhone.

– Paul Graham, Apple’s Mistake, November 2009

The current paradigm for writing software on iOS involves connecting a terminal app to a remote Linux server – so the iPad is purely the interface to the remote server. Paul Miller documented this in 2018.

This has led developers of terminal apps to employ creative workarounds to maintain background connections to the remote server, such as Panic’s use of background location services in Prompt 2:

As Prompt can’t make use of other iOS backgrounding options (like turn-by-turn navigation or media playback) this was our best option to allow users extended background time on iOS. Without this, Prompt is limited to iOS’ general background time limit, explained below.

This initially allowed Prompt 2 to maintain a background connection for 10 minutes, but iOS 13 sadly closed this loophole.

Interestingly, an app called iSH Shell made headlines a couple weeks back when it was allowed into the App Store. iSH allows users to run a full Linux shell within iOS. Unsurprisingly, as the iSH team posted, Apple reached out four days later and threatened to remove them from the App Store. But then, after a public outcry, the app’s removal has now been delayed.

One common pattern is that Apple only reconsiders a removal notice if the issue goes viral. The lesser-known a-Shell app, for example, is still scheduled to be removed.

Apple’s behavior prevents entire categories of apps from being developed – would you spend months writing a software development app if you knew there is a 90% chance that Apple will remove or reject it from the App Store?

Poor External Display Support

Another key feature crippling iOS is lack of proper external display support. While iOS provides basic support for mirroring or extending displays, the implementation is severely limited.

First, there is no support for scaling. When mirroring an iPad, for example, there are unsightly black bars on either side of the external display due to pillarboxing. Fonts appear comically large, and it’s difficult to use this setup for anything productive.

Second, support for screen extending is limited at best. It is primarily designed for games, presentation apps like Keynote, or video apps like VLC. A few productivity apps like MindNode support extending without pillarboxing, and others like Shiftscreen are explicitly designed to provide a full web browser and web app support in an attempt to work around iOS’s limitations.

Moreover, screen extending when multitasking on iOS is confusing and broken. In split-screen view, the app on the left side of the display is considered the primary app and can drive the external display. If moved to the right side, it can no longer extend to the external display! Nowhere in iOS does it indicate which app is primary and secondary; this is a broken implementation of multitasking with edge cases left unaddressed.

Federico Viticci of MacStories provides a fantastic, in-depth post about using his iPad as a primary computer. Not many people besides Federico could figure this out:

First, due to a legacy aspect of the iPad’s multitasking system, it is possible to use two apps in Split View and let one of them output full-screen content on an external monitor; however, that app has to be placed on the left side of the Split View. With this in mind, I can open iA Writer or Notes on my iPad, create a Split View with Shiftscreen on the left, and take notes while looking at a big, full-screen webpage on my UltraFine 4K display. Shiftscreen doesn’t have native integration with the iPadOS pointer yet (although it should be coming soon), but clicking and dragging on its virtual touchpad is good enough for now.

If Apple provided proper external display support on iOS, we could all be plugging our iPads and iPhones into external monitors and taking advantage of the powerful 5nm A14 processors for desktop-class work. Instead, we are forced to use our iOS device as mere consumption companions to our Macs.

I suspect this is intentional – restrict iOS functionality and prevent cannibalization of Mac sales.

Curtailing Personalization

iOS 14 introduced some workarounds to enable home screen customization; users can now change the look of the home screens with widgets and alternative icons. We immediately saw an explosion of apps to take advantage of these new features, with countless user screenshots displaying creative and novel home screen designs across Twitter, Instagram, and TikTok.

Widgetsmith was propelled to the top of the app store, and even now there are new apps being created to take advantage of other creative opportunities (like the Clear Spaces app, which provides blank widgets).

This reaction to iOS 14 clearly demonstrates the level of pent-up creativity possessed by users and developers. If only Apple gave us the ability to fully customize our devices and express our personal tastes.

False Privacy

Apple has begun marketing the iPhone as a privacy-preserving device, in a clear contrast to Google’s Android. But does iOS really preserve user privacy, and are Apple’s motives pure?

I think Apple is marketing false privacy. Apple’s version of privacy means that only Apple can store your data – and developers must go through Apple to get it. In my opinion this is not true privacy; this is merely another way to control developers and lock users into the Apple ecosystem.

Sign in with Apple

Apple’s implementation of Sign in with Apple, at first, appears to be a more user friendly and privacy preserving authentication option. Rather than providing an email address and creating a new password for each service, users can simply select Sign in with Apple. If desired, users can keep their email address hidden from the app developers, and instead provide a randomly generated Apple email address.

In practice, this means that Apple becomes the gatekeeper. Apple can choose to reject a service from its ecosystem and prevent users from logging in. For users that elect email privacy, Apple acts as the email delivery middleman – with the power to withhold or censor emails sent from developers to users.

This increases Apple’s power and ability to serve as gatekeeper while diluting the connection between app developers and users.

Ad Policy

Apple sparked a huge amount of controversy with its new policy in iOS 14 to ask users to opt-in to ad tracking via IDFA. Due to the uproar from both large companies like Facebook and small app developers, Apple has decided to delay this change until early next year.

But is this new policy good or bad for user privacy? At first, it seems pro-privacy and user friendly. It gives users the ability to opt out of tracking their behavior in iOS, which provides more privacy and control over data collection.

However, these changes give Apple more power in advertising. By taking power away from Facebook, Apple has more leeway to implement its own ad networks. As explained in Input Magazine:

But it's notably allowing itself to continue tracking IDFA's without user consent, which could draw more anti-competitive scrutiny at a time when the company is under attack for some quarters for hampering developers who try and bypass its 30 percent commission.

This opens the door for Apple to build a competing ad network. Apple already offers ads within App Store search results. It would not be unthinkable to imagine Apple expanding its ad functionality in an attempt to extract more revenue from its ecosystem, while simultaneously reducing the power of competing ad networks.

I love the idea of reducing Facebook’s ability to track me across my iOS devices. But not if that gives Apple exclusive power to track me, extract more money from app developers, and show me more targeted ads.

Search Deal with Google

While heavily advertising user privacy, Apple accepts $8-12 billion per year from Google to make Google its default search engine across iOS and MacOS. This represents a staggering 14-21% of Apple’s annual profits.

Apple and Google explicitly work together to increase revenue from Google’s search. As detailed in the New York Times:

In fact, Mr. Cook and Mr. Pichai met again in 2018 to discuss how they could increase revenue from search. After the meeting, a senior Apple employee wrote to a Google counterpart that “our vision is that we work as if we are one company,” according to the Justice Department’s complaint.

This search deal undermines any genuine privacy efforts pursued by Apple. Both Apple and Google want all search data flowing through Google. Google then uses this data to target users with advertising.

According to a former senior executive who spoke on the condition of anonymity because of confidentiality contracts, Apple’s leaders have made the same calculation about Google as much of the general public: The utility of its search engine is worth the cost of its invasive practices.

As Google fights antitrust battles that threaten the Apple-Google search deal, Apple is rumored to be actively developing its own search engine. This worries me, as an Apple search engine would likely be pushed as the default search engine on Apple devices, and it would likely display targeted ads.

I’ll continue to use DuckDuckGo, thank you very much.

iCloud Backups

Apple devices are encrypted locally, but data stored on iCloud – such as iMessages, photos, notes, and reminders – are not end-to-end encrypted. Apple has a key and frequently cooperates with law enforcement across the world.

The company said it turned over at least some data for 90% of the requests it received. It turns over data more often in response to secret U.S. intelligence court directives, which sought content from more than 18,000 accounts in the first half of 2019, the most recently reported six-month period.

Apple originally intended to implement end-to-end encryption in iCloud, but reportedly abandoned its plans after pressure from the FBI.

This behavior is anti-privacy and hostile to users. While Apple makes a big deal out of not cooperating with the FBI on unlocking terrorist’s iPhones, it readily makes data for tens of thousands of users annually accessible to law enforcement across the world.

Yes, this includes communist regimes like China – where citizens do not have a right to free speech or privacy. By refusing to add end-to-end encryption and cooperating with law enforcement, Apple is tacitly supporting the efforts of oppressive governments. Anything for more iPhone sales!

Closed Source

Finally, it is impossible to know exactly what Apple is doing with our data because everything is closed source.

How do we know iMessages are encrypted? How do we know Apple doesn’t have a back door? With closed source software running on closed source hardware, we are forced to trust Apple 100%. There is no oversight.

This critique is not unique to Apple. But over the last few years, as tech companies have continued to violate our trust, I’ve developed a strong preference for open software and open hardware. Security via openness is far more robust than security via obscurity.


I hope this post offered a more refreshing, higher-level analysis of how Apple restricts software and services on iOS – and how these restrictions affect our privacy, sovereignty, and freedom as individuals and businesses.

Enjoyed this first part? Subscribe below and leave a comment!