There are so many parts of Steve’s iPad Pro manifesto I would quote here on MacStories, but I’m going to limit myself to just a couple of excerpts.

What I like about this story is that it’s a balanced take on the limitations of iPadOS from the perspective of a developer, laid out in a comprehensive roundup. It serves as a great companion piece to my story, but from a more technical angle.

Here, for instance, is a well-reasoned assessment of why Stage Manager isn’t ideal for developers of iPad apps:

Stage Manager was such a missed opportunity: it tried to bolt-on a windowing model onto iPadOS without providing developers any way to optimize for it, and has had virtually no meaningful improvements in two years. What I really want to see are APIs. APIs to know when an app is running in Stage Manager and give it an opportunity to enable extra functionality to accommodate that — like having an ‘open in New Window’ context menu option that it would otherwise hide. APIs to set window size/shape, minimum and maximum size. APIs to open a window in split view if possible, with a preferred screen side. APIs to drag a window on mouse-down. Auxiliary views or inspector panels that can be floated on/near a primary window, like visionOS’ ornaments.

Many of these features are available as APIs to apps using the iOS SDK… on macOS and visionOS. Which is why it boggles the mind that iPad’s own Stage Manager spec completely shunned them, and ignored the explicit intent provided by developers as to how they want their apps to work. Stage Manager wasn’t provided as an opportunity to make our apps better, it was inflicted on developers in a way that harmed the developer, and user, experience. Which is why today you can very quickly stumble upon apps that don’t quite resize correctly, or have important parts of the UI covered by the virtual keyboard, or toolbars floating in strange places.

To this day, developers have no way to fine-tune their apps so that they behave differently (and better!) when Stage Manager is active. This part about JIT is also worth calling out:

Just-in-time compilation is essential to power things like web browsers, console and PC emulators, and language-based virtual machines. It is used by Apple’s own apps, like Playgrounds, to empower key functionality that no third party app can match. And it is provided in a very limited way (with a ton of asterisks) to Alternative Web Browsers in the EU under the DMA, so they can implement their own JavaScript engines. The DolphiniOS project, which emulates Nintendo’s GameCube, recently posted a video that perfectly encapsulates the problem and demonstrates why emulators for newer consoles just can’t come to iPadOS. Other app stores, like Microsoft’s Windows Store, offer a JIT entitlement as standard, and I think Apple should, too.

It’s not like JIT cannot exist on iPadOS; it’s that Apple has chosen not to offer it as an entitlement for third-party developers.

I also want to point out two more aspects of Steve’s manifesto. It’s almost a 1:1 match of a story he wrote for us in 2019, which is quite sad as it tells you a lot about iPadOS’ state of affairs. Five years later, and we’re still asking for the same changes. Additionally, it should be noted that Steve is not asking for Apple to call it a day and put macOS on iPad. Claiming that someone who criticizes iPadOS does so because “they just want the iPad to turn into a Mac” has become the de rigueur dismissal for some reply guys these days, and it completely misses the point.

I highly recommend reading Steve’s full story here.