It is a pretty common habit of developers to hard code labels and text directly into xib files or if they plan to localize, it is specified in localizable.strings files for iOS. For android, same goes into strings xml or some even hardcode into layout XML by ignoring warnings.
In most scenarios, the above approach is adapted for speedy development and with a misconception that there will be hardly any change for labels and headers or in case of any change, it would be a minor one that can be easily fixed.
But in adapting this, developers usually don’t consider the following things:
1) Difficulty in finding out where the text is displayed.
There are chances of other developers taking over the project, in which case it will be tough and time consuming for them to figure out the place from where the text has been set. It is not always the case that UI components can be easily found by searching its relevant xib (iOS) and layout (android) files. In some scenarios where the UI is generated dynamically, it becomes difficult to figure out from where the text is getting displayed.
2) Text changes after the app goes live.
Often it happens that, after the app goes live, the client turns up to change some text here and there which they found is not correct or there might be some typos that went unnoticed. In this scenario, if the strings were hard coded within the app, it will require an app update just to change the text. And normally big organizations don’t go for frequent app updates unless there is a blocker issue. In this scenario app will reflect wrong spelling / incorrect text till the time when there is a specific requirement for the new version to be uploaded. And in case of iOS, even the app approval time needs to be taken into consideration, which will delay the change being reflected by a week or two.
3) Maintaining consistency between different platforms.
If your app is supported on more than one platform, it can happen that text or error messages are different in iOS as compared to those on android for the same functionality. This would be a bad user experience and will affect client impression in the consumer market.
To avoid issues like these, there is an approach to handle text displayed on the UI for iOS / android app, from the server side, which provides flexibility to update it dynamically and does not require app version upgrades just for some copywriting correction.
To know more about this approach, be sure to check in on us in a couple of days when I’ll be posting a solution for the issues listed above.
Edit: Here’s Part 2 which talks about how I deal with the above issues! Dynamic handling of strings/text for Mobile apps – Part 2
Follow me on Twitter