When I tried to put a third-party framework(installed by carthage) in the embedded binaries, I got such an option. I got confused, since "Embedded binaries are binary files that are copied to your application bundle when you build the project", It is already a copy instead of a link, why do I want a copy of a copy?
"Copy items if needed" has nothing to do with the building of your app. It means copied into the project folder, right now (if it isn't in the project folder already). I suggest you always say yes, because otherwise your project might end up depending upon stuff that isn't in the project folder, and which you might therefore throw away or rename by accident, thus causing your project to break.
Like matt has said, I recommend you always leave it selected as well. I have had troubles uploading the app, even though I know I have not moved or renamed the file. Also an extra benefit of leaving it enabled is that it makes it easier to share the project with others without having to track down the files not in the project folder.
I can see two cases why leaving it off might be convenient:
You have multiple projects which share the same file and want to reduce space,
You desperately need to save the space on your computer, in which case I would buy extra storage for your computer.
Edit: Even though you copied the file in, XCode treats it as a link to the file, this is why you are seeing this message.
Xcode Copy items if needed
Copy items if needed usually (but not always, e.g. the project already contains this item) copies files into your project directory as a result you can use relative path(instead of absolute) safely. For example when you use some version control(Git, SVN...) your team members will not have some troubles with solving issues with paths
In case of third-party framework you can use $(PROJECT_DIR) in Build Settings -> Framework Search Paths
*Also do not forget additionally set dependency if not dyld: Library not loaded[About]
[Create groups vs Create folder reference]
Related
I'm developing an iOS app with some other students of my class. One of them created our Xcode project and set up all the folders (groups) we need. These folders also appear in his finder. When pushing everything the folders are not visible in our repo. When I pull it, everything in Xcode is fine, all the folders are there (which also says the pbxproj-file). BUT in my finder none of these folders are there.
This is how it looks like
How can we also put the folders in Git, so that they are visible in our repo and the files are in them?
Edit: The below is the question I thought you were asking, but the image you added suggests a different problem. I would first make sure you're actually looking at the same directory. Cmd-rightclick the project in the navigation bar and make sure it's the folder you think it is. This is a surprisingly common mistake.
I would then make sure you haven't referenced external folders or put things in a strange place. Select a folder and open the right-hand sidebar (Cmd-Opt-1), and check the path. It is very common when you drag things into a project, or rearrange a project by dragging, to accidentally create absolute path references to locations outside your project.
Xcode has traditionally used groups rather than folders to organize files. Groups are a virtual structure, purely in Xcode. Most of the files are put into a single physical directory.
(Whether this is good or bad is a matter of taste. I've long preferred having most files in one directory to make reorganizing the structure easier, and to make it easier to write scripts that search or process all the source code. But over the years, and particularly moving to Git from Perforce and SVN, and especially with the rise of GitHub, I've grown to prefer the folders, and that seems to be the direction Apple is moving towards as well.)
In recent versions, Xcode has moved towards supporting folders directly.
You can see the difference in Xcode. This is a group without a folder:
This is a group with a folder:
Note the lower-left corner of the icon.
You can make folders from the local menu, either by right-clicking an existing folder/group, or by selecting files you would like to move into a folder and right-clicking:
I don't believe there's any shortcut to convert all existing groups into folders. You'll have to restructure. But as you create new things, make sure to create folders if you want those.
It's better to maintain relevant folder structure as mentioned by #Rob Napier so that when you modularise/move files in xcode the files are moved to the corresponding folder structure and they are in sync with the file system.
Right click on any one of the file(under view/vm) and -> click show in finder to check the absolute path of the file.
From the beginning of my project, I use a custom framework, let's call it "custom.framework". But there was a bug in this framework and now I want to use another version of the "custom.framework".
At first, I simply removed the "custom.framework" file from my project and added the new one. But nothing changed, the bug was still there.
After multiple tries and hours, I understood that Xcode add the old version in memory and used this one instead of the new version. I know it because in the new version I added a method and when I cmd+click the class I've add the method into, it's not there and the file's path is unavailable.
Searching through the web, I tried to change some version parameters to my framework projects: Compatibility version, Curent Library version, Framework version. But this didn't change anything to Xcode which keeps using the old version.
I also tried to make the framework's project as a sub-project and add resulting framework as a dependency to my target. It worked well, but as the framework's project is on a separated remote git repository, I don't think this is an acceptable solution.
So my last try was to build a "custom2.framework", to force Xcode to use the real file and not some cached version. But again, it doesn't work and when building I get errors telling me that all my classes in custom2.framework are duplicated symbols of its cached version of "custom.framework".
So my question is simple: how can I finally tell Xcode to deleted its cached old version and let me use the file I gave him? I already tried to delete my project's derivedData but it seems cached frameworks aren't there.... I'm so desperate :(
Edit: Here are 2 screenshots to illustrate the issue
First screenshot is the path as shown by Xcode when I opened the file from the .framework object in the project navigator.
Second screenshot is the path as shown by Xcode when I opened the file from a cmd+click to a "DCEquipmentManager" in code.
As you can see, the framework linked with the code is not the framework in the project.
it seems problem with binding in new framework, your project still linked with old framework files.
try to remove all files and folder related to your "custom.framework and also remove path for that framework from project setting--> build setting --> search Path
Then after Drag and Drop Your "custom.framework" files in project.
it works for me.hope it resolve your problem.
Please try to clear derrived data:
Window -> Organizer
at the right side you will see projects list. Find your project and tap on it. I the top part of window you will see button delete in front of Derrived data, tap on it.
I guess it will solve your problem.
It might sound silly, but sometimes restarting XCode or the whole machine fix things.
Did you remove the old framework from Build Phases --> Link Binary With Libraries?
Use Clean Build Folder: option-shift-command-K, or select it from the Product menu when holding down the alt/option key.
First lets say something upfront. The build stage is a(are) command line tool(s) that is managed by Xcode according to your Build Settings.
So when Xcode doesn't find your Framework - the Build System will usually also not find it. This forces you to act but may end up in confused Xcode to catch an older reference.
Yes it may happen that the Header Xcode is pointing to is correct but the build system still uses an old copy somewhere. An outdated copy can dangle around literally anywhere depending on the steps you took before.
It (Xcode) assumes where it is located but the Build System still uses another version or the Search Paths just pointing in the wrong Locations even if they are visible to you and even your Framework icons are visible in the lists. So when you erase the last build you actually only force Xcode to rebuild from the known arguments, the settings stay the same, the lists stay the same. Even restarting Xcode does not change anything, the problem persists.
Ergo: Compiler Instructions, Xcode settings and Build System settings don't match what the code tells with #import <NAME/Name.h>
So you will check at least those 6 stages again:
Is your Framework Header File published in your Framework project?
are Build Settings really pointing to the right Framework Search Paths or System Framework Search Paths?
Is your Framework in linking list?
Is your Framework in Embed Framework list?
Does your framework appear in the Framework Group Folder in Workspace/Project Browser? (usually the very last Group Folder in the Browser below all your other files)
Is my Folder Structure correct?
At least 1 to 4 must be right otherwise it will fail.
Here a random list of common causes
Framework is located outside your Source Paths structure
Structure got changed after you added it to the project
You use Workspace's where Framework development and Final Application can appear side by side but you assume Xcode uses this to change its Search Paths
The contained build settings are misleading from former drag and drop operations, ending up tricking Xcode in the "wrong" corner. In this case recreating a project is just one of the possible ways to fix it but not the solution.
Also dragging a Framework into your Project > General or separated in Build Phases > Link Binary list or Embed Framework lists does not make Xcode aware of the wrong Build Settings.
The Linking works, embedding works, but compiling does not. The Header information is still missing.
The solution must be to correct your Build Settings.
As mentioned above Build System and Xcode are two different things. In particular only setting the right Framework Search Paths will solve those issues, even if you managed to kick your derived data manually.
Erasing Derived data?
Derived data is the place where precompiler collects data to compile. So it can be seen as expression of what all the settings are told to do. Erasing it does of course not change the settings but may fix inconsistencies related to former Build Settings. It would erase the derived data and rebuild from the Build System Settings you gave.
Correcting Linking?
Also Linking is not the same as making Xcode aware of the desired Headers. Linking is for your final Product to know where Symbols are to call on them at runtime, it does not change Framework Search Paths and System Framework Search Paths, they stay the same as given.
But it is not wrong to start fixing first with
Product > Clean Build Folder, it forces your build to parse all and compile all again on the next Build.
When the troubles come up because of folder structure in parallel or Frameworks are simply placed outside the Source Directory then you must point to them directly or relative.
Most likely you should place one extra entry in your Framework Search Paths like $(SRCROOT)/../Yourframeworksource/build/Debug. expression to point to relative higher folder structure.
Needless to say that a Release Build likely needs another entry ending in "/Release".Hint: Well you can have different Search Paths for different Compile Schemes..
This works particular good after you cleaned Linking List, Embed Frameworks List and then also check the very last Group Folder "Frameworks" for double entries to drag and drop a fresh Framework reference in there.
How to know if leading /../ will fix it?
Click on the dropped Framework Icon inside the workspace Framework Group Folder (lower most) while your Project is the active selected to work on, now watch for the relative Path information on the very upper right side of Xcode, if there is some /../ you know you need it as well.
Sorting of Framework Search Paths
play a role of course, just the same as #import/#include rule sorting matters.
Remember the first found, first wins rule because often we use #import that works different then #include but ignores second attempts to declare. This leads to once wrongfully declared headers to hide corrected declarations later on in parsing that share the same filename or define rules
#ifndef xyz
#define xyz
// all your code here.
// a second read attempt would be ignored
// a second read is hidden also when you use #include then.
#endif
So you can sort those entries either by code and/or in the build settings if needed because of course it matters what is declared before other declarations depend on it.
I'm now developing my first iOS app, and I found that two of my classes (hence, four files) are located outside of my MyApp/.
So in my filesystem, here's the current situation:
My App
- ClassA.h
- ClassA.m
- ClassB.h
- ClassB.m
MyApp/
MyApp.xcodeproj/
MyAppTests/
Other than the two classes, all of my class files are located in MyApp subdirectory. The other resources, such as Core Data model file or images are saved in the same directory.
However, why are the two classes, and only the two classes, located in the outside of MyApp subdirectory? When I move those files to the supposedly correct location, those files are no more "valid" in Xcode with the color of the file name is converted to red.
So here's my question:
Why are those two files located there?
Do they have any issues if they remain to be located there?
Should I fix this issue and save it correctly? I think I haven't had any issues so far with the Simulator and the actual iPhone...
I use iOS 7 and Xcode 5.
•Why are those two files located there?
A: When you have created these files or imported from external directory, you may have not taken care of the group/folder these files are getting created/imported into. Hence they are inside the main app folder in the file system.
•Do they have any issues if they remain to be located there?
A: No, this is certainly not an issue in the correct functioning of your app, but it is always good to manage your files under groups/folders for better file structure and it is easier to find files when they become large in number.
•Should I fix this issue and save it correctly? I think I haven't had any issues so far with the Simulator and the actual iPhone...
A : This depends on you. If you like to keep your files in folders and like everythin arranged in some pattern, then yes you can divide the app into different folders. When you move the files in a folder, the reference of those in XCODE should change as well, and thats why you see those files in red in XCode. No worries. Just delete the files and add them again. Make sure you uncheck the option "Copy files under detsination group's folder".
Now, you may seem the option of creating New Groups inside XCode. But it is good to be aware that these groups do not create separate folders inside file system. These are just for Xcode refernce. So, a neat way is to create folders outside of XCode, and then import these folders(can be empty) in Xcode. Now when you add any file in these imported folders, even from XCode, it will go inside the correct folder in file system.
I am sorry I am not on my MAC right now, so cannot paste actual images, showing how to do it. Feel free to comment, if I have instead of solving the issue, have rather confused you more:D
You can put your source files wherever you want, as long as Xcode knows where to find them. You can leave them here, or organize it in another way, as you seem to be willing to do.
So, if you want to move these files in your Myapp/ subfolder, just move them there, and when Xcode complains it can't find them, highlight all those files in red in the navigator, and in the "File inspector" pane (right hand side of the window), click on the little Folder icon to browse to the new location. If you selected all files you don't need to do that 4 times, Xcode will find it out by itself.
I thought it would be interesting to attempt building multiple apps using the same code base, where the only differentiating data is held in a few plists. For example, one plist holds some theme info - a few key/values to drive the color scheme used in the app. I'll call the original version of this theme.plist.
I soon learned that I should create multiple targets in my project, and have been able to add these successfully. Each one, via it's own appname-info.plist, has a different name and bundle id - it's neat seeing all three on my home screen without any real extra work.
But right now they are all identical. I haven't figured out how to use a different set of data for each one.
My first thought was to have some folder for each target - each with its own theme plist named theme.plist - and somehow distribute each target with a different folder. But researching that idea doesn't get me much google juice.
So what about multiple theme files? Ok, so far that looks better - I can create an app1-theme.plist and 'app2-theme.plist' with different values for the same keys in each. And Xcode even lets me use some flags to say which targets should include each resource.
But I don't know how to load the appropriate plist at runtime. I need to examine something (the bundle ID?) and then assign the appropriate name of the theme plist to something (what)?
It seems like this might have something to with #ifdef, whatever that might be...?
Can someone explain how I should be looking to accomplish this? Am I on the right track? I'm happy to put some reading time in but I don't even know what to look up yet.
You are just about there. Xcode supports having multiple files with the same name in a project, one way you can do this by storing them in different folders within your project folder.
Unfortunately at this point Xcode won't give you a lot of help, so open your project in the Finder, create one subfolder for each of your apps, in those folders place a copy of the plist. Now add each copy in turn to your project, making sure you add each to just one of your targets.
You might want to create a group in Xcode called, say, "Theme files", to keep them altogether.
HTH
What you are trying to do is trivial. If you select a file from your project, and bring up the "File Inspector" in the utilities area (Press Command option 1) you should see a section "Target membership". Each target in your project will be listed, with a checkbox next to it. If you check the checkbox for a file and target, that file is built into that target. Un-check the checkbox for a file and target and that file is not copied over to the specified target (you may need to run a clean, and delete the app from the target device, to get rid of files that used to be included but that you have un-checked. Xcode generally won't automatically remove things that used to be included.
You could create a directory in your bundle and teach your app to scan that directory for plist files. Then include a different set of files in that directory for each target and each target app's behavior will change.
I have some binary files with a proprietary extension that don't get updated in a build when I compile. In previous versions of Xcode with this same project, it would detect the file was changed, and rarely would I have to perform a 'Clean' as I have to do with this version. Of course this is consuming a lot more time -- I would appreciate it if someone could let me know what's changed with Xcode 5 and/or what I could do about this.
I didn't include any project specifics because it's really just a proprietary binary file with a custom extension in a resource folder, which, used to update automatically upon it being changed since last compile. If you need any specific project settings I would be glad to offer it.
It's using the sort of 'blue' resource folder that is a reference to the folder it's in, and isn't just copied into the project directory. I apologize since I forget what this particular resource folder type is called (I'm guessing Reference).
Version: Xcode 5 (5A1413)
UPDATE:
This only happens when I'm referencing a file that I modify programmatically with fopen,fwrite,etc, and upon using a file editor in OSX to resave the file (without really changing it) Xcode will then see it as changed.
I'm now looking into FSEvents to see if this underlying API is something I need to use, although I'm not exactly sure how to set flags with this just yet.
UPDATE:
Well, just as a simple test, I take the same file and resave it via:
NSData* data = [[NSData alloc] initWithContentsOfFile: #"/location/file.dat"];
[data writeToFile:#"/location/file.dat" atomically:YES];
Sure enough, after I call that and then run the app that uses the resource, it is updated via Xcode during the build. So it would seem that Xcode 5 relies on some special flags not set by the standard io functions. At this point I can either patch what I've got with that 2 line thing or figure out what the flagging mechanism is, and how to write to it. (FSEvents? I don't see a writing mechanism there..)
I had the same problem. I set up an Xcode build-phase script to touch the root resource folder, and it works now. I found the instructions here and they are as follows (see link for more detail):
1) Add your single resource directory (named anything but ‘Resources’) to your project in the Resources section as a blue ‘Folder Reference’
2) Right click on your app target, select Add->New Build Phase->New Run Script Build Phase
3) In the resulting ‘Info’ window, change the shell to /bin/tcsh and copy and past the script below into the ‘Script’ text view.
Script:
touch -cm ${SRCROOT}/../../YourResourceFolder
(Also, you may need to know how to find "Build Phases" in Xcode 5)
I was also running into problems. Everything was fine before Xcode 5, and my referenced resources folder would copy pretty dependably. However, after updating, no matter what I did to an individual file (touch it, delete and re-copy it, etc.), nothing triggered Xcode to scoop it up again.
However, I now modify the last write time on the referenced folder during my build step, and now it's contents seem to be copying correctly again. I Hope that helps you too.
I am using custom tools, but I'm sure a build script can do the same. My guess is that Xcode tries to optimize the dependency step, and checks the folder's last access/write times before diving into it.
well a simpler way would be to just touch the folder from your shell or term.
e.g. on your terminal just run
touch -cm PATH_TO_FOLDER_UNDER_RESOURCES
PATH_TO_FOLDER_UNDER_RESOURCES is actual path to the folder under resource folders which contains the files.
Since changing your files do not necessarily change the timestamp of the folder and Xcode looks into the timestamp of the containing folder.
I had the same issue with xcode5, I need to update javascript frequently. I had to clean and then build, it took long time because my project had many source files. Later I tried to delete the app (choose "move to trash" rather than "delete reference") and then build, it was quite fast, but I had to restart xcode so that app can appear in the project again.