# FCFileManager: static convenience methods over NSFileManager for iOS > FCFileManager wraps Apple's NSFileManager in a set of static Objective-C methods that default to the Documents directory, so most file operations take a relative path and a few lines of code. It is a small, MIT licensed convenience layer rather than a component library, and its only tagged release dates from 2020 while the repository was last pushed in April 2026. **fabiocaccamo/FCFileManager** — :iphone: :open_file_folder:  iOS file manager on top of NSFileManager for simplifying files management. - Repository: https://github.com/fabiocaccamo/FCFileManager - Stars: 905 · Forks: 134 - Language: Objective-C - License: MIT - Published: 2026-10-20 · Updated: 2026-10-20 · Language: en - Canonical page: https://hysenlabs.com/projects/fabiocaccamo-fcfilemanager ## A thin layer of static methods, not a component library FCFileManager is described in one line as an iOS file manager on top of NSFileManager for simplifying files management, and the point of it is stated immediately after: it provides many static methods for executing most common operations with few lines of code. That is the whole product. There is no view, no delegate protocol, no observable model, no background queue. The repository listing is correspondingly small, with a .github directory, a .gitignore, the FCFileManager.podspec, an FCFileManager source directory, the LICENSE and the README. Two source files are what the manual installation instructions ask you to copy into your project, FCFileManager.h and FCFileManager.m. The stated requirements are iOS 5.0 or later with ARC enabled. The ARC requirement is worth noting, because a static method library written for ARC will not drop into a project that still has manual retain and release in the same target without care. So the audience is narrow and specific: an iOS team that writes Objective-C, does a lot of file work, and wants the boilerplate of building absolute paths and checking existence out of every call site. If your application is in Swift, this library is not aimed at you, and the documentation does not mention a Swift wrapper. It is also the kind of dependency that disappears into the codebase. Once installed, nobody thinks about it again, which is both the point and the risk: the value is a slightly shorter line of code, and the cost of the dependency is a permanent one to replace later. ## Relative paths are the design decision, and they are relative to Documents The one behaviour that distinguishes this library from calling NSFileManager directly is the path handling, and it is worth being precise about. By default the library works in the Documents directory, so a relative path resolves there. The documentation is explicit that you must build absolute paths only if you need to work outside of the Documents directory. That is a deliberate trade: the common case, which is a document or a cache the application owns, gets a short call, and the uncommon case, which is a shared container or a bundle resource, needs an explicit path builder. The path helpers cover the standard iOS locations. The README lists the shortcuts as pathForApplicationSupportDirectory, pathForCachesDirectory, pathForDocumentsDirectory, pathForLibraryDirectory, pathForMainBundleDirectory, pathForPlistNamed which looks for a plist with that name in the main bundle, and pathForTemporaryDirectory. A typical call looks like this, with the first path relative and therefore resolved against Documents, and the second built explicitly against the temporary directory: ```objc NSString *testPath = @"test.txt"; NSString *testPathTemp = [FCFileManager pathForTemporaryDirectoryWithPath:testPath]; ``` Note the security implication of the default. The Documents directory is user visible through the Files application, so anything written there by default can be seen and deleted by the person using the app, and it counts against the app's backup allowance. The library does not warn about this anywhere in its documentation, so a developer who assumes the default is a private scratch area will be wrong. ## The API surface is one call per operation The documentation gives a usage example for each operation, and reading them together is the fastest way to understand the conventions. Every call is a class method with the FCFileManager prefix, and the ones that can fail return a BOOL or nil. Copying moves an item from the Documents directory into Application Support, with the destination built explicitly: ```objc NSString *testPath = [FCFileManager pathForApplicationSupportDirectoryWithPath:@"test-copy.txt"]; [FCFileManager copyItemAtPath:@"test.txt" toPath:testPath]; ``` Creating a file writes content in the same call, and the documentation describes it as creating the file and writing content to it if it does not exist. Creating directories takes a path ending in a slash and creates the whole tree, since the feature list says directories are created on the fly: ```objc [FCFileManager createDirectoriesForPath:@"/a/b/c/d/"]; ``` Existence is a BOOL, moving returns a BOOL, removing and renaming take a path and a new name: ```objc BOOL testFileExists = [FCFileManager existsItemAtPath:@"test.txt"]; [FCFileManager moveItemAtPath:@"test.txt" toPath:@"tests/test.txt"]; [FCFileManager removeItemAtPath:@"test.txt"]; [FCFileManager renameItemAtPath:@"test.txt" withName:@"test-renamed.txt"]; ``` Reading and writing are type specific. The feature list names arrays, custom models, data, dictionaries, images, json and strings as the content formats, and the example writes an array of strings: ```objc NSArray *testContent = [NSArray arrayWithObjects:@"t", @"e", @"s", @"t", nil]; [FCFileManager writeFileAtPath:@"test.txt" content:testContent]; ``` Error handling is described as using NSFileManager, which is the least specified part of the documentation and the one to check in the header before you rely on it. ## Extended attributes and EXIF are the features worth the integration Two capabilities go beyond what a plain NSFileManager wrapper would give you, and they are the reason to pick this library over a dozen lines of your own. The first is extended attribute access. The documentation describes reading a string value stored for a specified key, returning nil if the key does not exist, and setting a value with a BOOL result: ```objc NSString *value = [FCFileManager xattrOfItemAtPath:@"test.txt" getValueForKey:"uploaded"]; BOOL success = [FCFileManager xattrOfItemAtPath:@"test.txt" setValue:@"1" forKey:@"uploaded"]; ``` Extended attributes are the standard way to attach out-of-band metadata to a file, and on iOS they are how you mark a file as downloaded, as excluded from a backup, or as already processed by a sync job, without a sidecar database. Doing that through the raw Foundation API means dropping down into the xattr C functions and handling the raw byte buffer yourself, so a string valued helper is a genuine saving. The second is image metadata. The documentation lists reading image metadata, EXIF data and TIFF data as features, with a call that returns a dictionary: ```objc NSDictionary *exifData = [FCFileManager exifDataOfImageAtPath:@"test.jpg"]; ``` For a photo library app or anything that writes images with orientation and camera data, that saves pulling in an image parsing dependency. The size helpers are the third piece worth noting, in both byte and formatted form, with the formatted variant producing a human readable string with the appropriate suffix: ```objc NSNumber *directorySize = [FCFileManager sizeOfDirectoryAtPath:@"/a/"]; NSString *fileSizeFormatted = [FCFileManager sizeFormattedOfFileAtPath:@"test.txt"]; ``` The directory size is described as including all subdirectories and files inside it, which is a recursive walk and therefore the kind of call that is slow on a large tree. ## Installing it is a podspec or two copied files There is no configuration, no build phase and no dependency to resolve. The CocoaPods route is a single line in a Podfile: ```ruby pod 'FCFileManager' ``` The manual route is to copy FCFileManager.h and FCFileManager.m into your project. There is a FCFileManager.podspec in the repository root, and the README links the full list of methods in the header file, so the API reference is the header rather than a separate documentation site. The repository is organised around a single author, and the README carries a donation link to that author's open source projects. The repository also has a .github directory, so the automation and issue templates live there rather than in the root. The maintenance record is where an adopter has to look carefully, and it is mixed. The most recent release listed is 1.0.20, dated 2020-08-05, and the README badge points at the CocoaPods version. The last push to the repository was on 2026-04-22, and the repository is not archived. So there is more recent activity than the release tag suggests, but the published version history is thin, and a CocoaPods consumer is consuming whatever the pod index points at, which the repository does not describe. For a library of this size that is defensible. The risk is not that the code breaks, it is that a maintenance expectation forms around a component nobody has committed to sustaining, and a future iOS change removes a method the application quietly depends on. ## Where the wrapper stops and the platform resumes The boundary of this library is set by what it does not wrap, and the omission is large. There is nothing about background transfers. A file that needs to be written while the application is suspended is a job for NSURLSession, and no method here schedules one. There is nothing about document coordination, the mechanism iOS provides so that two processes editing the same file in a shared container do not overwrite each other, and there is nothing about ubiquity containers or iCloud Drive, so the library is a local filesystem helper and cannot be made to sync by configuration. There is nothing about file protection levels, the attribute that controls whether a file is readable when the device is locked, and nothing about excluding a file from backups. The extended attribute support could carry such a marker in principle, but the documented use of it is a general key and value store rather than a specific exclusion mechanism. There is also no asynchrony and no completion handlers anywhere in the documented surface. The size of a directory, which walks the tree, runs synchronously on the calling thread. On a large directory that is a visible stall, and the library offers no documented way to move it off the main queue. The honest comparison is with writing the same twenty lines of NSFileManager code yourself. The library saves the path building and the existence checks, and it adds the xattr and EXIF helpers. If your application is mostly reading and writing its own documents, the trade may not be worth a dependency. If it moves files, reads image metadata and marks progress in extended attributes, the saving is larger. And if you need any of the platform features listed above, you will be writing platform code anyway, with the library only covering the easy half. ## Conclusion FCFileManager suits an iOS codebase written in Objective-C that performs repeated file operations and wants shorter call sites without adopting a whole file management component, and the MIT licence lets you vendor the two source files directly. It is the wrong choice for a Swift-only project, since the library is Objective-C with no Swift interface, and it is the wrong choice for a team that needs background transfers, document coordination or sandbox groups, none of which the documented feature set covers. Before adopting it, check that FCFileManager.h still builds against the iOS version you target, because the stated requirement is iOS 5.0 and the newest tagged release is 1.0.20 from 2020, and confirm whether the CocoaPods pod has moved past the version you can see in the repository. ## FAQ ### What is FCFileManager and what does it add to NSFileManager? It is an Objective-C library that exposes static methods wrapping NSFileManager for common file operations, so copy, create, move, read, write, rename, remove and size calls take a few lines. It also adds extended attribute access, EXIF and TIFF metadata reading, and formatted size strings. ### How do I install FCFileManager in an iOS project? Through CocoaPods with pod 'FCFileManager', or manually by copying FCFileManager.h and FCFileManager.m into your project. The stated requirements are iOS 5.0 or later with ARC enabled. ### Which directory do relative paths point to in FCFileManager? Relative paths resolve against the Documents directory by default, and the documentation notes that absolute paths are only needed when working outside that directory. Helpers exist for the Application Support, Caches, Library, main bundle and temporary directories, plus one that looks up a plist in the main bundle. ### Can FCFileManager read and write extended file attributes? Yes. The documentation gives a call that returns the string value stored for a key, returning nil when the key does not exist, and a call that sets a value and returns a BOOL result of the operation. ### Is FCFileManager still being maintained? The repository is not archived and the last push was on 2026-04-22, but the most recent release listed is 1.0.20 from 2020-08-05. The README points to the CocoaPods badge for the current published version, and the licence is MIT. ## Sources - [fabiocaccamo/FCFileManager on GitHub](https://github.com/fabiocaccamo/FCFileManager) - [Issues](https://github.com/fabiocaccamo/FCFileManager/issues) - [License: MIT](https://github.com/fabiocaccamo/FCFileManager/blob/master/LICENSE) - [README](https://github.com/fabiocaccamo/FCFileManager/blob/master/README.md) - [Releases](https://github.com/fabiocaccamo/FCFileManager/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/fabiocaccamo-fcfilemanager