Импорт Project-Swift.h в класс Objective-C... файл не найден
У меня есть проект, который был запущен в Objective-C, и я пытаюсь импортировать некоторый код Swift в те же файлы классов, в которых я ранее написал Objective-C.
Я консультировался с документами Apple по использованию Swift и Objective-C в том же проекте, а также с таким вопросом, как этот, но все еще безрезультатно: я продолжаю получать сообщение об ошибке "файл не найден" после помещения в #import "NewTestApp-Swift.h" (NewTestApp это название продукта и модуля).
Вот что я сделал до сих пор:
- В
Define Modules, выбранныйYESдля приложения. - Убедитесь, что в имени модуля продукта не было пробела (см. Скриншот ниже вопроса)
Я пытался использовать #import "NewTestApp-Swift.h" внутри ViewController.m, ViewController.h а также AppDelegate.m но ни один из них не сработал.
Что еще я делаю неправильно? Спасибо за вашу помощь.
Скриншот настроек:
Ошибки, с которыми я сейчас сталкиваюсь:
21 ответ
Я столкнулся с той же проблемой и не смог заставить мой проект быстро импортировать в классы obj-c. Используя Xcode 6, (должен работать для Xcode 6+) и смог сделать это таким образом....
- Любой класс, к которому вам нужно получить доступ в файле.h, должен иметь такое предварительное объявление
@class MySwiftClass;
- ТОЛЬКО в файле.m, если код находится в том же проекте (модуле), то вам нужно импортировать его с
#import "ProductModuleName-Swift.h
Ссылка на яблочную документацию об этом
Если код Swift находится внутри модуля (как в вашем случае):
#import <ProductName/ProductModuleName-Swift.h>
Если код Swift находится внутри проекта (смешанный Swift и ObjC):
#import <ProductModuleName-Swift.h>
В вашем случае вы должны добавить эту строку в файл *.m:
#import <NewTestApp/NewTestApp-Swift.h>
ВАЖНО: посмотрите на "<" в операторе импорта
Как мне удалось импортировать swift в target-c:
- Определяет модуль, установленный на YES (на проекте - не на цели)
- Наименование модуля продукта установлено (на цели - не на проекте)
В вашем ViewController.m импортируйте код swift с помощью:
#import "MyProductModuleName-Swift.h"- Добавьте файл swift в ваш проект target-c (File -> New -> Swift), и Xcode создаст соединительный заголовок из target-c в Swift, но это крайне важно для того, чтобы заставить его работать и наоборот - очевидно.
За последний фрагмент этой головоломки спасибо Swiftoverload за то, что он сообщил мне о фактическом добавлении файла Swift через графический интерфейс Xcode, а не просто перетаскивании существующих swift-файлов в мой проект, чтобы заставить его работать: http://nikolakirev.com/blog/using-swift-in-objective-c-project
Используя Xcode 8.2.1 и если вы посмотрите на Проект > Настройки сборки> Имя заголовка сгенерированного интерфейса Objective-C, там он покажет только один заголовочный файл, названный как Product -Swift.h
Это означает, что вместо импорта каждого модуля отдельно из файла Objective-C .m, используя отдельный файл -Swift.h, вы просто импортируете один продукт -Swift.h, который объединяет все модули Swift.
Я столкнулся с той же проблемой, когда искал традиционный способ импорта модулей по отдельности, но текущая версия Xcode и Swift 3 изменила его, чтобы использовать только один заголовок для импорта всех модулей.
Потратил час на решение этой проблемы, выполнив следующие действия, чтобы понять, чего не хватает:
- Откройте настройки XCode и перейдите в папку DerivedData.
- Искать "swift.h" в поиске
- Если вы не можете найти файл project-swift.h, этот файл не был создан. Обычно вам нужно добавить @objc в один из ваших swift-классов и успешно собрать приложение, только тогда Xcode сгенерирует этот файл
- Если вы нашли файл "xxx-swift.h", убедитесь, что ваш оператор импорта содержит правильное имя.
-Swift.h должен создаваться Xcode автоматически, если код Swift предоставляет API через @objc или @objcMembers [Около]
Обычно локация выглядит как
~/Library/Developer/Xcode/DerivedData/
ProductModuleName-foo/
Build/
Intermediates.noindex/
ProductModuleName.build/
Debug-iphoneos/
ProductModuleName.build/
DerivedSources/
ProductModuleName-Swift.h
Это может быть изменено
Project editor -> select a target -> Build Settings -> Per-configuration Intermediate Build Files Path
По умолчанию значение равно $(PROJECT_TEMP_DIR)/$(CONFIGURATION)$(EFFECTIVE_PLATFORM_NAME)
У меня были проблемы с импортом Swift в проект Objective-C. В конце я заглянул в папку "Производные данные", чтобы проверить, что генерирует Xcode 7. Имя файла полностью отличалось от того, которое я ожидал.
Как только у меня появилось реальное имя файла, я импортировал его, и проект можно было построить.
Если в имени вашего приложения есть какой-либо специальный символ, используйте _ для специального символа.
Например, если ваше приложение называется "Test App®"
Затем вы можете импортировать быстрый файл с помощью "Test_App_-Swift.h".
Пробел и ® заменяются на _ во время импорта.
Убедитесь, что ваш быстрый класс имеет публичное объявление и расширяет NSObject:
public class MySwiftClass: NSObject {
//...
}
Импорт должен работать с кавычками, а не скобками, если класс swift находится в том же проекте.
Импорт файла заголовка, т.е.
#import "<ProjectName>-Swift.h"
в.h файле сгенерировал ошибку, заявив:
-Swift.h 'файл не найден
и сборка не удалась.
Вместо этого используйте:
#import "<ProjectName>-Swift.h"
в файле.m, и, несмотря на то, что появляется та же ошибка, запуск проекта в любом случае подавляет ошибку.
Затем классы swift доступны в файле.m.
ОПРЕДЕЛИТЬ МОДУЛИ: ДА и импортировать "ProjectName-Swift.h" в файл.m класса Obj-C
Это помогло мне получить доступ к классам Swift в Obj-c.
Если вы сначала добавите Swift File, не забудьте добавить быстрый файл к вашей цели... в левом столбце
Столкнулся с той же проблемой с моей командой, когда работал над проектом с использованием git. Один разработчик не обновил Xcode до последней версии (7.3), которая требовалась для последней версии Swift 2.2. Таким образом, компилятор не распознал новый синтаксис Swift и не смог сгенерировать интерфейс для библиотеки Swift (projectname-swift.h). Проверьте, последняя ли версия Xcode!
Я столкнулся с проблемой с названием проекта (target). В него включен символ "-". Поэтому решение было следующим: если имя проекта "Test-App", то имя импортируемого класса - "Test_App-Swift.h".
Я столкнулся с этой проблемой после дублирования существующей цели. Когда я попытался построить с дублированной целью, появляется ошибка « Файл ProductName-Swift.h не найден ».
После просмотра настроек сборки в новой цели я обнаружил, что значение параметра « Имя продукта » каким-то образом установлено таким же, как имя цели. После установки правильного, ошибка исчезла.
У меня была такая же проблема с #import "myProj-Swift.h" not found, Xcode 12.3, год 2021.
Похоже, что до тех пор, пока не был сгенерирован мостовой заголовок, невозможно импортировать myProj-Swift.h.
Мое (воспроизводимое) решение, когда нужно добавить Swift в проекты Objective-C, состоит в том, чтобы создать (Файл - Новый файл - Файл Swift) фиктивный пустой файл Swift в моем проекте. Затем Xcode спрашивает, создавать ли заголовок моста, на что я отвечаю да. В результате в мой проект будет добавлен файл «myProj-Bridging-Header.h», который отображается в навигаторе проекта.
Как только это будет сделано, ошибка #import "myProj-Swift.h" исчезнет.
После этого я могу удалить фиктивный файл и вставить в проект необходимые классы Swift.
Логика создания видимого связующего заголовка, но оставление -Swift.h полностью невидимым, полностью ускользает от меня. Не обращайте внимания на проблему попыток узнать об этом в официальной документации « Импорт Swift в Objective-C» , в которой (на мой взгляд, неточно) говорится: «Вам не нужно делать ничего особенного для создания сгенерированного заголовка».
Вероятно, неплохо было бы также принять во внимание ответ @Sandeep Bhandari на этот вопрос - кто говорит, что файл -Swift.h будет сгенерирован только в случае успешной компиляции проекта.
Если название вашего продукта TestApp-Dev, то имя файла будет TestApp_Dev-Swift.h.
Вы можете проверить это, перейдя по следующему адресу ~/Library/Developer/Xcode/DerivedData//Build/Intermediates.noindex/yourProjectbuild/Debug-iphonesimulator/MashreqMobileApp.build/DerivedSources.
Если вы хотите, чтобы у каждой схемы сборки было одинаковое имя файла, перейдите в «Настройки сборки», чтобы они были одинаковыми для всех ваших модулей/схем. (установите $(PROJECT_NAME)-Swift.h).
Если имя проекта — TestApp, то сгенерированный файл будет TestApp-Swift.h и останется одинаковым для всех схем.
Во время разработки может существовать вероятность того, что у вас будет какой-либо быстрый класс, который не полностью реализован, из-за чего могут возникнуть некоторые синтаксические ошибки. Заголовочный файл swift будет доступен для использования только в том случае, если все файлы swift не содержат ошибок.
Убедитесь, что в файлах swift нет синтаксических ошибок, а затем попытайтесь импортировать заголовок swift в файл target - c.
Xcode 11
Я столкнулся с этой проблемой при создании Xcode 11. Мне потребовалось немного времени, чтобы понять, что было не так, но по сути, я изменил параметр "Отображаемое имя" на вкладке "Общие" цели вместо изменения непосредственно в Info.plist файл через вкладку "Информация" в Target.
Это привело к тому, что Xcode 11.5 переписал / создал кучу совершенно новых пользовательских настроек сборки и изменил имя модуля приложения и созданного продукта.app. В этом случае новое отображаемое имя также имело косую черту (/) Характер, в ней, которые могут в конечном счете, именно поэтому он не строит (см Jignesh Mayani"s ответ).
Как бы то ни было, я решил эту проблему, отменив все автоматические изменения Xcode 11.5 в файле проекта и вручную внося такие же изменения в отображаемое имя пакета в Info.plist файл и все работает отлично.
Я бы хотел, чтобы он сказал вам, что он делал такие вещи, прежде чем он просто запустился и сделал это без вашего согласия.
Если у вас несколько целей, убедитесь, что вы собрали все фреймворки.
Целевой исполняемый файл не зависел от моей (или любой другой) инфраструктуры.
Фазы сборки -> Зависимости должны указывать зависимости цели, чтобы избежать периодических ошибок: в моем случае отладочная сборка прошла нормально, а автоматические сборки Jenkins CI терпели неудачу. Кошмар для отладки, учитывая, что вывод Jenkins производит объемный мусор, который требует огромного времени, чтобы пройти через него.