With PNG images, one can attach img.png, img#2x.png, and img#3x.png via assets and then load the correct one at runtime based on the device screen dimensions. In addition, the iTunes upload/download process will "slice" asset resources so that a large app that contains 1x, 2x, and 3x assets can avoid having to download 1x and 3x assets when running on a 2x device. What I am wondering is this, can videos attached to an app also take advantage of slicing so that the app need not download 3 sets of video resources in those cases where videos created for specific screen sizes are included in the app? I see that assets do contain a generic "data" type, but it seems to only be able to mark data files as differing in terms of the Metal API version.
So, I looked all around the internets but was unable to find anything on how to solve this tricky issue. In the end, I rolled my own custom solution that basically wraps the m4v video file and treats the binary file as a PNG image, so that it can be included in an iOS asset catalog. This makes it possible to load #2x or #3x assets on iPhone and use iPad specific video asset dimensions on an iPad while also supporting slicing. For a working example, take a peek at my AlphaOverVideo Framework on github, the Bloom demo shows the client side logic to decode from PNG and then load the decoded .m4v video into a looping player. This demo is cool because it shows off the slicing idea, but it also contains a full screen 1 to 1 pixel aspect video of a flower blooming that shows how amazing perfectly rendered video can look. If anyone is interested in the command line encoder, I uploaded it to github at PNGRewrap.
Related
One of our team member is urging to use SVGs using github.com/pocketsvg/PocketSVG, instead of regular assets #1x #2x #3x. We have over a hundred image sets.
I have 2 questions:
1) 100s of SVG data rendered using PocketSVG or even another library, is that gonna be a performance kill?
2) Using SVGs over regular assets, going to make any different visually, though our designer have these all images extracted properly using vectors.
Thanks in advance.
Answer for first Question : Yes, Whenever trying to show an image on the screen, it will process your SVG file and create a new image assets. May be the library can cache the image to avoid second time processing.
You no need to use PocketSVG if you have all SVG images on your Asset Catalog. Because Xcode Asset catalog itself able to handle the SVG images.
Xcode will create #1x #2x #3x images from SVG file at the time of compilation.
Answer for second Question : SVG is a vector image. You can extract good quality image from svg. You will not get any different by using #1x #2x #3x images or SVG image.
The advantage of using SVG is no need to create one more asset #4x if Apple introduced another different screen resolution devices. Just recompile the code Xcode will create on behalf of you
Refer the link : How to use vector in Xcode
For an upcoming update to one of my apps I have packed all the image resources into Asset Catalogs.
However, at the moment I do not have #3x version for most of my images. I have checked with the simulator and on iPhone 6 Plus #2x versions are used.
I don't mind this behaviour for two reasons:
The result is good enough for images which I am using
Only 50% of my users are using iOS 9. If I add #3x images the size of my app will skyrocket for those on older OS
Although images load correctly in the Simulator for iPhone 6 plus, I am a bit worried about what happens when I archive my app. In particular, I am afraid that with App Thinning iPhone 6 Plus users will get an app without any images :)
So, I have two questions:
If I do not provide #3x images will #2x be loaded on iPhone 6 plus
after my update goes live on the App Store?
Will I still benefit from App Thinning because users with #2x and
#3x displays will not be downloading #1x images (and vice versa)? Or will App Thinning not work in this case and users will get the same assets irrespective of their device's screen?
These are trivial questions, but I couldn't find info anywhere online as to what happens when you do not follow Apple's guidelines by not providing #3x images in asset catalogs but your app is still available for iPhone 6 +. In addition, some of my images are in JPG format which adds extra uncertainty because it is not an ideal format for iPhone.
Thanks in advance for any assistance!
I performed several additional tests using the procedure proposed by Matt:
When minimum deployment target is iOS 6 no Assets.car is being
generated. [UIImage imageNamed:] returns nil for JPG images unless ".jpg" extensions is provided as part of the image name
When minimum deployment target is iOS 7 Assets.car is generated but
it contains only those images which were imported in Asset Catalog
as PNGs. All JPGs get copied outside of Assets.car. [UIImage imageNamed:] returns nil for JPG images unless ".jpg" extensions is provided as part of the image name.
When minimum deployment target is iOS 8 Assets.car contains all
images. Its size is 13MB. [UIImage imageNamed:] returns JPG images correctly even when not specifying ".jpg" extension. Images also load correctly when ".jpg" extension is included
When minimum deployment target is iOS 9 Assets.car contains all
images. Its size is 11.5MB. [UIImage imageNamed:] returns JPG images correctly even when not specifying ".jpg" extension. Images also load correctly when ".jpg" extension is included
I have used the image extractor tool suggested by Matt to extract images from these Assets. I was only able to export from archives for devices which are with Retina and I can confirm that all images had correct resolutions (i.e. only retina size, iPad specific images ignored). The tool, however, saved all of them in PNGs format and so the resulting size of the folder was always bigger then Assets.car.
What is most surprising is that the size of the folder was the same (39.4MB) for cases 3 and 4. Also, the images seem to be exactly the same. So, I really wonder what happens there because there is a difference of 2MB in the size of Assets.car for these cases.
To conclude, we are still not sure if such testing method can be used to accurately mimic the App Thinning behaviour. So, if anyone had a personal experience with this it would be awesome if they could share it.
However, assuming that exporting for specific device for AdHoc produces the same result as actual App Thinning performed by App Store we can conclude that:
App thinning only kicks in when deployment target is iOS 7 or later
App thinning for JPG images only works starting from a minimum deployment target of iOS 8
[UIImage imageNamed:] returns JPG images correctly without providing ".jpg" extension only when JPG images are correctly processed through Asset Catalogs. Which, as mentioned earlier, only happens when minimum deployment target is iOS 8 or later
[UIImage imageNamed:] always loads correct images if ".jpg" extensions is specified.
The last two conclusions seem to be irrelevant to this question, but I have found several conflicting opinions on Stack Overflow about how to load JPG images correctly with Asset Catalogs. Some people claimed that you can load them without providing ".jpg" extension whilst others complained that this approach doesn't work. I think 3 and 4 above explain in details what is happening in this case and why people get different results.
Answer your own question. Archive the app. Export the app for the target device you're interested in:
Now look inside the exported app and see what resources it contains. An .ipa is just a .zip file by another name; it's easy to look inside it by changing the suffix. Now you know what resources an iPhone 6 Plus user will download from the App Store.
After getting iPhone4s and iPhone 6SPlus archive, from a project with missing 3x images
then using the image extractor tool suggested by Matt,
deployment target iOS 7
here's the result:
I am developing my first app (iOS universal app), I want to reduce my app's size because it contains many images (png files) and sounds(mp3 files).
So my problem is:
How can I reduce the size of my app (images and sounds)?
Thanks!
Images:
Only include the basics in your app bundle (i.e. app icons, launch image, and possibly images for the first page)
Use Parse (or any other similar service) to download any additional images after the app is downloaded.
This approach will significantly decrease the size of your app but also let you pull down additional image files as needed.
Sounds:
What is the type of sounds files you're using? .caf files are incredibly large. Using .aifc files are just as good quality (to my untrained ear at least) and takes up significantly less space
Depends, compress png images to jpeg usually reduce app size, there are also image optimizers that compress pngs. If your images are part of the UI, tile them or stretch them really helps you in reduce app size and also memory usage. The image asset function in Xcode 5 helps in you in create resizable images.
For sounds the concept are pretty close to images, use compressed file audio as eckyzero said.
If your sounds and images aren't part of the UI but resources, you can make the app download them from the internet at first launch.
I am going to work on client application, in which he need to have whole app locally resources loading, and I have almost 70mb images files for iPad. I am going to start development soon but before that I need healthy suggestion and guidelines to reduce my app size with these images use locally. I don't want to make this heavy size like any 3d game? So I am looking for suggestion what should I do? Thanks in advance.
There are few ways:
zip all the image resources in the bundle. On first launch, extract that zip folder into documents directory and refer the image from there only. You will have to do it on first launch only.
create jpeg version of your images with some reduced quality. Apart from icon and splash, you can use jpeg version of images.
If possible, use 1 pixel width/height images for repetitive gradients.
This is related to Default-Portrait.png for iPad: any way to make the file size smaller?
Is there any way to specify a more efficient file format (like JPEG) for Default-Landscape.png
and Default-Portrait.png?
Yes it's possible to use jpg files as launch images. Just add "Launch image" key with the base filename (e.g. LaunchImage.jpg") to the Info.plist. Then add files to your project such as
LaunchImage.jpg
LaunchImage#2x.jpg
LaunchImage-568h#2x.jpg
and Xcode will pick them up.
However through personal experience I've discovered if you're supporting the larger iPhone 5 screen the App Store expects PNG format and uses the presence of PNG to determine iPhone 5 support and display of iPhone 5 size thumbnails on the store. Using JPG images will not show the app as iPhone 5 optimized in the app store (even though it will work fine on the device) so it is best to stick with PNG.
There is no way to use an image other than a png.
All launch images must be PNG files and must reside in the top level of your app’s bundle directory. Section: App Launch (Default) Images
Update: JPEG images to work and Apple's documentation no longer specifies that the images must be PNG files.
If you use xcassets, then since Xcode 6 you can use JPGs. However Xcode will still not let you drop JPGs into the LaunchImage folder. But you can do it in Finder. Simply drop your PNGs into that folder with Finder and then edit the JSON file changing all .png extensions to .jpg.
I haven't submitted an app to the store using this yet, but it works in the iPhone simulator at least.
Update: Doesn’t work on the device. I’ll leave this answer here anyway so people know that this technique was at least tried so the effort won’t be repeated.