File Providers

The discussion around file management on iPad wouldn’t be complete without an examination of third-party file providers and how they integrate with the Files app. Since I started using the Files app in iOS 11, and following my steady embrace of iCloud Drive as my preferred cloud storage service, I’ve settled on using a handful of file providers on a regular basis in addition to Working Copy, and I think it’d be useful to offer concrete examples of what they can do in iOS 12.

Let’s start with an obvious misconception. File providers are not cloud integrations that you set up in the Files app; they are extensions enabled by third-party apps that you have installed on your iOS device, and which may or may not communicate with a cloud service behind the scenes. That is to say, file providers are not limited to Dropbox, Google Drive, and OneDrive; any app that manages documents on your device can offer a file provider extension, even if it just manages a library of local documents that do not sync with any cloud service.

A good example of this is iCab, a third-party web browser that, among its (many) features, offers a proper desktop-like download manager, unlike Apple’s Safari. Ever since I acquired a high-res music player earlier this year (a Sony Walkman), I’ve increasingly found myself wanting to download albums in the lossless FLAC format from websites such as 7Digital, HDtracks, and Onkyo Music. A FLAC album can vary in weight depending on bit depth (24-bit files are larger) and the number of songs contained in an album; let’s say that, on average, I download files in the 500 MB to 1.5 GB range – and when I do, it’s usually because I bought multiple albums together in a single purchase.

Now, on a Mac this wouldn’t be a problem: I would click on the ‘Download’ button for each album, and multiple .zip files would be added to the browser’s download manager queue, which is a popup that lets me monitor the progress of each download and reveal it in the Finder too. Safari for iOS has no such concept of a download manager: you can tap on links that point to a downloadable file such as a .zip archive or .mp3 song, but Safari will always try to render that content in a tab without adding it to a download queue.

Safari shows no actual download progress (there’s just a thin blue bar in the address bar, but it doesn’t show download size or speed) and it forces you to decide where to save a file after it’s been “downloaded” because Safari doesn’t have its own location to store downloaded items in Files. Worst of all, if the file you want to download is a content type that Safari can preview inline, such as MP3s or MP4 videos, you’ll have no way to tell the app “do not preview this, but download it instead”. Effectively, Safari for iOS has no dedicated download feature, which, frankly, is appalling in 2019.

iCab, on the other hand, does everything right: when you tap a link to a downloadable file, it gets added to a separate download manager window, which supports simultaneous downloads; the download manager displays file sizes, source URLs, and progress; when they’re complete, downloaded files are automatically saved locally in the iCab file provider that you access from the Files app.

Items downloaded with iCab’s download manager show up in its file provider.

iCab’s approach to web downloads is the right mix of a traditional feature (a desktop-like download manager) accessed from a modern environment (a file provider). These days, whenever I have to download music albums or any other file from a webpage⁵, I open iCab, queue downloads and wait for them to finish, then move them elsewhere from the iCab Mobile location in Files using drag and drop. In the future, doing all of this shouldn’t require me to use a third-party web browser: Apple should copy this approach with Safari in iOS 13.

Speaking of local documents, one of the limitations of iOS file management I frequently hear from readers who would like to use an iPad more is the fact that you cannot easily manage local documents on iOS devices. Sometimes you just want to save something locally without having it upload to a cloud service; or maybe you have limited storage available in your iCloud Drive account and you can only save files locally. iCloud Drive is, by and large, the most prominent location of the Files app and Apple promotes it heavily, but it is possible to avoid using iCloud Drive thanks to the ‘On My iPad’ file provider that is installed by default for everyone – with a catch.

The ‘On My iPad’ file provider (called, well, ‘On My iPhone’ on iPhones) aggregates folders of apps that store documents locally without iCloud Drive.⁶ If you open the ‘On My iPad’ location in the Files app, you’ll likely be presented with something that looks a little like this:

Those folders contain documents of apps that have opted to store their data locally rather than relying on iCloud Drive. So far so good. The problem is that most people are under the impression that they can also drop any file in the root view of the ‘On My iPad’ location to store it locally in a safe location, but that’s not the case: you cannot create new folders in the ‘On My iPad’ location, nor can you import any arbitrary file into it via drag and drop. The ‘On My iPad’ file provider is limited to aggregating folders of apps that store documents locally. Hence why a lot of folks complain about the fact that it’s impossible to manage documents locally on an iPad like it is with the Finder on macOS.

You cannot create new folders in the ‘On My iPad’ file provider.

The workaround I’ve found for this limitation is playing by Apple’s rules and using a third-party app that shows a folder in the ‘On My iPad’ screen, and which acts as a dumb container for all kinds of documents that you can throw in it. The app is called Local Storage and, again, it is not a file provider per se, but an app that creates a folder in the ‘On My iPad’ file provider location.

You can drop any kind of file in the Local Storage folder, and even create sub-folders inside it, and they’ll be saved locally on-device as part of Local Storage’s documents library. To make the process easier, I’ve added the Local Storage folder to my Files favorites, so it kind of looks like Files has native support for local files now.

Different file types I dropped into the Local Storage folder.

Local Storage does more than simply turn the ‘On My iPad’ file provider into what it was meant to be, though. In the main Local Storage app, you’ll find an overview of the local files you have on your device with three different ways to visualize them:

• In the Overview tab, the app will give you a summary of the total number of files stored in the Local Storage folder, along with their size and available disk space;
• In the Types screen, you’ll get a breakdown of your files by category (audio, videos, images, etc.), which is represented with a colored bar chart and individual categories you can tap to inspect individual files;
• Finally, the Files view shows you a visualization of local files sorted by size and structure using a treemap, which is typical of disk analyzer utilities for desktop PCs. I have no particular use for this screen, but it looks cool.

Visualizing local files in the Local Storage app.

I’ve been using the Local Storage folder for throwaway files I don’t need to save in iCloud Drive, and it works well for that purpose. As I mentioned above, however, none of this should be necessary: the ‘On My iPad’ location of Files should be an actual file provider where you can save any file you want regardless of app folders. I hope Apple rectifies this with iOS 13; especially for professional users who deal with large assets that they don’t want to sync with an online service, having reliable, built-in local file management is paramount to a productive iPad experience.

Sometimes I need to access files on a local network. I have a Mac mini that’s always on and acting as a home media server, and I frequently have to access files in its Desktop or Downloads folders to move them elsewhere.⁷ This is another area where the iPad’s Files app is lacking because Apple hasn’t provided built-in features to connect to external servers from their file manager (something that, unsurprisingly, has long been possible with Finder). This omission has left the door open for third-party developers to provide functionality absent from Files; as I noted in February, FileExplorer is currently the best option to bring (S)FTP, SMB, NAS, and other types of server connections into the Files app with a file provider extension.

FileExplorer is a third-party file manager that reinvented itself after the introduction of Files in iOS 11 as an advanced file manager that does things Files cannot. The only reason I use it is its ability to make external servers available in Files with a couple of taps. Unlike other apps that have attempted this before (see FileBrowser), FileExplorer’s file provider extension can connect to servers independently from the main app; even if the FileExplorer app hasn’t been opened or has been force quit, its file provider will be able to connect to a server and let you browse its contents from the Files app.

External servers made available by FileExplorer in the Files app.

The contents of my Mac’s desktop, accessible from the iPad’s Files app thanks to FileExplorer.

The only downside of FileExplorer’s approach is that you can’t add a new server from the file provider itself – you’ll have to configure connections in the FileExplorer app first. In my case, I’ve added multiple shortcuts to connect to different folders of my Mac, both locally and remotely, as well as connections for my wireless Western Digital hard drive, and now I can connect to them instantly from the Files app and any other instance of Files (including file pickers and the document browser).

If I’m using Slack on my iPad and need to attach a file I left in my Mac mini’s Downloads folder, all I need to do is bring up the Files picker, connect via the FileExplorer file provider to the ‘Mac mini Downloads’ connection, and tap the file I want to import; similarly, should I want to copy high-res albums downloaded with iCab on the iPad to the Samsung T5 external drive connected to my Mac mini, I can pick up the .zip files with drag and drop in iCab’s file provider, connect to the /Volumes/T5 connection in the FileExplorer file provider (while I’m still holding the files), and drop them to initiate the copy operation.

Dragging a file downloaded with iCab on my iPad to the external SSD plugged into my Mac mini through a file provider extension in the Files app. No big deal.

As I argued a few months ago, FileExplorer’s file provider has bridged the gap between the Mac’s filesystem and the iPad’s Files app for me, allowing me to browse and transfer files from and to the Mac mini through the iOS file manager I’m already using every day. In my experience, FileExplorer’s file provider has been one of the most reliable I’ve ever tested – for all kinds of different server connections – and it never ran into the ‘Content Unavailable’ messages or authentication issues that I noted about FileBrowser last year. FileExplorer is one of the must-have tools in my arsenal right now, but its functionality should really be a native option of the Files app, matching what the Finder is already capable of doing with its ‘Connect to Server…’ menu.

I saved the most popular file provider for last because it also turned out to be the most problematic and bug-ridden over the past couple of years.

Dropbox has offered a file provider extension for a while now, and, in theory, it fulfills the original promise of the Files app: in a centralized location you can access all your documents, including those from non-Apple cloud services, using the same UI and tools available for iCloud Drive. For the most part, the Dropbox file provider lives up to this vision: I can browse folders and preview files from my account; I can see which folders are shared (though not which people they’re shared with); I can even generate shareable links from Files thanks to Dropbox’s custom additions to the copy and paste menu. I use the Dropbox file provider regularly to copy individual files into other apps, and it works sufficiently well for this kind of basic workflow.

The problem with Dropbox’s file provider is that it’s based on a poor implementation of the Files APIs, which in return make it extremely buggy when paired with apps that want to open files from and save edited versions back to Dropbox. As outlined by the PDF Viewer team, for instance, the Dropbox file provider is their #1 cause of poor reviews on the App Store because customers believe that PDF Viewer creating corrupted versions of documents or outright losing them is the developers’ fault. In reality, PDF Viewer simply abandoned their custom file manager and in-house Dropbox sync in favor of Apple’s document browser and third-party file providers, but as a result they have no control over the reliability of the Dropbox file provider extension.

If Dropbox does a poor job at supporting file coordination and presentation, their mistakes have ripple effects that trickle down to all iOS apps that have chosen to rely on Files, causing the perception in customers that it’s those apps that accidentally deleted their files and edits. This creates the absurd situation where apps like PDF Viewer or MindNode get punished for being good platform citizens and supporting a modern Apple API instead of rolling their own proprietary sync solutions.

After having experienced a few of these issues myself, and after hearing enough stories about the Dropbox file provider eating edits to files opened with the Files document browser, I decided to stop even trying to use it for important work-related documents. This also played into my decision to embrace iCloud Drive for sensitive work files that I want to access and modify from my iPad; for other Dropbox shared folders that I can’t move to iCloud Drive (because Apple’s service still doesn’t support folder-based collaboration), I use the regular Dropbox app for iOS. Ideally, I should be able to access everything from the centralized location in the Files app, but I don’t trust the Dropbox file provider to do a reliable job syncing edits at this stage.

Thanks to file providers, apps can work with any storage service without writing custom code for it and without having to build their own standalone file managers that behave differently from Files. In my everyday usage of the iPad Pro, I’ve greatly benefitted from the fact that Files and third-party providers can be available in every iOS app that integrates with the Files framework. I strongly believe that the idea of unifying different file sources in one location is a good move – because that’s exactly what the Mac has been doing for decades now.

In trying to reinvent the wheel of iOS file management for years, Apple has eventually landed in a place that’s eerily similar to the Mac. And that’s okay, I think: in this process of realizing that file management as a system-wide layer isn’t such a bad idea after all, Apple has been able to build a more secure, intuitive structure that abides by iOS’ sandboxing model and integrates well with apps. Some things do not necessarily have to be reinvented; maybe, however, they can be modernized and made more secure, which is what Apple’s trying to do with Files and file providers.

Apple is on the right path, but, particularly with third-party file providers and cloud services, there’s more they could do to enforce the creation of solid experiences that implement modern APIs well and do not sacrifice reliability for convenience, as is the case with Dropbox. I don’t know what the solution could be; perhaps stricter guidelines and code verification, combined with simpler APIs, more documentation, and more open-source examples for developers could be a good starting point. In an ideal state, Dropbox and other cloud storage companies should offer the same reliability and performance of iCloud Drive; I hope to see this kind of message at WWDC next month.