Hi @ed95,

I’ve seen some problems with slower iOS devices not responding to orientation changes, and hence was digging back to the Juce source code to see if there had been any recent fixes in that area.

I see that the most recent commit in develop added a call to forceDisplayUpdate(); in juce_ios_UIViewComponentPeer.mm … but I can’t see that implemented anywhere?

I was wondering what the purpose of this commit was, or if it missed something?

Best wishes,


There shouldn’t be any change in behaviour - ComponentPeer::forceDisplayUpdate() just calls Desktop::getInstance().displays->refresh() replacing the nasty const_cast that was there before. Are your sure that the change isn’t due to any of the other recent iOS changes? Can you do a git bisect to find the actual commit which caused the change in behaviour?

Hi @ed95

I know - this is a really weird one! I’ve not updated the Juce side of our code since I merged-in the Juce 6 code a month or so back.

This is just something that “started happening”. My best guess, is that recent changes to Wotja are taking more CPU, and that somehow affects timings on the Juce/iOS interaction side.

Luckily, the version of the above two files, where I’d implemented my own split screen implementation, before merging-in the Juce 6 versions, work fine with orientation change (and split screen of course). Phew!

I’m going to try to figure out for you what the problem is, and if/as/when I do, I’ll be sure to feed it back to you.

Final thought - if you asked me to speculate what the source of the problem is, I’d guess:
static Rectangle getRecommendedWindowBounds()
… but I’ve yet to investigate!

Best wishes,


NB I’m talking across myself - this issue is also on iOS Multitasking - #20 by reuk … sorry :slight_smile: