Add iOS device accessibility settings to device properties.

[selanthiraiyan]

Related to - woocommerce/woocommerce-ios#7576

Changes

In order to understand the accessibility settings of our users, this PR adds the following properties to the deviceProperties dictionary of analytics events.

• preferred content size category to know the font size settings.
• is accessibility category boolean to know whether the font size falls under accessibility category.

Known issue

As this PR adds two properties to the Transformable deviceInfo (a dictionary) property of the core data model, we will face errors when trying to load stores created using previous versions of the core data model.

This is handled here by deleting the old store and creating a new one using the latest core data model.

I hope that we have to use a ValueTransformer to deal with the Transformable deviceInfo property of the core data model. I am not sure whether this issue was ignored because,

• A change to the Transformable dictionary (deviceInfo, customProperties, and userProperties) type properties is not supposed to happen often.
• Optimistically, the events are expected to have been already uploaded by the time the user updates the app, and the store gets deleted. 🤞

Please correct me if I am wrong about this.

Testing instructions

Follow the testing instructions from woocommerce/woocommerce-ios#7576

[jaclync]

LGTM, thanks for taking on this task to help us understand the usage

If I understand the two properties correctly, do they correspond to the two controls in the settings below?

I was trying to verify the new properties in Tracks Live View but couldn't seem to access them probably due to a data backend issue p1661755847008199-slack-C03DKP1JP. The API requests seem to send the expected properties, so we can verify them in Tracks later.

Re Known issue:
I also saw Core Data error messages in Xcode like this:

CoreData: annotation: reason : The model used to open the store is incompatible with the one used to create the store

But I also checked Wormholy that application_opened (the first event) is always tracked despite the migration errors. I didn't test the case with unsent events before the migration, but it seems like another previous PR that adds a new device information property didn't do anything about it either.

[jaclync]

I haven't used Objective-C for a long while 😅 do you know if this pauses the return statement below until this line is called when it's not on the main thread?

[selanthiraiyan]

It has been a long time for me as well. 😅

do you know if this pauses the return statement below until this line is called when it's not on the main thread?

Yes, as we dispatching synchronously using dispatch_sync, this will wait before executing the following return statement.

[jaclync]

this doesn't seem to match the behavior in the comments for this method?

This will be null for Mac OS.

Suggested change

	return @"Unknown";
	return nil; // or NULL in objc?

[selanthiraiyan]

Nice catch. Done in bbb876a

[selanthiraiyan]

If I understand the two properties correctly, do they correspond to the two controls in the settings below?

Oh, it looks like that. I didn't realise this before. 😄

I added the device_info_is_accessibility_category property with the help of UIContentSizeCategoryIsAccessibilityCategory method as it looked like an easy way to filter events.