I am getting compile error when I added a framework into my app. Framework Feature1 is built successfully but from module App import is not working.
How to solve this issue?
There are several potential misconfigurations the issue can arise for,
Please confirm that you have opened the .xcworkspace but not .xcodeproj file. Also make sure you have build Feature1 first before you build App.
Make sure that iOS Deployment Target is set same for all modules with App. For example is Apps deployment target is set to 9.0, Feature1s deployment target also need to be set to 9.0.
Make sure your main module (App) and your used framework (Feature1) have same set of configurations. i.e. If your Project has three configurations, Debug, Release, ReleasePremium than your Framework also need to have three configurations Debug, Release, ReleasePremium. Also make sure that the archive configuration is set same for both App and Feature1. i.e. if your Apps archive scheme is set to ReleasePremium, your Fearure1s archive scheme also need to be set into ReleasePremium.
Please assure that you do not need to import Feature1 in each .swift files when its already added in the Bridging-Header.h.
In case of issue came from Pod files, make sure you have uncommented #use_frameworks! into use_frameworks! from you Podfile. Sometime re installing pod works if Feature1 has any dependency on pods.
If none of the above steps works, delete your derived data folder and try re building.
Related
I've bee really struggling with this bug the past few days.
So I have a workspace we can call XYZWorkspace.
Then I have an app project in this workspace called XYZ.
Then I have a Cocoa Touch Framework in this workspace called XYZCore (which contains reusable non-UI files)
Lastly, I have Cocoapods set to install Alamofire on the XYZCore framework.
I have XYZCore listed as an Embedded Framework of the XYZ app project target.
Here is my issue, when I build the XYZCore framework, Alamofire gets imported properly. However, when I build the XYZ app target, I get the error "No such module 'Alamofire'" in the XYZCore.
I know that Pods is set up properly on the XYZCore framework because when I build that scheme, everything succeeds. I think I don't have something set up correctly from connecting XYZCore to XYZ app.
Other information: I have custom configuration files set up for the XYZ app project that import the Pods configuration files.
Some checklist steps I've performed:
Made sure building from the workspace
Marked the Schemes for both the framework and app target as Shared
Deleted Derived Data and Cleaned build folder
I've even gone as far as restart the project completely to make sure I didn't miss a step, however something is still connected correctly. I've done this setup on other projects without any issues, could someone help me?
this usually happens when your frameworks are not set-up correctly on the target's Build Phases settings page.
Have you checked that under Target/Build Phases/Embed-Frameworks // Link-Binary-With-Libraries everything is added correctly? If so can you provide with screenshots of those screens, also maybe try running 'pod install' again on your root folder, it has worked for me several times.
I am creating a new app MyApp, where I decided to put some parts of the app in a seperate framework MyFramework, instead of the app itself to make them reusable in other projects. The framework has its own project (MyFramework.xcodeproj) which is a subproject of the main app project (MyApp.xcodeproj). The main app project has a dependency (does linking & copying) on the framework (MyFramework.framework), of course. This part works fine so far.
Now, MyFramework needs a cocoa pod (Alamofire) in order to work. As far as I understood, I don't want to set up cocoa pods for the MyFramework.xcodeproj project directly, so I just set it up for the main app MyApp.xcodeproj (now MyApp.xcworkspace because of pods) and also included the Alamofire pod there. I then linked MyFramework.xcodeproj against the Alamofire.framework (not the MyApp_Pods.framework), but did not set Alamofire for copying. The MyApp.xcodeproj does the usual cocoapods linking/copying/bundling stuff, so also includes the Alamofire.framework in the final product. This worked partially fine.
(Note: I say 'partially fine' here because I occasionally had errors in the MyFramework sources not finding the Alamofire module when compiling, which could be fixed by re-linking the Alamofire.framework in the MyFramework.xcodeproj. Besides that, building and running the app works fine.)
The issue is now, when I try to archive the app, the Alamofire module is again not found in the MyFramework sources. The error occurs both, when archiving the MyApp (which also builds MyFramework), as well as archiving MyFramework directly. The error occurs not in the linking phase, but in the compile phase of a source Swift file that has an import Alamofire statement.
I suspect something like the linking of the Alamofire.framework to use a wrong relative path that can be found while building, but is different on archiving or such. I already tried to set the Alamofire.framework path to Relative to build products, but couldn't get this to work, not even for regular building (not archiving).
I'm now stuck and wondering whether my whole setup with linking from the MyFramework.xcodeproj project to the Alamofire.framework and having Alamofire included as a pod is correct.
Can anybody give me a hint what might be wrong here? Either in the paths or in the whole setup?
This won't tackle the problem itself, but would provide a solution that serves your need:
Transform MyFramework into a pod. Host it in your private spec repo, or — even simpler — use the git parameter in the pod file to access it.
pod 'MyFramework', :git => 'https://gitsever/maxscompany/MyFramework.git'
I am using the latest beta cocoapods release that support frameworks with xcode 6.1.1, sudo gem install cocoapods --prerelease
I then ran pod lib create podtry to create a sample app, no demo app, no testing framework, no view based testing. I then opened it in xcode and notice that it created 3 schemes, pods-podtry, pods-podtry-podtry-podtry, podtry-Example and 2 Pods targets, Pods-podtry, Pods-podtry-podtry-podtry. Can someone explain why there are 2 targets and 3 schemes? It seems like ony Pods-podtry-podtry-podtry target contains the plist.info version specified in podspec s.version field.
Ok I think I figured this out, hopefully this will help someone new to cocoapods. There are 2 targets and each of the scheme has one of the 2 targets. For example, podtry-Example scheme has Pods-podtry target plus testaction has podtry test added. Pods-podtry-podtry-podtry scheme has Pods-podtry-podtry-podtry target but no test action. Pods-podtry scheme has Pods-podtry target, no test action but has a target dependency on Pods-podtry-podtry-podtry. Phew that's a mouthful but there it is.
There are a couple of things I still don't quite get though
Why did cocoapods create Pods-podtry target that builds a Pods_podtry.framework in addition to podtry.framework. Ultimately I am only interested in podtry.framework and I am not sure about the purpose of Pods_podtry.framework.
Why did cocoapods not create a test target like xcode normally does for a new project, instead it make that a test action target dependency.
Any insights will be much appreciated.
Whenever I try to use a build configuration named other than 'Debug' or 'Release', Xcode suddenly cannot find my Swift frameworks. The configurations are the exact same other than their name (in fact, the new configuration was duplicated from the working 'Debug' configuration).
Xcode reports 'No such module'
This seems like a really strange bug. Surely someone has come across this before? My Google search yielded no results. Does anyone have any idea what may be causing this issue? I'm pretty sure I added the framework correctly.
I've created a short screencast to show you exactly what I'm doing: http://www.screencast.com/t/zpgZ5ZYgvH
Bottom line:
Make sure project currently builds using third-party Swift frameworks
Select the project in the project/file navigator
Select the project above Targets in the editor left sidebar and make sure you are on the Info tab
Duplicate the current configuration (likely 'Debug') by clicking the + button below the list of configurations and selecting 'Duplicate XXX Configuration'
Modify your scheme to use the new configuration by going to Product (menu) > Scheme > Edit Scheme...
Select Run in the left sidebar
Select your new configuration under Build Configuration
Attempt to build again
You can also download the sample project: http://s000.tinyupload.com/?file_id=48797763216274271820
I'm running Xcode 6.0.1 (6A317) and Yosemite 10.10 (14A361c).
Add the following Framework Search Path in the Build Settings of your target:
$(SYMROOT)/Release$(EFFECTIVE_PLATFORM_NAME)
and make it non-recursive
In my case this was for Alamofire, which was added to my project as a git submodule.
The framework was being built correctly which can be seen in the build logs, but I assume the default framework search path is derived from the scheme name. The Alamofire framework & dSYM file are in Release-iphoneos/ Release-iphonesimulator.
This should work work with any Swift framework as long as it's scheme names are default. If not, check the build logs and adjust the framework search path accordingly.
I had this issue as well and fixed it by adding the same configuration names to the included Alamofire project.
My build schemes in my main project:
And the build schemes inside the Alamofire project:
Note:
Also, make sure your iOS deployment target is the same in both projects.
If you are using CocoaPods, try pod install this will generate some .xcconfig files with your configuration name. Clean your build folder and build again.
If you have a modular structure (e.g. the App uses frameworks to decouple UI, Services or Business Logic from the application's main module) then add the new Build Configuration to each subproject that builds these frameworks.
In this case if the author had, let's say, Services Framework in his workspace then he had to add a Debug Original configuration to it too. And then run pod install, of course.
This is how I fixed my issue.
I use Cocoapods for my project and I need a specific set of frameworks for each Debug/TestFlight/AppStore release:
Debug (simulator or device): common frameworks + Calabash - Google Analytics
TestFlight: common frameworks + TestFlight SDK
App Store: common frameworks only
I could use targets, but they are annoying:
Every time you add a new file (or create one) you have to remember to add it to all targets. It makes it really easy to produce builds that don't have a required file.
Changes in build settings of one target don't propagate to other targets (i.e: changing a llvm flag).
On the other hand, cocoapods doesn't support weak frameworks, so I can't weak-link to Calabash in my main target and force-load it when building in Debug mode (because it'll still be in the framework set when building for the app store)
What would be a good balance between the very segregated option that are targets, and "all in" solution of a single target?
I have a makefile that removes certain pods then runs Pod install. We're making it much easier in the next release to do config based pods, so you will be able to do all of what your asking in version 0.34+. This is in the current HEAD on github.