I may have missed it in the release notes, but the Xcode 7 beta 5 compiler is complaining that stringByAppendingPathComponent is not available on String (only NSString). Is this intentional or a bug I wonder?
I don't know for sure, but I think my point still holds. The fact that there's no URL-based alternative after all these years is probably a hint that referencing an image by path or URL is not recommended. The fact no error parameter was ever added supports this conclusion.
Indeed, looking at the alternate ways of creating UIImages suggests that the future of UIImage creation for UI purposes is in asset catalogs, because the file you want depends on the display resolution.
In the case where your app deals with UIImages that are not UI elements (e.g. an image editor, or a gallery viewer), the intent is likely that you should find and read the file yourself, and create the UIImage from a NSData object. (A related thing happened with old NSFileManager API that wrote raw data to files — the URL-based methods were added to NSData instead.) It's quite possible that UIImage.imageWithContentsOfFile is merely a thin wrapper around UIImage.imageWithData, and that it's future is doubtful.
I didn't say it very well.
In almost all cases, you don't need API that's specific to and limited to an existence check. You can almost always get this information as a byproduct of another file system method that you needed to use anyway. This was true of your Xcode example, because Xcode is checking for and reporting other things besides existence.
In rare cases, where you need to know existence and nothing else, then it's convenient to have a method that doesn't do anything else. But I'm not sure I can think of a plausible case. The NSURL class reference for checkResourceIsReachable:error: gives an example of a download list, where "you might remove an item from a download list if the user deletes the file". I don't find this convincing. A dynamically-updated download list is likely going to want to be notified of file size changes, at least, as download progresses.
Can you think of an example of a list of files where nothing in the list changes when the file changes, except that items disappear when their file is deleted?
In almost all cases, you don't need API that's specific to and limited to an existence check. You can almost always get this information as a byproduct of another file system method that you needed to use anyway. This was true of your Xcode example, because Xcode is checking for and reporting other things besides existence.
Like what? All that's displayed in the sidebar in my copy of Xcode is the filename (determined from the path/URL), an icon (determined from the extension, which is part of the filename; nottaken from the file itself, as you can easily verify by pasting a custom icon on a source file and seeing that that icon is not picked up in Xcode), and a text color that tells me whether or not the file exists (black if it does, red if it doesn't). That's it.
I think it's a pretty good example, TBH.
In general, I'd assume, Xcode at least needs to track the mod date of the file represented by the item, or otherwise track when the represented file was touched. I also wouldn't be surprised if Xcode tracks the UTI, and whether the file system entity is a file, symbolic link or directory, independently of what the extension implies.
(If Xcode literally doesn't need to track anything except the existence of the file represented by an item, I can't really think what the item is doing in the project at all.)
Not even close! UIImage.imageWithContentsOfFile() is critical to performance on iOS!
I'm shocked that more people don't know this.
Images take a huge amount of memory, and when you create a UIImage using the contentsOfFile method, it will remember the path where it loaded the image from. Under high memory pressure, the UIImage may release its backing store and lazily reload it from the path later.
UIImages created from URLs cannot do that, just like they don't automatically use retina variations. The NSURL APIs are much inferior to the path-based ones.
Not only that, but there are times when you want to create a path as part of constructing a URL - for example when using NSURLComponents. Continuous calls to NSURL.URLByAppendingPathComponent are just an ugly way to do it, and you'll still need to extract the path from what you get and go back to NSURLComponents later on if you wanted to work on non-path components, for example.
Working with paths and URLs is enough of a headache without this. NSURL is extremely nuanced, and often to get the data you want in the correct format (e.g. trailing slashes or not, percent encoding or not, etc) you need to drop down to CFURL-level functions such as CFURLCopyPath() or CFURLCopyFileSystemPath(). See http://lists.apple.com/archives/cocoa-dev/2012/Apr/msg00154.html. It's not always possible to do your work on the URL level before extracting the path - sometimes you really do need to extract the path first and then operate on it.
What on Earth is Apple thinking? Introducing a change like this completely under the radar is highly disrespectful towards their 3rd-party developer community.
