Android app size and lib_FoundationICU.so

[keeshux (Davide)]

@marcprux

@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.

I'm getting here from the KMP thread, and while I agree on a leaner Foundation (and the Swift runtime, with a 10MB "core" plus 10MB libc++_shared.so is not a cakewalk either), I kind of disagree with the initial assumptions of this thread.

Here we tend to talk about apps, and apps definitely need localization, no doubt about that. However, from a cross-platform perspective, the common (and most sane) use case for Swift in Android is to create a library to share the business logic of the apps.

In this scenario, localization can be made a frontend/view concern to be resolved within the respective UI frameworks (SwiftUI and Compose), outside Foundation, IMHO. At least, I think that localization should be strongly opt-in, because in most cases, there are better workarounds to avoid its dependency at the library level (e.g. string keys, error codes, absolute UNIX/UTC timestamps).

My two cents.