Me and my friend are trying to collaborate on a project that he recently uploaded to GitHub. I checked out the repository but do not get the same project structure after opening it in Xcode. The project contains Cocoa Pods which in Xcode appear as a separate file along with the main one. The problem is that when opened in Finder on my computer, the main project contains folders DummyApp, DummyAppTests and Pods together with some other necessary files as in the picture below.
When the main file is being opened in Xcode, only the Pods folder is recognised. The main project file is empty and there are no error message available to provide some clues. It seems like Xcode does not recognise the other folders as valid projects and excludes them.
We compared our folders locally in Finder, both have the same files and structures. So we've figured that the check out from GitHub works fine. We've been thinking that maybe my friend needs to invite me to collaborate on that project in order for Xcode to validate my participation but found nothing of this sort on Apples Developer sites. Any ideas what might be causing this problem?
The project has been re-uploaded to GitHub, re-opened, re-checked out and all that basic stuff..
I've learned that using GUI for gits causes more problems then it does good. Uploading just the podfile(via the terminal) and excluding all the individual pods solves the problem above.
Related
I have been working on a project at my workplace and before holiday, I’ve e-mailed the files (entire folder as zip) I’ve worked so far, so that I can open and work on it from home.
But I’m getting error when trying to run the project. It says main. Storyboard and launchscreen not found, but they are available in project .
I’ve e-mailed the files I’ve worked so far, so that I can open and work on it from home
No, you cannot email files selectively. All contents of a project are needed. You zip the entire project folder and email that. Or, push the whole project to github and clone it to your other computer when you get home.
First off, I know this is a config issue because my code was building and running just fine before I synced my project to GitHub. Xcode's internal source control seems to be having trouble recognizing some of my files and I'm getting Use of unresolved identifier... errors where these files' initializers are in use, and were working before. I'm running the latest versions of Xcode and OS X, and these are the steps I was taking before and after the issue started...
BEFORE:
After several rounds of implementation and committing with the default local repository, I built and ran the app multiple times with no issues.
I created a new repository on GitHub, committed (w/push to remotes) and everything made it to GitHub just fine and was building and running in the simulator.
In order to organize the repository (to match the 'groups' I had created in Xcode) I did some brief research and then added nested directories to my project folder. I re-opened Xcode and repaired the file paths. Some took, but several kept showing ? (although I could still access the code just fine) and I got the corresponding Missing Files... warnings.
Because I couldn't get the new hierarchy to work (the files w/?s, not being recognized, were not able to be committed to GitHub), I tried to move the files back. This worked for most, but for a few (which seem to be the effected files) I had to rename them, recreate a new file and then paste their contents over (this is where I think the problem lies). I was able to commit everything to GitHub (even the problem files went up) but all the warnings remained.
To clear out the warnings I attempted to run my tests, and that's when the Use of unresolved identifier... errors popped up, and of course the build failed.
AFTER:
I verified all the paths and target memberships were correct.
When that didn't work, I built an entirely new project (although I did add it to the same workspace; not sure if that matters) and copy/pasted all my code over to new files. I didn't drag / reference the files and I didn't link the new project to GitHub. When I went to build, same errors in the same places...
I exited the workspace and opened the new project separately. Still no joy.
Any help or points in the right direction would be much appreciated.
EDIT:
After some help, I tried deleting the reference and dragging the file in manually but that didn't resolve the issue.
I also checked Build Phases -> Compile Sources and everything was listed fine with no compiler flags. I removed and re-added from Compile Sources, issue persists.
You can try removing referencer for the missing class file in Xcode,then add same file to folder (right click add file ) from physical workspace location this might help.
After rebuilding an entirely new app a third time, with all new files, I copied the files over and this time everything seems to be working fine. Had to repair a bunch of provisioning issues to make sure it worked (maybe that was part of the problem, but I doubt it), but everything is back to normal with the app. The only thing I did differently this time was not adding the new project to the same workspace.
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.
I have recently upgraded to cordova 2.1.0 and previously each Xcode project referenced its own cordovalib folder.
I thought I understood that if you want an Xcode to use a cordovalib on its own and not share it with any other projects, then you can run
./update_cordova_subproject
in
Cordova-2.1.0/lib/ios/bin
and that if you don't run the update script with its parameters then you can share the CordovaLib.xcodeproj file across many projects. However if I open two Xcode projects that reference the same Xcode project I get this error:
Cordova-2.1.0-global/lib/ios/CordovaLib/CordovaLib.xcodeproj Couldn't load CordovaLib.xcodeproj because it is already opened from another project or workspace
and if I try opening the CordovaLib/CordovaLib.xcodeproj file I get this error:
The file couldn’t be opened.
However all projects run without any problems.
Quitting xcode and reopening the project without any others that reference the same cordovalib open removes the error.
Does this mean that:
I cannot share a CordovaLib.xcodeproj file across many projects and each project has to have its own cordovalib that it references, otherwise I could run into serious problems in the long run? Or
I can share a cordovalib across many projects but can only have one Xcode project open at any point in time and that I will not run into any serious problems in the near future?
Is there something I am overlooking?
I have tried googling the problem but most of the questions refer to previous versions of cordova whereby the method of referencing the CordovaLib was different.
Thanks in advance.
You can reuse the subproject, but you can only have it open in one app at a time.
Not a problem if you only work on one thing at a time like most people, but since my current preferred development setup involves 18 desktops and never closing anything, I work around it with git submodules - each app gets its own fully independent copy of Cordova without actually keeping a separate copy in source control.
This question seems related to XCode Build and Archive for Enterprise Distribution builds old archive but the answers have not worked for me;
We have an iOS application that is distributed using the Enterprise Distribution method. This has been updated regularly for the past year by issuing a new IPA and having users delete and reinstall the app. Lately when I archive and distribute the app it installs correctly, but it is a previous version from a few days ago with none of the recent changes. These are things as simple as text labels and alerts with the wrong text.
I've done everything I can think of, including:
Confirming it builds and runs correctly in the simulator and when building directly to an iPhone. Everything works great in these cases.
Cleaning the project.
In the Organizer, deleting all archives and removing the project.
Manually deleting the DerivedData folder.
Renaming the IPA and updating the distribution plist to ensure that the file isn't somehow being cached on the web server.
Deleting the entire project and doing a fresh checkout from SVN.
Even when I do all of these things together, so that I've completely removed the project from my computer and Xcode and re-archived it with a fresh checkout of the source files, it still archives an outdated version. Where could this be coming from? Should I just reinstall Xcode completely?
Since you have deleted and checked that your build files are clean from old rubbish, I would have a look at the actual source files and the project and make sure you are actually making your changes on the right place.
Right click on the files that you are working on in your project and select "Show in Finder" and see where they are actually located. Maybe they are in a different location than you would expect?
Do the same with the files under "Compile Sources" in your target, and make sure they are the same files and at the same location as the ones you have been editing.
It could be that if you at some point has fiddled around with your files and projects that you actually imported the wrong files and that you are editing different files than the ones included in your build. It happened to me once, I had to re-import lots of files to my project to get it working again.
The network was caching it! The wireless network in my office is serving up a cached version of the IPA from yesterday, while an external network downloads the latest copy just fine. It's embarrassing that I never thought to check this, but I suppose the solution is often obvious in hindsight.
Thanks to Jake and Mike for the suggestions; I'm sure they will be helpful to others who come across this question.