I'm developing a reasonably simple app using Xamarin iOS and the smallest size I've gotten for the .app file is 13.5 MB.
I've performed all the recommended optimizations - no debug symbols, LVVM code generation, thumb-2, link all assemblies, single architecture only (ARMV7).
The first question is, does my 13.5 MB sound like something to be expected from Xamarin iOS, or am I likely doing something wrong?
The second question is, how much extra size overhead does Xamarin iOS add to an equivalent native implementation (roughly)?
The third question is, roughly how small can a Hello World app get compiled down to using Xamarin iOS?
The fourth question is, roughly how small can a native Hello World app get compiled down to?
The .dSYM is a directory that includes debugging symbols. This is not something you're shipping as part of your application (to your end users). Note that this is produced even in non-debugging builds since it allows you to symbolicate crash reports (that comes from end users running the release binary).
For the real application size you need to look at the .app directory.
You can learn quite a few tricks to reduce your application size (and build time) by watching this year Evolve video Advanced iOS Build mechanics. That will also answer the other questions you had.
Xamarin apps are a bit larger in release mode, as one would expect. As an example, looking at my binaries from two shipping apps, the binary + dlls are around 12m and 18m (I think I need to look into why the 18m one is so much bigger...). I would guess if I had done these in objective-c they would have been around half that size, from past experience building native apps.
If you're running debug hardware builds, they are enormous. the 12m example above jumps up to 96M (?!) for binary + dlls. Before I checked this, I had in my head that they doubled in size to deal with software debugger, but I guess there's a whole lot of other crap going in that I wasn't aware of.
Related
My SpriteKit playground book averaged 15 FPS on my MacBook Pro.
Do playgrounds run slower than iOS device simulations? If I run the same playground book on my iPad Pro, will the FPS limitation be similar? Will other apps opened on my computer limit the speed of playgrounds?
EDIT:
Moving code such as subclasses and extensions to auxiliary code in the "Sources" folder of the playground book allow the simulation to run quicker because the code only compiles once.
On the Mac, Xcode's "Playgrounds" are super useful for quick experiments but, due to their nature, terribly slow for "real" tasks.
If your code is more than a few pages long, and/or involves working with the UI, as you do with SpriteKit, the Playground may become really slow, sometimes even unresponsive.
"Playgrounds" are part of Xcode and run on top of the iOS simulator - that's how they display graphics and UI in the "Assitant Editor". The iOS simulator is not really known to be fast either.
On the other hand, "Swift Playgrounds" on iOS is a completely different app, even if it shares a lot with its Mac cousin.
Most importantly, it runs in iOS on the real device, with the real hardware processing, not emulation, which makes it ideal to use for SpriteKit, as Apple themselves often shows in their demos.
I would therefore say that your code should indeed run faster/better/properly on the iPad version.
Even if of course, I can't really know, since I don't know your code - you will probably be the one telling us later if using the iPad version made a difference.
I like Apple and the things they do, but Swift... OH GOD!
I have a problem with `Swift` compile time.
Configuration:
MacBook Pro (Retina, 13-inch, Mid 2014)
2,6 GHz Intel Core i5
8 GB 1600 MHz DDR3
SSD 256 (up to 800 MB/s)
1k classes
10 pods
Compile time: 3 min.
Looks like for "new best and amazing swift, the dream" this configuration is not enough and it works like Google Chrome - InfiniteLoop(find free memory - eat)
I tried various methods to speed up the compile time:
Set HEADERMAP_USES_VFS to YES (no change)
Set Build Settings / Architectures / Build Active Architecture Only
to YES (some improvement)
Set defaults write com.apple.Xcode PBXNumberOfParallelBuildSubtasks 4 (8)
(sometimes it's become even worse)
Set optimisation level to -Onone (no major improvement)
Set debug information format - DWARF instead of DWARF with dSYM File
Disable Find implicit dependencies from your scheme (no major
improvement)
Created a new project and moved all files to the new one (takes too long and give small time improvement)
Change compilator from default to others available (even worse)
Strict rules on how to write fast compiled Swift code (below more details)
I've found a few posts where people describe the same problem: here and here
I guess everyone is waiting for new Xcode 8.2 beta 2 where:
Xcode will not rebuild an entire target when only small
changes have occurred. (28892475)
But this is only partially true, I still have long compile time - moved from 6-12 minutes to 3-8. Detailed description of this can be found here and here
Also, I followed all these rules during code writing:
Chained function reduction
Unwrapping the optionals
Implicit typing for an object (dictionary especially)
Avoiding ?? operator (this one extremely hungry!!)
Avoiding ?: operator
In othe words, don't use any "new cool features" because you'll wait for ages.
One more try - is a workaround described here:
Go to Product -> Scheme -> Edit Scheme. Select Build in left side
column and uncheck "Find implicit dependencies" But this flag should
remain checked when you are building the project for the first time.
But, this workaround isn't what I'm looking for and this is also can be as a temporary solution.
Swift is a pain not because it's hard to write, but because it's hard to use (at least on some machines).
For comparison: I have a project on Objective-C with 2k classes, and 11 pods - clean compile time is ~30 seconds.
Also I found a lot of opened bugs on swift performance:
SR-2461
SR-1465
SR-1707
SR-663
and many others, the list is too long, and some of them were opened a few years ago
My question is:
Does anyone have any solution on improving compile time for Swift?
This issue has been extremely frustrating for me as well. We've tried several of the solutions you've mentioned and none of them worked.
The one thing that made a significant improvement in compilation time is:
Turning on the Whole Module Optimization while adding -Onone in Other Swift Flags.
See this - Speed Up Swift Compilation
I'm using Swift 3 with Xcode 8.3.
We improved our compile times a lot by using Carthage instead of Cocoapods to include third party libraries.
It's likely you have code optimisation switched on, whilst this is a must for building your release version, for dev builds it isn't particularly important.
What code optimisation does is exactly what it says, it optimises your code to make the end binary that is produced smaller. It does things such as rename variables/methods to single characters etc... Like I said you obviously want this when submitting to the app store but you might not care if the app is larger whilst developing it.
You can turn off code optimisation for development builds by going to Project Settings > Build Settings, searching 'optim', under Swift Compiler - Code Generation set Optimization Level to None [-Onone] for Debug builds.
This should significantly improve your build times.
WHOLE MODULE OPTIMIZATION WITH NO DEBUGGING RESTRICTIONS
Just add SWIFT_WHOLE_MODULE_OPTIMIZATION as an user-defined setting with the value YES and your compile times should improve a lot.
This fix was introduced by the developers at Zalando. Shout out to them.
https://jobs.zalando.com/tech/blog/improving-swift-compilation-times-from-12-to-2-minutes/?gh_src=4n3gxh1
I just have some problems uploading my app to the appstore.
The problem is the 60MB filesizelimit for armv7! (See Screenshot)
There are almost no embedded images or something like that.
the application-file is only 0,5MB to big, but I'm sure it will increase soon due to next updates
Are there any possibilities to reduce the application size? Or maybe to change some settings for excluding the armv7 and only build for 64bit?
Our App is online since a couple of years and now we got "too big"? I see no possibility to "reduce" the code.
I build with AIR 22 and compiler options "-optimize=true -strict=true"
There's 2 ways.
The first is make your binary under 60MB.
2nd way is setting up project deployment target number.
ths following is I received email from Apple DTS
There are a few approaches to solving this situation:
Look through the suggestions in Q&A 1795, Reducing the size of my app. The section on compiler options is relevant for your scenario. Also, if you have data in your binary, such as long strings, tables, or encoded images, you should move those resources out of your binary and into external files.
https://developer.apple.com/library/ios/qa/qa1795/_index.html
The 60 MB limit is per architecture in your main executable. Identify sections of your app that would make sense as either a single framework, or as a small number of frameworks, so that they are built into a different binary.
If your app’s minimum deployment can be raised to iOS 9, the limit on executable size is higher, up to 400 MB for the entire executable. This is described at the link below.
https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/iTunesConnect_Guide/Chapters/SubmittingTheApp.html
I tried to get answer to my question searching among other questions already answered but I did not.
Actual, my question is very simple:
I am trying to integrate third party frameworks to support Ads in my iOS app (AdMob by Google e MoPub). What I can see is that these framework are really huge (>10MB each one). So, I guess the final app size will be very large, also for a trivial app. How can I handle this. I think this is a common situation. Am I missing something in integrating third party frameworks? How do you handle Ads integration in your apps? If you want to have AdMob and you download the latest GoogleMobileAdsSdkiOS-6.12.2, it weighs 13.4MB!
I hope my question is clear enough.
Wait for answers, thank you very much.
Have you tried to make a Release build (e.g., by using the Archive command) of an app that links those frameworks and check the final size?
When the app is built for release, all debug information and other symbols that are required for linking are stripped out, so the binary size will shrink a lot, usually.
Be assured that a release build will be much smaller than a debug build and that the debug build will be smaller than the sum of the individual binaries that you are linking together. You could go, in specific cases I am thinking of, from 200MB pre-link to 2MB after linking in release mode. Generally speaking, unless you have many images or other kind of media bundled with a library, the size will not be a great concern (compiled code shrinks a whole lot) -- but there is no other way than linking the library and see what the linker comes out with to know the real size...
I am uploading my iOS application on iTunes. I am using MonoTouch for compiling my LibGdx Game for iOS. In Android it is hardly 7-8mb. But When I upload on iTunes AppStore then its goes to 78 mb. I dont know why ? Please Let me know.
I have also received this error from Apple.
Dear developer,
We have discovered one or more issues with your recent delivery for "Run Panda Run: Racing". To process your delivery, the following issues must be corrected:
Invalid Executable Size - The executable size of 72037504 bytes exceeds the maximum allowed size of 60 MB.
It's hard to give a definite answer without more details. There's a lot of things that can affect the size of the applications. Let's start with the basic.
What you should check:
First, ensure that your application is not being build with Don't link. That will create very big applications since you'll be AOT'ing nearly the full .NET framework that Xamarin.iOS ships;
Second, make sure you're building for a single architecture (ARMv7). FAT binaries (e.g. ARMv7 and ARMv7s) are build two times and needs twice the space;
Third make sure you have not enabled the Debug build (it's possible to do so in Release build, it's a checkbox). That will create larger binaries to support debugging;
Fourth make sure you're using the LLVM compiler. It takes more time to compile but it generates better (and smaller) code;
Those initial checks are pretty easy to do and are the most common reasons for getting very large binaries.
To understand where the size come from you need to know how the application are built.
The main difference between the Android and iOS version is that JIT'ing (just-in-time compilation) is not allowed on iOS (Apple's rules).
That means the code must be AOT'ed (ahead-of-time compilation) and that process creates much larger executables (because IL is way more compact than native code);
If your code is generic-heavy then the final binary can get quite large since it will need to natively compile every generic possibilities (many cases can be shared, but value-types cannot).
What you can do to reduce size:
First try to reduce your managed code size. The easy way to do this is the enable the linker on every assemblies, i.e. Link all assemblies in your project options.
Many people think it's not worth linking their own code - because they know it will be needed at runtime (so the linker cannot remove it) or else they would not have written that code.
That's half true. The linker might not be able to remove most of your application code but if you're using 3rd party assemblies they are not likely 100% used. The linker can remove that extra code (and also remove, from the SDK, all the code that is kept to support that unneeded code). The more shared code you have the more the linker can help you.
Less IL code means faster AOT time, which translate to faster builds and smaller final binaires (including the executable size).
Note: there's a lot of documents and blog entries on how you can control the linker to skip some assemblies, some types or method from being processed/removed.
Second try to reduce your native size. If you're building native libraries then have a second look at them as they will be statically (not dynamically) linked to your final binary (another rule for iOS applications). Some of them might not be worth (feature wise) their weight in your final binary (and there might be lighter alternatives).
Debugging should not be enabled, as it will make the build unnecessarily large.
For more information refer : https://learn.microsoft.com/en-us/xamarin/ios/deploy-test/app-distribution/app-store-distribution/publishing-to-the-app-store?tabs=windows
I had the same problem but in my case I had minimum os version set to 8 in the info.plist causing a larger .ipa file. I changed this to version 10 and was able to pass the size requirements. Even 10 is a bit generous