iPad Pro 10.5 dimensions revert to 1024x768

When my app launches UIScreen.mainScreen.bounds.size is 1112x834 but when view controller (which I create procedurally) uses those dimensions in loadView to create self.view, by the time viewDidAppear happens the dimensions of self.view are 1024x768... I've tried upping deployment target to 10.3 but that didn't help.


Any ideas why the view controller's is view reverting to original iPad dimensions???


Is there a magic plist key that I need to set to support new iPad? :-)

Replies

I found the same thing and spent some time trying to work out the cause. From what I can tell it's related to Split View. If your app's info.plist isn't configured to fully support Split View then the iPad Pro 10.5" simulator will run your app at 1024 x 768 points and scale it to full screen instead of running it at native 1112 x 834 points. I don't know if this is intentional or a bug.


Three notes:

1. Overriding supportedInterfaceOrientations in a UIViewController doesn't seem to make any difference, it's all about how the info.plist is configured.

2. The relevant entries in the info.plist are as follows

  <key>UIRequiresFullScreen</key>
  <false/>
  <key>UISupportedInterfaceOrientations</key>
  <array>
  <string>UIInterfaceOrientationLandscapeRight</string>
  <string>UIInterfaceOrientationLandscapeLeft</string>
  <string>UIInterfaceOrientationPortraitUpsideDown</string>
  <string>UIInterfaceOrientationPortrait</string>
  </array>

To avoid scaling UIRequiresFullScreen must be absent or set to false, but not true, and all four of the UISupportedInterfaceOrientations must be set.

3. The iPad Pro 12.9" is unaffected and apps run as expected at its native resolution of 1366 x 1024 points regardless of these configurations (so long as a storyboard is used for the launch screen). This appears to be because even when running in full Split View, the 12.9" screen is so big that each pane remains in the regular horizontalSizeClass, whereas the 10.5" screen moves to the compact horizontalSizeClass.


I'm not sure if I've conflated this configuration with Split View support, though they're somehow related. I'd like to hear from anyone with more insight.

Sounds like a bug — I want my game to take advantage of the extra pixels, but I also don’t ever want to be smaller than 1024 pt so I don’t want to support split view. It is also a landscape-only game…

That's the exact boat I'm in. :-)

I filed Radar 32604743. Either it’s a Simulator bug, an iOS bug, or a documentation bug. I encourage you to file a duplicate since you’ll no doubt have a slightly different ***** which could provide insight (and at the very least indicate how many developers are affected.)

I think this might be deliberate. They *have* to scale existing apps up to the 10.5" size because those apps were built in a world where the new size didn't exist. In the past, they used the presence of a Launch Storyboard to avoid scaling up on the 12.9" iPad Pro.


This time, they *could* use the fact you've built with Xcode 8.3.3 instead of an earlier version to opt you in, but that could be very surprising to a lot of developers (especially those who run the Mac App Store version of Xcode and can't easily go back to an earlier version).


On Stack Overflow (https://stackoverflow.com/questions/44392646/how-to-add-support-for-10-5-inch-ipad-pro), alexkaessner claims that building with Xcode 9 beta 1 *does* result in the new resolution. That would make sense. Any developer using Xcode 9 and iOS 11 is opting in to all sorts of things.

Ah, will have to try that again (Xcode 9 wasn’t launching my app in Simulator).

A good test would be to build on Xcode 9 (i.e. linked aganst iOS 11) but deploy on a 10.5" iPad that is running iOS 10.3.x. My Xcode 9 beta 1 install isn't showing a 10.3 simulator for the 10.5" and many attempts at downloading the 10.3 simulators just fail with network connection timeouts. I should be receiving a real 10.5" tomorrow so will be able to test that combination.


Another interesting combination would be to build with Xcode 8.3.3 but run on a (real) iPad 10.5" that has iOS 11. I'm probably going to put the beta iOS 11 on my iPad Air 2 though, not my shiny new 10.5", so won't be able to test this. Also, unless you mess about copying files, Xcode 8.3.3 almost certainly won't deploy onto an iOS 11 device. Using TestFlight (or a real app store release made with Xcode 8.3.3) would make that possible, but that's a lot of hassle!

I can confirm that when built with the Xcode 9 / iOS 11 beta, UIScreen.mainScreen.bounds in my app does return a size of 834 x 1112 under the iPad Pro 10.5 simulator. The same app built with Xcode 8.3.3 / iOS 10.3 returns 736 x 1024. I tried changing the deployment target from 8.1 to 10.3 but the results were the same. The app I tested is a universal app, does have the UIRequiresFullScreen key set to true and supports all orientations.



I am going to test a more recent app that supports split screen to see if that make any difference. But the app above is the one that I need to add 10.5" support to immediately.

"...many attempts at downloading the 10.3 simulators just fail..."


I, too, experienced this but yesterday managed to download 10.3 simulators. It _may_ be due to server bandwidth. Keep trying...

Here's a summary of what I and others have found. This is true of Xcode 9 beta 1 and, in theory, might change. But I think Apple's thought about this and deliberately chosen the behaviour I'm about to describe.


Some basic facts:


  • Xcode 8.3.3 (building against iOS 10) is the first to include support for the 10.5" iPad.
  • Xcode 9 beta 1 (building against iOS 11) supports running iOS 10.3 or iOS 11.0 on the 10.5" iPad simulator (10.3 requires a download from Preferences).
  • You're going to need to support all orientations and have a launch storyboard in order to avoid simple scaling. That was true of the 12.9" iPad and is also true of the 10.5" iPad, no matter what iOS version it is running or what version of Xcode you built your app with.


The key factor in determining whether an app is scaled from 1024x768pt or sees the 10.5" iPad's native 1112x834pt screen resolution is whether the app sets UIRequiresFullScreen to YES in the Info.plist.


Case 1: UIRequiresFullScreen = NO

Built with Xcode 8.3.3 or Xcode 9.0, apps that already work with auto layout, size classes, Slide Over and Split View do see the new resolution. I strongly suspect, even apps built before Xcode 8.3.3 will behave the same. If you already support the various sized devices you've effectively declared your self adaptable and get the new resolution and it doesn't matter what Xcode you build nor what iOS version is on the iPad. You get to see the world how it really is!



Case 2: UIRequiresFullScreen = YES

The version of iOS that the device is running seems to determine the behaviour. Build with Xcode 8.3.3 or 9.0 beta 1 and run on an 10.5" iPad simulator with iOS 10.3 and your app will see the 9.7" iPad screen resolution. I.e. your app runs at 1024x768pt and is scaled to fill the larger screen. But if the 10.5" iPad is running iOS 11 then you see the native resolution, even with UIRequiresFullScreen = YES.

Unfortunately, without real hardware the only way to currently run on a 10.5" iPad and iOS 11 is by using Xcode 9 beta 1 and the simulator. That conflates the iOS version on the device with the major Xcode version so we don't have a full set of test results yet.

More Testing Needed

We need to know what happens when an Xcode 8-built app with UIRequiresFullScreen = YES is run on a 10.5" iPad running iOS 11. And that requires real hardware. It will also require installing from Xcode 8 before upgrading to iOS 11, or a TestFlight / App Store build of an Xcode 8-built app being installed on the iOS 11 device.


I strongly suspect that an app built with Xcode 8.x, including 8.3.3 and even later 8.x versions and run on an iPad 10.5" that has iOS 11 installed will also scale rather than see the native resolution when UIRequiresFullScreen = YES. To me this is the safest approach that Apple could take. We know that anything built with Xcode 8.3.2 or earlier MUST scale, irrespective of the iOS version running on the 10.5" iPad, because doing otherwise would break existing apps.

Apple could have used Xcode 8.3.3 as the cutoff point but we've seen that isn't happening when UIRequiresFullScreen = YES. I.e. apps built with 8.3.3 are being scaled on 10.5" iPads running iOS 10.3 (in the simulator). Installing iOS 11 on a real 10.5" iPad that was scaling almost certainly wouldn't change the behaviour, because Apple would backwardly-compatibly adjust for the fact that the app was built on Xcode 8.x

I think that the only way to see the native resolution on a 10.5" iPad is to either already be fully adaptive (UIRequiresFullScreen = NO), or to build with Xcode 9 against iOS 11, which is a major cutoff point for opting in to new behaviour.

Yeah, full resolution regardless of configuration on the Xcode 9 beta iOS 11 simulator, but only when configured for all iPad interface orientations and without requiring full screen on the iOS 10.3 simulators.


So no way to avoid scaling of a landscape game under iOS 10.3, though users will likely update their iPad Pro 10.5"s to iOS 11 when it becomes available.

But iPad Pro 10.5 is available next week, and we cannot ship games that take advantage of it until Xcode 9 goes GM…

Hi David. This is a little late I realize, but I have found that this solution worked with Xcode 8 and does not require Xcode 9.


Add a UILaunchImages key to the info.plist.

Mine is pasted below, which supports iPad (9.7, 10.5, 12.9 inches) and iPhone (3.5, 4, 4.7, 5.8 inches).

In the UILaunchImageSize key, make sure the comma has a trailing space.

Both Landscape and Portrait UILaunchImageSize dicts should include the same portrait dimensions (don't reverse width and height).

The LaunchImage PNG files should be at the root level of your app's project, and their filename roots should not include @2x or @3x suffixes, but be a those retina resolutions. Example: LaunchImage-iPad10_5-Port should be 1668 x 2224.

The LaunchImageName keys should not include filename extensions.

And, of course, be sure to add those LaunchImage PNGs to your Project.


On the Project's General tab:

The Requires Full Screen checkbox is unchecked.

Launch Images Source is not set.

Launch Screen File is blank.


Hope this helps! It helped my app launch on a iPad Pro 10.5-inch in full native resolution. I have tested this on both iOS 10 and 11.


<key>UILaunchImages</key>
<array>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPad12_9-Port</string>
<key>UILaunchImageOrientation</key>
<string>Portrait</string>
<key>UILaunchImageSize</key>
<string>{1024, 1366}</string>
</dict>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPad12_9-Land</string>
<key>UILaunchImageOrientation</key>
<string>Landscape</string>
<key>UILaunchImageSize</key>
<string>{1024, 1366}</string>
</dict>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPad10_5-Port</string>
<key>UILaunchImageOrientation</key>
<string>Portrait</string>
<key>UILaunchImageSize</key>
<string>{834, 1112}</string>
</dict>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPad10_5-Land</string>
<key>UILaunchImageOrientation</key>
<string>Landscape</string>
<key>UILaunchImageSize</key>
<string>{834, 1112}</string>
</dict>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPad9_7-Port</string>
<key>UILaunchImageOrientation</key>
<string>Portrait</string>
<key>UILaunchImageSize</key>
<string>{768, 1024}</string>
</dict>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPad9_7-Land</string>
<key>UILaunchImageOrientation</key>
<string>Landscape</string>
<key>UILaunchImageSize</key>
<string>{768, 1024}</string>
</dict>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPhone5_5-Port</string>
<key>UILaunchImageOrientation</key>
<string>Portrait</string>
<key>UILaunchImageSize</key>
<string>{414, 736}</string>
</dict>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPhone5_5-Land</string>
<key>UILaunchImageOrientation</key>
<string>Landscape</string>
<key>UILaunchImageSize</key>
<string>{414, 736}</string>
</dict>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPhone4_7-Port</string>
<key>UILaunchImageOrientation</key>
<string>Portrait</string>
<key>UILaunchImageSize</key>
<string>{375, 667}</string>
</dict>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPhone4_0-Port</string>
<key>UILaunchImageOrientation</key>
<string>Portrait</string>
<key>UILaunchImageSize</key>
<string>{320, 568}</string>
</dict>
<dict>
<key>UILaunchImageMinimumOSVersion</key>
<string>7.0</string>
<key>UILaunchImageName</key>
<string>LaunchImage-iPhone3_5-Port</string>
<key>UILaunchImageOrientation</key>
<string>Portrait</string>
<key>UILaunchImageSize</key>
<string>{320, 480}</string>
</dict>
</array>

The problem was fixed with ios 11+ but it again with ios 12.1 tested in below devices.


ipad 12.9 3rd gen and ipad 11 with ios 12.1


The same workaround works.

😟