10.5 Ipad Pro

[Kansas Eiffel]

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.

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.

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

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.

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.

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.

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!

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.

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.

Tablets are just "flatter" computers. Trust me, RAM is always the first thing you want to know when buying one, especially if you love video and gaming. A faster chip does NOT always equal a faster computer without the RAM to go with it. Just my take....

Apps are constantly updated and their size grows up accordingly. My old Ipad 3 was incredibly zippy when I got it, but nowadays it lags so much in pdf reading apps, in cbr comic reading apps and in safari as to make it almost unusable. Its processing power is adequate enough but it is ill-fitted with ram. Having more ram dramatically increases the ipad's longevity. I, for one, wouldn't even consider getting the 9.7 with 2 gb.

Yes it's 4 gbs I found out Tuesday the 13th when I received mine. Used the app named system status. Sorry I was too busy working and using my new iPad! And it was difficult to find this thread, until I got an email about the response about fixit.

Considering there is no way to alter the RAM and no alternate configurations to be had, it seems rather pointless to know how much RAM it has. Its designed to work with the amount of RAM it will have and that's all it will ever have. RAM on iPads unlike other devices is not a really important spec.

Yes, safe to say between 2 and 4gb. It is certainly NOT pointless to know which, and the amount of RAM is a hugely important spec. Anyone who has compared safari running on 1 gb versus 2 gb will understand this.

Phil0124, The amount of RAM is definitely not pointless. It is the difference between me buying now or waiting. It would be nice if we could perpetually run more resource intensive and powerful apps with one or two GB of ram, but that is a pipe dream.

And I suspect Apple knows this, I don't think they expect us to run new apps and the new iOS 11 in less RAM than previous models. And I don't expect Apple to produce an iPad that cannot at least perform as well as previous models with the demands that will be placed on it.

The 12.9 inch screen iPad Pro has 4 GBs of RAM because some of that RAM, as well as the GPU, are used to drive just the larger sceen which is a LOT more than just 20% larger than the standard 9.7 inch screen iPad Pro.

I am shocked that Apple do not seem to think this important to provide this information. When I buy anything I want to know every component that I am paying for. In the UK it is called transparency and is enshirned in consumer law. It also means that there is tracability in the supply chain.

True, but in the case of iPads, any game that runs on an iPad will do so in as good a way as it possibly can on any iPad that runs the iOS version it requires. A Game won't suddenly lag, or look horrible on an iPad with 2GB of RAM vs one with 4GB of RAM.

Some games may have added features in newer more powerful iPads, but unlike regular PCs there will be no real difference in how the game works or plays. Unlike standard computer games you don't lose shading, or FPS, or graphic quality with less RAM on an iPad.

Brand new (obviously) iPad Pro 10.5. It happens, very intermittently but it happens. It's like the touch screen is dead. Double-clicking the home button brings up the task list. You can then move to a different app. But then the screen is still dead. Turning the screen off and on will reset things, so that the screen becomes live again. Frustrating and not something I've ever seen before. This is my fourth iPad. Maybe it's defective? Just wondering is it just me or do other people see this too.

c80f0f1006