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