Difference between folder and group in Xcode? - xcode

In Xcode, what is the difference between a folder and a group? Are these interchangeable terms or is there a subtle difference?

Groups
With groups, Xcode stores in the project a reference to each individual file.
Folders
Folder references are simpler. You can spot a folder reference because it shows up in blue instead of yellow.
There are two types of folders in Xcode: groups and folder references.
You can use groups to organize files in your project without affecting
their structure on the actual file system. This is great for code,
because you’re only going to be working with your code in Xcode. On
the other hand, groups aren’t very good for resource files.
On any reasonably complicated project, you’ll usually be dealing with
dozens – if not hundreds – of asset files, and those assets will need
to be modified and manipulated from outside of Xcode, either by you or
a designer. Putting all of your resource files in one flat folder is a
recipe for disaster. This is where folder references come in. They
allow you to organize your files into folders on your file system and
keep that same folder structure in Xcode.
Reference

A folder in Xcode represents a folder in the file system.
A group in Xcode is a "fake" folder which does NOT represent a folder in the file system.
It is common to use a combination of groups and folders for a given Xcode project.

Xcode behavior (starting with v9) has changed and groups are now actual folders on-disk.

I found that Xcode 9.2 has two versions of group when you create a group. One is group the other is group without folder. The first one also creates folder in your file system, the second one doesn't.

I was following a tutorial and it had me drag a nested folder with a number of autogenerated Swift files with public classes and structs. I missed that I was supposed to click the "Create groups" and not "Create folder references". When I added the folders/paths using the incorrect 'folder ref', my other scripts did not see these public objects. When I did it the right way, added them using 'groups', then they were recognized in other scripts. I think this is in keeping with TheNitram's comment, that 'group' adds to the root ...

Related

Why are there some blue folders in my Xcode project?

When I import my project from Github, I have two folders which appear in Xcode with a blue color, but all the other folders are yellow. What's going on?
Blue is used to represent a "Folder Reference".
A clear description of what these are and when to use them comes from http://struct.ca/2010/xcode-folder-references/
There are two types of folders in Xcode: groups and folder references.
You can use groups to organize files in your project without affecting
their structure on the actual file system. This is great for code,
because you’re only going to be working with your code in Xcode. On
the other hand, groups aren’t very good for resource files.
On any reasonably complicated project, you’ll usually be dealing with
dozens – if not hundreds – of asset files, and those assets will need
to be modified and manipulated from outside of Xcode, either by you or
a designer. Putting all of your resource files in one flat folder is a
recipe for disaster. This is where folder references come in. They
allow you to organize your files into folders on your file system and
keep that same folder structure in Xcode.

What is a blue folder in Xcode

I have opened a project from Github, which has blue folders in its file structure.
As far as I understand this is a physical folder reference rather than just a means of grouping files together which might just lay around loosely on your hard drive.
So my question: When do you use those blue folders over the "normal" Group, what are its advantages and drawbacks and how do you create them in Xcode?
If you use blue folder references for your resources these folders will also be created inside your application bundle, while resource files in groups will simply be copied to your mainBundle's root directory.
When folder structure is managed outside of XCode (for example, a cross-platform project which has project files for different versions of XCode, Visual Studio and other IDEs, all using mostly the same directory tree), you normally want folder references. Otherwise one would have to recreate every project file every time folder structure changes.

When to tick "copy items into destination's group folder (if needed)"

Whenever I am adding some files to my project by dragging and dropping in Xcode, a popup message is shown "Copy items into destination's group folder (if needed)".
I noticed that when we are using most of the third party library's we DON'T tick the checkbox and instead specify the library path in "Header Search Path/Library search Path". But for smaller resource files like images, we tick the checkbox.
Which specific scenarios do I have to tick and what difference will it make?
It all depends on how you want to organize you project. It's far more common to store 3rd party frameworks somewhere on your machine that is independent of any project that may use that framework, thus allowing multiple projects to reference the same shared framework project from a standard directory. In that case, you don't want the 3rd party framework copied into your own project, and so you don't check that box.
Images and other resource files are typically owned on a project-by-project basis, so it makes the most sense to store those in the directory of the project itself. To pull that off, you check that box to make sure a copy is made in the project's directory if one doesn't already exist.
Neither of those rules are absolute, you could copy an entire framework into your project's directory if you want, and you could reference media assets from some standard location. It's all up to you to implement good project organization.
Typically, your project is saved to a project folder. If you drag stuff from outside the folder into your project without copying, only references to the added files are stored. You will have to be careful not to delete them, or your project will break.
Also, if you are using version control, such as the built-in git, files not in the main folder will not get added to your version tree.
I got into the habit of copying everything I need into the main folder and then drag-add without copying. This is working well for me and has so far avoided any errors.

a few basic xcode questions

what is copy items into destination group's folder (if needed)
is this a good option? If I dont choose it will it just make a reference to my files?
Also if I have two images with the same name like /images/home.gif, /public/home.gif
but they are in different groups how does the compile know which image to use? is this even possible?
I'll have a crack at this :-)
1 & 2 - Used when adding files to a project. If selected, the file you are adding is copied into the projects directory from wherever it originally was. Note it is copied. If not selected, the project can still use it, it just has a reference to the original source file. Which means that if something happens to the original file, the project will not longer have a copy it can use. Personally for files such as images I copy them into the project so they stay with the project. For other things such as external apis, I don't because I don't want multiple copies everywhere.
3 - If you have two images with the same name you won't be able to copy them in without renaming one. XCode may do this for you, I've never tried. I'd suggest renaming one so you control it's name.
4 - Don't get confused by groups. They are logical groupings of files within XCode and do not refer to the underlying file system. Having said that you can actually assign a directory to a group so if you really wanted to you can match the two. I tend to do it a little. In my projects I generally have a src and test directory. I setup two groups and assign them to refer to these directories. Then when I create a new source code file I can create it in the src or test group and it will be created in the sub-directory instead of the project root directory. Often below src and test I will use other groups, but they do not map to any sub directories. The result is that the root directory of the project is free of source code files and the source code also has source and test code separated.

how do I package support files in a cocoa app

I'm building an application where I want to provide the user with a few dozen templates that will internally take the form of property lists. I would also want to group them in categories, which would conveniently be achieved using folders.
While I have contemplated shipping these files as simple resources in my application, I don't like the idea of this single location containing dozens and dozens of files, and besides it doesn't seem to be possible to group them in folders.
I can see that many applications have installed such resources in their application support directory (~/Library/Application Support//...), but I can't seem to find any documentation resource on how to achieve this.
I don't like the idea of this single location containing dozens and dozens of files, and besides it doesn't seem to be possible to group them in folders.
It is. Put them in folders in your project directory, then add the top-level folder(s) to your project. Make sure you add it/them as folder reference(s) and not group(s) (see? that sheet does have a purpose!).
Then, add the folder reference(s) to your Copy Bundle Resources or Copy Files phase.
One word of warning: When you change one of the files in the folder, you may need to “touch” the folder to get Xcode to re-copy it. You can do this in Xcode or from the terminal.
You can group items in sub-folders of your app bundle's Resources directory. Unless you want users to edit these plists, keeping them in your app bundle allows users to drag-n-drop install your app, rather than having to use an installer package (a big win).
You can group them into folders in your application bundle by adding a "New Copy Files Build Phase" to your project as described in this forum post:
http://forums.macrumors.com/showthread.php?t=458594

Resources