Not really ... this is the answer to the original question:
How much is it necessary to search for an image path using the NSBundle pathForResource method when creating a UIImage using imageNamed?
Not much . How well accepted is the accepted answer from Zoul and another from Ranga. In fairness: they are correct if you are talking about the directory structure of application packages or for the (rare) case when the image is in the blue folder in Xcode (more on this later), but not for most common cases
In any case, to one true answer.
As usual, I found this question, trying to find the answer myself. I never found the documentation or other answers to this question satisfactory, so I decided to check.
My test data is all lower, but let me summarize the results here. In short, when using imageNamed: to download images, it depends on where you put them:
if your images are at the root of your project, even if they are organized in a purely logical Xcode group, then no, you don’t need to think about a path: just the name of the image.
if your images are in a group attached to a directory in your file system through "create groups to add folders", you still don't need to worry about the name.
if your images are in the “blue” group attached to the directory in your file system via “create folder links for added folders”, you can upload it using imageNamed: specifying the relative path as suggested (by coincidence?) with the accepted answer above .
if you are using the main alternative to imageNamed :, imageWithContentsOfFile: you really need the full path to the file, including the package path, which means you need to know how the Xcode navigator structure translates to the paths in your package directory structure.
Other important differences between the two methods:
- imageNamed does not require you to specify a file type extension, so just “icon” is not “icon.png”, whereas imageWithContentsOfFile does require the full file name
- this first point helps with the second function: imageNamed will automatically download the retina version of the image, if any, by adding @ 2x to your file name. Therefore, if you ask for an "icon" on the Retina Display, it will try to download "icon@2x.png". imageWithContentsOfFile not
- imageNamed caches the image: there is a lot of controversy surrounding it: if you are looking for SO or the Internet in general, you will find many messages recommending you to avoid this, because it doesn’t clean it properly. This, however, was fixed several years ago, so you don’t have to worry about it not clearing its cache. You still need to worry about what it caches at all. If your images are large and do not load very often, you save memory by loading them from a file rather than caching them. This has nothing to do with leaks: even if you don't have leaks, you still have limited memory on the device, and you don't want to cache unnecessarily. This is a classic caching compromise: what else is important in your situation? Memory performance or processor performance (Time).
So, my tests.
I created a simple UITableView application with three simple icon files shown in the rows of a table using different methods. Icons vary in location in the Xcode project structure. Pay attention to the emphasis on Xcode. The key to understanding the answer to the original question is that there are three completely different project directory structures in the iOS application: there you see in the Xcode navigator, the one in the file system for the same project that you see in Finder (right-click any element in the Xcode navigator and select "show in Finder") and, as you rarely see, the directory structure of the "bundle" of the deployed application. You can also see this last one in Finder - by finding your application in ~ / Library / Application Support / iPhone Simulator and collapsing into the .app directory. I will show you my photo in a minute.
So, in my application, I dragged all three png image files into Xcode in different ways:
icon1.png (clock), I dragged it as a file to the root of the Xcode project, then I later created a new group in Xcode and dragged it into that. This group is not represented by any directory in the system file: it is a pure Xcode group. Hence this name: "JustGroup"
icon2.png (eye), I initially put my file system in a directory called "RealDir", and I dragged this entire directory into Xcode, and when asked, I chose the option "Create groups for any added folders." This means that the RealDir group in Xcode is tied to a real directory called RealDir in the file system (in my projects directory) and there is a2.png icon there.
icon3.png (target), I also had in a separate directory, which I also dragged into Xcode. Only this time I chose the second radio option "Create folder links for any added folders." This creates a so-called “blue” group in Xcode. Learn more about what this is all about later. I called this group (and directory) "FolderReference"
Here is a selection from what Xcode gives you: 
And here is what my project structure looks like in Xcode: 
Now, in my application, I used two methods to load each of the icons: UIImage imageNamed: and UIImage imageWithContentsOfFile. I created a series of rows in my table, with the title of each cell being the name of the group containing the icon: JustGroup, RealDir or FolderReference, plus the name of the method used: imageNamed vs fromFile (which I use as the abbreviation imageWithContentsOfFile)
The cell label label (the weaker text under the heading) shows the name of the file or path that I gave to the method.
To be clear, in the case of "fromFile", I add the package path to the "relative" name that you see. So for "fromFile" I really use this code:
NSString *bundlePath = [[NSBundle mainBundle] bundlePath]; NSString *imagePath = [NSString stringWithFormat:@"%@/%@", bundlePath, filePath]; UIImage *image = [UIImage imageWithContentsOfFile:imagePath];
where "filePath" is the path you see on the table cell label. For imageNamed :, on the other hand, the filePath in a cell element is passed verbatim.
And the line image is, of course, the loaded image. Therefore, for rows in the table that do not have an image, loading the image failed.
Here, in a nutshell, there are results. If you don't read anything about this post, at least a look at this image will tell you everything you need to know.
Here's the main explanation at easily digestible points:
as stated in the official documentation, the imageNamed method: loads images from a set of applications. This means that you do not need to specify the location of the package, only the file name. And even then, just the base file name. The documentation here is a bit thin, so it should be clear that it loads an image from a given file path relative to the application root directory.
(here, pay attention to the kicker, this is the rule) that the rule about the package directory refers to the root directory in your bundle of your deployed application. If you research, it means that the ".app" directory itself. This is not the same as the root directory of the Xcode project in the Xcode navigator, and it does not match the root directory of the Xcode project in finder
this is because when you deploy your application to a device (or simulator), all project directories represented by "groups for added folders" are smoothed. That is, the directory is ignored, and all its contents are unceremoniously uploaded to the root directory of the package. (I say “unceremoniously”, because if there are files with the same name in different folders, they will come across here and you will not get any help in resolving the problems.) This is an example of RealDir in my example: in deployed application, RealDir is bigger does not exist, and icon2.png remains mixed with the general population (scary). This almost does not mean that "JustGroup", a purely logical Xcode group, is also ignored - in any case, it was never a real directory, just visual assistance to the Xcode user, and icon1.png is also at the root of the package.
This is why imageNamed: failed to load icon2.
Also, why imageWithContentsOfFile could not be found in "RealDir / image2.png": since the deployed application does not have a RealDir directory.
"blue folders", on the other hand, that is, directories represented by "folder links for added folders," are actually stored in the application directory structure. This is apparently the point of the blue folders: they give you a way to create a directory structure in a deployed application. I'm not sure about the original raison d'etre for this, but one good use case is where you have several directories containing alternative versions of resource files with the same name and you want your application to be able to switch between them in runtime by changing the directory. Anyway, icon3.png in my FolderReference remained in my FolderReference directory in the deployed application.
- This is why imageNamed: could not be found using the icon3 icon, but can be found using the FolderReference / icon3
- imageWithContentsOfFile was able to find it also using FolderReference , but only when connecting do not forget to specify the full path of the package using the code above. (The main difference is here: imageNamed works with a relative path in this case, imageWithContentsOfFile always works with an absolute path).
To clarify, here are my folder structures:
You saw my Xcode project navigation structure above, here is the file system directory under it: 
And finally, perhaps, most importantly, the directory structure of the file system with the expanded structure: 
Note. I found this in this place on my Mac: you will find your place in a similar place - you may have to search a bit to find a subdirectory with an ugly GUID name that contains your application.
~/Library/Application Support/iPhone Simulator/5.1/Applications/4EB386B2-CD7E-4590-9757-18DDDEE6AF4F/ImageLoadingTest.app
Hope this helps. Testing, learning, and finally its description certainly helped me.