mParticle / mparticle-apple-sdk

mParticle Apple SDK
Apache License 2.0
46 stars 66 forks source link

test: Ensure language code consistency on iOS 17 #217

Closed einsteinx2 closed 1 year ago

einsteinx2 commented 1 year ago

Summary

We have a failing unit test on Xcode 15/iOS 17 due to a change in the way the locale/language string is generated in MPDevice.

/Users/dev/mparticle-apple-sdk/UnitTests/MPDeviceTests.m:40 testDictionaryDescription: ((testDictionary[@"dll"]) equal to (@"en")) failed: ("en-US") is not equal to ("en")

It looks like iOS 17 now uses the full ISO language + location string (en-US) in [NSLocale preferredLanguages] instead of just en.

Interestingly, according to Apple (and various SO question and blogs), they supposedly changed this format from “en” to “en-US” back in iOS 9…but I can confirm that in a test app if I run it on iOS 16, I get “en” and with no code changes, on iOS 17 I get “en-US”…

See this technical note here: Technical Note TN2418: Language Identifiers in iOS, macOS, watchOS, and tvOS

With iOS 9, the results returned by Locale.preferredLanguages() can differ from previous releases. In iOS 8 and earlier, only certain language, script, and region combinations were returned by this API. However, in iOS 9, more combinations of language, script, and region are permitted. This change is also applied to macOS Sierra, watchOS 3, and tvOS 10.

For example, when a user has configured their iOS device with language set to English and region set to India, Locale.preferredLanguages() will now return [ "en-IN" ], instead of [ "en" ].

So no idea why we’re only hitting this now on iOS 17, but to keep things consistent, I’ve changed the logic to only grab the language portion and throw out the country code. This is a standard ISO format so it can be relied on to be consistent (e.g. it won’t sometimes be en_US or en:US or en US, it will always either be en or en-US, etc).

Testing Plan

einsteinx2 commented 1 year ago

In this case, changing the data format could/would be considered a bug as customers would start to receive different values depending on what iOS version the user is on, so I think this is the correct solution for now.

We can definitely look into providing the new style value, but it would likely need to be opt in as in general customers don't like data formats changing out from under them... In any case, agreed that would be a product decision.

mparticle-automation commented 1 year ago

:tada: This PR is included in version 8.15.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: