This style of import is a modular import.Īny header imported into the umbrella header can now be seen by Swift files belonging to your framework target. The umbrella header imports the headers you want to be made public like this: #import. Where app targets use a bridging header to talk to Objective-C code, frameworks rely on the umbrella header – LanguageKit.h in our case. Your Swift files that belong to the your framework target implicitly import the target. Usually you won't have a custom name, but that build setting is what you'd use if you want to. It also needs to then define a module name (the PRODUCT_MODULE_NAME build setting). The framework target needs to be configured to build as a module (using the DEFINES_MODULE build setting). So how are you supposed to get your mixed-language framework target working anyhow? Fear not, you've come to the right place.įor this example let's say we have a language learning app called BiLingual, and it has a framework target called LanguageKit. A bridging header here, some declarations there, and you're probably good to go.īut the rules change a little bit when you want to start breaking your code up into frameworks and suddenly there's no bridging header. If you've worked on an iOS app that has both Swift and Objective-C code you're likely well familiar with the rules for getting the two languages to talk to each other. Mixing Swift and Objective-C in a Framework
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |