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.
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.
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?
Yes, after reviewing this I think that approach makes sense, so let's proceed. Nice job on the thorough discovery.