В этом случае нет «наилучшей практики». Есть практики, и некоторые могут быть немного более подходящими для вашего случая, чем другие.
Вы говорите, что не планируете добавлять поддержку других языков, но кажется, что вы хотите быть готовым к этому, если передумаете. Итак, прежде всего, спросите себя, какова реальная проблема, решение которой вы ищете. Я бы сказал, что проблема заключается в накладных расходах, которые вы получаете, когда приложение уже вышло, и вам нужно найти все строки, которые вы использовали в своем приложении, и обернуть их в NSLocalizedString. Обычно это включает в себя бесконечное тестирование, и вы все равно, в конце концов, скорее всего забудете локализовать хотя бы несколько строк.
Вы можете с самого начала начать упаковывать вещи в NSLocalizedString, что в итоге поможет вам извлечь все строки, используя встроенные инструменты из вашего кода. Проблема тогда - все еще Раскадровки; не столько извлечение строк из раскадровки, сколько удаление тех текстов по умолчанию, которые вы не планируете переводить (например, «Имя» на самом деле будет некоторым именем и не должно переводиться) Так что по моему опыту это половина решения.
Для решения проблемы раскадровки должен быть инструмент (я не могу вспомнить, какой, может быть, какой-то другой CocoaPod), который позволяет игнорировать представления, которые не следует переводить. Так что в этом случае вам нужно использовать 2 вещи; NSLocalizedString и игнорирование непереводимых предметов в IB.
Как вы уже сказали, вы можете использовать R.Swift для получения строк непосредственно из файла strings. Это очень аккуратно, но и отвлекает по мере вашего развития. При этом вы заставляете разработчика сначала ввести текст в файл strings, прежде чем он сможет его использовать. Лично я ненавижу это. Также это может быть проблемой, когда несколько разработчиков находятся в конфликте. Не говоря уже о том, что это почти не устранило вашу проблему с раскадровками.
Создание отдельной системы структур для хранения всех строк работает довольно хорошо. Вам не нужно выискивать все строки в вашем коде, и вам не нужно переходить к файлу strings (переход к другому источнику гораздо приятнее при разработке, поскольку вы можете легко переходить к нему). Вы также сохраняете хорошую структуру, предполагая, что вы поддерживаете ее как label.text = Strings.Settings.User.firstNamePlaceholder, которая помогает вам легко находить нужные вам строки или устаревшие. Вы можете удалить целые экраны с большой легкостью. Но это все еще непроизводительно для разработчика, и у вас все еще есть проблема, связанная с тем, что теперь вам нужно перетянуть все выходы из раскадровки, чтобы установить для них локализованные строки.
Выполнив эту процедуру, вы можете в итоге выбрать NSLocalizedString напрямую или R.Swift. На самом деле вы можете просто ничего не использовать, и у вас по-прежнему не будет много сверхурочных переключений на любое из двух (опять же, при условии, что поиск этих строк в коде занимает большую часть времени).
Лично я бы вообще ничего не делал или занимался бы созданием системы пользовательских структур, которая затем ничего не использует, а просто возвращает необработанные строки. Но все это на самом деле зависит от того, какого размера ваш проект, какого типа проект, сколько вещей находится в раскадровке ... Это также зависит от того, когда вы ожидаете, что у вас будет больше ресурсов, поэтому вы либо тратите больше времени сейчас и не беспокойтесь позже, или вы просто делаете это проще всего, теперь готовьтесь к большой работе, когда локализация действительно необходима (надеюсь, когда это произойдет, это одна из "сладких" проблем, потому что это означает, что у вас есть тонны пользователей).