To provide cross compatibility, Swift allows for the generation of a bridging header so that Objective-C can communicate with Swift classes.
Due to Swift's wonderful namespacing we no longer need to worry about prefixing our Swift files as they are namespaced by their containing framework. A UIView for instance is implicitly namespaces as UIKit.UIView.
Now that Apple are pushing frameworks, I was wondering what the best practices are to avoid header collision when there exists two swift bridging headers with the same symbols.
An example: Say we have two frameworks that have declared a Swift class called Downloader. The Downloader provides the interface: downloadWithURL(url: NSURL)
Generating a bridging header will yield a Downloader-Swift.h file for both of these frameworks. Thus causing a collision. What are the best practices to avoid this?
According to Apple's engineers the <#Module Name#>-Swift.h header uses a macro that mangles the name so as to avoid conflicts (see WWDC video Swift Interoperability In Depth, beginning at 45 min, 40 sec). They gave an example of a Document Swift class:
SWIFT_CLASS("_TtC5MyApp10Document")
#interface Document : UIDocument
// rest of the interface...
To your Swift code, the class will be available as MyApp.Document, if MyApp is the module it is in. So, if you have two Swift classes of the same name coming from different modules – say, one is your own and the other from an open source Swift framework SomeFramework – they will be available to your Swift code as MyApp.Document and SomeFramework.Document...
On the Obj-C side, however, importing these two classes into the same lexical scope leads to Duplicate interface definition for class 'Document' compiler error. That's just Obj-C... In the vast majority of cases, though, this will not be an issue since you can still import these two classes across the app as long as they do not trespass each other's territory. Indeed, how often would you want to use MyApp.Document and SomeFramework.Document in the same module of your app? As we are moving into swifter times, I'm not sure this particular issue warrants a particular strategy, compared to so many urgent issues, such as, multicore, distributed, functional, haptic, anticipative, wearable, autonomous, etc...
Related
I want to import a Swift framework called "Beethoven" into Objective-C project. I import this framework via cocoapods.
The problem is that framework is written in pure swift. Since the classes are not subclass of NSObject they can't be used directly in my objC classes.
I am newbie in Swift and intermediate in objC, but I think there may be 2 solutions for that:
1-Modifying the whole library: which is probably not an optimal solution.
2-Using a new class which behaves as an interface between swift framework and my objC code. I think second solution will be a better alternative in terms of time and effort needed.
Actually below given post explains modifying the pure swift classes but I don't know how to apply this in my case.
How to use Swift non-NSObject subclass in Objective-C
As I mentioned I am not a very capable programmer and there may be better solutions for that problem. I would be grateful if someone can help me and suggest the best solution for integrating pure Swift framework into my objC project.
NSObject is usually not the only problem. Swift has many features that are not supported by Objective-C. To name a few: swift value types (struct's), swift enums with attached values. If a library uses any of those, it will not be possible to auto-generate an Objective-C header (.h) for it.
Adapting the code of the library on the spot might work, but it is likely more work long term in case if you ever need to update that library again.
Your 2nd approach sounds better: create a layer that is compatible with Objective-C on top of the library which exports methods that need to be exported with #objc and adapts the types. If you go that way consider making a PR contribution to the original library so that everyone could use it in Objective-C projects, and you share responsibility of updating it when the swift code changes.
The 3rd approach would be actually to rewrite some parts of you app to Swift. That might or might not be easier depending on the size of the part of the app that is using the library and how well it is isolated from the rest of the app.
I am building a new framework. The project is to be coded into Swift language, however the clients using this framework have the freedom of using either swift or Objective-C framework.
The question is how do I start. There could be numerous issues like
using structs in swift code but it cannot be made available in
objective C framework.
optionals are missing objective c
Even if I
write different set of files for Swift and Objective C, how will I
map them onto different frameworks under the same project.
Enums with other than Int as rawValue can't be used.
Tuples would not work
I know there have been a few questions around this but none have any satisfactory answer.
PS - Any link to a tutorial or blog would be super helpful too
I did this and got some unexpected results: I have trouble integrating the framework in Swift application. Objective-C works just fine.
You mentioned some of the caveats here.
I suggest doing this iteratively while writing test application in Objective-C which uses all the features. This way if there is some feature that does not cross Swift to Objective-C boundary well, it will be discovered as early as possible.
Your remarks about issues are generally correct with one small exception: optionals are not missing from Objective-C, they appear as nullable/nonnull modifiers on variables and method parameters. Although this does not replace optionals fully, it helps detecting issues early in the process.
Here is a random list of some other issues I discovered:
Bridging between Swift Error and NSError used in Objective-C. The conversion is not always as smooth at it could be, so better use NSError in exported code.
If you mix Objective-C and Swift in your framework, you cannot use bridging header, instead using modulemap files which tend to turn pretty large and complex.
Since you cannot embed frameworks inside a framework, you have to make sure that the application sets ALWAYS_EMBED_SWIFT_STANDARD_LIBRARIES flag for its target. This has to be clearly indicated in the documentation. Also, when creating fat library for your framework, you have to strip these files from the distributed SDK.
And, as I said in the beginning, I still have no success using the resulting mixed language framework in Swift application.
Hope, this will add to your list of things to take into account when developing the library.
I have been using xcode's jump bar feature. It is very convenient to use but occasionally I encounter symbols in the jump bar that I do not know what it represents.
For example, I want to know what the middle symbol (i.e. the symbol before Collection actually represents), where could I find relevant information on a list of symbols used and what they actually means?
Even I used to wonder what these icons meant so I just went through a lot of official Swift frameworks and classes - hope this helps,
M - module, shown for Frameworks like UIKit, UserNotifications, CoreLocation
Header Files mostly but this comes up for Swift classes too
Class & Interface (Obj-C)
Structs
Enums
Extensions
Methods & Functions
Variables, Properties & Constants
Overloaded methods, sometimes normal methods too
Protocols
Pragma marks
Macros
TypeDef
Union
Frameworks
Libraries
Plist files
Storyboard
Entitlements
Folders or groups
Flat files
Header files
Implementation files
Swift files
Asset catalogs
P.S: Used Xcode 8.1, will update more if I come across anything new.
You will encounter these types of symbols in the jump bar when you jump in for iOS native types like String,Int,firstIndex etc.
In the above example collections are used for data storage. Swift provides three primary collection types, known as arrays, sets, and dictionaries, for storing collections of values. Here in the example above you have jumped in for countable range which comes under collections in swift module.
Can we create iOS app with swift and obj c both.My half app is made using OBJ-C and just want to improve apps performance so is that possible to use swift in between
Yes you can.
You have to add objc header #imports in the <module name>-Bridging-Header.h that you want to make available in swift, and you can use swift code from objc by importing the <module name>-Swift.h file in your objc code.
Note that the latter header file is automatically generated when building, and it is not visible in the project navigator - but you can open it by cmd+click-ing its name in an existing #import. Also to note that if compilation fails, most likely the file will not be generated.
Last, I highly recommend that you avoid circular references between objc and swift - for instance, creating a SwiftClass, inherited from BaseObjcClass, and using SwiftClass from objc - I've experienced that it doesn't work (compilation errors), and I am not aware of any workaround
Yes, you can. You just need to follow this:
https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html
Apple’s intention to replace the Objective-C language using Swift, it is not practical in the short term simply due to the fact that developers are deeply entrenched in Objective-C. Rather than force Swift down the developer’s throat, Apple has made it easy to allow Objective-C to interoperate with Swift.
http://mobiforge.com/design-development/using-objective-c-and-swift-together-ios-apps
Dec 2018 - I found this useful YouTube video that helps explain what files you need to add and how to make the connections.
YouTube - How to use Swift and Objective-C in the same project
Background
I'm new to iOS development and playing with Swift for the sake of learning. As a small challenge, I'm trying to get the SSID of network to which a device is currently connected.
This is well-covered ground on Stack using Objective-C: iPhone get SSID without private library, for example ... but the Objective-C / Swift dance is causing me some conceptual challenges.
Specifically, the suggested solution (discussed in the above-linked post) is to call the function CNCopyCurrentNetworkInfo() -- but, according to Apple's documentation, this function is not available in Swift.
So far
I've included (I think correctly) SystemConfiguration.framework by adding it to the Linked Frameworks and Libraries of the project. I've also brought it into the View Controller using import SystemConfiguration.
Questions
Do I need to also use import SystemConfiguration, or is that already done due to including the framework with my project?
Is there another / better way to include the SystemConfiguration library?
The big one: How, once the required library is imported, do you call the Objective-C function from the library?
Thank you!
I know this is not directly answering your question, but it's an answer to your problem.
You can do everything in swift in your case.
After importing the library,
import SystemConfiguration.CaptiveNetwork
You can immediately call:
CNCopySupportedInterfaces()
and it will work.
Confirmed in Xcode 6.3.2.
Apple's interoperability book (from Understanding the Swift Import Process):
Any Objective-C framework (or C library) that’s accessible as a module
can be imported directly into Swift. This includes all of the
Objective-C system frameworks—such as Foundation, UIKit, and
SpriteKit—as well as common C libraries supplied with the system.
Regarding your specific questions:
The opposite is the case: you do not need to manually include Apple's frameworks. Xcode will automatically make them available to you given a valid import statement (such as import SystemConfiguration in your case), even – or rather: especially – in a playground!
ditto...
Given the above import statement, SystemConfiguration is indeed imported since you can call its functions (e.g. SCCopyLastError() // --> __NSCFError) and access its constants (e.g. kCFErrorDomainSystemConfiguration // --> com.apple.SystemConfiguration). Unfortunately, CaptiveNetwork does not seem to be imported with it (e.g. CNCopySupportedInterfaces() // --> Use of unresolved identifier).
You should be able, however, to use this framework on the Objective C side and simply call your own wrapper functions from Swift. You just need to remember to include them among the imports listed in your bridging header (see Swift and Objective-C in the Same Project for more about bridging headers).