Decrease iOS Application size to App Store

Question

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 m

Answer 1

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).

Answer 2

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.

Answer 3

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

[…]

Answer 4

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.

Answer 5

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/

Answer 6

I came across an article in the web which explains the process in the following 9 points:

1. Ensure that you have reached the maximum level of iOS stripping, for more info on iOS stripping, see this post.

2. 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.

3. 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).

4. 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!

5. 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

6. Check that the /Plugins/Android is not included in your iOS project. See this post for more information.

7. Make sure you don’t have any unused scenes in your build settings.

8. 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