1. Help us improve the editor usability and artist workflows. Join our discussion to provide your feedback.
    Dismiss Notice
  2. We're looking for feedback on Unity Starter Kits! Let us know what you’d like.
    Dismiss Notice
  3. We’re giving 2017.1 beta testers a chance to win t-shirts and a Nintendo Switch. Read more on the blog.
    Dismiss Notice
  4. Unity 2017.1 beta is now available for download.
    Dismiss Notice
  5. Unity 5.6 is now released.
    Dismiss Notice
  6. Get further faster with the Unity Plus Accelerator Pack, free for new Unity Plus subscribers for a limited time. Click here for more details.
    Dismiss Notice
  7. Check out all the fixes for 5.6 on the patch releases page.
    Dismiss Notice
  8. Learn how you'll soon be able to publish your games to China in four simple steps with Xiaomi. Sign up now for early access.
    Dismiss Notice

IL2CPP build size improvements

Discussion in 'iOS and tvOS' started by David-Berger, Apr 28, 2015.

  1. David-Berger

    David-Berger

    Unity Technologies

    Joined:
    Jul 16, 2014
    Posts:
    645

    NOTE:
    The original post is outdated. Please refer to this knowledge base article instead - https://support.unity3d.com/hc/en-us/articles/208412186






    Deprecated original article:

    We created a small guide on IL2CPP build sizes. What is important, what can be improved and how you can improve it. We constantly work on the improvements and could already gain massive size improvements in the latest patches. Ensure always to use the latest patch, as we fix bug on daily basis and work on size improvements in parallel. :) Although, many parts are similar to WebGL this guide is mainly targeted to iOS. But all the fixes we make for IL2CPP have direct affect on WebGL and iOS builds.

    Why is the the binary size of the IL2CPP project larger that the mono version?

    Two things apply:
    • If you make a universal build, there's a 32bit slice and a 64bit slice, which contains the exact same executable for 2 different architectures so nearly doubled size.
    • IL2CPP produced bigger builds even if you just compare ARMv7 Mono with ARMv7 IL2CPP; this had to do with how we dealt with the type metadata. It was resolved in Unity 4.6.4p2.
    With "Universal" builds, you will always yield larger binary sizes than just having ARMv7 or ARM64. The removal of the managed assemblies already made the builds smaller (in Unity 4.6.3f1), the real improvement came when we were able to construct at least generic typeinfos at runtime, but this is now partly possible (since Unity 4.6.4p1). But we have some more improvements in production, so stay tuned. Universal builds include 32-bit and 64-bit slices in the fat executable which results in at least doubled size of standard mono 32bit.

    We made improvements to generic type and array generation in Unity 4.6.4p1 too. Apart from that, there's information here about reducing your iOS build size: http://docs.unity3d.com/Manual/iphone-playerSizeOptimization.html. For additional information read in Stripping below.

    Please always make a comparison table with mono (ARMv7), IL2CPP (ARMv7), IL2CPP (ARM64), IL2CPP Universal and which striping settings you use to have all information to compare!

    It's always worth to check the actual binary size, as this is the one which is affected by the source code compilation referred to as the fat file containing binary from ARMv7 and ARM64 if it is a universal build and therefore nearly doubled size of a single ARMv7 mono or IL2CPP build. If you make a universal build, there's a 32bit slice and a 64bit slice, which contains the exact same executable for 2 different architectures so nearly doubled size. If you want to compare the output directly please compare ARMv7 mono with ARMv7 IL2CPP.

    Which sizes limit does Apple check?

    Apple has a 80MB limit for the 32bit+64bit code segment in total if you support a minimum OS of less than iOS 7.0. Apps that are set to minimum OS of 7.0 or greater have a binary size limit of 60MB (60 000 000 bytes) per architecture slice. 100MB (mobile data) application limit (user needs to download via Wifi if >100MB) and max 4GB application limit. 80MB and 60MB/60MB is the limit for code segment size included in the fat binary for the 32bit and 64bit slice. You need to use otool to get the right numbers. 100MB applies to to the .ipa size (Use the estimate button in Xcode after archiving to get the right estimate), this determines if users need a WiFi connection to download your app. Follow following steps to get the right numbers:

    1. Build your app in release mode. Do not use debug mode, as it does not represent your final app. Ensure you use correct optimisation, more information can be found here: http://docs.unity3d.com/Manual/iphone-playerSizeOptimization.html.
    2. Archive your app in XCode.
    3. Use the estimate button to get the estimated size of your app to ensure if you are above or below 100MB or the overall size of 4GB.
      Note: since XCode 6.3 there is no estimate button anymore. You can calculate it by using following formula, but be aware that the compression coefficient might vary:
      Code (CSharp):
      1. app_store_size = sizeof(.ipa/(zip with exec_binary removed)) + sizeof(codesegment(exec_binary)) + 0.2 * sizeof(datasegment(exec_binary))
      The formula is coming from broader knowledge that only the code segment gets encrypted and the data segment compression ratio can be verified pretty easy.
      Extract the data segment from executable via dd command (you can specify byte offset + length) and then try to compress it. The code segment gets scrambled to look like a perfect noise. You need to descramble it with a decryption key before executing. iTunes/App Store app manages there keys. That's why we add code segment as whole without adjusting for compression ratio.
    4. Once you have archived your app, show the .xcodearchive in your finder
      1. Show Package Content
      2. Go to Products/Applications/Productname.app. (Which should have nearly the same size as the estimated size button in XCode returns)
      3. Show the content of the Productname.app
      4. Locate the ProductName binary (exec_binary) on the top level.
    5. Use otool to generate the output for the 80MB limit.

      Code (CSharp):
      1. otool -l path_to_exec_binary
      or even
      Code (CSharp):
      1. size path_to_exec_binary
    6. Now you can retrieve the output depending on the architecture (armv7 + a section arm64 if it's a universal build) Gather the information for armv7 (LC_SEGMENT) and do the same for arm64 if applicable (LC_SEGMENT_64)
      1. Locate the LC_SEGMENT with segname __TEXT and take the filesize
        code segment size = 30474240 ~= 30MB
      2. Locate the LC_SEGMENT with segname __DATA and take the filesize
        data segment size (mostly metadata) = 10420224 ~= 10 MB
      This results in following otool result table:

      architecture armv7:
      code segment size = 30474240 ~= 30MB
      data segment size (mostly metadata) = 10420224 ~= 10 MB
      segment + data segment = 30 + 10 = 40MB

      architecture arm64:
      code segment size = 25559040 ~= 26MB
      data segment size (mostly metadata) = 17727488 ~= 18 MB
      segment + data segment = 26 + 18 = 44MB

      Apple uses for their check armv7(code segment)+arm64 (code segment) which results in a otool report of 30MB + 26MB = 56MB in this example which is below the 80MB for <7.0 and 30MB & 26MB are each below 60MB >=7.0 for a universal build.
    It's easy to test this, make a test app in release mode and submit it to the app store, the static project checker in the beginning should alert you if a slice is over a certain limit. For the estimated size XCode should take all the DRM measurements into account, but if you encounter a different behaviour please let us know! Again, as soon as you uploaded a test app to iTunesConnect, it should show you any pitfalls and you should see also the app size in the Version Summary page.


    Stripping
    The IL2CPP scripting backend always does byte code stripping, no matter what the “Stripping Level” setting is in the editor. The best option for a user is to set the “Stripping Level” option in the editor to a value of “Disabled”, as the affect of any other “Stripping Level” option will likely be minimal on executable size, because IL2CPP will strip anyway. If the you choose a “Stripping Level” value other than “Disabled” you could run into problems, because then the IL2CPP build toolchain in the editor will attempt to determine which native engine code is used by you scripting assemblies, and only register that native code when the player starts. If you encounter problems with your stripping settings and you believe they are wrong, please submit a bug report.

    Exceptions
    By default Mono exceptions are caught in Xcode, but IL2CPP exceptions are not.

    You can make the Xcode debugger break on exceptions by adding an Exception breakpoint as described here: https://developer.apple.com/library.../articles/adding_an_exception_breakpoint.html

    Replace the text "std::underflow_error" with "Il2CppExceptionWrapper" in the text-box shown on that page. You may need to restart Xcode, or possibly just the debug session.

    In general the il2cpp managed callstacks are currently unreliable and on iOS only partially working - the way we do them often prints wrong functions. So for now you need to check the real callstacks int the XCode callstack window. We work on improvements on these areas though.

    A managed exception is not necessarily an app crash. But to break on a managed exception in Xcode, set a breakpoint at il2cpp_codegen_raise_exception or in case of a nullreference exception you can set a breakpoint in NullCheck method in il2cpp-codegen.h You don’t want to break when the method is called, as it will be called very often, but you can break after the if check at the start of the NullCheck method.

    5.3.x build size increase due to BitCode
    Recently we are seeing number of questions scattered around forums regarding build size increase when building iOS applications with Unity 5.3.x often due to BitCode support enabled which is new in 5.3.x. This post aims to clarify some aspects of it in single place. http://forum.unity3d.com/threads/unity-5-3-x-build-size-increase-faq.383533/

    Some more information to read about IL2CPP and 64bit can be found on our blog:
    IL2CPP blog posts
    iOS 64bit support

    I hope this helps and if you have any questions or suggestions to improve the post, please let me know! :cool:
     
    Last edited: May 9, 2016
    Gametyme, jpthek9, drawcode and 5 others like this.
  2. greyhoundgames

    greyhoundgames

    Joined:
    Jan 24, 2014
    Posts:
    8
    Can you elaborate on the generics part a bit more?
    For example Dictionary<K,V> is bad. You suggest replacing it with something. Does replacing it with a Hashtable which is not generified do the trick? You mentioned using your "own implementation".

    Also you say generic lists and arrays. Is ArrayList a good substitute for List<T> and what about arrays. Did you mean object[] arr; is bad?

    We have encountered a bug in the il2cpp generation where a happily compiling project can create not compiling Xcode files by simplly adding or removing a large .cs file(iTween).

    I noticed that our Bulk_Generics has hit file #100 which sounds fishy being such a nice round number. The error is related to a type missing:
    ArraySegment_1_t12037

    I wonder if we just have too much generics for this to handle. Our code base is pretty huge.
     
  3. GabrieleUnity

    GabrieleUnity

    Unity Technologies

    Joined:
    Sep 4, 2012
    Posts:
    50
    Hello,

    did you file a bug for this codegen issue? We will be very happy in checking and fixing it :)
    Which version of Unity are you using? Are you still having the same issue with the latest patch release btw?

    Thanks,
    Gabriele
     
  4. David-Berger

    David-Berger

    Unity Technologies

    Joined:
    Jul 16, 2014
    Posts:
    645
    @greyhoundgames I had to remove the generic parts for now, as it lacks information and a proper example. I'll work on one now and once I can provide you proper stats and examples, I'll push it again. What I generally do is to compare my codebase or the function I need against what is provided by the default implementation and estimate if it is suitable to make my own minimal implementation which I can compare then in a specific minimal example to compare the output. However, this is not easy and needs to be evaluated very carefully. The array part did not come out correctly, in the latest version it's not a problem to use them anymore, but in older versions the sizes of the generated code for arrays was not as improved as it is now. This should have been a hint if you have problems with the generated code sizes, you need to consider upgrading to one of the latest patch releases.
     
  5. greyhoundgames

    greyhoundgames

    Joined:
    Jan 24, 2014
    Posts:
    8
    We are on 5.0.1p1. I eagrly await some sample ideas ;) Also the comment about the 100 gen files. Does that sound normal or crazy high?

    To Gabriele I have not yet made a bug. We have a massive project and I have to get permission to upload the source since its a high value project as well. Is there anything I can do for you in the meanwhile that would help?
    [Update]
    I tried again on today's release(p3) but still cannot delete that file without the errors coming.
     
    Last edited: Apr 29, 2015
  6. greyhoundgames

    greyhoundgames

    Joined:
    Jan 24, 2014
    Posts:
    8
    Oh can you also clarify which of these is a bad idea to use still
    List<int>
    List<Mystruct>
    Dictionary<int, object>
    Dictionary<MyStruct,object>
    Dictionary<string,int>
     
  7. GabrieleUnity

    GabrieleUnity

    Unity Technologies

    Joined:
    Sep 4, 2012
    Posts:
    50
    Any chance you can create a smaller repro case that does not contain the sensitive information and send that one to us? It is by far the best way to get the issue fairly quickly :)

    Thanks,
    Gabriele
     
  8. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,450
    @greyhoundgames

    It is not surprising to have 100 Bulk_Generics .cpp files, it just happens to be exactly 100. As you make changes to the project or we make changes to the code generation, I would expect that number to differ. The il2cpp.exe chooses a number of types to include in each Biuld_Generics file, but it doesn't do anything about the number of Bulk_Generics files generated, so this should not be a problem.

    None of the generic types you mentioned are bad to use. I would continue to use them, as they provide nice expressive power in C#, and the alternatives are often more difficult to use. We have had some customers see binary size decreases by making some targeted changes to the use or implementation of these generic types. For most projects though, this is an optimization that you should only undertake after measuring.
     
  9. bluescrn

    bluescrn

    Joined:
    Feb 25, 2013
    Posts:
    397
    It's rather scary to read 'generics are bad' when you've got a sizeable codebase making heavy use of them and a project with serious memory issues (System.ExecutableAndDlls taking 92MB)...
     
  10. Mantas-Puida

    Mantas-Puida

    Unity Technologies

    Joined:
    Nov 13, 2008
    Posts:
    1,713
    System.ExecutableAndDlls is actually not where the memory pressure comes, because most of these pages are read only and can be reloaded from disk. You should be looking into Xcode Instruments Activity Monitor "Real memory" column or VM Tracker Dirty memory numbers.
     
  11. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,450
    @bluescrn

    It's not really correct to say that "generics are bad, actually. In past releases, the IL2CPP conversion process did cause generics to lead to increased code size. However, recent improvements in IL2CPP mean that generics are not a significant problem any more. n the next few weeks we will land changes to complete generics sharing, mean that the implementation of generics with the IL2CPP scripting backend will be on par with the implementation from the Mono scripting backend.

    So I would not encourage you to move away from generics in your code. In fact, mscorlib makes heavy use of generics, so we need to do everything that we can to improve generics support no matter how much they are used in user script code.

    With all of this said, we have has some users experience executable size decrease by moving away from generic types in some cases. This improvement is more about analysis of what parts of the managed code are actually being used (and removal of parts that are not necessary) than it is about generics in general.

    As usual with any type of optimization, measurement and data are the best options.
     
  12. bluescrn

    bluescrn

    Joined:
    Feb 25, 2013
    Posts:
    397
    The XCode figure is quite a lot larger than the Unity profiler figures...

    In one test case, XCode shows a real memory usage of around 260MB

    A detailed memory profiler capture shows numbers which add up to 209MB (92MB of which is System.ExecutableAndDlls).

    The green 'total allocated' line on the memory profiler graph shows a 'total allocated' size of just 140MB?

    So from the 260MB that's allocated (according to Instruments), less than 120MB is accounted for by 'assets', 'scene memory' and 'not saved' (the textures, meshes, and other assets that we'd expect to be using the bulk of the memory!) - Something doesn't seem quite right there?

    Even if we are losing a whole 92MB to compiled code, that still leaves about 50MB not accounted for?
     
  13. Mantas-Puida

    Mantas-Puida

    Unity Technologies

    Joined:
    Nov 13, 2008
    Posts:
    1,713
    It's Unity profiler missing big chunk of allocated memory. It is expected to be some underestimation on Unity side (because not all the low level measurement tools are available to Unity, that are available for Xcode), but this one sounds like serious problem. Are you running on Metal or GLES? Also do you have custom native plugins that would be making lots of allocations?
     
  14. big_march

    big_march

    Joined:
    Mar 2, 2015
    Posts:
    36
    As IL2CPP could do stripping automatically , for reducing IPA size and memory pressure, is it necessary to use link.xml for IL2CPP build now?

    In a IL2CPP build, "System.ExectableAndDlls" takes a usage of 133MB(whole usage of the game is 250MB), I didn't get any way to decrease this value. Beside reducing asset loading, how to reduce memory pressure for "IL2CPP app"?
     
    Last edited: May 14, 2015
  15. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,450
    @big_march

    It is necessary to use link.xml only if you need to preserve some types from being stripped. Usually this happens with serializers, as they tend to use types at runtime. The need to link.xml will vary on a project by project basis.

    I'm not sure how to reduce memory pressure other than to reduce the use of assets that are unnecessary. We're looking now at how to lower the IL2CPP memory usage to bring it in line with Mono, but we don't have anything ready yet.
     
  16. big_march

    big_march

    Joined:
    Mar 2, 2015
    Posts:
    36
    So in IL2CPP, using "stripping level" and "link.xml" was no longer a way to reduce memory usage, right?
     
  17. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,450
    @big_march

    In IL2CPP stripping is always enabled. So even if the "Stripping Level" setting in the editor has a value of "Disabled", the IL2CPP scripting backend is still doing the equivalent of the "Byte code stripping" value. So you can same that "Stripping Level" is no longer a way to reduce executable size (and therefore memory), but that's only because IL2CPP is already doing stripping!

    The link.xml file is used to augment stripping, to actually include code that would otherwise be stripped. It's role is unchanged with IL2CPP.

    I hope this clears things up, let me know if it is not clear. Thanks.
     
  18. big_march

    big_march

    Joined:
    Mar 2, 2015
    Posts:
    36
    I've learned.Thank you for detail explanation.
    Now I got a reason to stop trying to use stripping to reduce memory usage in IL2CPP.
    But in IL2CPP bulid, "System.ExectableAndDlls" in Profiler still cost 135MB, which is over half of the total memory usage, is there any way to make it smaller?
     
    Last edited: May 18, 2015
  19. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,450
    @big_march

    As long as you are sure that there are not any managed or native plugins in the build that you don't actually need, there are not too many options to make that smaller. We're working on some things from our end to decrease the executable size though, so this should decrease in future releases.
     
  20. emkill2005

    emkill2005

    Joined:
    Aug 15, 2012
    Posts:
    8
    Hi everybody. Just sharing the idea that worked for us.

    When uploading the build to the store from the Organizer there is an option to include/exclude the symbols. (dSYM file). It is not required by Apple but the checkbox is checked by default. Maybe it could be an idea for you to try if you didn't try it yet. On our case excluding the debug symbols lowered to game from 101 MB to 64 MB. (We were surprised. We expected to save around 1-2 MB but it seems it uses a lot of space). This size is according to the test flight. It might add up a bit when it goes live due to encryption .
     
  21. MrEsquire

    MrEsquire

    Joined:
    Nov 5, 2013
    Posts:
    2,577
    So how would one turn this off properly without any side effects?
    Cannot find the option using Xcode latest 6.3.2, organizer has changed in latest builds.
     
  22. David-Berger

    David-Berger

    Unity Technologies

    Joined:
    Jul 16, 2014
    Posts:
    645
    With Xcode 4.0 and later, when you build and archive, the products of your target and their dSYM file will be all archived. The archives can be used to symbolicate crash logs. Select the archive, and [show package contents], you can see the dSYMs and app are there. The dSYM is included within the app archive but not within the .ipa file. So so it is not possible to get it from downloading the app from the App Store. If you make a final distribution build for the app store the dSYM file is not used in the calculation of your app size and never included in your .ipa or transferred to the end user. Find more information about this topic in the official Apple Developer manuals.
     
    MrEsquire likes this.
  23. emkill2005

    emkill2005

    Joined:
    Aug 15, 2012
    Posts:
    8
    After you archive you press Submit to App Store. You have the option to choose an account. Choose that and before you press submit you can see the check mark. We tested it using test flight. (no difference in the game play). You will not provide Apple with the symbol information used for the crash logs if you can live with that.
     

    Attached Files:

    MrEsquire likes this.
  24. emkill2005

    emkill2005

    Joined:
    Aug 15, 2012
    Posts:
    8
    I don't know how it works exactly but since the app size estimation button is not there anymore we always uploaded a build on the App Store and checked the size there. We did it with symbols and it was 101 MB and we did it without symbols and it was 63 MB. Now we didn't go live with 64 bits enabled yet so we don't know what to expect but at least we will get a warning email from Apple if the final size after encryption goes from 63 MB to over 100 MB for some reason. (You get this mail only if the app submitted was under 100 and it will be over 100 after encryption).
     

    Attached Files:

    Last edited: May 22, 2015
  25. UnLogick

    UnLogick

    Joined:
    Jun 11, 2011
    Posts:
    1,403
    There is many threads on how to add stuff to your link.xml to ensure that the byte code stripping doesn't strip too much. However I want the opposite. Failing to figure out exactly which internal part of the System.Security.Cryptography namespace we really needed I had to white list the entire thing.

    However after the initial white list it seems subsequent blacklist doesn't work? I tried specifically blacklisting System.Security.Cryptography.RijndaelTransform since that alone takes up 160kb according to my analysis. However it still ended up in my final build. Now if I specifically says don't include that type, I have taken the decision it should be stripped because I know those particular code paths will never happen in our project.

    Rather than document it Lucas linked to the Unity mono git repo. Is it possible to hack the ResolveFromXml ourselves and use that rather than the shipped dll?
     
  26. andyt

    andyt

    Joined:
    Mar 5, 2015
    Posts:
    1
    My app submission experience is similar as well. With symbols my ipa submission is over 120 MB, and 54 MB without. You can test by exporting your archive with and without checking the include symbol checkbox. It is the same thing with app submission.

    At this point I don't think I can afford to include symbols as part of the ipa submission if I want to keep the size under 100 MB
     
    emkill2005 likes this.
  27. big_march

    big_march

    Joined:
    Mar 2, 2015
    Posts:
    36
    Is there any way to check which native plugin make a big part of "System.ExectableAndDlls usage"?
     
  28. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,450
    @big_march

    I don't believe that this is possible. However, you may want to try some of the profiling tools in Xcode. They might give you a better view into memory for native plugins.
     
  29. lawrence.ward

    lawrence.ward

    Joined:
    May 13, 2014
    Posts:
    7
    On the topic of build sizes at least in the last 2 patch releases on our project and a blank project we have noticed that two versions of the mono dlls, in the Data/Managed/ directory and under the not-stripped folder. The dlls seem different (One appears to be stripped and the other not) but is there a reason both versions are included in the IPA and aren't removed? As this is contributing quite a lot of space in our case to the final IPA. I also couldn't see a direct reference to the DLLs in code and removing them seems to cause no side effects. I couldn't seem to find any references to this folder on the forums at all.
     

    Attached Files:

  30. wokuku

    wokuku

    Joined:
    Mar 19, 2014
    Posts:
    2
    I noticed this issue as well and it was because my build script was doing

    xcodebuild -build | export ipa

    The build phase does not remove the dlls, which are not needed.

    I have since changed my build script to do

    xcodebuild -archive | export ipa from .xachieve. This will produce an ipa without the dlls.

    One other thing I noticed is that unity will insert the default unity splash screen across all device orientations even if you specified in the player setting to only support certain device orientation. This adds quite a bit to the final iOS size. To combat this I just put in a 1 pixel texture to splash screens orientations hat my app doesn't support



     
  31. David-Berger

    David-Berger

    Unity Technologies

    Joined:
    Jul 16, 2014
    Posts:
    645
    The Data/Managed/*.dll AND Data/Managed/non-stripped/*'dll can be safely removed when using IL2CPP this is a bug which should be fixed soon. :oops:
     
    oddurmagg likes this.
  32. lawrence.ward

    lawrence.ward

    Joined:
    May 13, 2014
    Posts:
    7
    Thanks we will add a post build script to do so in the meantime, just wanted to confirm :)
     
  33. shinymark

    shinymark

    Joined:
    Aug 7, 2011
    Posts:
    51
    We've just submitted our first update using il2cpp. Unfortunately, due to the increase in executable size it has pushed us over the 100 MiB over the air download size limit. Our game was previously clocking in around 75 MiB and now it is 117 MiB. We didn't add any significant data content in the update so the increase is coming from the switch to il2cpp and the additional 64-bit code segment.

    What can I do to reduce the final size at this point? I could try to squeeze our existing game content even further but I doubt I can get 17 compressed megabytes out of it. We're already running pretty lean. Re-architecting the game to download data at boot-up or as the player makes progress through the game would be a significant pain.

    Is dropping 32-bit support completely an option in an update to an existing app? I understand the business/technical implications of doing so, what I can't seem to find an answer to via Googling is whether or not Apple allows you to do this.

    Edit: As a comparison point our Android build is 35 MiB with identical game data. I know it's an apples and oranges comparison but I thought it was worth mentioning to give a sense of how small our game data is and how different the sizes between the two are.
     
    Last edited: Jun 6, 2015
  34. catacomber

    catacomber

    Joined:
    Sep 22, 2009
    Posts:
    674
    You can drop the 32 bit support and build only for 64 bit from what I understand from asking in the Apple forums. But whether you can do that for an update I don't know. Maybe ask in the Apple developer forums. I got a quick answer. I asked if I could build only for 64 bit there and got a "yes but why would I want to do that" response. It does have business ramifications, especially if you have followers who were looking forward to running your app on a 32 bit device.
     
  35. larku

    larku

    Joined:
    Mar 14, 2013
    Posts:
    1,157
    I think one of the reasons for the much larger size of iOS apps here is that Apple encrypt/sign the app prior to compression which means that the final compress (of the .ipa) is very ineffective. Whereas .apk files compress much better..
     
  36. JeffersonTD

    JeffersonTD

    Joined:
    Feb 5, 2013
    Posts:
    231
    I had a game package whose size was about 28 megs (in testflight) prior to adding the 64-bit support by changing to the universal architecture. Now the game size is about 50 megs. That feels like way too much of a size addition. Can I expect to get much closer to that 28 megs by optimisations?
     
  37. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,450
    @shinymark

    Your best option for optimization is to follow the steps in David's initial post here to determine what is causing the size increase. If the entire 42 MB increase is from the 64-bit binary slice, then there is probably not a whole lot you can do from your end (other than drop 32-bit support, as you mentioned).

    However, if the increase from the 64-bit slice is less than the total increase, then we probably need to do some more investigation to determine where the size is going.

    Note from our side, we're still pushing to decrease binary sizes, so expect it to be less in the coming releases. However, we'll likely not be able to get both slices down to the size of a single slice.
     
  38. shinymark

    shinymark

    Joined:
    Aug 7, 2011
    Posts:
    51
    Thanks for the additional information. It looks like the 64-bit slice is approximately 34 MiB (~24 MiB code, ~10 MiB data), about 8 MiB less than the overall growth we're seeing after switching to IL2CPP.

    Even if that 8 MiB was recoverable somehow we'd still be over the size limit unfortunately. We will have to try to see if we can compress assets more, reduce texture sizes, etc. to reduce our game data size further. I'm not optimistic we can reduce the size by 17 MiB of compressed data without a major refactoring to download data dynamically post-install.
     
  39. dragonstar

    dragonstar

    Joined:
    Sep 27, 2010
    Posts:
    191
    i want to know if someone have submitted and app with the new unity version 5.1 and have been rejected? i got a lot of warnings on my game he runs well but still little worried if i finish the app and get rejected.
     
  40. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,450
    The IL2CPP version is pretty much the same between versions 4.6, 5.0, and 5.1. The compiler warning in generated C++ code occur in all versions. So while I've not heard of any app submissions with 5.1, I do know that we've had many app submissions with the C++ warnings occurring, and we've not had any rejections do to those warnings.
     
  41. dragonstar

    dragonstar

    Joined:
    Sep 27, 2010
    Posts:
    191
    thanks for answer hopefully when i finish the game soon for the submission i will not have any problems
     
  42. Quaker_SDR

    Quaker_SDR

    Joined:
    Jun 21, 2013
    Posts:
    34
    I have successfully made the xcode project with unity 4.6.6 [IL2CPP]. I am managing to build the app on my device. But when i try to archive its not letting to build, It shows lots of warning and throws BUILD FAILED.
     
  43. larku

    larku

    Joined:
    Mar 14, 2013
    Posts:
    1,157
    What are the errors that cause the build failed?

    Don't worry about the warnings for now - lots of warnings are standard with an IL2CPP build, but there will be an error that causes the build to fail - post that and we've got a chance of helping, but "build failed" is not enough information to provide any real assistance.

    If it turns out to be libiPhone-lib.a error (or similar) look at the second answer here:

    http://answers.unity3d.com/questions/538363/error-when-i-updated-to-xcode-5-to-get-import-to-i.html

    Quote:
    Looks like either Unity or Xcode incorrectly puts double quotes around the search path for the Libraries folder.

    In the project's Library Search Paths, find the entry that looks like this:

    \"$(SRCROOT)/Libraries\"

    double click the entry to edit it and remove the escaped double quotes, so it looks like this:

    $(SRCROOT)/Libraries

    The project should now compile correctly again.
     
  44. CPXTom

    CPXTom

    Joined:
    Apr 24, 2010
    Posts:
    113
    There is a UnityEngine.xml file included twice (I diff'd them) in iOS builds. Once in Data/Managed and once in Data/Managed/not-stripped Is this a required file? If so, does it need to be duplicated?

    There are also a couple SymbolMap files (for 32/64bit), I'm guessing these are required though?
    I'm in the middle of trying to get our ipa below 100mb. It hasn't been easy considering an empty project with just our scripts is ~60mb (universal build). We are currently using asset bundles to offload assets, but there are some that we had kept in, so the player wouldn't have to hit a download screen right away.

    My point is that any space we can get rid of the best :)

    I'm currently using Unity 5.1.1f1
     
  45. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,450
    @CPXTom

    I don't think that there is a need for the UnityEngine.xml file in either of the directories you mentioned. This file probably should not be included in the build at all. The fact that is sounds like a bug. Can you submit a bug report on this issue? We should be able to correct it.

    The SymbolMap files are used to generated accurate managed call stacks. So they are not strictly required, but if they are not present, managed stack traces will have some incorrect entries in them. If managed stack traces are not important for your project, then the SymbolMap files can be deleted.
     
  46. CPXTom

    CPXTom

    Joined:
    Apr 24, 2010
    Posts:
    113
    bug submitted, thanks!
    Edit: The case ticket is 705659_usa0k6b0s7ugesmj
     
    Last edited: Jun 18, 2015
  47. JoshPeterson

    JoshPeterson

    Unity Technologies

    Joined:
    Jul 21, 2014
    Posts:
    2,450
    @CPXTom

    Thanks, we will investigate it.
     
  48. PixelSquad

    PixelSquad

    Joined:
    Sep 4, 2014
    Posts:
    90
    Hi guys. Do you know if there's a way of submitting two separate binaries on iOS? One supporting 32-bit and another supporting 64-bit?
     
  49. larku

    larku

    Joined:
    Mar 14, 2013
    Posts:
    1,157
    Currently not allowed by Apple, I do believe they're working on something to address this situation though.
     
  50. moonjump

    moonjump

    Joined:
    Apr 15, 2010
    Posts:
    2,061
    No, but iOS9 includes a feature called App Thinning. It downloads the code required by that device, so allowing a much smaller download and storage requirements. Unity have it on their Research list on the Roadmap, so it is unknown how long before they support it. It is desperately needed.