In the modern mobile OSes (like iOS and Android) the applications are run into a sandbox for more control, security and performance reasons and there are no (easy) ways to separate/use a "runtime" library (in Delphi's case RTL + FireMonkey) to be shared by multiple apps. This problem is common to all mobile x-plat runtimes/wrappers like Adobe AIR (http://www.adobe.com/products/air.html) or Mono (http://www.mono-project.com).
In Delphi's case the problem with the increasingly fat apps (statically linking RTL + FireMonkey to the application binary) comes from the non-optimized linker (GCC/LLVM LD ?) that should "collect" into the generated lib/app just the actual code used not all the unused-dummies.
The good old Delphi linker used to be quite smart, being quite well known for generating small executables (VB-runtime killer !) ... but for some time, with the new added RTTI and Generics support the bloat was coming into Delphi's town as well.
In this context more than one year ago I created a QC proposal "Extended $RTTI for metadata inclusions & exclusions for classes and units" (http://qc.embarcadero.com/wc/qcmain.aspx?d=103317) but Embarcadero doesn't seems to be interested into it ... so please vote for it if you find it useful.
Now, with the new LLVM backed Delphi next-gen compilers and LD linker there is a different story, and I hope the compiler guys (Allen Bauer & co) are already looking to the bits in this area (LLVM & ld) for "smarter" linking to trim-out the unsed fat from generated executables.
So, while optimizations in the LLVM backed nextgen linker will benefit all the FireMonkey supported platforms (Win, Mac, iOS, Android) ending up to smaller static FireMonkey apps.... I consider that an Android specific solution will dramatically decrease the application size and benefit the overall runtime FireMonkey reuse.
My *PROPOSAL/IDEA* to Embarcadero is to add support for generating an application using a shared mobile FireMonkey runtime APK similar to Adobe's AIR runtime. The Adobe AIR runtime could be found here on Google Play: https://play.google.com/store/apps/details?id=com.adobe.air and the AIR applications using it will automatically detect its presence and if not available asking for it to be downloaded. I envision that Embaracadero could do the same, by creating a FireMonkey runtime to be made available on G
oogle Play (suggestion: https://play.google.com/store/apps/details?id=com.embarcadero.firemonkey) that will include all the FAT from the RTL and FireMonkey Android API ... so a Delphi FireMonkey app relaying an the FireMonkey Runtime will include just the REAL code & resources ... Anyhow, while the implementation might not be a small feature ... this should be quite "natural" to Delphi that already supports dynamic runtime packages.
I created a QC Feature Request so please vote if considered useful: "Create a shareable FireMonkey Runtime for Android" http://qc.embarcadero.com/wc/qcmain.aspx?d=119119
*NOTE*: This "feature" could not be definitely used on iOS due to drastically constrained sandbox/Apple policy where you can't access non-Apple shared libs. In this case Adobe AIR use a "Captive" runtime for iOS where the AIR runtime is statically linked to the application (similar to in Delphi's FireMonkey approach)
As a reference, here are some useful links in the context of Adobe AIR Runtime for Android and iOS:
How are Adobe AIR applications packaged and deployed?
Package Adobe AIR applications for Apple iOS devices
Adobe AIR Runtime for Android ...
Adobe AIR Captive Runtime FAQ
Installation and deployment options in Adobe AIR 3
*MORE-GENERAL PROPOSAL*: Providing dynamic package support for Delphi for Android compiler/linker could greatly benefit the Delphi components providers (including Embarcadero with the above proposed FireMonkey Runtime for Android) that could create specialized Android "component packages" (similar to VCL bpls) that could be shared into the Google Play. I see quite a *HUGE BENEFIT* for Delphi Android developers and vendors with having such support in our Delphi tool-chain for Android !