Do we have any iOS developers here?

I’m particularly interested in you’ve created apps for both an iPhone and the iPad.

I’ve noticed more and more apps on the ipad that don’t honor the rotate lock.
You need to turn the ipad into portrait orientation in order to use it. This isn’t always convenient, especially when you need to switch between apps.

Is it really that much more work to monitor the rotate lock and adjust the window orientation?
I would expect that apple has concise API’s to do this, so that the developer needn’t write a lot of code.

That said, I’ve written some GUI apps myself (not for iOS though), and they can be tedious to manage Window details.

I’m not sure I understand the question. AFAIK if the rotation is locked there’s nothing the app can do about it.

Are you referring to how some apps don’t support layout in both orientations, i.e. the app only displays in landscape, for example?

I’m not referring to changing the lock setting, just monitoring it.

Yes. The apps must be able to read the roation lock setting, so that they know to change orientation, or not.

I don’t claim to know all the ins and outs of iOS, however my app, which contains no special code for monitoring rotation lock, does act as I expect wrt locking rotation, meaning that if the screen is locked in portrait orientation, the app appears in portrait orientation regardless of how the device is rotated.

As of today, I’ve encountered at least 5 apps that ignore the rotation lock setting.
They always orient in portrait mode, regardless of ipad orientation and lock setting.

Are any of them stock Apple apps?

I don’t believe so. I’m fairly sure they are all 3rd party.

What exactly do you mean by “not honoring the rotation lock”? I’ve encountered apps that are portrait only (or more rarely, landscape only), but that’s more about not honoring the orientation that you’re holding the device than the rotation lock setting.

Perhaps that’s it, but that seems like a bad choice to limit an app to only one orientation.

Perhaps @ChrisUpchurch has explained it better but this is what I meant when I referred to an app not supporting one orientation or the other. Apple’s guidance on this states (last time I checked) that apps should support both orientations but they don’t seem to enforce it.

I will say that it’s more work (for the developer) to support both orientations.

1 Like

When the user rotates the device, the device lets the app know that the orientation has changed and it’s up to the app to decide what to do next.
By adding one function (traitCollectionDidChange(_:)), the developer can run some code that updates the screen layout or anything they want to do, so that part of it is incredibly simple.

The problem is that small developers like me have such limited resources that designing a whole additional UI for landscape is simply not justifiable use of time. In one of my apps I spent a couple of days trying to figure it out a reasonable layout. And if I change one little bit of the design, I now have 2 configurations to figure out.

Supporting portrait-only on iPad is relatively easy. If I design a look that has 6 buttons across the width on iPhone, I can just apply that to any size or shape iPhone or iPad and it will look reasonable. Apply that to landscape, and it looks awful.


Just curious, does iOS have a layout manager, or do you have to place things where they should be?
For example, (and it’s been a while) I recall layout managers where you specified control size in percentages, or some arbitrary unit, and also the direction you wanted the control to go: upper left, etc. seems like this might have been Tcl/Tk.

If there’s a layout manager, it would seem the change for orientation could be mostly automatic.

There is a tool called Interface Builder, which contains a feature called Auto Layout, but it’s probably not like anything you’ve used before. Its primary purpose, I believe, is to relieve the developer of having to create and maintain separate layout files for every iOS device. It can respond to orientation changes but it’s not as easy to configure as one might hope.

The developer can choose to not use Interface Builder, and instead do all layout in code. Personally I find this approach more difficult but I acknowledge that there are cases where it is necessary.

Even if the developer opts for Interface Builder, Auto Layout is not required. Auto Layout is relatively new and for code and/or interfaces which were developed before Auto Layout, I suspect many developers continue to use the practices that were used before, eschewing Auto Layout.

1 Like

I use Interface Builder or code depending on how I’m feeling/where I am in my learning curve, and you can use auto-layouts with either.

The issue is really with having it look good-enough-to-ship.
I can tell a button to go up to the top left, go 5 points from the left, 20 points from the top, 50 tall and take up 20% of the width…but for portrait and landscape they’ll end up looking very different. If I choose to make the width 50points instead, there’ll be lots of whitespace.

Basically, it takes time to design an interface in one orientation and it takes a similar amount of time to design it in a second orientation (that’s my experience; I know it would appear to need much less time). That’s then compounded by split-view.

For one of my apps I had the great idea of simply placing multiple views on screen at once in the landscape version, using the space nicely. When going into split-view, it all crashed though because some views became hidden when I switched to the portrait mode. It’s all solvable, of course, but it’s time-consuming.

All in all, sticking to portrait only and using auto-layouts neatly avoids a whole can of worms and time.

Nobody wants an app that will only do Portrait Mode on iPad.

So you either cope with Landscape or abandon the iPad market.

No one said anything about portrait mode only.
One app I’m referring to is a long list, which could easily be scrollable vertically, in landscape mode. Instead, it’s stuck in a portrait mode.

If it’s that simple an app, it could literally be zero lines of code, just one tick box to tick.

It depends on the underlying architecture though; if the dev made inappropriate choices early on, they could theoretically find it harder.

Whilst I wholeheartedly agree that devs should try to make their apps work in any orientation the user prefers, even Apple makes apps that work only in portrait (eg Clips) or only in landscape (eg GarageBand).

I can’t see any valid reason for either app having this restriction beyond an executive decision that it’s not worth the effort, but they do and I’m happier to have the limited app than not.

Out of curiosity how often do you use iPad in portrait? I find I almost always have mine in a case that doubles as a stand - I’d bet < 5% of my usage is in portrait.

Having said that, though I’m not an iOS developer, I’ve built a lot of custom interfaces in FileMaker for FM Go, just for my own use, and I’ve always built for both orientations. Not pixel perfect but good enough for my use - 10 minutes of resizing and moving elements and It’s acceptable.

1 Like

Only when I have to. That is, when I use one of these apps that only use portait mode.

1 Like