I would like to add a background image for iOS and I want the background image to have appropriate resolutions for all tablet and phone versions. What design considerations should I take into account? What resolution should the image be in?
This the list of current screen resolutions for the variety of devices: click for resolutions
You could create 10 different images, 5 each for the landscape and portrait views.
Alternatively, you could create 2 or 4 images to cater for the landscape and portrait views and use code to check the devices size to size them appropriately.
The advantages of creating all the right sized images means that you have a precise background that is consistent across all devices, especially if you have logo's in the background as distortion may occur with resizing of images across devices.
Conversely, creating only 2-4 images should reduce memory size as the app downloaded will only be packaged with those background images instead of 10, and if resized correctly, shouldn't look to out of place.
I would test the 2-4 images using simulator, checking the look and performance on all devices you plan to release to. If you aren't happy, either customise your layouts for the images so they stretch to fit appropriately, or, for symmetry across all devices, I would create all the images and package, with an attempt to reduce the size of each image to be perfectly aligned with the device boundaries to reduce memory consumption.
The disadvantage of using 10 different images is the extra code required to fit, and should a new device size come out, you will need to create additional images, which ultimately consumes more memory and requires long term monitoring. It also consumes unnecessary memory if you are using an iPhone 6 and have images for all the other devices.
My advice - weight up whether you really need the background and if so, whether or not resizing just 2 images to fit any device will impact the look of your app.
Related
I have a universal game written in Swift with about 200 images, which take up around 200 MB of ram. However, on storage they take up only 15MB. On Xcode the size of the default view is 600x600, and the view that my UIImageView is residing in is 200x200.
My goals is to have an image that uses the least amount of ram, and uses the least amount of storage space, but retains its quality.
For the ram:
Should I run some code to resize the image prior to displaying it in order to use less memory, which I worry may be slightly CPU intensive.
For the storage space:
Is there a way I can calculate the image dimensions I would need in order to satisfy all iOS devices?
Or am I looking at this completely the wrong way.
The assets catalog is going to be the most efficient way to have different assets for different devices, while enjoying "app thinning" which can allow a device to only download the assets needed for that particular device (keeping app downloads as small as possible).
For example, if you have a 200x200 image view, if you want to be most memory efficient for different types of devices, you'd have a 1x (i.e. 200x200), 2x (i.e. 400x400), and 3x (i.e. 600x600) rendition of that asset, and through the efficiency of assets catalogs, the device would download and use the asset of the appropriate scale for that device.
If, on the other hand, you only supply only a 1x image (e.g. a 200x200 image in our above example), it will look pixelated on a retina device, which will put off many users. Or you can supply only a 3x image (e.g. a 600x600 image), it will look sharp on all devices, but you'll be taking up more memory than needed on non-retina devices (or, if you do just-in-time resizing, you can offset the memory impact, but at the cost of performance).
So, if you want the best looking and most responsive UI that works on well on devices of multiple scale resolution, you'd supply all three resolutions. And if you use an asset catalog, it makes the selection of the asset at runtime easier, and you open up the possibility of app thinning.
I am trying to figure out how to use the xcassets folder in Xcode 6 and I have to say Apple could have done a way better job. I'm a big fan of Xcode but their images storage per type of screen / phone is a nightmare.
First, in my application I am using images which will have a height of half their width. From what I understood, taking pictures of around 1200x600px should do for all types of iphones (full width minus small margin). So I put them in 3x universal, right? If I gave the maximum size why would apple need 1x and 2x ...? Just resize it yourself, no? Is it compulsory for me to give something or will it work by itself? Images are not vector but simple PNGs. In the simulator nothing is complaining and it works well for all types of iphones. Is it okay to leave the other two empty? From I see from the simulator iphone 6 will use downsized #3x images so what is the point of having two images? Only ratio is important and they have the same ...
Secondly, I just added today a launch screen for retina hd 5.5 / 4.7 and now when I run the app in the simulator my uitableviews only take around 4/5 of the full width instead of full width .... can't figure out why adding a launch screen would modify layout of my uitableviews ....? Navigation bar and other screens seem untouched though ...
Any help appreciated.
you need to add the images for the 2x & 3x because when you add large size image then at the run time this image get resize as per the actual width of the image it utilize memory lots of memory to do this & some time if your application have too many images then you will get memory issues
if you want to test this then run your application in iPhone 5 then see the memory utilisation by first keeping the high resolution image now take image which will be of appropriate size to iPhone 5 & then run again you will see the difference
so the best practice is to use different image for different size & not images in this fashion.
The answer to your second Question
if you are not adding the splash screen for iPhone 6/6+ then iOS stretches your UI of iphone 5 to fit into the size of the iPhone 6/6+.
But when you add splash screen it stops doing that.
late to the party but yes you need to manage all this resolution by yourself. Otherwise it will consume more memory.
but yes there is one tool which will make your work less by generating all assets for you
AVXCassets Generator
I'm developing a game with lots of graphics for iOS platform. None of the graphics are dynamic, they're all ready made images. There are 6 layers on the screen and each layer contains 3-4 graphics objects in average that constantly scroll to left, each with different speeds. So with each screen refresh about 20-25 objects are scrolled, removed from screen and added again from right. The game is universal so images of all sizes present in the resources folder.On iPads, iPhone 5, iPhone 5s it goes smooth. But on 4th Gen iPod touch I notice some hiccup.
When I test the app with Instruments, I notice a critic memory problem at start and then the problem goes away. So this is all because I load all the above graphics on application start. All the images are combined into 4 different sprite sheets. So here's my question:
Is it the weight in kilobytes that matters or is it the dimensions? I'm asking this because I reduced the size of the images by about 70-80 percents, though their height and width remain the same, but that memory problem still exists.
If you are reducing the size of the images by utilizing compression, then expect there to be delay and a memory hit as the images are uncompressed when first loaded, and they will take up as much memory as they did before compression.
The 4th generation iPod Touch probably is having some memory pressures and it will try to release memory elsewhere in order to allow for your images to load up and stay in memory. That may be the hiccup you see, as other apps, like Mobile Safari or Mail are asked to give up some memory or to terminate.
(The size the images take in the resources folder is inconsequential. It is the size they take when they are uncompressed and in memory that matters).
You could make the images smaller by making them 4bit instead of 8bit color, or you could make them monochrome. You can also use a non-retina size or smaller, and then let the OS stretch them out to fit the space required. I would try to use the best images first, and if you get a memory warning (didReceiveMemoryWarning), then reload with the images that are less dense.
you can not load all image before the game beginning, you should use the cache to control the size of the memory. And before the scenery of game change ,the release the cache ,reload the need ones.
So you must control your resource dependents in the every game scenery.
This is the common method to management the large resource application.
I Just started developing an Universal iOS app for which I need to set the Background image.
Instead of using 3~4 different size images for iPhone, iPhone-retina, iPhone5 , iPhone5-retina & iPad, iPad-retina , I Just want to take one Highest resolution Image (say 1024*780), Which I want to use to fit all the above mentioned devices. How???
self.view.backgroundColor = [UIColor colorWithPatternImage:[UIImage imageNamed:#"sfond-appz.png"]];
& it is not occupying the exact screen size for smaller devices. it is shrinking.
Please Advice!!!
If Apple suggests to use different images for each kind of display there is a specific reason, and that reason is memory.
As display size increases it increases also the memory available on the device that's because bigger images require more memory. Even if you want to resize (not stretching) them at runtime, the first time you open it will occupy that memory until you release it. The memory occupied it doesn't have to deal with the file size.
If you still want to try take a look at this library that will help you to resize (not stretch) images at runtime NYXImagesKit
I'm doing the same thing in one of my apps in the App Store. On the main menu view, I use a UIImaveView as the background and set the mode to Aspect Fit in Interface Builder. I use struts and springs to keep it aligned to the edges.
For a universal app, you'll create this UIImageView on both the iPhone and iPad story board (or .xib files) and use the same image file.
However, I still have a 2x version for retina displays. So, I use just two images to cover all devices, orientations, and resolutions.
It will consume less memory if you create a background image to fit each device, but you will obviously increase the bundle size. In my case, the goal was to keep the bundle size small (under 50 MB for cellular delivery), and I had memory to spare.
If you have an app that works fine on non retina devices, and then you deploy it on a retina device, without providing the requisite #2x images, what side effects could occur?
high memory usage? crashing of the application?
No, the events you mentioned will not occur. However, obviously your images will look terrible as they will not scale properly (therefore they will be pixelated and incorrect sizes etc.).
There isn't any point in not using retina images - all you have to do is add #2x to the images and double the image size, and they will scale correctly for both non-retina and retina display.
If you do not include #2x images, then the device will automatically stretch the image on a retina device to take up the same room (enlarge the image).
The scaling method that UIKit uses does not do any interpolation. Instead, it merely doubles the size of every pixel ("nearest neighbor" scaling). For images of squares with hard edges, that works fine. However, for photos or most artwork, the image ends up looking very pixelated (has artifacts).
Scaling the images up on a retina device is not performance intensive because of the simple scaling method that is employed. It is not likely to affect performance, only image quality.
If you include only high resolution images, they are not automatically scaled down for the non-retina device. Instead, for an UIImageView, for instance, you would set the view mode to Scale to Fill, so that the image scales down to fit the frame. However, again, UIKit uses the nearest neighbor, but when scaling down, artifacts are less noticeable.
The newer, retina devices are more performant, so they are able to handle high resolution images at the same speed as non-retina devices can handle the low resolution images, and scaling images up is trivial for them. However, older non-retina devices will simply be slower with high-resolution images which require more memory and more graphics power, especially since it has to scale them down as well.
This is very noticeable if you have high resolution images in a UITableView. Your retina device will scroll the table very smoothly, whereas you will notice some jitter on the non-retina device. It will not crash, it just won't be smooth. If the user experience is too bad, your app could be rejected. For static, non-moving images, there is unlikely to be much noticeable performance difference.
If you have room in your bundle, you should include both retina and non-retina images. Even if you simply double the image size in a nice photo editor like Photoshop to create your #2x images, the images will be of much nicer quality than what UIKit produces.
Remember that if your zipped app bundle is over 50 MB, it can only be downloaded via WiFi from the App Store. PNGs and JPEGs do not compress much since they are already compressed. That is one reason why you might choose to only include high resolution images (to keep the size of your app bundle down, especially for a universal app, where you might end up having 4 sets of images).
Of course you can provide only retina or even only non-retina images.
We did some testing on this matter a few month ago.
Only non-retina images resulted - as expected - in poor graphics. Even an non-trained eye could notice the blurrines.
Only retina images: it works. But memory footprint is bigger (for non-retina devices that would otherwise load non-retina images) and some lag could be noticed. Though we had to measure it to be sure.
To answer your question: zenith provided the answer. If you only provide non-retina images the graphics on retina devices will be blurry, but no low-memory condition could emerge because of this.
EDIT:
Unless you are doing some kind of research on graphics capabilities of different iOS devices i'd strongly suggest to provide both types of images: retina and non-retina.
If your designer is giving you hard time because of this you can do few things:
get a new designer
provide him some kind of tool to make his job easier: Unretiner for example