Theo on iOS: Developer Friction, App Store Rules and the Future of Mobile

I prefer iOS and love my iPhone, but I think Apple’s control over the platform increasingly holds software back. Building and shipping our T3 Chat and T3 Code apps has made those restrictions feel especially frustrating. My concern extends beyond the iPhone to how the whole mobile industry develops.

I think about software in terms of importance, cost and capability: these are different dimensions, not necessarily linked. The original iPhone made mobile software more capable and more important, even though developing for it could also cost more than making the simpler mobile applications that preceded it.

Theo plays a historical Steve Jobs presentation in which Jobs describes using Safari and web standards to create and distribute iPhone applications without a separate SDK. Jobs presents web distribution and updates as advantages; Theo sees that early vision as much more open than today’s mobile development experience.

I recognize that the original mobile web had limitations, but the promise of easy experimentation matters. In my view Apple’s incentives changed as its market position grew. I believe its control of distribution and payments now gives it less reason to make developers’ lives easier.

I focus on the familiar 30% commission as an example of Apple’s incentives and argue that iPhone users represent a disproportionate share of mobile spending. Actual commission rates and payment rules vary by program, transaction and region, so the percentage should not be read as universal.

The immediate trigger for this video was an iPad. My team’s app ran on my registered phone, but when I added my iPad to the developer workflow, the device remained pending for 36 hours. I could not install the app I helped build on the device I owned while that process was stuck.

Even after the device was approved, another obscure message led me to a developer agreement hidden in an account dashboard. Multiple redirects and banners made the issue difficult to find. My complaint is about how much process stands between a small change and trying it on my own hardware.

Signing, provisioning and distribution each impose their own requirements. I find the need for a Mac, account setup and project-specific signing configuration particularly painful for open-source contributors who simply want to modify and test an app. Tools such as Expo can hide some of the complexity, but they do not remove every platform constraint.

I also complain about seven-day reinstallation and recurring signing work. Apple’s documentation specifies that seven-day provisioning applies to free Personal Team profiles; it is not a universal requirement for every paid developer setup. Likewise, the available testing and distribution paths depend on the account and region. [Apple developer documentation](https://developer.apple.com/help/account/basics/about-your-developer-account/).

These steps feel hostile to experimentation. If an application is open source, I want to change it, test it and contribute without navigating an account-specific maze. I think the friction discourages people who are curious about how software works, including people who already like Apple’s devices.

Sandboxing is another part of the argument. I want applications to collaborate and users to customize their behavior more easily, for example with changes comparable to browser extensions. iOS does offer specified sharing and inter-app mechanisms, but I find their scope and ergonomics too restrictive for the ideas I want to build.

I also criticize restrictions on just-in-time compilation and dynamic execution, which affect possibilities for emulators and other tools. The exact technical permissions have exceptions and depend on the app and region; my point is that developers cannot assume the same freedom available on a desktop.

Browser engines illustrate that distinction. I object to Apple’s longstanding WebKit rules because I want browser makers to experiment with their own engines. Apple now documents alternative-engine entitlements in the EU and Japan subject to requirements, so the rule is not a blanket worldwide prohibition. [Apple developer documentation](https://developer.apple.com/support/alternative-browser-engines/).

I want software that can be extended and combined in ways its original creator did not anticipate. Apple’s security and review boundaries limit that experimentation, in my view, even though some approved extensions and sharing mechanisms exist. The question is how much control users should be able to exercise on their own devices.

On distribution, I argue that app review and marketplace rules give Apple too much control over what reaches users. The actual options differ by region and have changed over time, including alternative distribution in some markets. My broader criticism is that developers face gatekeeping even when they already have willing users.

I give examples involving game streaming and sign-in policies, arguing that rules can exclude useful products. Those examples need qualification: Apple’s published guidelines address streaming games and include exceptions for some enterprise sign-ins. A developer should check the current rule for the specific app instead of treating my examples as universal bans. [Apple developer documentation](https://developer.apple.com/app-store/review/guidelines/).

Payment restrictions and commissions matter to creators and platforms because each party has costs. I describe Twitch subscriptions, creator support and the difference between digital purchases and physical services as examples of how policy can shape a business model. Applicable rates and external-payment options depend on the transaction and jurisdiction.

At Twitch, I remember working around the economics and restrictions of in-app subscriptions using a separate in-app currency. I find it absurd that a platform should have to redesign a simple subscription flow around a store’s payment rules. The specific arrangements and rules may have changed since that experience.

App review is another source of unpredictability. I say reviewers have mistyped the test credentials I provided, delaying updates. My concern is not that every review goes wrong, but that a developer can be blocked by a process they cannot directly debug or control.

I am also angry about misleading subscription offers, especially when children encounter expensive recurring charges after a free trial. I believe Apple should do more to prevent predatory designs. My claims about the company’s motives and the scale of its revenue from such apps are my own accusations, not demonstrated measurements here.

My next complaint is Xcode. I attribute some of its design and age to Apple’s NeXT heritage, but the practical issue for me is what happens today: crashes, reindexing, caches that need clearing and builds that repeat work. Those are experiences and complaints, not a full history or an assessment of every Xcode project.

I describe opening Xcode only to see unchanged files reindexed and substantial memory consumed. Simulator downloads and maintenance add friction too. For developers who primarily work on another operating system, relying on Apple’s toolchain to produce iOS binaries can also mean maintaining access to a Mac.

Expo can improve the iteration loop: after the native shell is available on the phone, JavaScript can be loaded from a development server. I still worry about approval and signing when distributing or testing a dynamically updated app. My concern about T3 Code’s review is a prediction, not an actual rejection.

I ask an AI to gather further complaints and compare them with my own experience. The list includes incremental builds that unexpectedly repeat work, confusing error messages, clearing derived data and restarting the IDE. An AI-generated list is a starting point for investigation, not independent proof that every item applies to every developer.

SwiftUI and type checking provide another example: a concise expression can become hard to compile or diagnose, and the error may not clearly identify the underlying problem. I find this especially frustrating when developers have to reshape otherwise reasonable code to get past tooling limits.

Mixed-language and dependency-heavy projects add more moving pieces. I point to third-party tooling such as CocoaPods and the challenges of coordinating large builds. Apple platforms also have other dependency mechanisms, so my criticism is about the workflow and its history, not a claim that no package system exists.

I describe problems with indexing, SwiftUI previews and the debugger, and ask viewers whether they use previews. Their chat responses are anecdotes rather than a representative survey, but they echo the frustrations I have had. The issue for me is the accumulation of small failures in a required toolchain.

Simulators create another testing gap: they can consume substantial disk space, lose useful functions, and behave differently from physical devices. Login, push notifications, background behavior and entitlements are among the areas where I have found those differences hard to reason about.

I also dislike project.pbxproj changes that are difficult to read and can create merge conflicts. The generated research shown on screen notes that newer synchronized folders and external project-generation tools can help. My complaint is that teams still have to spend effort managing project structure alongside the code itself.

A viewer says iOS developers eventually get used to the quirks. I reject that as a sufficient answer: recurring build failures, debugging friction and slow feedback still cost time even when a team learns to work around them. Familiarity should not be the same as accepting a poor development experience.

My broader worry is about AI that changes how we use a computer rather than merely adding a chatbot to an app. On desktop I use voice input, window-management tools and agents that can interact across applications. These tools modify the workflow around apps, not just the content of one app.

For example, Wispr Flow can transcribe speech into whichever desktop text field I am using, while Codex can work with a browser and other applications. Desktop automation still has its own problems, but I can experiment with it. I want a similar range of choices on mobile.

On iOS, I describe the voice-input app’s keyboard workaround and the extra steps it takes to access the microphone. I see this as an example of how platform boundaries can shape the product itself. My prediction that certain experiences will never be possible is an opinion about Apple’s direction, not a proven forecast.

Theo plays a clip of designer Scott Jenson discussing the difficulty of shipping unconventional ideas at Google. Jenson recounts being told that a feature would be easier to ship after Apple did it first. Theo uses the anecdote to argue that Android too often follows Apple rather than exploring alternatives.

I think Android shares many of the same problems, though it does have different capabilities and choices. My claim that Google copies Apple’s incentives is an interpretation, not evidence of Google’s internal motives. I would like Android to embrace more customization and give users more room to experiment.

I have even begun experimenting with an Android fork for the customization I want, although I do not know whether it will lead anywhere. The point is not that one existing platform already solves everything; it is that mobile devices should invite more experimentation than they currently do.

Imagine a child building an app on an iPad and sharing it with friends, or a person adapting the interface to their own accessibility needs. I want multiple assistants and input tools to compete for system-level usefulness, and I want building and sharing software to feel approachable.

When I tried to describe on-device builds for my Android experiment, even the model I used kept assuming a remote server or a virtualized environment. What I actually wanted was something familiar from a desktop: install software, build it locally and change how the device behaves within appropriate boundaries.

I still consider the iPhone remarkable hardware. My request to Apple is to let that hardware support more experimentation: install more software, build on the devices themselves and choose how to interact with them. These are goals for a different product direction, not a claim that the security trade-offs disappear.

I worry that children growing up with locked-down devices may encounter software mainly as something they consume, rather than something they can change. That is my concern and not a measured conclusion about a generation. I want the next generation to have opportunities to create and share their own experiences.

I do not know whether Apple will change, and I am frustrated enough to consider moving more of my work to Linux. Yet I still need access to Apple tools for iPhone development. I hope people give children opportunities to explore computers and understand that software can be changed.

My closing request is simple: treat these powerful devices as platforms for creation as well as consumption. I want people to be able to install, experiment and learn, instead of assuming that the only possible software is the software a platform owner has chosen for them.