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
Related
I have created an project of size nearly 5 MB, but after archiving app from xworkspace it increases upto 194Mb and IPA file size upto 70 MB.
Will it fine to have a large size "ipa" for normal application ?
Thank you
It is fine as long as the IPA file size is less than 100 MB. Once the file size becomes larger than 100MB, then it won't be available to download from the Appstore on Cellular Internet. It will be available to download only on WiFi.
I would recommend you inspect the Xcode project to find large dependencies that are causing the file size to increase.
If your entire project is only 5Mb size, you may have a dependency or copy build path resources problem.
Double check :
do you need all frameworks linked to the project ?
do you have a build phase which copy to final resources path unused or unwanted files ?
if you use dependency manager suche as cocoapod or carthage: are all the pulled external frameworks necessary ?
If you want to know what are the big files, it's pretty easy once you have the IPA file: rename your ipa with "zip" extension, unarchive, explore
Bonus: Even the finder say to you "XX MB", it's not the final size. To know the final size, you can upload your ipa on ituneconnect, even if you don't want to use it. after processing, in builds list. You can have the final size for each devices. ex:
As you can see Universal is quite big compared to the specific build for, for ex, iphone 6 !
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
Yesterday i have created IPA file and it was showing estimated app store size is 100 mb and today i also tried to create IPA but its showing estimated app store size is 525 mb.
I read apple instruction for accepting an IPA file :
Apple support maximum size 2GB.
Executable size should not be grater then 60 MB.
i saw that "bin" and "obj" are the folder consisting 1.5 and 5.5 gb in my code.and supported architecture set as ARMV7 and ARMV64 with linking behavior as NONE.
Any Solution for reducing the ipa file size?
Xamarin app sizes are slightly bigger than Objective-C apps as the Mono framework is part of the app bundle.
The architectures you build for will also increase the app size as a binary will be created for each one - I suggest that you only build for ARMv7 and ARM64, omitting ARMv7s unless you need to utilise the specific optimisations provided with that architecture.
You can potentially reduce the app size by setting the linker options to link all assemblies in your release configuration. Note that setting the linker to none, as stated in your question, will be detrimental to your app size.
https://developer.xamarin.com/guides/ios/advanced_topics/linker/#Link_all_assemblies
Each nuget package added to your project will also increase the size of your app. However, with the use of the linker, the impact of this will depend on how much of the package you are actually using. Anything unused will be stripped out during the linking process.
You can also reduce your app size by looking at what other assets you have included in your app, such as images, and see if you can save space by making them smaller or increasing compression.
As a final note, after you upload your app to iTunes Connect, the App Store adds it's own encryption to your app which can significantly increase the overall size. As encryption obfuscates patterns, the resulting compressed app will be larger. The impact varies from app to app. Moving data, such as long strings, or tables, out of code and into external files will make the final download smaller, because those files will be compressed more efficiently.
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.
I am trying to submit an application in App Store, and I need to decrease its memory a little bit, if this is possible. I tried a method which I am gonna describe below to make my app lighter, but with not luck.
Details
I followed these steps to see what was causing this large size
Make an archive of the project
Distribute it
Save for Enterprise or Ad-Hoc Deployment
Select the .ipa file and changed the extension to .zip
Extract it, and open Payload
Show the Package Contents
Contents
I had .png files with 680 Kb (when I added those where 32 kb approximately), I deleted them and I reduced the size of application by 2 MB. There are other files that take space but not considerably, except one executable file that is taking about 90 % of the .ipa's size.
Question
Is it possible to decrease executable file's size? If not then can you give me a hint where I should look to make my app lighter in terms of size.
P.S I use third party libraries like Vuforia SDK and libraries on GitHUB
How can I reduce the size of this executable file
You cannot reduce the size of the executable inside your built app bundle. This is your code! The only ways to reduce its size are:
Cut code. Obviously you can't do that because you would exclude functionality that makes your app work.
Remove an architecture slice. You should not do that because you want to build for all possible architectures.
Having said that... I have never generated an executable inside the app bundle anywhere near this large. Maybe you are measuring / building wrong:
Make sure you are archiving. Nothing else except an archive is worth measuring.
Make sure that you are generating a Release build when you Archive.
Make sure that your Release build settings include the full compiler optimization (smallest, fastest).
Suggestion how to reduce binary size from Reducing the size of my App:
Compiler Options
Setting the Optimization Level build setting to Fastest, Smallest [-Os]; and the Strip Debug Symbols During Copy build setting to Yes (COPY_PHASE_STRIP = YES) can dramatically lower the size of your compiled binary. These settings are the default for the "Release" configuration in Xcode projects.
Assets are almost always the main culprit of large apps sizes.
If you archive your app and export the IPA you will be able to convert it so a .zip by changing the extension and then unzip and look at the contents of the package.
If you sort by file size you will see which files are the largest. Keep in mind images with transparency are larger.
Some more insight as well: http://bjango.com/articles/pngcompression/
If you're truly concerned about the internals of the executable, build with a link map. That shows sizes by segment and by symbol.
e.g.
# Sections:
# Address Size Segment Section
0x0000AB90 0x00711D30 __TEXT __text
0x0071C8C0 0x00028D34 __TEXT __symbol_stub4
0x007455F4 0x00001A58 __TEXT __stub_helper
0x0074704C 0x00057452 __TEXT __cstring
[…]
# Symbols:
# Address Size File Name
0x000122A0 0x00000020 [ 6] ___Block_byref_object_copy_
0x000122C0 0x0000001C [ 6] ___Block_byref_object_dispose_
0x00012320 0x00000028 [ 6] ___copy_helper_block_78
0x00012348 0x0000001C [ 6] ___destroy_helper_block_79
[…]
I came across an article in the web which explains the process in the following 9 points:
Ensure that you have reached the maximum level of iOS stripping, for
more info on iOS stripping, see this post.
Enabling bitcode DOES increase the size of your over-the-air download.
In our case, it was the difference between 130 and 70MB. If you wish
to turn bitcode off, you can do so in your xcode project, or using a
post build attribute such as this one.
The Launch image in your xcode project is NOT optimized. While running
something through a compression algorithm doesn’t work because Unity
decompresses and stores images without much compression in order to
decrease startup time, it does work for the launch images that are
generated by Untiy after project generation.Run all your images
through a lossless compression algorithm in order to save a few MBs
(10 in our case).
If this isn’t enough, it’s time to start looking at your asset logs.
Run your build in Unity and open the Editor log, it’s this
ridiculously small icon next to your console preferences. In our case,
they are already optimized. With a 111MB in uncompressed assets, we
were able to achieve an over-the-air size of 70MB. Go over each asset
and change the resolution to the lowest possible quality that your
users won’t notice. The best compression setting is PVRTC for iOS.
While you are at it, check out Resource Checker in order to see large
textures in-memory. Reducing the resolution on these will also
decrease build size, as well as memory consumption. Also, please use
sprite atlases – you will see the wonders this does!
Check for unused libraries in your project, or libraries that are
using far too much space for their functionality. Commands such as df
and ls -lh might come in useful here, run these in your project files
and see which files really stand out and need to be reduced in size.
Keep in mind that these individual libraries do not necessarily have
the same build effect as your textures – generally, these are compiled
for multiple architectures, and if a library is 20MB, it generally
only affects your build size by about 6MB, due to the fact that
libraries often include architecture support for i386, arm64, and arm7
in the same library
Check that the /Plugins/Android is not included in your iOS project.
See this post for more information.
Make sure you don’t have any unused scenes in your build settings.
Build your project, and check out the archive before you submit it to
iTunes Connect. You can do so by clicking “Product -> Archive”,
letting it archive, and when it’s done, “Window -> Organizer” to pop
up this interface and find the build location.
Under “Products/Applications/game.app” Run the mv command to turn your
.app into a browsable directory.In this directory you’ll be able to
see a lot of the stuff we did, and also find inspiration for more
things you can do.
Now, there are a lot more things that could result in a bigger than
expected build size, and I’m sure there are a lot more things you can
to do get below it also.
If you’d like to add to this list, or have further questions (I’m usually happy to answer questions), leave a comment below with your specific use case, and I’ll try to help!
All the best,
Pim
If you have already checked all your assets (images, audio, etc... ) just check if you need all the external libraries (3rd party libraries out of the iOS sdk) that you import in your app.