I'm trying to install Alamofire into my Xcode project. However, after following all the steps for installation given by the documentation on the github project, the Alamofire.framework file shows as red in Xcode, and the project will not build. Further, there seems to be no way to fix this, because the Alamofire.framework file does not exist in the package on github.
More detailed explanation:
Following the instructions on github to install manually is fine until the final step: "Click on the + button at the top left of the panel and select "New Copy Files Phase". Rename this new phase to "Copy Frameworks", set the "Destination" to "Frameworks", and add Alamofire.framework."
Because we have already included the project, when we go to add a new framework, Alamofire DOES show up in the list of available things to add. However, when we add it, it shows up red. As we know, this means that the path is incorrect relative to the SDK. Ok, fine... but when we go to correct the path by looking at the Alamofire directory that we put into our project directory, there are a lot of files and none of them are "Alamofire."
I know that I downloaded the package correctly. I installed as a git submodule, I deleted it to retry, I downloaded the zip from github, retried again, etc. Even for this tutorial (http://www.raywenderlich.com/85080/beginning-alamofire-tutorial), if you look at the pictures for this step, we can see that there is no framework file in the directory!
So, Xcode demands a path to a .framework file that doesn't exist... yet we were able to add the framework somehow. Forgive me if I am confused.
There are quite a few questions out there on Alamofire install issues, but I think there must be something here that noobs like me are missing. One poster, here (Alamofire framework not found), is asking something similar, but it appears that her question was misunderstood (she did not accept any answers). I notice the "It's red tho!" frustration showing up in many comments for Alamofire install-related posts- an answer here would really help clear that up.
I was having the same issue as you, however, I found this question which made me build the project even though everything was red. To my surprise it ended up actually building successfully and afterward I was able to import Alamofire into my Swift files.
I had tried to build earlier unsuccessfully, however, between builds I did change one thing. I moved the Alamofire-master folder to the first level of my App's file structure before including the .xcodeproj file in the Project Navigator, as indicated by the tutorial that you linked. I had initially just moved it from its place in my downloads folder.
The whole copy frameworks part seemed to be a nonissue for me because the framework ended up instead in embedded frameworks automatically, after doing the embedded bin step.
Related
I'm programming a Swift iOS app in XCode 9.2 (Dated, I know), and I've tried to integrate GoogleAPIClientForREST using Cocoapods. When you integrate GoogleAPIClientForREST (and possibly other pods, I don't know), it also downloads GTMSessionFetcher. Since the integration of the pods, the app won't run and gives this Shell Script Invocation Error:
/Users/username/Library/Developer/Xcode/DerivedData/Teachers_Assistant-aphjxihtqtmedabcymmxjlmxduzc/Build/Products/Debug-iphonesimulator/Teachers Assistant.app/Frameworks/GTMSessionFetcher.framework: No such file or directory
However, I can't open Teachers Assistant.app, as it's not a folder. GTMSessionFetcher.framework exists, but inside of the folder circled in red in the image at this link, not inside the .app file circled in blue.
I've tried the suggestions at this link, the suggestions in the question at this link, this link, this link, and this link. None of them have worked, though if you think that there was something I did wrong while trying to carry out those steps feel free to tell me.
All of my code is online at this repo, including the podfile. Thanks for the help!
Additional information: I plan on using the Google API to automate Sheets as a sort of storage information system to log attendance data and other miscellaneous information, if that helps at all.
Project's name should not contain special characters like ' or space, this could create some problems when Cocoapods try to link the libraries. I suggest you to change your project's name to TeachersAssistance (it worked for me). Here is the suggested steps:
Change project's name in the navigator. Xcode will recommend you to refractor the project, accept it:
Update podfile to point to new targets's names
Cocoapods will create a new workspace TeachersAssistance. Use it and delete the old one.
Remove Pods_Teacher__Assistance from new workspace. From now it will use Pods_TeachersAssistant.
Compile again and enjoy your project :)
I am manually adding the SQLite.swift subproject to my project. As the directions indicated, I copied the .xcodeproj file to my project. This allows me see all the source files (unlike this SO question).
Everything seemed like it was working fine. However, I discovered that the source files of that subproject were not copied to my project. They are still in original location where I downloaded them. Is this by design? What if I want to share my project source code with other people in the future? They won't have the subproject source that is necessary for my project to work.
If I do need to copy the subproject source to my project, then how do I do that?
Add it to your filesystem-structure first. For example by pressing "Show in Finder" on the "Chimee"-project which will lead you to the folder it's located in. Then copy the SQLite-project structure in there.
Afterwards you can then drag&drop the xcodeproj into your project which will then still link to its original path, but as it's now inside your project-structure isn't a problem anymore.
I guess that this is by design, because when you try it via Add files to "YourProject" you can select the Copy items if needed-option but it will still not get copied (only with .xcodeproj-files, it works with all other filetypes)
After doing more research, I now feel that using a dependency manager (like CocoaPods or Carthage) is a better option than manually adding the framework to the project.
This will allow easier updating in the future.
Github source code sharing and App Store submission issues have already been considered.
Using Carthage is not too difficult if you follow this excellent guide: Carthage Tutorial: Getting Started
Notes
Delete the framework files that you manually copied in before installing the framework with Carthage.
I will leave #TMob's answer as accepted for now, but I am no longer pursuing that route.
I am using the DropboxSDK.framework in a project of mine.
I have everything setup and working fine. However, every time I quite Xcode and open it again at a later point I get the error below:
Which is weird because I can see that the framework is in the project and nothing (that I know of) has changed since the last time I had the project open and working.
The way I make the error go away is to:
Right click on the DropboxSDK.framework in my project --> Delete --> Remove Reference.
In my project's Build Settings under Search Paths I remove the path that is under Framework Search Paths (the highlighted selection in the image below).
Then I clean my project SHIFT + CMD + K
Lastly, I click File --> Add files to my project, navigate to the DropboxSDK.framework file which I previously removed reference to and add it back to my project.
Then I build my project again and the error goes away and will remain gone until I quite Xcode and open it again.
Has anyone else ever encountered this happening and fixed it?
Or have any suggestions I could try to fix it? I'm using Xcode V5.1.1
Let me know if there's anything I can clarify. Thank you!
$(SRCROOT)/Application_Folder
Application_Folder is the name of the folder where your whole code other resources resides
Insert above line in Header Search Paths
I had a random thought sparked by Indrajeet's answer that solved my problem.
When a new project is created in Xcode a project folder is created. In that folder there is another folder with the same name as your project, a .xcodeproj file with your project's name and a yourProjectNameTests folder.
Visually like this.
Application_Name --> Application_Name
Application_Name.xcodeproj
Application_NameTests
When I was having the error I described above the DropboxSDK.framework and it's accompanying files were stored here in this folder:
After removing all references to the DropboxSDK.framework in my project I decided to move the DropboxSDK.framwork and it's accompanying files one folder level up to the main Application_Name folder here:
Once I did this, I clicked File --> Add files to my project, navigated to the DropboxSDK.framework file, now one folder level up and added it to my project.
After building no error was thrown. I restarted Xcode and tried again to make sure; still no error. Rebooted my computer to be truly sure... still no error!
I was having the sane problem and just found the answer by chance!
It happens when you create your project name with SPACES between the letters. Somehow it makes XCode crazy when searching for the frameworks.
So if want to create a project called "This is My Project Name", call it "This_is_My_Project_Name" and the frameworks will be found every time. It worked with me.
So im trying to use the route-me widget in my app, but xcode keeps complaining that it cant find FMDatabase.h, yet its included in the project (albeit under a different project that is included into my project). I've copied how a sample app has been made yet the sample project doesnt get this error. The RMDBMapSource.h file is contained within the MapView project, so i shouldn't need to include the fmdb stuff myself (and because the sample project doesn't do that)
Surely if the files are under compile sources / copy headers under build phases, that means it should be able to find the file? This is a pretty lackluster explanation of my problem, but if anyone has used the route-me library before maybe they have had the same problem and can point me in the right direction
Resolved my own mistake. First off in the build settings of the main project, the 'search for header paths' was not set correctly, it was set to /MapView/ instead of /MapView/** that resolved the FMDatabase.h missing error.
Then in case someone else had a linker error like i did after i resolved the first issue, make sure you have libMapView.a included in your link binary with libraries section. (i had it their before, but during a version control commit, somehow our project file decided to not add that library anymore and i had totally forgotten about it, so took me quite a while to find out that it was missing)
THIS QUESTION REFERS TO RESTKIT 0.9.x.
IF YOU ARE NEW TO RESTKIT CONSIDER USING THE NEWER 0.10.x branch.
I recently inherited a project that uses restkit (restkit.org). I have started using a branch (402-new-build-process) that is more compatible with xcode4.2.
My project an all the example projects build and run, but when it comes to Archiving an app the build fails:
/Users/AUser/Documents/SubFolder/stable-branches/project-iOS-client/RestKit/Examples/RKTwitterCoreData/Classes/RKTwitterAppDelegate.m:9:9: fatal error: 'RestKit/RestKit.h' file not found [2]
#import <RestKit/RestKit.h>
^
1 error generated.
I have followed the Installation Troubleshooting guide on the project wiki, but this did not work.
As per Blake's answer I am building to the DerivedData directory:
In addition I have tried setting header search to these (in many combinations [just guesses]):
"$(BUILD_DIR)/RestKit/Build"
"$(SOURCE_ROOT)/RestKit/Build"
"$(SOURCE_ROOT)/../../Build"
"$(BUILD_DIR)/../../Build"
I think all these fixes were stabs in the dark, or at least felt like that to me. I half expected to read one about getting some hair from a young virgin and burning it over the Mac.
If it compiles for you in dev but not for archive its bound to be something simple. Or at least it was for me.
My source files were not in the right place:
The search header was set to "$(SOURCE_ROOT)/RestKit/Build"
But I had simply dragged the proj file from where I downloaded it into XCode. This was never an issue when compiling for debug etc. Just when archiving so I didnt spot it for a while.
Just make sure what ever that path is to the RestKit/Build is where the actual files are.
Fixed it for me, unlike all the cross your finger fixes I've read. Like moving headers into a group etc... what a load of rubbish that was.
Good luck, hope this helps. Thanks to the Restkit team, this really is a great framework.
Jamie
I am building against the development branch and integrate RestKit as a submodule in my root git folder
+ root project folder
|--+ RestKit
|--+ <Projectname>
|--+ <Projectname>.xcodeproj
So I use the following search paths
"$(BUILT_PRODUCTS_DIR)/../../Headers"
"$(SOURCE_ROOT)/../RestKit/Build"
!!!Update to the latest version of the branch!!!
I've just built RKCatalog and RKTwitterCoreData as an archive on Xcode 4.2 without issue. I am failing due to a Code Signing issue. Have you confirmed that you are building with the DerivedData directory:
RestKit assumes that you are using a modern Xcode project building to the DerivedData directory. Confirm your settings
via the "File" menu > "Project Settings...". On the "Build" tab within the sheet that opens, click the "Advanced..."
button and confirm that your "Build Location" is the "Derived Data Location".
I can push changes that rsync the headers to a known location, but I was hoping that standardizing on DerivedData would simplify the process.
To reiterate Jamie Reynolds answer, most (if not all) of you have set your header search paths to "$(SOURCE_ROOT)/RestKit/Build", this is fine while debugging and also fine for archiving, unless of course your Restkit framework IS actually in this directory.
Like the majority of you out there, you have probably just linked to the framework from the default download directory, in which case go to finder, open Restkit->Build cmd+i to see the info and select the directory path, copy and replace "$(SOURCE_ROOT)/RestKit/Build", dont forget the brackets.
mine was "/Users/edwin-b/Downloads/RestKit-RestKit-8d0d9fc/Build" worked like a charm
I followed the steps outlined in several SO answers, and the issue ended up being a problem with the Header Search Paths. Sometime between adding RestKit in XCode 4.2 and trying to archive in XCode 4.3.1 (I had updated twice between starting the project and providing a build), a comma had been injected in the Header Search Path list which Xcode could no longer parse. As a result, the entry for RestKit's header location was:
"$(SOURCE_ROOT)/RestKit/Build",
When it should have just been:
"$(SOURCE_ROOT)/RestKit/Build"
While this didn't produce any issues building to device or sim, once I tried to archive, it caused the error reported by the OP.
Just add "$(SOURCE_ROOT)/RestKit/Build" to you target "Header Search Paths", Thanks to this answer.
I'm sure some of these are redundant, but I just spent over 3 hours debugging this thing and almost ruined my project in the process. So... Here you have it.
For the sake of your sanity, create a zip backup of your project before messing with RestKit project paths, commit all files (especially the project) to source control, cross your fingers, burn a virgin hair over your mac, then proceed.
After eliminating them one by one, I narrowed it down to this line allowing me to archive.
"$(SOURCE_ROOT)/../RestKit/Build"
Restkit is a folder at the same level as the main project folder
I'm adding this answer so I can find it later - it matches some responses above. Look in your targets "Header Search Paths" - and depending on where your restkit directory is in your project, add one of the lines specified above in Alex Stones answer. In my case, it was "$(SOURCE_ROOT)/../RestKit/Build"