# Android app size and lib\_FoundationICU.so **URL:** \ **Category:** Android\ **Tags:** android, icu\ **Created:** [March 9, 2025, 5:26pm UTC](https://forums.swift.org/t/android-app-size-and-lib-foundationicu-so/78399 "2025-03-09T17:26:02Z")\ **Posts on this page:** 1\ **Showing post:** 7
**Author:** ![marcprux](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/marcprux/32/12098_2.png) [@marcprux](https://forums.swift.org/u/marcprux)\ **Post date:** [March 13, 2025, 7:27pm UTC](https://forums.swift.org/t/android-app-size-and-lib-foundationicu-so/78399/7 "2025-03-13T19:27:28Z")
> [@Tony\_Parker](#): > > Also, some parts of Foundation depend on functionality that is specific to Apple's ICU and has not been upstreamed for one reason or another. Ahh, well that effectively eliminates options #2 and #3, since I don't think Android's built-in ICU is ever likely to provide functions like `ualoc_getAppleParent`. > [@icharleshu](#): > > Currently, the `icu_packaged_main_data.*.inc.h` files are built from a prebuilt version of [Apple ICU](https://github.com/apple-oss-distributions/ICU). Ideally, in the future, we should build the data file as part of the SwiftPM build. This way, as you mentioned, we can also support optional thinning. However, I haven’t yet found a good way to “merge” the CMake-based build with the SPM build, which is why we’re currently using pre-built embedded files as an interim solution. I suspect the ultimate solution will involve rewriting the [ICU data build tool](https://unicode-org.github.io/icu/userguide/icu_data/buildtool.html) as a plugin, allowing it to be integrated into the SPM build. Yes, I'm thinking that externalizing the data to a separate file will be the solution (like on macOS: `/usr/share/icu/icudt74l.dat`). This is tricky on Android due to the way they expect assets to be accessed (see: [Overriding Bundle.module for loading resources from Android assets](https://forums.swift.org/t/overriding-bundle-module-for-loading-resources-from-android-assets/78507)). But one immediate benefit is that the app would only need to contain one single instance of the data file, rather than repeating it N times for each supported architecture. In addition, this opens the possibility of performing some "thinning" of the ICU data to only include those locales that are supported by the containing app. This is what Flutter does to keep its bundled ICU data size as minimal as possible. This thinning could be done as a post-processing step by the packaging tool for the app. --- _[View the full topic](https://forums.swift.org/t/android-app-size-and-lib-foundationicu-so/78399)._