I have an app which needs to be upgraded all the PNG files to also support retina. How is this done in regards to filenames when I have a folder with about 40 files for buttons etc.
Sorry for the "stupid" question but we all have to start somewhere..
For images within the app, just double the size of the image and put an #2x suffix on the image. For example, if you have a 100px x 44px button image named MyButton.png. You'd create a 200px x 88px image named MyButton#2x.png. Place that button in the same folder as the other image and the OS will take care of the rest for you.
Secondly,
If you're worried about nomenclature for the Launch Images and the image icons I'd recommend reading up on the freshly updated programming guide and human interface guidelines.
Lastly,
I created a nice little inforgraphic that combines the requirements into an easier to read format. Feel free to check it out. It lists what's required, the names of the new image files and the sizes apple requires for those images. Hope this helps!
Programming Guide - Images
Human Interface Guidelines - Images
iOS Image Guide - Inforgraphic
Related
I often use iPhone 2x image also for iPad 1x. By adjusting the layout the app still looks nice.
Asset Catalogs supports this, except for one little detail.
When I drag & drop an image to iPhone 2x and also to iPad 1x it creates a copy of the image.
I clean it up by editing Contents.json and delete the copy from the imageset.
Am I allowed to do this?
Editing the json-file does not help to reuse images and save disk space. If you build for pre iOS 7 you see that the image files are automatically generated and named in the app-bundle:
image~ipad.png
image~iphone.png
image#2x~ipad.png
image#2x~iphone.png
The main aspect of Asset Catalogs seems to improve the workflow between design and programming. It's a visual tool to structure your image data and care a little less about the naming. I heard of teams, in which designer works directly on the Asset Catalog.
Yes, it should be fine. The Contents.json file is valid and contains accurate information and the images all exist. These are the requirements that need to be met for the asset catalog to be valid.
As I say in the title, I'm developing an iPhone app. I use nib files, I don't use any storyboard, and I know that for iPad I'll need to replace some of the controls I currently use for iPhone, since, for instance, in iPad is more suitable to use popovers in some places, and some other considerations. But I'm not sure if I'd need to create a separate nib file targeted for iPad per each nib file I have now for iPhone, or it should be just the convenient thing but not needed, or I can keep just one nib file if views are for example scroll views or table views, and just resizing things would be enough...
What I want is some guidelines to avoid redundant files and work when creating an iPad version of an existing iPhone version, and what the best practices are, since I don´t find how to handle this, programmatically speaking, neither in Apple's docs nor in posts...
Thanks in advance
EDIT. A question about dealing with icons and images: let's say I have an image view that is 50x50 in iPhone. I have two .png images for the iPhone version of this image: 50x50 and 100x100 for retina display. Let's say I need this image to be 80x80 in iPad. What should be the best way to deal with this: having 4 versions of the image (50x50, 100x100, 80x80, 160x160)? or just having the greatest versions (the 80x80 and 160x160 for iPad), and just resizing them to be smaller for iPhone? In general, what is the best practice about this, having one image file per each size you need, or just having the greater you need and fitting it to smaller sizes?
At xib files you should use the AutoLayout with constraints. That was introduced in ios6.
The key and the war with patience and time it will be setting up correctly those constraints.
One xib can be used to iPhone and iPad too, not needed 2 separate files in this way. As speed of development the 2 file are faster to develop, at least for me...
You can usually get away with not re-implementing a lot of .nib files to be iPad specific and just reuse your pre-existing ones. I have a lot of projects that do this.
That said... you usually have to reimplement the top level container .nib to be iPad specific and you really need to think about where you can take advantage of the larger screen size on iPad and adapt or create new .nibs as you see fit. While you're in any .nib... consider updating it to use AutoLayout if you can!!!
Using child view controllers (UIViewController has had childViewController since iOS 5.0) and other libs like for example SGBDrillDownController (you can find it in CocoaPods.org) might be things to take a look at.
On your images question... If the images scale well and don't get too anti-aliased looking when you go from largest to smallest rendition then going that route can make your life a lot easier. I have found however that to get a decent looking image it is best to use scalable vector art and then create a separate rendition for each size needed. Getting the best possible graphics possible is certainly a key to success.
The most of the responses that i saw are about buttons and icons, but and how about pictures?
I have several pictures in the database of my app and my question is, should i have many versions of each image (one for each resolution) or scale the pictures?
scale the pictures can be a good approach, but you can store some format for caching and avoid cpu processing. you can't choose only one, you can combine.
For all the images used in your app bundle you really should provide #2x images these days. They just look so much cripsier....
As for images downloaded or kept in the database - at least for .png or .jpeg images - you can always take advantage of the info that they hold in their bellies. That's why the scale property of UIImage is there for...
For every developer arrives the day to improve the user interface experience because apps are evalutated mainly from the ui carefulness.
So, i've took a look around the websites and I found some psd where to start to desing my apps.
My question is: How to transform a psd prototype to a well-working app?
I don't unserstand how a mockup can help a developer to build a ui...
Can someone make me some clear the situation?
Well, I'd be careful to make a distinction between the graphics an app uses and the actual User Interface. Certainly the graphics are part of the UI, but the UI is soooo much more than that. Depending on how it is done, photoshop mock ups can be simple graphics you can use for your interface to complexes 'scenes' describing how the app functions. In the latter case, the mock-up can be useful for UI design, in the former case it just gives you pretty images to use (which can certainly be useful).
But to more directly answer your question, most people take 'slices' (individual pieces) of the photoshop image and export them as .png images (or .jpg). If the .psd file doesn't already have the images 'sliced', look up 'photoshop image slicing' on Google. You can then import them into Xcode and use them as background images for the controls you want to use. Especially since iOS 5.0, images can be used for a lot of controls. Also, you'll probably want to make sure you make the image resizable with proper UIEdgeInsets. This will allow the image to resize without pixilation by setting an area that can be tiled within the image.
I'm making a Universal App using MonoTouch, and I'm adding my Default-Portrait.png file. That file alone (a 768x1004 .png file) is adding 711k to the size of the app. My app itself is only about 7 megs, so it's adding 10% just for the splash screen.
I could easily make this thing an 80k jpg file instead of a png, but the device doesn't seem to look for a .jpg file. Does anyone have tips for reducing the size of this launch art?
At this point, I'm thinking I might just leave the launch art out and load my own jpg and display it as soon as I have the ability to. That'll keep my app size down, but it's not as nice as having the launch art scale in immediately like most apps do.
Hmmm...given the screen of the iPad and the visual quality users are expecting, I'd just leave it like that.
But if you do want to reduce the disk space, try going to Project > Edit Project Settings > Build (tab at top), and searching for a parameter called "Compress PNG Files." Make sure that's checked. It'll run the pngcrush utility before loading the file onto disk (check the size of your IPA archive after to see if it had any effect).
pngcrush is nice as well, however that will not reduce the quality of you image. If reducing the quality of the image is an option for you, then you might try this tool: http://www.punypng.com/ - or just use an image editing tool to "optimize" the image ...
I recommend pngout if you want to really squeeze those PNGs down, and this won't cost you any quality. It simply removes unnecessary metadata (like pngcrush) and uses its own compression algorithm which is compatible with the regular decompressor used in PNG (zlib). It's really slow, though.
A simpler option is to try "Save for web" in your image manipulation program of choice. Exporting from Acorn (not just the regular save) sometimes gives me vastly smaller files. This is especially true for default images which have large, uniform areas in one colour (screenshots, a small logo in the middle of a black screen).
Is there any reason why you want to reduce the file size that badly? I don't think it matters in your case. I just checked 3 of my apps and the Default.png (of various portrait/landscape varieties) is between 29KB and 422KB, so whilst yours do seem a little heavy, your still way under the 3G download limit.
Are you positive it's adding that much to the size of the app? Did you compare a before and after?
Xcode uses pngcrush on the images for you. I know because I just tried to substitue jpegs for pngs and got the following result:
So, in short, there's not a lot to be done except simplify the image beforehand. Xcode will handle the rest.