Ship the Android and iOS V8 runtimes with ICU so Intl is available #11563

Is your feature request related to a problem? Please describe.

The NativeScript 9 Android and iOS runtimes ship V8 without ICU, so Intl does not exist:

typeof Intl // 'undefined'
new Intl.NumberFormat() // ReferenceError: Intl is not defined

Verified at runtime with @nativescript/android 9.1.1 on a physical device (Android 16) and @nativescript/ios 9.1.0 on an iOS 27 simulator. The same code works in Chromium, Safari/JSC, Node, and Hermes.

The cause is a build flag, not a runtime bug. Both build scripts in NativeScript/v8-buildscripts set it:

• scripts/matrix/build-android.sh: v8_enable_i18n_support=false
• scripts/matrix/build-ios.sh: v8_enable_i18n_support=false

The script comment says this "reproduces the shape of the 10.3 build these libraries replace". The flag was carried over from the old build rather than chosen fresh. The 14.9 rebuild seems like a good moment to revisit it.

The flag removes more than the Intl constructors. These engine features also fail or quietly misbehave on Android and iOS:

Real-world impact:

• Libraries crash at import. Any module that builds a formatter at module scope throws on load. One example is the common const fmt = new Intl.NumberFormat() pattern.
• i18n libraries break. @lingui/core calls Intl.PluralRules, so every pluralized message throws.
• Bundles need patching. Libraries that use \p{L} regexes (linkifyjs, @lexical/link, and others) fail to parse. Apps have to patch them or transpile the regexes.

Describe the solution you'd like

Build the Android and iOS V8 libraries with v8_enable_i18n_support=true, and initialize ICU in both runtimes before V8 starts.

Two packaging options would work:

1. On by default. This matches browsers and Node. React Native's Hermes exposes Intl on Android and iOS too, but delegates to the platform's ICU instead of shipping its own data — a precedent for exposing Intl by default, not for bundling ICU data (and that delegation path isn't available to V8 anyway; see alternatives).
2. An ICU runtime flavor. Ship it next to the existing AAR flavors and the iOS framework, selectable from app config. This also fits the "optional" direction in WinterTC Minimum Common Web Platform API Alignment #10297 (comment). The optional piece would be the engine build, not a JS polyfill.

Size data to help weigh the cost:

• Ship the data once. The scripts set icu_use_data_file=false, which embeds the data in every ABI's .so. With icu_use_data_file=true, Android can ship one architecture-independent icudtl.dat in assets. That stores it once per APK instead of once per ABI.
• Filter the data. ICU's data filters can trim locales and features further, as the Chromium and Flutter variants show.
• Precedent: react-native-v8 reports about 7 MiB per ABI for ICU, and the jsc-android intl variant about 6 MiB.
• Not measured yet: the ICU code-size delta under these exact GN args.

Describe alternatives you've considered

FormatJS polyfills. These are the current workaround, as suggested in #10588. They work: for the cases we tested, forced FormatJS gave byte-identical formatter output on Android, iOS, Chromium, and macOS JSC. They aren't a substitute for engine ICU:

• They can't fix engine features. \p{…} regexes, normalize, locale case mapping, and localeCompare stay broken.
• Size, measured with esbuild, minified:
  • About 957 KiB (250 KiB gzip) for eight constructors with English only.
  • About +337 KiB per extra locale.
  • About +789 KiB for time-zone data.
  • Intl.Collator with all locale data is 5.8 MiB.
• Startup: importing a full bundle (about 10 MiB) took 314 ms in a debug build on a physical Android device.
• Setup burden: every app must wire up load order, locale data, and defaults itself. Without that, the polyfills fall back to en and UTC on device.

Platform formatter bridges (android.icu, NSNumberFormatter/NSDateFormatter, like the legacy nativescript-intl). These give only a partial API whose output varies by OS version. iOS has no public plural-rules API. Hermes's maintainers describe the platform APIs as "simply inadequate for a complete and correct implementation" (facebook/hermes#1211). Hermes itself took this path for space efficiency and still hasn't reached parity — it lacks PluralRules, RelativeTimeFormat, ListFormat, Locale, and Segmenter, which a third-party ICU4X library (hermes-intl) now fills.

Anything else?

• Related: WinterTC Minimum Common Web Platform API Alignment #10297 (comment on Intl), Improved support for localeCompare #10617, Add Device number format #10588, toLocaleString() doesn't localise the number #8249, JavaScript Date functions not fully working #8472, localCompare not working with 'Umlaut' #7810.
• Where this came from: we found this building a cross-platform framework on NativeScript, where the same app code runs on web, macOS, iOS, and Android.
• Open question for maintainers: which shape would you accept — on by default or a separate flavor, and embedded data or a shared data file?

Please accept these terms

• I have searched the existing issues as well as StackOverflow and this has not been posted before
• I agree to follow this project's Code of Conduct