I was working on a game for iOS in Unity3d and after building my game and sending it to device I noticed that the actual size of installed application is terribly big (by terribly big I mean size over 2GB, lol).
I was wandering, why so? So I created test project, created scene and added to it one image with size 2048x2048. So I got project with this files:
MySprite
MyScene
MySprite was imported with following settings:
Texture Type: Sprite
Sprite Mode: Single
Pixels To Units: 100
Filter Mode: Point
Max Size: 2048
Format: Truecolor
And I even didn't forgot to uncheck overriding this settings for iOS. So, MySprite has size of 16 MB in uncompressed state. It's good. No quality loses, 32bit per pixel.
Then I created Xcode project. And found in Data folder file sharedassets0.assets that wights ta-da-da 16.1 MB! I made some research and found that this file is big because of MySprite. So... I was confused. A bit. Then I made ipa file from this Xcode project and unpacked cool-game.ipa file and again found sharedassets0.assets that wights ta-da-da 16.1 MB!
I don't like this behaviour. Why MySprite has physical size of 16 MB? I understand, that in uncompressed state in memory it will take 16 MB anyway. But I would like to have compressed file on device and uncompress it in runtime. Because I don't like to have application with size = 16 MB * 100 :)
So, is it possible to ask Unity3d to compress images on build?
P. S. I am using OS X 10.9.3, Unity3d v.4.5. I have Unity3d Pro, but not iOS Pro.
I found next solution.
I put all images I need to be physically light into Resources folder with .bytes extension. Then I load them via
var binImage = Resources.Load<TextAsset>(imagePathInResourcesFolder);
myTexture2D.LoadImage(binImage.bytes);
If you need Sprite from Texture2D you can always use Sprite.Create() function.
It's good for me because I can easily load images and unload them to free memory usage. But this solution has great drawback. Without any Unity3d extensions we loose usual Unity workflow. That's sad. But it's only solution I found working.
P. S. actually you can use WWW class to load images. But currently I prefer working with Resources.
P. P. S. remember that Unity3d include everything it can work with from Resources folder into build.
Related
Currently I'm on the verge of making a 2D puzzle game for iOS. When I zip my project it's size become 16MB approximately. When I build it in xcode the project size become 780MB and when I archive it then it becomes 1.5GB.
But the real problem begins when I upload it to test flight for internal and external testing then in iTunes connect it's compressed size became 143MB and Universal install size become 285MB and for different iPhone install size become 160MB in average. Now I think 160MB is very large install file for a simple 2D puzzle game and can cause major drop outs when I publish it.
Unity version: 5.4.2
Scripting backend : IL2CPP
Api compatibility Level: .Net 2.0 subnet
Can anyone tell me what can I do to solve this problem, or the size will reduce when I'll publish it.
Thanks in advance.
To solve that (My app was 1.7 GB for iOS, while Android's apk file is just 50 MB) I changed the compression method for Unity build:
Build Settings -> Compression Method -> LZ4HC
Now it is just ~80MB (instead of 1.7 GB). Hope it helps someone.
This is my checklist for reducing file size of APK I guess it applies to iOS.
Removing duplicate or unused assets
Reducing sprite sizes (power of 4 for iOS)
Reducing SFX sample rate and bit rate (mono, vorbis, 44100)
Using Texture Compression for sprites (16 bit is better. and disable mipmaps)
Removing external assemblies (and most of .NET references)
Using pngopt to strip out the unnecessary informations from PNG files
I have a Unity3D project that I've already released for iOS via Xcode. Previously the archive size was about 30-40Mb which I'm happy with.
I've now changed a few things within the Unity project, and rebuilt it for Xcode. Now when I archive it, the size is around 110Mb, which is huge compared to the previous file size. I only changed the logo, and splash screen design.
Also, when I rebuild the older version, the size isn't 30-40Mb anymore, it's 110Mb too!
So I'm guessing this is something to do with the new Xcode for iOS8? Not 100% sure, hence why Im asking.
Thanks.
Try to turn off BitCode. Open XCode => Build Settings => search Enable BitCode. Set it to No.
Have you read this?
http://docs.unity3d.com/Manual/iphone-playerSizeOptimization.html
Also it can be fault of stripping level, try to use micro mscorlib.
In addition you can take a look at Decrease Your App’s Code Size from Mac App Programming Guide.
https://developer.apple.com/library/mac/documentation/General/Conceptual/MOSXAppProgrammingGuide/Performance/Performance.html#//apple_ref/doc/uid/TP40010543-CH9-SW2
I believe part of what is happening here is the additional overhead for the arm64 slice (unless you were already including the arm64 slice previously). I would not expect that much of an increase in size for the arm64, but it would still be roughly X2 on the app binary (minus the resources).
As of Feb 1, Apple requires arm64 support as well as the app being built with the iOS 8 SDK. The default Xcode build setting enables arm64.
What you can do is Show Package Contents on the xarchive and work your way to the app executable binary. You can then compare the size difference on the app executable binary from before and now. You can also run lipo -info on it to see all the slices from before and now. Note I am assuming you have an older xarchive to compare with.
I would then probably diff the rest of the resources (use something like Araxis merge) to see the differences in the files. This will let you see what resource files changed or got added. If your diff is only the executable, then you have isolated were the size difference has come from.
The 'Estimated App Store Size' reflects the installed app size, not the download size.
I'm basing this off the following test:
(Unity app build) Estimated App Store Size: 140.8 MB, size listed in store: 33.4 MB. The splash images alone inside the package add up to 30 megs uncompressed (all my jpegs were converted to pngs) so there's no way the installed size is 33.4 MB. After install, if I go to settings -> general -> usage -> Manage Storage I see the app is 141 MB installed.
I'm not sure how to estimate the download size, which is what matters if you have an app you want to be downloaded over cellular network and needs to be under 100 MB downloaded.
I added this as a comment to the question, but I wish I had read this as an answer, so here it is.
Is there a way to reduce the size of the framework ScoutMaps-iOS-SDK, because right now the size of the bundle is so huge and the user probably won't download an app with >100 Mb.
For people who are interested:
To minimizing the size of the project you can do the following:
Benchmark: demo project unpacked – 173.883.119 bytes (195,7 MB on disk)
Things that can be removed for iOS:
1. Remove all audio advices but en_us from SKAdvisorResources.bundle (Note: you can host & download the audio files on demand)
2. Remove Outdoorstyle and Grayscale style from SkMaps.bundle (if you're not using these syles)
Demo project unpacked - 115.890.904 bytes (118,5 MB on disk)
3. Remove all other architectures but armv7 (there should be a small performance penalty on arm64, but since you exclude an entire set of architectures the size of the .ipa should be considerable smaller) - this change will be visible in the final .ipa file
Things that can be removed for Android:
On Android you can repeat steps 1 and 2.
Regarding architectures – if you have control regarding which Android devices you will be using, you can also remove the unused libraries (we have by default /libs/armeabi/libsngnative.so, /libs/armeabi-v7a/libsnative.so and /libs/x86/libsnative.so)
These are the things that can be done for the moment to decrease the size- but we're still working on this improvement for the next versions
I am in the process of updating Hungry Helga (iPhone and iPad versions) for iOS 6, and all of the PNG files in my new app bundle archives are between 20 and 40 percent larger than they were in my past releases. Of course, this is putting me over the 3G download limit of 50 MB so I'd really like to figure out what's going on.
I am currently using version 4.5 of Xcode on OSX 10.7.5. If I recall correctly the previous version was built with Xcode 4.2. I tried turning on and off PNG compression in the build settings but that had no effect on the image sizes in the bundle.
To give a concrete example, my largest PNG image is 1.9 MB as a source asset. It is 2.1 MB in the old app bundle, and 2.5 MB in the new app bundle.
Did Apple change the way the PNG compressor works or is there maybe a setting that I'm missing or something?
I do not work for Apple nor do I have any inside information - however, I did poke around and have some theories. If you use terminal you can cd into the Xcode.app and find pngcrush there:
$ find . -name pngcrush
./Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/pngcrush
If you then run:
./pngcrush -?
you find some interesting tidbits:
| It was compiled with LLVM 4.2.1 Compatible Apple Clang 4.0
(tags/Apple/clang-420.0.12) and modified by Apple as indicated in the
sources.
and
-iphone (optimize for iPhone OS)
Since I too saw that some large pngs where also much larger in the bundle than the original (which I had previously crushed myself!), I wanted to see how Xcode uses pngcrush. I used an old UNIX trick:
move pngcrush to xpngcrush
create a new executable shell file that calls pngcrush with the same argument list
log the arguments into a text file in /tmp
What I found was that Apple calls pngcrush as:
pngcrush -q -iphone oldFile newFile
One can infer from this that this Apple specific feature of pngrush was designed specifically to tailor the image for iOS. I say tailor, not crush.
Does Apple really care if your png is the smallest possible file, to save the greatest amount of space? I'd argue, not really - the devices have fairly large file storage space. Do they really care if your app downloads really fast? Again, I'd argue not really, since the user is going to assume the time is related to the size of the app, and that that is under the control of the developers.
However, what the user is going to hold Apple accountable for is the launch speed. From the first tap to when the app starts doing something - people will believe that is all the speed of the device (which we developers know is not strictly true). With the new iPad3, some of the launch images are now really big, so what can be done to make loading them as fast as possible?
I don't know the answer to that question, but I can imagine that Apple decompresses the original image, then re-compresses it with settings that make loading it in the device as fast as possible.
PS:
1) I just disabled the crush option, and observed Xcode 4.5 copying my png files without modification.
2) To get your app size down, have you tried using JPEGs with a high quality setting - even 1? Such images will look very good and be much much smaller. Virtually all images in my app are JPEGs. You can experiment with Preview to do the conversions.
EDIT: it occurred to me there may be an elegant solution to this. That is, for really important images - ones that you want to appear as fast as possible - then use pngcrush with the '-iphone' flag. For others, use more standard pngcrush options.
One way to do this is to create a new image directory, and write a shell file that pre-processes every png with a real crusher or tje '-iphone' flag, putting the output in the original image folder (where Xcode can get them). Then turn off the automatic 'Crush PNG Files' option.
EDIT2: I entered a bug at bugreporter.apple.com and posted on the Xcode listserv - if you have an interest in this bookmark the question and come back when its updated.
EDIT3: someone gave me a link that explains in more detail the how and why of Apple's '-iphone' option ImageOptim
EDIT4: Apple responded to my bug report, confirming that they modify the images for easier processing by iOS, which may make them larger, by intent.
Xcode 5 now got changes in image compressions. the best and compressed way is to use asset catalogs.
If even using Xcode 5 and asset catalogs doesn't result well for your app, check the other relative post PNG optimization issue using pngcrush tool for more answers could be helpful
Using David H's script, I found that Xcode is also passing the command line parameter "-f 0" to pngcrush. The man page indicates that the "-f 0" will disable any IDAT filtering before compression which can result in a larger PNG file. Testing on my 1.9 MB example file from above confirms:
pngcrush -iphone in.png out.png gives the 2.1 MB result that I am looking for
pngcrush -iphone -f 0 in.png out.png yields the undesired 2.5 MB result
Now the questions are: Why did Apple change this? Will it break image loading in some way if I work around it? If not, is there a setting for this in Xcode or will I always have to use a script to filter out the "-f 0" argument?
I'm baffled by how Xcode is managing to compress my iOS app so effectively. All of my images and sound files combined add up to 282 MB for about 3000 items. However, the .app is somehow only 126 MB! Further, the file sizes inside the .app package contents are the same, yet the folder sizes are all roughly half size. How is this possible?
The main reason is probably that all your images (assuming images make up the majority of the 282 MBs in your app) are compressed using pngcrush as a build step in your application. You can actually watch this by looking at at the build log from xcode.
The special version of pngcrush that is used in the iOS SDK cause the PNG images to be non-standard (making them unviewable on the Mac or any other standard program for that matter). Instead, they are adapted to the display hardware of the iOS devices which means that they will load faster as well.