You should probably use asset catalogs as what Apple wants to use in the future (tools reflect this), and they bring many benefits:
Application Thinning
Setting asset properties without code, for example, rendering mode or slicing
You do not need to remember naming conventions such as @2x , ~ipad , -568 , etc., to automatically receive device attributes
Asset catalogs will indicate missing assets if you check the correct fields for supported versions and devices and provide a good overview.
You should get used to them, as some platforms (e.g. watchOS) require the use of asset directories.
There are a few caveats:
If you return to iOS 6, some functions do not work as expected - asset directories still help organize your assets, but the runtime functions will not work, because Xcode will simply delete the regular image files in your package.
If you upgrade to iOS 7 or later, Xcode will compile all assets into a single .car file (which is the whole idea). However, it can be harder to debug, because you cannot look into the compiled file, which also means that you cannot just get the file URL from one asset. To create a file URL, you always need to download the asset (by its name) and first write it to disk. *
The last point also implies that you cannot use the NSBundle API (in Swift 3.0: Bundle ) to retrieve URLs or paths to image files. To rely on assets from a package other than the main package, you rely on Apple to provide the API that they run with iOS 8.0 . If you organize common code in resource sets and deploy it on iOS 7 or earlier, you should not use asset directories. This is probably mostly true if you intend to develop a framework.
* For example, the CoreSpotlight API allows you to set thumbnailURL , but if your image is in the asset directory, you must either write it to disk yourself or use the thumbnailData property. If you had the URL of the file, you would never have to load it into memory. I'm not sure if Spotlight can access file urls from your application suite. This is just an example.