iOS - Spike for looking how we can update strings in strings.swift class and its inner classes.

Description

To introduce the in app setting for language update we did spike and found that the strings which are using in whole app are coming from Strings.swift class which has inner classes and static variables which actually created via script when we start the app and view initialises, due to static behaviour they are not updating on runtime.

We decided to create this ticket to find the workaround for the strings.swift classes update and look how we can move forward for the in app language setting feature.

Steps to Reproduce

None

Current Behavior

None

Expected Behavior

None

Reason for Variance

None

Release Notes

None

User Impact Summary

None

Activity

Show:
Salman Nawaz
October 3, 2019, 9:53 AM
Edited

According to current code architecture for strings localization, the script is running. When we add strings in the localized file the script creates inner classes, variables and functions which are generated at compile time. It is difficult to update the strings at run time as per our current implementation. The only solution seems to terminate the app and restart it again.

For now, we come up with a solution that after changing the language from the app setting, we would show the alert message that you would have to terminate and restart the app again, If a user would go for this option the app will be closed. When a user would restart the app the strings file would be updated as per localized setting.

I searched and found many developers to say that this is not recommended by Apple.

 

The iOS Human Interface Guidelines specify,

"Always Be Prepared to Stop iOS applications stop when people press the Home button to open a different application or use a device feature, such as the phone. In particular, people don’t tap an application close button or select Quit from a menu. To provide a good stopping experience, an iOS application should:

Save user data as soon as possible and as often as reasonable because an exit or terminate notification can arrive at any time.

Save the current state when stopping, at the finest level of detail possible so that people don’t lose their context when they start the application again. For example, if your app displays scrolling data, save the current scroll position."

> It would be appropriate to remove any mechanisms for quitting your app.

Reference Link:

https://stackoverflow.com/a/14335936

https://developer.apple.com/library/archive/qa/qa1561/_index.html

 

cc

Mian Khalid
October 4, 2019, 11:21 AM

As this is a feature that would help quite a lot of our userbase and due to our current code architecture, the only easy way to implement such a feature requires terminating and restarting the app, we should go ahead with it.

Re: excerpt from the link you shared:

Warning: Do not call the exit function. Applications calling exit will appear to the user to have crashed, rather than performing a graceful termination and animating back to the Home screen.

Suppose a user selects a language, a dialog will appear asking for their permission while notifying them that pressing the OK button will terminate and restart their app, that would be a pretty graceful thing in my opinion. What's your take on this & ? Should we go ahead with this approach?

Greg Sham
October 9, 2019, 3:26 PM

Yes, after reviewing this I think that approach makes sense, so let's proceed. Nice job on the thorough discovery.

Assignee

Salman Nawaz

Reporter

Salman Nawaz

Labels

None

Reach

None

Impact

None

Platform Area

None

Customer

None

Partner Manager

None

URL

None

Contributor Name

None

Groups with Read-Only Access

None

Actual Points

None

Category of Work

None

Platform Map Area (Levels 1 & 2)

None

Platform Map Area (Levels 3 & 4)

None

Story Points

2

Components

Sprint

None

Priority

Unset
Configure