So I'm not to up on Objective-C so I apologize if this is a basic question but I can't seem to find someone with my exact problem.
I added the JBChartView(written in Objective-C) Cocoapod to a Swift project. The chart is good to go and fully up and running. However I then added some other separate Objective-C files and when trying to import a file from JBChartView it can't be found. What gives, I can access this Objective-C library from Swift files but not Objective-C files. Any ideas?
Below is everything I have tried.
#import "JBChartView.h"
#import <JBChartView/JBChartView.h>
You don't really give us much to go on here, but if you're able to import the framework successfully using Swift, then the framework is probably defining a module. In this case, you can just take the import statement you're using in Swift, add a # to the beginning of it and ; to the end of it and you've got a module import for Objective-C. So, if the import in Swift looks like:
import JBChartView
then you can do this in Objective-C:
#import JBChartView;
The mechanism is the same in both cases, so if one works, the other should too.
I'm trying to use the SwiftyChrono swift library from an Objective-C project. Since it's using a struct instead of a class (amongst many other Swift only features), I'm unable to make it work.
Given I am not in the position of moving all our Objective-C code to Swift, what are my options? Would writing a second Swift framework work, one that sits in between our app and SwiftyChrono and serves as a wrapper? Would that even work? I'm guessing if this new Swift framework was dumb enough to only perform a single function in 'Swift Land', it would play well with Objective-C?
I haven't dealt with inter-op and it really feels like a losing battle. Any help would be appreciated.
I am using Cocoapods. I'm creating a Pod.
Most of the classes are written in Swift.
I would like to write a class in Objective-C using one of the Swift class.
I don't know how to import the "corresponding header". In a usual project, I would have used the "NameProject-Swift.h" file, but within a Pod, I don't know how to do.
How can I do?
What is the use of bridging header?
Is it just for using Objective-C and Swift code in the same project?
Should we avoid using bridging header?
Say, if there are two third party library which are very similar; one of them is in Objective-C and other is in Swift. Should we use the Swift library or use Objective-C library. Are there any downside of using bridging headers?
Apple has written a great book that covers this in depth. It can be found here:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html
I will quote it to answer your questions:
"What is the use of bridging header?
Is it just for using Objective-C and Swift code in the same project?"
To import a set of Objective-C files in the same app target as your Swift code, you rely on an Objective-C bridging header to expose those files to Swift. Xcode offers to create this header file when you add a Swift file to an existing Objective-C app, or an Objective-C file to an existing Swift app.
The answer to this question is yes. It is just there to make Swift and Objective-C work together in the same project.
"Should we avoid using bridging header? Say, if there are two third party library which are very similar; one of them is in Objective-C and other is in Swift. Should we use the Swift library or use Objective-C library. Are there any downside of using bridging headers?"
There are always tradeoffs. The first answer to this is no you should not avoid using a bridging header; however, as far as third party libraries you have to look at many factors. Which one has more functionality? Is it being maintained and/or added to frequently?
Using an Objective-C library will also add things to be aware of and work around. From the book:
Troubleshooting Tips and Reminders
Treat your Swift and Objective-C files as the same collection of code, and watch out for naming collisions.
If you’re working with frameworks, make sure the Defines Module (DEFINES_MODULE) build setting under Packaging is set to “Yes".
If you’re working with the Objective-C bridging header, make sure the Objective-C Bridging Header (SWIFT_OBJC_BRIDGING_HEADER) build setting under Swift Compiler - Code Generation is set to a path to the bridging header file relative to your project (for example, “MyApp/MyApp-Bridging-Header.h").
Xcode uses your product module name (PRODUCT_MODULE_NAME)—not your target name (TARGET_NAME)—when naming the Objective-C bridging header and the generated header for your Swift code. For information on product module naming, see Naming Your Product Module.
To be accessible and usable in Objective-C, a Swift class must be a descendant of an Objective-C class or it must be marked #objc.
When you bring Swift code into Objective-C, remember that Objective-C won’t be able to translate certain features that are specific to Swift. For a list, see Using Swift from Objective-C.
If you use your own Objective-C types in your Swift code, make sure to import the Objective-C headers for those types before importing the Swift generated header into the Objective-C .m file you want to use your Swift code from.
Swift declarations marked with the private modifier do not appear in the generated header. Private declarations are not exposed to Objective-C unless they are explicitly marked with #IBAction, #IBOutlet, or #objc as well.
For app targets, declarations marked with the internal modifier appear in the generated header if the app target has an Objective-C bridging header.
For framework targets, only declarations with the public modifier appear in the generated header. You can still use Swift methods and properties that are marked with the internal modifier from within the Objective-C part of your framework, as long they are declared within a class that inherits from an Objective-C class. For more information on access-level modifiers, see Access Control in The Swift Programming Language (Swift 2.2).
Que : What is the use of bridging header?
Its correct to say, Bridging header allows user to use Objective-C classes/files in their swift code in same project.
A Swift bridging header allows you to communicate with your old Objective-C classes from your Swift classes. You will need one if you plan to keep portions of your codebase in Objective-C. It should be noted that even if you decide to convert all of your code to Swift, some classes or libraries you may use such as SVProgressHUD haven’t been rewritten in Swift and you will need to use a bridging header to use them.
Que : Should we avoid using bridging header?
Considering your question there are 2 possible cases.
case 1 : Lets say your project is developed in Objective-C and now you are developing new features using swift in it, in this case you have to have BridgingHeader as you need access of your Objective-C classes in swift code.
case 2 : If your project is developed in swift then there is no need to have Bridging header, as well if its in only Objective-C and you are not planning to move it in swift then also you don't need it.
Read more about Using swift with cocoa and Objective-C in apple documentation.
Following apple document image indicates usage of Bridging header
No, there are no downsides to using Obj-c code in your Swift project. Bridging header only exposes your Obj-c files to Swift. The two languages can coexist in the same project with no problems, as you can expose your Swift code to the Obj-c just as easily too - xCode will generate a header for all of your public Swift declarations. Although everything is possible, if you start a new project you should stick to one language so the project is easier to understand. For example if you decide on Swift you should only use Obj-c for libraries that are not available in Swift.
The bridging header allows the use of Swift and Objective-C in the same project. There are no downsides to having a bridging header in your project as the two languages can work well together within the same app.
Removing a bridging header from a project after it has been added may cause errors, as it is referenced in other places in the project when it is created.
If you only intend to use one of the two languages, a bridging header is unnecessary. On the other hand, if you are using both Swift and Objective-C, a bridging header is required and will not cause any issues.
Here is a link to find more information on the subject:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html
I hope that answered your question. Good luck with your project!
What is the use of bridging header?
You have already got that answer. You're right.
Should we avoid using bridging header?
No. Its good when a third party library developed in Obj-C and may not available in Swift yet. You should use bridging header to have a best library for your app.
It depends which on you choose. In case of networking? If your project is in Obj-C based you can use AFNetworking or with the case of Swift you can use AlamoFire, you can still use AFNetworking in Swift but its not suggestable.
Bridging headers are a great way to get Objective - C code into your Swift project. If you have two libraries, one that is in Swift and one that is in Objective - C, choose the one that will offer more functionality in your app. If they offer the same functionality, I'd just go with the Swift library -> My reasoning: if the Objective-C library isn't widely used and there aren't many tutorials on how to convert the Objective - C code into Swift, it can be very time consuming to figure it out on your own. If you use a Swift library, the code is already formatted in the correct language, saving you time and potentially money (depending on if this is a hobby for you or not). As far as any downsides to using a bridging header, their really isn't! With so many libraries written in Objective-C, you almost need a bridging header in your app. Take, for example, Reachability (Here is a video on implementation in Swift). This is a library that Apple created to handle network interruptions in your app. This is a great tool for developers and requires a bridging header. Here is a great YouTube video on how to use a bridging header, but if you add a header file into your Swift file, Xcode typically asks to crete one for you. Hope this helps!
I want to create an Objective C class at runtime from a file. So for example I have an objective c application, I want to then point it at a text file (or an .h .m pair, whatever works) and then have the application parse the text file and create the class at runtime (Class no object). Of course I would write the parser and all of that stuff I just want to know if its possible. I read these two articles:
http://www.mikeash.com/pyblog/friday-qa-2010-11-6-creating-classes-at-runtime-in-objective-c.html
http://www.mikeash.com/pyblog/friday-qa-2010-11-19-creating-classes-at-runtime-for-fun-and-profit.html
Which shows how to make an objective C class at runtime, but its being done using C functions which were defined at compile time. If I can find a way to do the same thing using strings to define the functions that would be perfect, because then I don't have to define them at compile time.
That's what called reflective programming. I guess there's no code evaluation support for Obj-C since it's not a scripting language, so the reflection concept for Obj-C is quietly limited. Plus, at run-time the compiler already translate the code into Obj-C clang code and it's a very time-consuming job just to reverse-translate the bytecode and recompile it again
For Obj-C reflection you can refer to these answers
Build a class :
Create objective-c class instance by name?
Implement a method :
Objective-C, how can i hook up a method in another class
Change class for an object :
Objective-C: How to change the class of an object at runtime?
Sure. Totally possible.
I would suggest starting with the Objective-C support in this as it includes a full-on Objective-C parser and code generator.
see my github project cocoa-interprreter it does part of what you want.
it takes a text file and compiles it at runtime .. and then runs the resulting executable using NSTask. It would be quite easy to change it so the binary is loaded into the own process using NSBundle
https://github.com/Daij-Djan/cocoa-interpreter