iOS/iPadOS does allow you to have one code base that dynamically responds to screen sizes.

But almost always the experience for iPad users is terrible.

Which is why Apple's initial approach of forcing developers to build distinct iPad apps was the right one and a large reason why its tablets dominated the market versus Android competitors.

> iOS/iPadOS does allow you to have one code base that dynamically responds to screen sizes. But almost always the experience for iPad users is terrible.

are you saying the tools aren't there for developers to create equally pleasing (mutatis mutandis) apps, or simply that the developers aren't able to create equally pleasing (mutatis mutandis) apps? Or that designers can't grok the mapping between their equally pleasing ideas and the tools available?

I'd say it's on the other end. users can't find the apps which are properly designed for tablets, and get tired of wading through crap to find them. the tips are totally there, but if you search for, eg, python, you can be sure the iPadOS app is decent and designed for ipad, vs you have no idea if the Android app is actually pleasing on tablet.

That developers have the tools and can or cannot use the tools is secondary to that, imo.

A phone and a tablet are just wildly different devices. Screen size —sure— but also usage patterns, input methods, workflow conventions, etc.

The “mutationes” that must be made reach deep into the functionality of an app, not just UI-level stuff. The whole purpose of the app should probably change. It’s therefore a big and challenging job to make an app scale seamlessly from one device to another. That’s irreducible complexity. The tools available will always be at best “necessary but not sufficient”.

There is no tool that can scale a mobile app to tablet size whilst maintaining a great UX.

You need to optimise for the particulars of each device.

Having worked on an app that, at least in my opinion, was pretty well done for each platform (phone and iPad), this is the case.

Our UI for the iPad was a completely separate one. The core code was shared via various internal libraries, but the UI was entirely different. Adding a feature to iPhone required one entirely separate set of code compared to the iPad app. The app was a universal binary though and one app ran on both device types.

This was, at the time, an absolute requirement. There was no way to scale the app from iPad to iPhone in such a way that it would give a great experience on both iPhone and iPad. It just wasn't possible to give an excellent app.

I've long since left and the app does seem to be written in SwiftUI now and seems to be one shared codebase. But I wouldn't say it's as good as it was previously.

If you're brave, you can configure views for all sizes (portrait/landscape/iphone/ipad) using XCode's UI Tool with trait based constraints. When you get it to work, it works quite well, animating changes when switching from portrait to landscape, but if things go wrong, it can be a massive pain to debug.

Software that dynamically changes to fit different form factors is difficult to write and rarely comes without compromises to the UX.

I prefer it when my iPhone and iPad apps have separate bespoke UIs that take full advantage of the different sizes and shapes.

writing software is about writing the hard-to-write parts one time, so that users aren't confronted with the anomalies all the time. Computers are our servants, we need to let them figure things out for users, and take care of the headaches, not simply declare "here, this is a headache".

yes, what you are pointing out is the challenge. solve it, don't slough it onto the user.

However, the same app can appear on different sized screens with different skins, it doesn't have to be a different app.

I'm not saying we should slough it on to the user. I'm saying there is no true substitute for hand tailoring your app for each platform you choose to support.

The iPad store didn't break away from the iOS store until 2019. The original app store came out in 2008, eleven years earlier. While you have as certain point, the division is meant to highlight apps which treat the iPad as a mini laptop, with a keyboard and pencil, vs just a bigger phone. If you've ever coded a website to resize, that's child's play. to actually get an app working properly across both sizes, you've got to put in significant work for each. For developers that don't want to put in that work *, listing in one or the other is fine, and possible Uber the current regieme.

* the developer for papers please's blog about the mobile port is indicative of the work that goes into supporting other screen sizes. Asking developers to have infinite time and motivation is just not realistic. also note that it took a few years for the mobile port to be released.

https://dukope.com/devlogs/papers-please/mobile/

This is not true. From the day that the iPad was introduced, you have always been able to sell separate iPad versions of an app then iPhone versions.

You can still do it without doing it well. That's probably not at issue so I think the parent is not false

> you've got to put in significant work for each

Even Apple themselves couldn't expend the effort to make an iPad version of their vaunted new Classical music app: https://www.apple.com/newsroom/2023/03/apple-music-classical...

I like your comment and not because I polemically see this as correct compared to the other people who disagree with you. I think it is a good comment although I don't agree with you, so thanks, and (on second thought I suppose you comment frequently so I am not referencing any other comments in general but) happy to hear more of your sensibility in various threads.

To each their own indeed. I think mobile responsive design has crippled the desktop experience of software, particularly on the web.