What is best size to design psd for including iPhone 4, 5, 6, 6 plus
There is no best size but I should develop it for the most sold phones
Most importantly, please follow the official iOS Human Interface Guidelines:
https://developer.apple.com/design/human-interface-guidelines/ios/overview/themes/.
Also:
If you have limited resources
Design for the smallest device (aka iPhone 4), and you're garantied that all the elements will also fit on a larger screen.
If you have classic resources
Prepare psd for all possible sizes that you support, because the layout will often be different:
4 inches
4.7 inches
5.5 inches
iPhone X
iPad sizes eventually
If you have too much resources
Prepare psd for:
both portrait and landscape
and for all class sizes combinations (Any/Compact/Regular height x Any/Compact/Regular width)
and for all languages (German/Chinese/Arabic often require different layouts)
and for all iOS versions (because the navigation bar background or the app icon corners have evolved through history)
and specify all transitions animations+curves+durations
Related
Our UI designer provides us the designs with the dimensions in points on a iPhone XS device. Please advice on the following;
How can these dimensions be converted to points in Xamarin?
How to Scale down (eg : font sizes) to small screens (eg: iPhone SE)?
How do I apply auto layout variations based on the screen size of the selected device? All iPhone devices are Compact width Regular height, so if I want to add a variation for an iPhone 4s screen only, the variation gets applied to ALL iPhone screens since they're all part of the same trait. I remember this used to be pretty easy and straightforward in Xcode 7, but I'm guessing that this just another of millions things that Apple unnecessarily has to overcomplicate. How do I do this in Xcode 8?
How do I apply auto layout variations based on the screen size of the selected device
In a nutshell: You don't. The idea of auto layout is that you apply constraints that cause your interface to look reasonably good in all the different iPhone sizes (that is, all the different ways that the trait collection can be Compact/Regular or Compact/Compact).
This is typically done by using constraints that are based in some way on the size of the ultimate superview; thus, when the superview size is different (because you've launched on a different size screen), things still look good.
I remember this used to be pretty easy and straightforward in Xcode 7
Then you remember wrong. There is no difference in this regard between Xcode 7 and Xcode 8. There is a difference in how Xcode 8 displays to you the effect of your constraints in the Interface Builder canvas, but this is merely a matter of display in Interface Builder, and is in fact an improvement over Xcode 7 (which showed you a big unhelpful square).
Are there downsides for using only #x3 images,
showing the same images on both #x2 devices (iphone 4, 4s, 5, 5s, 6) and #x3 devices (6+)
i guess it means resizing on the fly.
or should i use #x1 #x2 and #x3?
thanks!
If you only use #x3 images, the downside is that iOS will have to "do the dirty work".
So your app will be a little bit slower as the system will have to scale your images for #x2/#x1 devices
Also your screens might look less sharp as odd pixels in #x3 don't scale down nicely.
Since #x1 devices are almost a thing of the past (just the iPad mini 1 is on sale, as I write this), its worth considering dropping #x1. #x2 devices will probably be sold for a few more years so I'd keep using #2x.
Only advantage you gain if you only add #x3 images is your apps bundle size may reduce. But IMO scaling down images every time your app runs will definitely impact your performance (based on how image heavy your app is).
I fully agree with Fraser that you may take a decision to drop #1x images (based on your target market segment).
i am building windows store app. I am using windows 8 and WPF with visual studio .net 2012.
UI of this application should be scalable to different screens. I have created a page where the controls (buttons, images, texts) fits correctly when running the app on simulator with resolution 1920 x 1080 for 10.6" screens. The problem is that when i change resolution, controls do not behave correctly
when resolution or screen sizes are increased (ex. 1920 x 1080 for 23" screens) empty spaces are created on the page;
when resolution or screen sizes are decreased (ex. 1024 x 768 for 10.6" screens) controls sizes are increased too and some of them are not visible in UI because they are displayed too far in bottom.
Is there a way to build "scalable" store app which are independent of screen sizes or resolution? Control sizes and font sizes should increase and decrease when resolution change or from one screen to another but all of them should fit in the space and shouldn't create empty areas.
Any help would be very appreciated.
thank you
This MSDN article discusses the guidelines for scaling to screens.
it touches on Screen size, Screen resolution, and Aspect ratio. It provides a table which shows best practices recommended for apps that use scale-to-fit functionality and it touches on adaptive layout. there is a reference to [Guidelines for layouts] at the end of the article as well.
Hope this helps!
http://msdn.microsoft.com/en-us/library/windows/apps/hh780612.aspx
joelcitizen
With the new screen resolution and aspect ratio of iPhone 5 it seems there are two approaches to take advantage of the new screen real estate when handling images that are full screen (or mostly full screen) images:
Include two images bg#2x.png and bg-h568#2x.png and check the device's main screen bounds to figure out which to load.
Only include the one file but make it the full iPhone 5 resolution
(There are other methods also: stretching, tiling, and / or drawing with Quartz.)
Both of these options have drawbacks:
Including two files is going to increase your app's bundle size
Loading a iPhone 5 retina image on a 4 will clip the image data when displayed on screen, but will still consume the same amount of memory resources
I am particularly interested in understanding the details of the second drawback better.
I am thinking it would save the app bundle (and my designer) if I could use this consolidating images idea further...
Let's say I have an image that take up 320pt x 480pt in portrait and 480pt x 320pt in landscape (width x height).
(EDIT: Initially I hadn't considered a couple of other important tidbits. For sake of completeness, I'm including those thoughts here)
If we create a single image file at a 480pt x 480pt resolution instead of landscape and portrait files, it would prevent the app bundle from having two files that which each contain 320pt x 320pt area of duplicate image data. However, this large square image would include four 80pt x 80pt quadrants in the corners that won't be seen. All things equal, we should still have 20% less image data in the app bundle.
Having re-read Bill's "iBooks Author Experiment", the memory requirements are very easy to figure out:
Landscape or Portrait: 640 * 960 * 4 = 2,457,600
Large Square: 960 * 960 * 4 = 3,686,400
The memory required to load the large square is 50% more then loading the image sized correctly for the screen. Clearly the savings in the app bundle don't measure up to this hit on resources!
But, what about extending this to a giant square that would encompass iPhone 5 and iPhone 4 - 568pt x 568pt? Instead of four files (iP4 landscape, iP4 portrait, iP5 landscape, iP5 portrait), there would be only one file in the app bundle (giant square). The savings could be about 60%.
What about the resources hit?
iPhone 5 Landscape or Portrait: 1136 * 640 * 4 = 2,908,160
Giant Square: 1136 * 1136 * 4 = 5,161,984
That's 110% more memory for iPhone 4, and 77.5% more memory for iPhone 5.
My original question was roughly two parts: 1. Do I understand this correctly and 2. is this tradeoff a wise one to make.
I hope my edits (spurred by Bill's answer) show that I do understand this stuff now. And, if the new found knowledge is correct, then #2 pretty much answers itself. :-)
Generally you get it.
Assuming that you have the big square image and it's some kind of tiled pattern (linen etc) then you could use ImageIO to load the cropped image at the size you need which would use some extra memory decompressing the image but once done it would consume only what is needed to fill the background.
I would suggest against scaling the image.
On the flip side though, shipping an app with 3 images (foo, foo#2x and foo-h568#2x) instead of 1 makes way more sense. The only way I'd say you should go with one image is if you are close to the 3G/LTE download size of (I think) 50MB.