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...
Related
I am facing the project which should be as many other "boost cleaners". I'd appreciate any advise on this theme. As far as my research goes, I see, that it is quite more difficult to do in iOS, rather then Android. I don't hope for any good lib out there, and should probably do platform channels.
In general I need right now somehow get all device info - memory, battery, installed apps, cache, etc.
AS I've said, I had done a bit of research, and see the problem as stated.
If you can use Libraries for it i don't think there is any library which can support all info so you will have to use multiple libraries.
Just make sure library should support all the platform you want to build you apps on.
https://pub.dev/packages/system_info_plus.
https://pub.dev/packages/battery_info.
https://pub.dev/packages/device_info_plus.
https://pub.dev/packages/installed_apps (Only Android)
I'm very interested in using GStreamer's iOS framework http://docs.gstreamer.com/display/GstSDK/Installing+for+iOS+development for video streaming, but when I add the framework to a blank project and add a few lines of code to take advantage of its powerful features, the final IPA is 27MB. This is just way to big to be adding to my project, what is the best way to go about stripping this down the the bare necessities as I'm sure I'm only using a small percent of the code that is included in the SDK.
Here's a pic showing the package contents of the IPA:
Thanks!
In the gst_ios_main.h you can disable all the plugins that you don't need (make sure to enable linker optimizations so that unused code is removed). If that's not enough, you can build your own stripped down version of the iOS binaries with http://cgit.freedesktop.org/gstreamer/cerbero/ (you need to remove things from the .package and .recipe files to only build what you need). Just disabling things from gst_ios_main.h should be enough in 99% of the cases though.
Note that by default you'll build applications for multiple architectures, as such the resulting application will be rather large. Depending on your use case you can drop some architectures.
On another note, gstreamer.com is providing an completely outdated version of GStreamer and is in no way related to the GStreamer project. The official website is http://gstreamer.freedesktop.org .
SDKs have their source code encapsulated away from you, the user. You get access only to header files. Thus you just can't extract some class from it because you don't have access to the implementation file.
Of course if this library is opensource you can attempt to isolate one class, but sometimes everything is so deeply connected, that it is close to impossible.
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.
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
The library can be found here:
http://lpsolve.sourceforge.net/
The demo code on the site shows them doing a #include "lp_lib.h" and then making API calls to the library.
My question is: how do I get the various .so files that the site provides in the download of the library into a format and into xcode in a way that lets me include the .lib and make API calls to it?
Compiling lp_solve for the armv7 architecture is incredibly difficult and has gotten the better of many talented people. I say this because the above answer makes it seem like if you follow the instructions closely enough you will be able to compile, then drag and drop.
I would use GLPK which I got to work on iOS. https://github.com/wisaruthk/MyGLPK.
The gentleman that compiled this package for iOS initially attempted to do it for lp_solve, but could not get it to work. This package will allow you to do a proof of concept, but infects your app with the GPL license. If you want to put your app on iTunes, you'll have to figure out how to get your hands on a commercially friendly package.
AlgLib is the cheapest commercially available library, but it does not have mixed integer programming. Other solutions Gurobi, Frontline Solver, NAG, Rogue Wave charge in excess of $5,000 for a developer license and will cut you a deal at scale to only charge your users $350 for a run time license.
In iOS, you cannot use dynamic linking, i.e., you will have to link lp_solve statically. The docs have instructions on how to build the static library here.
When you're done compiling the static library, simply drag'n'drop the resulting .a file into the project and add it to the linking step of your target. That should be it. However, since lp_solve is LGPL-licensed, pay attention to licensing issues, see here.