I'm working on an iOS project written in Swift, and I would like to take some classes out of the regular "app" project, and bundle it into a reusable Swift framework instead (and maybe make it publicly available on Github and via Cocoapods).
I'm running into issues because frameworks seemingly can't have Objective-C bridging headers, but in order to compile my framework code, I need to reference several Objective-C classes (in this case: the Google Maps iOS SDK).
I've also added GoogleMaps.framework as a linked library in my framework project, but then, how can I "import" it from Swift code?
Is this even possible with the current tools and Swift version, and how should I proceed?
Thanks.
It wasn't that complicated, actually... I was just doing some things wrong.
First, bridging headers are not required in that setting: the Google Maps iOS SDK is provided as a regular .framework file, so the development language has no impact on how it can be imported in Swift. Apple clearly mentions it in the documentation: https://developer.apple.com/library/ios/documentation/Swift/Conceptual/BuildingCocoaApps/MixandMatch.html, "Importing external frameworks".
It's as easy as adding the framework to the "Link binary with libraries" section of the project settings. Do not forget to also add depending libraries and frameworks (in GoogleMaps.framework's case, there are quite a few).
Then, in Swift code, the framework classes should be available simply by doing:
import GoogleMaps
No bridging header, no dealing with "non-modular header etc." errors.
Related
I'm about to create a cocoaPod for a small iOS Framework for our customer. I have 2 questions about it.
1) I'm depending on another framework that is also available via cocoaPod. Could it happen that the original author removes the lib and therefor could kill my framework as well or is this secured?
2) I'm using Swift as the language of choice? Let's say one is importing an Obj-C Pod into a Swift project, he needs a bridging header. With the other way around, using a swift cocoapod with obj-c, does the user need to do anything to make this run?
Thanks
Yes, and hopefully the dependent framework doesn't remove his framework (its very rare they do it)
The bridging header is fine unless you use advanced generics (inheritance of a base generic class) as methods might not be available while converting to Objective-C.
Our company wants to distribute a closed-source SDK for iOS to our clients. I've been using Cocoapods to build the framework and built an example app making use of it. Previously the app worked fine on the simulator as well as when deployed on the device. However, I was also embedding the Pods.framework file in the app itself. One other piece of information that may be of interest is that the framework is written in Swift, the included cocoapods dependencies are both Swift and Objective-C.
I wanted to make the pods requirements easier to manage so the user doesn't need to be concerned with them and tried to embed the Pods.framework file inside of the SDK we're building - so I removed the steps to Embed Pods Frameworks and Copy Pods Resources from the example app, leaving them only in the framework, I also removed Pods.framework as a dependency of the example app, leaving it only in the SDK. This seemed to work in the simulator, but the app now crashes on mobile device with dyld: Library not loaded error.
Upon researching it, I stumbled into a few related discussions:
https://github.com/CocoaPods/CocoaPods/issues/344 https://objectpartners.com/2014/06/25/developing-private-in-house-libraries-with-cocoapods/
However, the suggested solution of using private pods does not look like it would work for us, it's my understanding that the source code in the private pod would still be open, and we can't share it with our clients.
Could someone advise on a solution that would work in this case?
OK, I finally have a more durable solution. It's a modified, cleaner version of my old one now that I understand how Xcode links in my Swift sub-frameworks better
Problem that makes distribution/compilation a bit ugly:
Since Swift standard libraries aren't bundled on the device like Obj-C, nor are they guaranteed to be stable between versions yet (stable binary interface promised in Swift 3: https://github.com/apple/swift-evolution#development-major-version--swift-30) we have to make sure the entire project is compiled against the same version of Swift. That means the guy using your closed-source framework has to be using the same version of Swift in their Xcode for their project as you did for compiling the library, even if he's not using Swift in his code because ultimately it's his version of Swift that gets bundled into the app and your SDK runs against. This is only an issue for closed-source frameworks because open-source ones will always be compiled against the same version as final project. Possible workaround is to restrict clients to same version you use or distribute multiple compilations (i.e. Swift 2.1 and Swift 2.0). To remedy this, you could provide users with copies of binaries compiled against multiple versions of Swift.
Aside from that, here is what I had to do during compilation/distribution to make a binary framework that works in Swift:
When building the framework:
In project target, make sure to add Pods.framework to Linked Frameworks and Libraries (make sure this is a pre-compiled RED version of Pods.framework, I had a black compiled Pods.framework in the same directory which built fine but then resulted in a framework that would cause the project to complain about missing armv7 architecture during linker phase in later project)
In Build Settings, under User-Defined section, add a field called BITCODE_GENERATION_MODE and set it to bitcode
DO NOT #import any frameworks in your bridging header, all instructions telling you to do that are leftover from Swift 1.0-1.2 days, you don't need it anymore and it does more harm than good (the later project will complain that it can't find these headers that aren't even exposed to it)
Change build target to Generic iOS Device, Archive and Export the framework
When building the project using the framework:
Drag and drop the framework into the project, in General tab add it to Embedded Binaries and Linked Frameworks and Libraries (you only need to add the framework itself, not the sub-frameworks or the pods file)
In Build Settings tab, add a new path to Framework Search Paths: $(PROJECT_DIR)/MyFramework.framework/Frameworks
Build the project
I have a an Xcode project which produces a static library. My team plans all new development in Swift. It is not possible to add Swift files to the static library project. We are dropping support for iOS 7, so it is now possible to include frameworks in our iOS app. Therefore, I intend to convert my static library project to a framework project.
I have looked but I cannot find any tools or advice for how to perform this conversion. The static library is large (more than 100 .m files).
I'm hoping for a better answer than create a new parallel framework target. I've attempted this twice. The first time as a swift target, but I wasn't able to easily import all the Objective C files. Next, as an Objective C target, but there is no .pch anymore.
To convert the static/dynamic linked framework from static linked library,
Add a new cocoa touch framework as a TARGET in your existing static linked library project.
In the Build Phases, adding all the .m, .mm, .c, .cpp, .metal, etc. into "\Build Phases\Compile Sources" phase of your static linked framework target.
Put the headers that you want to exposed in to "\Build Phases\Headers".
For dynamic linked framework, remember to check the Mach-O Type setting in your Build Settings. If you are going to use swift, you need to make sure the Mach-O type is set as dynamic library so that it will become a dynamic linked framework. For static linked framework, you'll need to set the Mach-O type as static library, but you cannot use swift in the converted static linked framework (only objective-c, objective-c++, C++, C, etc. are allowed).
Then for the app that wants to use this framework just need to include the headers as #import and add the framework into "Build Phases\Link Binary With Libraries" of your App Target. If the converted framework is dynamic linked framework, you will need to put it into "Embedded Binaries".
I saw that someone created the framework manually, creating a module.framework file and copying all the header files in a module.framework/Headers folder. This solution seems to work, the project can import correctly the files and see them as a framework correctly.
I'm not sure this is the best way to do it tough, I'm trying it on a big project that ATM is importing the static library through cocoapods, but it seems like I have some problem with the visibility of some of the classes using the framework.
I must have started from scratch about 4 times already. I've followed the solutions listed below but I still have an issue (which I think has something to do with the bridging header file).
Note: I have tried manually creating the bridging header as well as the automated solution Xcode offers when you drag some Objective-C files into a Swift project.
Swift Bridging Header import issue
Connect Objective C framework to Swift iOS 8 app (Parse framework)
Here are the main errors I am seeing. I've tried moving the header file up a level/down a level and it still claims to not see it. Everything is currently where Xcode put it when I selected "Yes" when prompted to created the bridging header automatically. You can also see the full contents of my bridging header.
The "Cannot find protocol declaration for NSObject" error usually refers to circular references problems.
I'm wondering why you put all those standard Apple frameworks in the bridging header? This might be the problem. This special file is supposed to "bridge" Swift and Objective C worlds together, so if you've already referenced and linked your app against those frameworks in your Swift code, you shouldn't need to do it again in the bridging header.
Try to remove all Apple-provided frameworks from your bridging header and only leave the specific ones (IBM....h), and see if it works?
If it doesn't, then start with Foundation/Foundation.h only...
How do I import 3rd part frameworks into Xcode Playground?
Swift Playground obviously has a framework import mechanism because we can import Cocoa, SpriteKit, and in an OSX Playground, XCPlayground (XCPlayground seems missing from iOS, oddly)
What I'd really like to do is hide code from my playground and be able to show a minimal example. Any thoughts on how to load a Framework into Swift playground?
See also:
How to import own classes from your own project into a Playground
Is it possible to import third-party Objective-C code into a Swift playground?
(This question is different because the request is to use a framework in Playground rather than simply regular swift files)
There is currently no supported way to import your own framework or app code into a playground, short of pasting it into the playground editor. We're aware that this is very desirable functionality, but as always we encourage people to "vote with bugreporter" at bugreport.apple.com
Right now, if you're just trying to hide code for showing in an example, code folding in the editor might do the trick.
It is now possible to import your own frameworks into a playground. This provides a way to share code between your applications and playgrounds, which can both import your frameworks. To do this, your playground must be in the same workspace as the project that produces your framework. You must have already built your framework. If it is an iOS framework, it must be built for a 64-bit run destination (e.g. iPhone 5s). You must have an active scheme which builds at least one target (that target's build location will be used in the framework search path for the playground). Your "Build Location" preference (in advanced "Locations" settings) should not be set to "Legacy". If your framework is not a Swift framework the "Defines Module" build setting must be set to "Yes". Once all these conditions are fulfilled, importing your framework will work in a playground.
Edited: As of Beta5 this is now supported when the playground is part of the workspace that builds the framework as a target. There are more details on the Apple dev forums site, but hopefully #Rick Ballard will add them to his answer here and that should becoke the definitive answer for this question.
Don't do the below anymore!
For the short term, while there's no supported solution, if you're producing a Module/Framework you can copy it into the SDKs System/Library/Frameworks directory and then just import <#Module#> the same way as you import system Frameworks.
For an OS X Playground: /Applications/Xcode6-Beta.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/System/Library/Frameworks
And for iOS: /Applications/Xcode6-Beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator8.0.sdk/System/Library/Frameworks/
But before you do that... go file a radar as #Rick says in his answer.
I've written a tutorial covering import of custom frameworks in Beta 6
In short, if you've got your playground and framework either in the same project or workspace, and your framework is built for 64 bits (even for iOS), they play very well together.
source: http://qiita.com/ryokosuge/items/2551cd4faa9dca324342
If there is anyone who still had difficulty understanding how to go about it after reading the accepted answer, this may help.
It's not in English though so I will explain here:
Using Carthage:
1: Setup your Cartfile in the root of the project, add your libraries and run:
carthage update --platform iOS --use-submodules
2: Make sure your project is saved as a Workspace. From the Xcode menu bar: File > Save As Workspace. Shutdown Xcode and reopen from the new .xcworkspace file.
3: Add your library's .xcodeproj file in your workspace: File > Add files to "your_workspace_name". Then find it in: ${SRCROOT}/Carthage/Checkouts/your_library_name/your_library_name.xcodeproj
4: Find the Embedded Binaries and Linked Frameworks and Libraries section in your project's general settings. Add your library's .framework file to both.
5: Clean(⇧+⌘+K) and build(⌘+B).
6: Import your library in the playground.
I solved it by copying the built frameworks to the Built Products Directory, where Playgrounds in the workspace also searches for frameworks. Note: you also need to run lipo and strip away unused architectures from the FAT binaries.
The steps needed (in a nutshell):
Create an aggregate target
Add a script phase to copy the frameworks
from Carthage/Build/iOS/ to BUILT_PRODUCTS_DIR (I use a swift script
in the example below, but you can use also use bash, ruby python
etc.)
Run aggregate target Now you can import the framework(s) in a
Playground
Additionally you can leverage the aggregate target in your app:
Embed frameworks from BUILT_PRODUCTS_DIR, not Carthage/Build/iOS/
Add aggregate target to app scheme to re-establish frameworks after a clean.
Here is an example project setup as above: https://github.com/richardnees/CarthagePlaygrounds
Like using Objective-C classes in Swift code, you can import 3rd-party library/classes into your project and Xcode will ask you if you wanna create a <#YourProjectName>-Bridging-Header header file. Choose yes and import all header files you need in that file. After that, in your playground, you can simply do import <#YourProjectName>-Bridging-Header after import UIKit and you will be able to use the classes you imported to your project.
Update: this is actually incorrect. Please see my comment below. Sorry for any confusion...