7

I have installed the newest Xcode 7.1 beta and trying to run my project on the iPad Pro Simulator. Everything is right and all of the features work correct.

But I have an issue with the screen size...

On the main screen of application I run the next log:

NSLog(@"%f", self.view.bounds.size.width);

I have 1024 for landscape orientation. But when I create a new application in Xcode 7.1 and run the same code on the main screen I get another value: 1366.

Today I plan to find diffs between project files created in old Xcode (6.4) and newest beta 7.1 using Araxis Merge.

Do you now how to fix this issue for the my old project?

Oleksandr Balabanov
  • 629
  • 1
  • 6
  • 30
  • Are there any news regarding this issue? I am having the same problem. No matter what I do, I am constantly getting 1024*768 in the iPad Pro simulator. – Gergely Kovacs Nov 08 '15 at 20:36
  • @GergelyKovacs for now I have no idea how to make it work. I am going to return to this issue next week. I will describe results if I'll find smth interesting. – Oleksandr Balabanov Nov 09 '15 at 09:25
  • @AlexanderBalabanov - Can you provide some more information about the problem that you're experiencing so we can help? I am also troubleshooting iPad Pro support and would like to make sure we can all support it appropriately. Where are you running your NSLog statement to see the view bounds? Are you using Auto-Layout? If you can provide us with some more context of what you are experiencing then hopefully we can all work together to help solve this. – Derek Lee Nov 11 '15 at 01:52

3 Answers3

3

I may be way off here, but I was having a similar problem with the iPad Pro simulator: it kept giving me the standard 1024*768 point resolution. After some digging, I realized that I was using the standard iPad launch image (since there is no iPad Pro version in the asset catalog), which restricted my screen to remain 1024*768 points. Once I introduced a launch storyboard, everything fell into place, and my app launched with the correct, 1366*1024 point size.

Gergely Kovacs
  • 1,045
  • 2
  • 10
  • 28
  • I too have a launch Storyboard for both my application and the test application I put together to confirm this behavior, but still as I explained in my answer I'm not seeing the actual size reflected until later in the view controller lifecycle. When you say "my app launched with the correct size", where are you confirming this? Does your launch storyboard have specific configuration? My launch storyboard is just set to the default: inferred size/orientation/etc. The launch image displays properly, but VCs still do not get the proper bounds until later. – Derek Lee Nov 14 '15 at 06:56
  • I confirmed the correct size by simply logging the window size rect. And no I do not use anything special; so much so, that I actually use a simple .xib with inferred size (not a storyboard), but it should give the same results. – Gergely Kovacs Nov 16 '15 at 09:15
1

TL;DR: It appears that the view hierarchy is not adjusted for the iPad Pro screen size until viewWillLayoutSubviews: and viewDidLayoutSubviews: is invoked. When this is invoked by the layout system depends on the construction of your view hierarchy.

In updating my app for iPad Pro I'm also seeing similar behavior. Therefore I took a deeper look at the view controller lifecycle events to see what was happening in both my existing project as well as a new project.

For a brand-new project, using a view controller that only has a navigation bar (placed just below the status bar) and a primary view (that takes up the remainder of the space, with auto-layout turned on, in landscape mode a la the following screenshot:

Sample view controller with navigation bar and auto-layout

I'm seeing the following output from the console for the view controller lifecycle:

-[ViewController viewDidLoad] self.navigationBar: .frame: {{0, 20}, {1024, 44}}; .bounds: {{0, 0}, {1024, 44}}
-[ViewController viewDidLoad] self.primaryView: .frame: {{0, 64}, {1024, 704}}; .bounds: {{0, 0}, {1024, 704}}

-[ViewController viewWillAppear:] self.navigationBar: .frame: {{0, 20}, {1024, 44}}; .bounds: {{0, 0}, {1024, 44}}
-[ViewController viewWillAppear:] self.primaryView: .frame: {{0, 64}, {1024, 704}}; .bounds: {{0, 0}, {1024, 704}}

-[ViewController viewWillLayoutSubviews] self.navigationBar: .frame: {{0, 20}, {1024, 44}}; .bounds: {{0, 0}, {1024, 44}}
-[ViewController viewWillLayoutSubviews] self.primaryView: .frame: {{0, 64}, {1024, 704}}; .bounds: {{0, 0}, {1024, 704}}

-[ViewController viewDidLayoutSubviews] self.navigationBar: .frame: {{0, 20}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}
-[ViewController viewDidLayoutSubviews] self.primaryView: .frame: {{0, 64}, {1366, 960}}; .bounds: {{0, 0}, {1366, 960}}

-[ViewController viewDidAppear:] self.navigationBar: .frame: {{0, 20}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}
-[ViewController viewDidAppear:] self.primaryView: .frame: {{0, 64}, {1366, 960}}; .bounds: {{0, 0}, {1366, 960}}

From what I can see here, the view starts out with a width of 1024 points but once 'viewDidLayoutSubviews' is executed, the appropriate size has been determined (1366 points).

In my own project for one screen which is using a split-view controller, I can see similar behavior:

-[XYZViewController viewDidLoad] self.navigationBar: .frame: {{0, 20}, {1024, 44}}; .bounds: {{0, 0}, {1024, 44}}

-[XYZViewController viewWillLayoutSubviews] self.navigationBar: .frame: {{0, 20}, {1024, 44}}; .bounds: {{0, 0}, {1024, 44}}
-[XYZViewController viewDidLayoutSubviews] self.navigationBar: .frame: {{0, 0}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}

-[XYZViewController viewWillLayoutSubviews] self.navigationBar: .frame: {{0, 0}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}
-[XYZViewController viewDidLayoutSubviews] self.navigationBar: .frame: {{0, 0}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}

-[XYZViewController viewWillAppear:] self.navigationBar: .frame: {{0, 0}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}

-[XYZViewController viewWillLayoutSubviews] self.navigationBar: .frame: {{0, 0}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}
-[XYZViewController viewDidLayoutSubviews] self.navigationBar: .frame: {{0, 20}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}

-[XYZViewController viewWillLayoutSubviews] self.navigationBar: .frame: {{0, 20}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}
-[XYZViewController viewDidLayoutSubviews] self.navigationBar: .frame: {{0, 20}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}

-[XYZViewController viewDidAppear:] self.navigationBar: .frame: {{0, 20}, {1366, 44}}; .bounds: {{0, 0}, {1366, 44}}

In this case, since the view hierarchy is different, viewWillLayoutSubviews: gets called earlier in the view controller lifecycle and the correct size has already been determined by the time viewWillAppear: is invoked. But as you can see, this really depends on your view hierarchy - so I would recommend that you confirm your view hierarchy and then determine the best location to add your resolution-dependent code.

Derek Lee
  • 3,452
  • 3
  • 30
  • 39
  • The new `viewWillTransitionToSize:withTransitionCoordinator:` method will also give you the correct frame geometry – Korey Hinton Nov 10 '15 at 14:38
  • 1
    Thanks for your comment @KoreyHinton! I haven't taken a look at this yet so it might be the case - however, since `viewWillTransitionToSize:withTransitionCoordinator:` is not really a part of the standard view controller lifecycle, implementing this just to get the correct size feels a bit unnecessary. According to Apple's docs, this is for "size and trait changes", which I wouldn't expect there to be any since both iPad and iPad Pro are both Regular / Regular for both portrait and landscape orientations. – Derek Lee Nov 11 '15 at 02:00
  • Downvoter: Can you please leave a comment with your concern so I can try to address it with my answer? I understand that while I can't provide an explanation for how Apple's frameworks are handling this on the back-end, the information I posted is accurate and the actual iPad Pro bounds are accessible from within the view controller lifecycle, though not maybe when we expect them to be. Please let me know what additional information you would find useful and I be happy to research/update as needed. Thanks. – Derek Lee Nov 14 '15 at 06:49
  • 1
    Good point about that method not being a part of a view's lifecycle. viewDidLayoutSubviews is a reliable place for changing frames by inspecting the the view's size after the change. The method I mentioned gives you the size before the view size change. My comment was meant as an aside since frame geometry is tricky and not as a correction since your data shows the complete lifecycle of size changes. Not sure why someone downvoted you, I found your answer helpful and upvoted you when I found it – Korey Hinton Nov 17 '15 at 15:32
0

If you hard code the frame of any UI elements due to some reasons, you may have to change it for upcoming iPad pro. Because, it has a different screen size (in points) altogether.

If you use auto layout and dynamic frames (e.g. self.view.bounds.size.width), it should just work fine I guess.

Rashmi Ranjan mallick
  • 6,390
  • 8
  • 42
  • 59
  • I am using auto layout and dynamic frames. I have not any hard code frames. It's strange but it does not works fine... – Oleksandr Balabanov Sep 14 '15 at 07:58
  • But, what's not working for you? In the question, you mentioned that your app was working fine. – Rashmi Ranjan mallick Sep 14 '15 at 09:09
  • All works fine, but i want to get self.view.bounds.size.width value == 1366 on iPad Pro Simulator. I have only 1024. But when I'am creating a new project in Xcode 7.1 the self.view.bounds.size.width value == 1366. – Oleksandr Balabanov Sep 14 '15 at 12:18
  • Yes. I guess it's working as expected. When you build the app with ios 9 sdk, it will give you the correct iPad pro point size. If it's an older sdk, it may return you existing iPad size. But, I have never tested it though. In fact I haven't installed xcode 7. – Rashmi Ranjan mallick Sep 14 '15 at 15:34
  • If I will find the solution for the fix this issue in old project I'll post it. Thank you a lot. – Oleksandr Balabanov Sep 14 '15 at 17:05
  • Ok. I don't think you need to fix anything in the old codebase. That's my perception without checking in real. Because, you mentioned that the app works perfectly fine with the old codebase. – Rashmi Ranjan mallick Sep 14 '15 at 17:17
  • You have to add a launch screen file, then it will switch to the full resolution. Otherwise it stays on the old point size.width of 1024 to be downwards compatible to the existing Apps. – Darko Nov 13 '15 at 22:23