Могут ли Cocoapods поддерживать использование общей платформы как в приложении iOS, так и в расширении iOS, если общая платформа использует API, небезопасные для расширений?

Я поддерживаю набор связанных приложений для iOS, некоторые из которых используют расширения (WatchKit и Today Widget). Все эти приложения и расширения используют общую частную структуру, которую я создал с течением времени для обработки определенных рабочих процессов, связанных с аутентификацией и общей бизнес-логикой. Эта структура поддерживается как частный модуль.

Недавно я столкнулся с проблемой, когда я хотел бы добавить в структуру метод, который действительно полезен только для приложений iOS (расширениям это не нужно), который использует определенные API, недоступные для расширений (например, [ UIApplication sharedApplication]). Я хотел бы получить обычное преимущество общего кода, где он реализован только в одном месте (общая структура) для использования всеми моими различными приложениями. Однако я не могу найти способ условно включить этот метод только для приложений, а не для расширений, не получая ошибки времени компиляции.

введите здесь описание изображения

Обычные рекомендации по этой проблеме обычно предлагают использование препроцессора макрос, чтобы при желании отказаться от проблемного кода, но на самом деле это не работает в ситуации с общим фреймворком. Макросы применяются во время компиляции, поэтому общая структура либо будет включать этот метод, либо нет, и, похоже, не существует решения времени выполнения, которое могло бы его исключить. Если он включен, расширения не могут скомпилироваться. Если он не включен, мои приложения не могут использовать эту функцию.

Я также начал исследовать, есть ли какой-то способ, которым Cocoapods может автоматически создавать две версии фреймворка, одну для использования приложениями, а другую — расширениями, но это, похоже, создает проблемы с повторяющимися символами и, как правило, не вроде поддерживаются.

Есть ли какие-либо другие предложения о том, как справиться с этим, кроме простого извлечения проблемной функциональности в другой фреймворк? (Я действительно предпочел бы просто поделиться одним)


person beno    schedule 13.11.2016    source источник
comment
Никто еще не опубликовал ответ, но я был вынужден временно обойти это, перейдя к обработке этого с помощью вызовов responsesToSelector/performSelector во время выполнения.   -  person beno    schedule 21.11.2016