{"id":53579,"date":"2026-10-20T15:24:49","date_gmt":"2026-10-20T19:24:49","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=53579"},"modified":"2026-10-20T15:24:49","modified_gmt":"2026-10-20T19:24:49","slug":"getting-a-file-path-from-a-swift-url","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2026\/10\/20\/getting-a-file-path-from-a-swift-url\/","title":{"rendered":"Getting a File Path From a Swift URL"},"content":{"rendered":"

Seth Willits<\/a> (2024, bug<\/a>):<\/p>\n

\n

There’s a deprecation warning in Xcode for URL.path<\/code> that reads:<\/p>\n

\n

WARNING: path<\/code> will be deprecated in a future version of macOS: Use path(percentEncoded:)<\/code> instead<\/p>\n<\/blockquote>\n

The problem is something like this:<\/p>\n

Bundle.main.url(forAuxiliaryExecutable: \"tool\")!.path<\/pre>\n
… which returns the expected file path (ex: \/Applications\/MyApp.app\/Contents\/tool<\/code>)<\/p>\n
would be quickly rewritten as suggested<\/em> to:<\/p>\n
Bundle.main.url(forAuxiliaryExecutable: \"tool\")!.path(percentEncoded: false)<\/pre>\n
… which simply returns tool<\/tt>, because the URL returned is relative to a base URL.<\/p>\n
[…]<\/p>\n
I’ve always found it not-completely-obvious to newcomers how to get a standard file path string from a file URL and this only makes it more<\/em> confusing.<\/p>\n<\/blockquote>\n\n
There are at least three issues here:<\/p>\n\n
    \n\n
  1. url.path<\/code> returns an absolute path, but url.path(percentEncoded: false)<\/code> returned a relative path as of his writing. I tested this on macOS 26, and now it returns an absolute path. The documentation now says, “This function will resolve against the base URL<\/code>.” It seems the behavior of the method changed without it being documented when, so be careful if you’re deploying to a mix of OS versions.<\/p><\/li>\n\n
  2. percentEncoded<\/code> has a default value of true<\/code>, whereas path<\/code> did not return an encoded string. In other words, url.path()<\/code> and url.path<\/code> are completely different. So this is another case<\/a> where Apple updated the API but flipped the default—a good way to introduce bugs.<\/p><\/li>\n\n
  3. It’s not obvious how to get the full file system path out of a URL<\/code>. With NSURL<\/code>, url.path<\/code> was natural and did the right thing. Now, the URL<\/code> equivalent is deprecated.<\/p>\n
    The natural replacement, url.path()<\/code>, is wrong. So is Xcode’s recommendation of url.(percentEncoded: false)<\/code>.<\/p>\n
    url.absoluteURL.path(percentEncoded: false)<\/code> is correct but verbose.<\/p>\n
    url.absoluteURL.standardizedFileURL.path(percentEncoded: false)<\/code> is possibly better but even more verbose.<\/p>\n
    FilePath(url)?.string<\/code> uses a newer API but gives you an optional, even though for a file URL it should never fail.<\/p>\n
    This seems like such basic functionality, but there’s no API that’s the obvious right choice, concise, and ergonomic.<\/p>\n<\/li>\n<\/ol>\n\n
    Previously:<\/p>\n