Как сделать универсальную библиотеку iOS для Objective-C и Swift?
Мне нужно создать библиотеку для iOS (либо Framework, либо статическую библиотеку - я еще не решил), которую можно будет использовать как в проектах Objective-C, так и в Swift. Каков наилучший способ сделать это? То, как я это вижу, у меня есть три варианта:
- Напишите библиотеку в Objective-C и добавьте поддержку Swift (мостовые заголовки и т. Д.).
- Напишите библиотеку на Swift и добавьте поддержку Objective-C.
- Написать две библиотеки, обе в Objective-C и Swift. Я действительно хочу избежать этого варианта.
Основное требование здесь заключается в том, чтобы разработчики могли использовать его как можно проще. В идеале они должны иметь возможность выбирать свой язык и не заботиться или даже не знать, на каком языке написана сама библиотека. Можно ли это сделать?
Кроме того, я хочу иметь возможность распространять библиотеку с CocoaPods, если это имеет какое-либо значение.
1 ответ
Вариант 2. Не может быть и речи (подробно описан позже)
Вариант 3. Как вы сказали, вы должны действительно избегать этого.
Вариант 1 самый лучший. Просто создайте свой API с учетом Obj-C и Swift. Что это значит?
• Не используйте селекторы - они не являются стандартом Swift.
• Использовать Nullability для преобразования в опциональные
• Закрытия и блоки могут иметь одинаковый синтаксис, но есть небольшая разница, остерегайтесь этого:
Закрытия Swift и блоки Objective C совместимы, поэтому вы можете передавать замыкания Swift методам Objective C, которые ожидают блоки. Закрытия и функции Swift имеют одинаковый тип, так что вы даже можете передать имя функции Swift.
Замыкания имеют семантику захвата, аналогичную блокам, но отличаются одним ключевым способом: переменные изменяются, а не копируются. Другими словами, поведение __block в Objective-C является поведением по умолчанию для переменных в Swift.
Источник: Apple использует Swift с какао и Objective-C - это объясняет все подробно.
Вы можете прочитать больше здесь.
При разработке такого API вы должны знать, как все конвертируется, но если вы все сделаете правильно, пользователи не заметят разницы:)
Файл модуля
Убедитесь, что ваш x.framework поставляется с modules папка и файл внутри.
Новый Xcode генерирует его для вас. Таким образом, пользователи могут использовать ваш проект Obj-C в Swift, не добавляя его в файл моста. Так они могут просто import myLib из коробки.
Почему не Свифт?
К сожалению, самый разумный способ распространения скомпилированной библиотеки прямо сейчас - это написать ее в Objective-C.
И это из-за одной большой причины: проблема быстрой двоичной совместимости
Несмотря на то, что обеспечивается совместимость приложения во время выполнения, сам язык Swift будет продолжать развиваться, и двоичный интерфейс также будет меняться. На всякий случай все компоненты вашего приложения должны быть собраны с одной и той же версией Xcode и компилятором Swift, чтобы обеспечить их совместную работу.
Это означает, что фреймворки должны тщательно управляться. Например, если ваш проект использует фреймворки для совместного использования кода со встроенным расширением, вы захотите собрать вместе фреймворки, приложения и расширения. Было бы опасно полагаться на двоичные фреймворки, использующие Swift, особенно от третьих лиц. По мере изменения Swift эти фреймворки будут несовместимы с остальной частью вашего приложения. Когда бинарный интерфейс стабилизируется через год или два, среда выполнения Swift станет частью операционной системы хоста, и это ограничение больше не будет существовать.
Питер Стейнбергер, основатель PSPDFKit, который также является библиотекой, распространяемой в виде скомпилированной библиотеки, столкнулся с той же проблемой: на данный момент они застряли в Obj-C и не могут использовать Swift.