#How to split screen on ipad pro 10.5 full
#How to split screen on ipad pro 10.5 simulator
#How to split screen on ipad pro 10.5 download

To me this is the safest approach that Apple could take. 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. 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.

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.

#How to split screen on ipad pro 10.5 full

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. 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. But if the 10.5' iPad is running iOS 11 then you see the native resolution, even with UIRequiresFullScreen = YES. your app runs at 1024x768pt and is scaled to fill the larger screen.

#How to split screen on ipad pro 10.5 simulator

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. The version of iOS that the device is running seems to determine the behaviour. You get to see the world how it really is! 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. I strongly suspect, even apps built before Xcode 8.3.3 will behave the same. 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 ist.īuilt 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. 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.

You're going to need to support all orientations and have a launch storyboard in order to avoid simple scaling.

#How to split screen on ipad pro 10.5 download

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).

Xcode 8.3.3 (building against iOS 10) is the first to include support for the 10.5' iPad.

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

I'd like to hear from anyone with more insight. I'm not sure if I've conflated this configuration with Split View support, though they're somehow related. 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. 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). To avoid scaling UIRequiresFullScreen must be absent or set to false, but not true, and all four of the UISupportedInterfaceOrientations must be set.ģ. The relevant entries in the ist are as follows UIRequiresFullScreen Overriding supportedInterfaceOrientations in a UIViewController doesn't seem to make any difference, it's all about how the ist is configured.Ģ. I don't know if this is intentional or a bug.ġ. If your app's ist 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. From what I can tell it's related to Split View. I found the same thing and spent some time trying to work out the cause.