@DTS Engineer Thanks a lot for you suggestions. The one thing that would definitely be better is a deletingPathExtension property on String, hence my suggestion that you file an ER for that. here is the case id for above request. FB21796995 ( Add path component properties to Swift String (ex: deletingPathExtension, lastPathComponent, pathExtension))

@DTS Engineer Thank you for your detailed response and for adding comments to my bug report. I have a few follow-up questions: Thanks. I’ve added my own comments to your bug. I tried to access FB21757864 via Feedback Assistant, but I don't see any replies yet. Are internal comments visible to the reporter, or are they only accessible to Apple engineers? Ah, I’ve found myself in that very conundrum. It’s annoying that we never got a Swift equivalent of Objective-C’s -stringByDeletingPathExtension method. I think it’d be reasonable for you to file an enhancement request for that. And if you do, please post that bug number as well. I found deletingpathextension in Swift. Is this the method you were referring to ? Regardless, given your requirements I agree that prepending a slash is a reasonable option. You mentioned that prepending a slash is a reasonable option. However, since our use case involves pure string manipulation (extracting filename and extension from a server-provided filename string), would using NSString methods be the more semantically correct approach? For example: let fileName = ((fileNameWithExtension as NSString).deletingPathExtension as NSString).lastPathComponent let fileExtension = (fileNameWithExtension as NSString).pathExtension This avoids URL semantics entirely and treats the input as what it actually is—a filename string rather than a path. I'd appreciate your guidance on whether this approach is recommended over the URL-based solution.

@DTS Engineer I'd like to clarify the expected behavior for URL(fileURLWithPath:) with a tilde-prefixed filename: let url = URL(fileURLWithPath: "~TestFile.irfd") print(url.lastPathComponent) Results: iOS 18: Returns ~TestFile.irfd iOS 26: Returns 924AF0C4-C3CD-417A-9D5F-733FBB8FCF29 (app sandbox UUID) Is the iOS 26 behavior the correct/intended behavior? Was iOS 18 being lenient by not resolving ~ as the home directory? I want to understand whether this is a bug fix, a behavior change, or something that should be reported.

@DTS Engineer Our iOS app receives filenames from a server (e.g., ~TestFile.irfd). We need to extract the filename without extension for display purposes. The original code used: func getFileName(fileNameWithExtension: String) -> String { // Pure string manipulation - correct for filename handling let fileName = URL(fileURLWithPath: fileNameWithExtension).lastPathComponent return fileName } This worked on iOS 18, but broke on iOS 26 when customers started using filenames beginning with ~. We don't actually need a URL or path. We're doing pure string manipulation on a filename to extract components. We used URL(fileURLWithPath:) as a convenient way to get lastPathComponent, but that's semantically wrong for our use case. This will be right suitable approach for our case, let fileName = (fileNameWithExtension as NSString).lastPathComponent This is the right approach because: We have a filename, not a path We need string manipulation, not path resolution NSString.lastPathComponent doesn't perform path resolution Bug filed: FB21757864

Solution - Adding leading slash with new URL API: func getFileName(from fileNameWithExtension: String) -> String { let url = URL( filePath: "/" + fileNameWithExtension, directoryHint: .notDirectory, relativeTo: nil ) // Debug logging print("Input: \(fileNameWithExtension)") print("URL created: \(url)") print("URL.path: \(url.path)") print("URL.lastPathComponent: \(url.lastPathComponent)") return url.lastPathComponent } // Usage let result = getFileName(from: "~TestFile.irfd") Debug Output (iOS 26): Input: ~TestFile.irfd URL created: file:///~TestFile.irfd URL.path: /~TestFile.irfd URL.lastPathComponent: ~TestFile.irfd By prefixing with /, the filename becomes an absolute path, preventing the ~ from being interpreted as the home directory symbol. This approach: Uses the modern URL(filePath:directoryHint:relativeTo:) API (not deprecated) Works correctly on both iOS 18 and iOS 26 Follows the "valid pathname" rule you mentioned Btw, i could not find the official Apple documentation that explains this path resolution behavior for ~ and the new URL API. @DTS Engineer Thanks for suggestion. if you know about any link about functions above please, share it Thanks.