Ответ 1
Я сам работаю над той же проблемой.
Мое текущее наблюдение состоит в том, что NSUserDefaults standardDefault содержит иерархию объектов (например,.plist), вы можете поместить все ваши ключи/значения SDK по умолчанию в некоторую запись "Dictionary" (например, названную в честь вашего домена SDK - "com.mydomain.frameworkname"). "). Это будет упаковывать ваши элементы и устанавливать их отдельно от собственных значений приложения.
Здесь есть и недостаток - KVO будет работать только для изменений ключа/значения верхнего уровня, поэтому вы не сможете "зарегистрироваться" для изменений значения по умолчанию, выполненных непосредственно в NSUserDefaults.
Затем есть часть "первой" загрузки "заводских значений по умолчанию" для SDK, в NSUserDefaults standardDefaults. Для этого есть стандартное поведение и API, называемый "registerDefaults".
Вы можете иметь некоторый ресурс .plist в своем пакете SDK, который называется "factoryDefaults.plist", а затем, при инициализации вашего SDK, вы будете делать что-то вроде этого:
NSString *path = [[NSBundle bundleForClass:[self class]] pathForResource:@"factoryDefaults" ofType:@"plist"];
NSDictionary* factorySettings = [NSDictionary dictionaryWithContentsOfFile:path];
[[NSUserDefaults standardDefaults] registerDefaults:factorySettings];
[[NSUserDefaults standardDefaults] synchronize];
Затем вы можете продолжить работу со значениями по умолчанию, используя стандартные пользовательские API-интерфейсы по умолчанию, вы можете обновлять их по мере необходимости и при этом сохранять настройки вашего хост-приложения в чистоте.
Можно скрыть неудобство копания в вашей отдельной записи SDK в NSUserDefaults standardDefaults, в классе, который как бы переопределяет функции NSUserDefaults и получит доступ к записи SDK вместо стандартного стандартного дефолта верхнего уровня.
Слово предостережения: я делаю это только сейчас - пока не могу сообщить об успехе. Поэтому я буду благодарен за любую критику и рекомендации, и вы можете попробовать этот метод.