I doubt it that you have to hard-code any of these data for iOS supported locales. It would take some extra effort to be able to avoid hard-coding it for any locales at all.
iOS heavily utilizes locale-sensitive data from CLDR and your locale is supported, you don't have to localize these strings since translations for these relative date names (which is the category in CLDR terminology covering words such as "Today", "Yesterday", and "Tomorrow") are planned to be part of locale data. An example showing this data for German compared to English:
<fields>
...
<field type='day'>
<displayName>Day</displayName>
<relative type='-1'>Yesterday</relative>
<relative type='0'>Today</relative>
<relative type='1'>Tomorrow</relative>
</field>
...
</fields>
<fields>
...
<field type='day'>
<displayName>Tag</displayName>
<relative type='-2'>Vorgestern</relative>
<relative type='-1'>Gestern</relative>
<relative type='0'>Heute</relative>
<relative type='1'>Morgen</relative>
<relative type='2'>Übermorgen</relative>
</field>
...
</fields>
Also, I found out that NSDateFormatter
has two attributes called setDoesRelativeDateFormatting
and doesRelativeDateFormatting
which most probably give you what you need for those supported locales. I'm not an iOS developer so I can't say with certainty.
Although the data for ka-KE
is available in CLDR, but since this locale is not yet supported by iOS, you have to go through hoops to make it work; e.g. build ICU for iOS which was covered in detail in this answer or using the static build available here.