I have been playing around on Xcode with size classes to try and make sense of it. The problem I have is that many different sized phones all fit into the same size class (like all iPhones in portrait) so I can't home in on a 3.5 inch screen for example. This is frustrating as I would like to change the layout constraints between phones rather than just classes as obviously I need to make the gaps between things larger or the buttons slightly bigger to keep everything in proportion. I don't know if it is something I have missed but it seems the only way I can do this is by creating every single layout constraint I want to change as an outlet and then testing in code for each phone and updating it using a rough estimate and run the thing on the simulator.
In Summary, how can I adjust the constraints based on the size of a device, when they're all in the same class? Using a percentage/proportional constraint should give me the result I'm after.
Apple have designed it so that you don't have to think about specific devices. The idea is that you use auto layout so that each screen automatically adjusts to the available space. Size classes is an extension of that so when you get a lot of extra space you can do something slightly different.
If you want to customise your layout to specific devices, you can. Pretty much as you describe it. However, what happens next year when Apple release the iPad Pro and a 4.3" iPod touch (you read about it here first)? In general, there is no need to hard code spacing and sizes; your interface should scale to use the space available, and that's what auto layout and size classes give you.
It's certainly harder to think it terms of constraints rather than a list of known screen sizes, but it should be worth it.
Well, Size Class has many advantages. It depends on how people viewing it. In specific to your question there is a way to change for all iPhones in Portrait and all iPhones below 4.7 inch Size in portrait.Below is the image of that. I can understand supporting 3.5 inch screen with size class is difficult. Setting a proper constraint and using the below class will help you to achieve it.
Related
My app has a lot of image assets so adjustments I make (resizing and changing position on the screen) to my artboards that make it look good in iPhone X make it look awful in iPhone 5 or 6 or XR. The main problem seems to be reconciling different screen dimensions, rather than sizes. Is there another way besides doing a whole new storyboard for the taller X screen dimension?
We have tried auto layout but that only works for the UI elements, not image-only graphics. What we end up with is a compromise that doesn't look fantastic on either screen.
No, you can do that through Auto Layout. There are so many techniques, you can use multipliers, you can resize heights based on widths, you can make views have a percentage size of other views, possibilities are endless. You can even make custom constraints for a specific model.
You should study more about Auto Layout, it is possible to make them all look exactly like you want.
For the past few months, I have been trying to learn iOS development. Most of it has relatively easy, however, one thing has been very difficult for me. AutoLayout. After I grasped constraints, I thought it would be easy, but I am having real trouble getting my layouts to look well on both iPhone and iPad devices. I can design pretty well for iOS. Recently, I was building an app where I put two buttons in the ViewController. on iPhone, I set the constraints of the buttons to equal the width of the screen (plus the screen margin), and set a reasonable looking height to the buttons. On iPhones, my layout looks great, but on iPads (especially the newest iPad Pro), things look horrific. Full width buttons look great on the iPhone, but on iPad they need to be a lot smaller width wise and a lot bigger height wise. Likewise, my images look great on iPhone, but are too small on iPads. In CSS, I could just use MediaQueries, and on Android, resource qualifiers on the values and layouts.
What are my choices here? How can I design my layouts to look nice on both iPhone and iPad when certain dimensions need to be different based on screen size, screen resolution, etc.? Constraints seem to be good for enforcing dimensions, but not adapting them.(Except maybe the Aspect Ratio constraint)
What features of the AutoLayout system can allow me to accomplish responsive layouts among larger screens and Retina resolutions? What are some common tips / tricks for developing responsive layouts.
You can use size classes in order to build for different screen sizes easily. raywenderlich.com has a solid guide on adaptive layouts.
You can use size classes to design differently for iPhones and iPads and also you can use proportional width height to look perfect based on the height ratio of all devices. If you want to choose first option then you can go with any tutorial available but if you want to choose the second option which is the little difficult way but time saving way then you need to really understand the sizes of devices and need to understand what actually proportional width and height constraints do. Thanks.
I have been using autolayout and constraints to make my app look pretty on every iPhone, and it looks ok so far. I am having problem with iPad. I have a screen that when viewed on iPad has to much blank space.
I would like to use bigger images, and larger font. Maybe add one more label. Can I do this with sizeclasses, or i have to do it some other way?
Yes, you can do all that with size classes – and indeed they are the preferred solution for this, because you automatically get support for slide over and split view.
If you're using Interface Builder (which, quite frankly, is by far the best way to work with size classes), you'll see little + buttons next to many configuration option of your user interface. For example, you mentioned larger font: right there to the left of the font options is a + symbol, and clicking it lets you add a different font size for specific size classes.
I made an app a few months ago that worked on all iPhones and iPads as well as Apple TV, all using the same base storyboard with customisations using size classes. There's such a big gap between the tiny iPhone 4s and the massive iPad Pro that size classes were basically essential. And yes, split view worked flawlessly out of the box, which was a bonus.
My primary advice: Design for your smallest screen first, then add size classes to configure the largest options. You can then choose some views to either not be installed (it's a checkbox) or just be sized down very small to make sure your UI looks and works great in its most challenging environment. If you can do that, making iPad work is a cinch because it feels like you have acres of space ;)
Another useful tip that enough people know about: Enable the assistant editor, then choose Preview mode for your storyboard. This lets you see how your layouts look on multiple different devices and orientations simultaneously, as you work. If you're looking to make best use of size classes (and the massive difference in space between iPhone and iPad) using the previewer is essential.
I would like to know which is the best way to make a view controller for iOS 9 swift 2 xcode 7, for different iPhone screens?
I have tried to make it with constrains but from iphone 4s to iphone 6s screens we can see wide gaps between the icons and text fields etc.
What i'm thinking is to make different view controllers for each screen (5.5inches, 4.7inches, 3.5inches) and to make my app check with which screen the user is opening the app and load the unigue view controller for this screen.
Or maybe there is a better way but im new to swift 2.0 so i'm asking for your help!
Thanks a lot for your time.
You can make a views for multiple screens using autolyout and size classes. You have proportional constraints that fit on all screens.
Proportional constraints means you can set for example view1 is 50% of screen.
These constraints fit on all screens.
Avoid excessive use of size classes (applying constraint in different size class). Try to go with proportional constraints in hAny wAny layout.
Only go for different size class if design on ipad is different then iphone. Or if you need different font sizes on different devices.
https://developer.apple.com/library/ios/recipes/xcode_help-IB_auto_layout/chapters/EditingConstraintAttributesintheAttributesInspector.html
I think this depends upon what your requirement is and what you prefer.
I usually prefer the good old Springs and Struts.
They can be used by disabling auto layout and screen sizes.
Using Springs and Struts i only create a single Storyboard to manage all iPhone and iPad screen sizes without any coding effort.
No matter how complex the UI maybe, for me Springs and Struts are the best solution.
Size classes give you a more fine grain control for different sizes and orientations. Please refer Apple's documentation
As I understood your question that you want to load storyboard as size of screen of device.
I will suggest you to refer this link to load a different storyboard depending on screen size. Sorry for Objective c but hope it helps you.
Load different storyboards
I've developed several iOS apps but never used auto layout when dealing with screen larger than 4 inch (iPhone 6 and 6+). What I did is to enable scaled mode (by deleting launch xib and adding launch image) and only layout views in 4 inch. Since they have same aspect ratio this could work.
But I'm wondering is there any drawbacks of using scaled mode instead of auto layout, or is there any particular reason to use auto-layout?
Since I think auto layout just too much work to do and I just want all the screens have same UI (i.e. the larger the screen, the larger the view, instead of keep the view size constant but more gaps)
Auto Layout is the future. If Apple comes out with a new iPad that's much bigger, do you want your app to be "scaled", or take advantage of the whole screen? Users will give you better reviews and be happier if your app is not scaled.
Auto Layout really isn't too much work. It's more work not to implement it, and you shut yourself out from features like Adaptive UI, and having one code base that runs on all their devices, present or possibly future.