Android app size and lib_FoundationICU.so

[marcprux (Marc Prud'hommeaux)]

@Finagolfin

In the general case, they do need localization, but what percentage of apps will stick localized strings or time/date lookups in their natively compiled Swift code? Probably not many.

On the contrary, I think almost every app will need to be able to format arbitrary numbers like 1,234,567.89 for the US and as 1.234.567,89 or 1 234 567,89 in Europe. And any app that shows a date needs to know that 1/2/2025 means something different to a US user (January 2) versus most other places (February 1). And as @jrose mentions, string sorting without locale awareness will be nonsensical for many languages. These all need FoundationInternationalization and the ICU data, or a subset thereof.

@Finagolfin

This seems like something you could immediately implement, ie have lib_FoundationICU.so load this data from a local file at first access rather than have it hard-coded in each arch-specific library. This would give you the biggest gain on Android for the least work and could likely be upstreamed back to Foundation, behind an optional build setting if nothing else.

I think you are right. It should be fairly straightforward to patch icu_packaged_data.h to access the data from an external resources if ICU_EXTERNAL is set, which immediately removes the issue of the duplication of the data in each arch's .so, as well facilitates compression of the data in the archive and, optionally, pruning out unneeded locale data at the packaging stage.