CFURL opaque type provides facilities for creating, parsing, and dereferencing URL strings.
CFURL is useful to applications that need to use URLs to access resources, including local files.
CFURL object is composed of two parts—a base URL, which can be
NULL, and a string that is resolved relative to the base URL. A
CFURL object whose string is fully resolved without a base URL is considered absolute; all others are considered relative.
CFURL is “toll-free bridged” with its Cocoa Foundation counterpart,
NSURL. This means that the Core Foundation type is interchangeable in function or method calls with the bridged Foundation object. In other words, in a method where you see an
NSURL * parameter, you can pass in a
CFURLRef, and in a function where you see a
CFURLRef parameter, you can pass in an
NSURL instance. This also applies to concrete subclasses of
NSURL. See Toll-Free Bridged Types for more information on toll-free bridging.
Starting in OS X v10.6, the
CFURL opaque type provides a facility for creating and using bookmarks. A bookmark provides a persistent reference to a file-system resource. When you resolve a bookmark, you obtain a URL to the resource’s current location. A bookmark’s association with a file-system resource (typically a file or folder) usually continues to work if the user moves or renames the resource, or if the user relaunches your app or restarts the system.
In a macOS app that adopts App Sandbox, to gain persistent access to a file-system resource you must use a security-scoped bookmark. Such a bookmark preserves, across app launches, a user’s intent to give your app access to a resource. For details on how this works, including information on the entitlements you need in your Xcode project, read Security-Scoped Bookmarks and Persistent Resource Access in App Sandbox Design Guide.
When you resolve a security-scoped bookmark, you get a security-scoped URL. The file system resource that the URL points to is not available for use inside your app’s sandbox until you call the
CFURLStartAccessingSecurityScopedResource(_:) function (or its Cocoa equivalent, the
startAccessingSecurityScopedResource() method) on the URL.
When you no longer need access to a resource that you obtained using security scope (typically, after you close the resource) you must call the
CFURLStopAccessingSecurityScopedResource(_:) method (or its Cocoa equivalent, the
stopAccessingSecurityScopedResource() method) on the resource’s URL.
The functions for using security-scoped bookmarks are described in this document in Working with Bookmark Data. For a general introduction to using bookmarks in macOS, read Locating Files Using Bookmarks in File System Programming Guide.
When you copy a security-scoped URL (as obtained from a security-scoped bookmark), the copy has the security scope of the original. You gain access to the file-system resource (that the URL points to) just as you would with the original URL: by calling the
CFURLStartAccessingSecurityScopedResource(_:) function (or its Cocoa equivalent).
If you need a security-scoped URL’s path as a string value (as provided by the
CFURLGetString(_:) function), such as to provide to an API that requires a string value, obtain the path from the URL as needed. Note, however, that a string-based path obtained from a security-scoped URL does not have security scope and you cannot use that string to obtain access a security-scoped resource.
CFURL fails to create an object if the string passed is not well-formed (that is, if it does not comply with RFC 2396). Examples of cases that will not succeed are strings containing space characters and high-bit characters. If a function fails to create a
CFURL object, it returns
NULL, which you must be prepared to handle. If you create
CFURL objects using file system paths, you should use the
CFURLCreateFromFileSystemRepresentationRelativeToBase(_:_:_:_:_:) functions, which handle the subtle differences between URL paths and file system paths.
For functions that read and write data from a URL, see Core Foundation URL Access Utilities