I was editing a Markdown text file in Pretext yesterday, when it occurred to me how naturally I was able to create a document and upload it to GitHub without dealing with the limitations and workarounds that used to be commonplace in older versions of iOS. Here’s a brief account of what happened.

Here at MacStories, we use Working Copy – a powerful GitHub client for iOS – to edit Markdown text files in a collaborative environment. This is probably not what GitHub was designed for, but it works well in Working Copy thanks to the app’s built-in diff tool and versioning system, both of which are ideal for writers and editors.¹

With iOS 11, Working Copy gained a file provider extension that turned it into a native location in the Files app. Instead of opening the Working Copy app, you can see all your repositories and documents as regular files and folders within Apple’s standard Files UI. For months, this has allowed us to drop new text files and images directly into Files, where it’s easier to aggregate documents coming from different apps or saved through the native Files extension on iOS.

A few days ago, Anders Borum, developer of Working Copy, went a step further and shipped an update with the ability to commit and push changes (in GitHub’s parlance, save and upload modified documents) directly from the app’s extension in Files. This is done by invoking the Working Copy extension from a button in the contextual menu of a selected item (i.e. the copy & paste menu) instead of opening the share sheet.

The ‘Commit’ button is a new extension point in iOS 11.

As I detailed in my review of iOS 11, this is one of the extension points available to developers of apps that integrate with Files and its document browser. You may have seen a similar implementation in the Dropbox file provider, which lets you copy shareable links just by long-pressing an item and hitting ‘Copy Link’. Saving and uploading documents from the Working Copy file provider brings up the app’s share extension as a modal controller displayed on top of the document browser.

Also new in iOS 11, document-based apps can eschew a proprietary file manager view and simply use an embedded Files browser as the main screen of the app. We’ve seen this feature adopted in apps such as MindNode 5, PDF Viewer, Textor, and Pretext. When you open apps that use iOS 11’s native document browser, you’re effectively dealing with the Files app, which has become a pervasive layer that is shared between apps. This includes third-party file provider extensions: services like Dropbox (or in this case, Working Copy) are treated as standard locations with the same UI of iCloud Drive and the same logical structure. As I wrote last year, the big advantage of this approach is that instead of building custom integrations for each cloud service, an iOS 11 app that uses the built-in document browser can support any third-party service as long as it integrates with Files.

Here’s where things get really interesting from a file management perspective compared to what iOS used to be. Yesterday, I needed to create a Markdown file to upload to the Club MacStories repo I sync with Working Copy. I opened Pretext² and navigated to the folder in Working Copy’s location in Files. The document browser is the same view I get in the Files app, so my favorite folders in the sidebar are the same as well.

Pretext uses iOS 11’s document browser as its root view, giving it the ability to create new files in any location.

I then created a text file, pasted what I needed to upload, and closed Pretext’s text editor. I was back in the document browser. Finally, to upload my document, I long-pressed it, selected ‘Commit’, and pushed the file using the Working Copy extension. This was done in 30 seconds without jumping between multiple apps, duplicating the same document elsewhere, or relying on advanced workflows. It was all possible thanks to iOS 11’s changes to file management and the extensibility framework for third-party apps.

Uploading an edited file to GitHub from the Files view in Pretext.

There are a few things worth appreciating with this example, as well as features of the Files API that Apple should improve going forward.

Notably, while some Mac users may scoff at my delight in iOS 11’s document browser and third-party storage locations, I think it’s remarkable how what I described above can be accomplished just by installing apps and extending the system without questionable installers or system modifications. Yes, I could probably save time by performing the same actions with a shell script on macOS, but I prefer having an intuitive GUI and a file manager that can be extended just by downloading new apps from the App Store. While not perfect, the document browser and file provider extensions are some of the most exciting changes in iOS 11 with a lot of untapped potential because they are deeply integrated with the system and consistent with iCloud Drive.

Which is why I’d like Apple to improve some aspects of this workflow: it’d be great, for instance, if Working Copy could show colored indicators for documents that haven’t been committed in the document browser, or perhaps offer a button to refresh the contents of a repository and update its contents inline within the Files view. Similar features are available in the Mac’s Finder; Apple should continue to borrow from it as they work on what’s next for Files.

Despite some initial issues, I’ve realized that my usage of the Files app is growing and I’m now seeking apps that take advantage of the document browser. Pretext and Working Copy are fantastic demonstrations of iOS 11’s file management improvements; I hope to find more in the near future.