I’ve been catching up with Matt Gemmell’s series of articles about his experiences of going iPad-only. Like Matt, I also use an iPad to manage a site that uses Jekyll, a popular Ruby static site generator. My approach is somewhat different, though the outcome is the same; I can fully update, develop, and maintain my website from the comfort of my iPad.

Continuous deployment with Netlify and GitLab

This site is hosted with Netlify, a service that specializes in static site generators. The beauty of Netlify is that there’s no server to maintain, no software to install, and no files to upload. As long as you’re using a Git repository (that’s hosted with a supported provider) and a supported static site generator, Netlify keeps your site up-to-date automatically.

Netlify uses continuous deployment to monitor the master branch of my site’s repository, which I host with GitLab. Whenever I commit and push changes (e.g., publish a new blog post), Netlify rebuilds the site with Jekyll and deploys it automatically.

Using Git on iOS

I interact with my Git repositories on my iPad using Working Copy, one of my favorite iOS apps. It provides a complete Git experience and allows me to work on my site and commit any changes I make. After writing a new blog post and saving it to the repository, I publish it by committing the changes and pushing them to GitLab.

Working Copy

Publishing new posts

Most of my blog posts are written using 1Writer, after which they’re saved to the repository using Workflow. If there are any images within a post, I first upload them to Amazon S3 using Transmit and update the image links1. Once I’m ready to publish, I use this workflow to complete the process, which performing the following steps:

  1. Gets the name of the text file passed to Workflow (this is used as the post’s title)
  2. Generates a correctly-formatted URL slug using the title, replacing spaces and special characters with dashes, and presents it in an input field for optional editing
  3. Gets the current date and time to use as the published date for the post
  4. Creates the necessary front matter for Jekyll
  5. Creates a text file, formatted for Jekyll, with the appropriate filename

The result of the workflow is a Jekyll-formatted text file for the blog post. For instance, a blog post with the filename Lorem Ipsum.txt is converted to 2017-04-10-lorem-ipsum.txt and contains:

---
title: "Lorem Ipsum"
date: 2017-04-10 12:20
---
Lorem ipsum dolor...

I save this to the _posts directory of the repository in Working Copy, then commit and push the changes. Netlify automatically detects the changes and rebuilds the site.

Previewing changes

For convenience, I tend to just work on the master branch when creating new blog posts. If I were making more substantial changes, or I want to preview the blog post on the site but not actually publish it, I create a new branch in Working Copy and work from that.

Netlify includes a really useful feature, available on Pro / Open Source plans, that auto-builds any remote branch with a temporary URL. I can then review a change or blog post looks on the site without having to publish it first. This is also useful to share draft posts without needing to publish them first. Once I’m happy with the results, I merge the branch into master.

Netlify's ability to create temporary URLs for branches is awesome.

Site changes and development

Jekyll includes a built-in development server to run locally while working on changes to the site’s structure, templates, or style. Since it isn’t possible to run Jekyll locally on iOS, I make use of a $5/month Ubuntu 16.04 instance, hosted at Digital Ocean, that I remotely access and work from (a server that was set up from my iPad). It has a standard (though locked down) install of Ubuntu 16.04, with Git and Jekyll installed. This is just a testing server I like to have around. It’s not hosting anything, nor is it doing anything important.

Using Coda, I remotely log in using SSH, run git pull so the repository is up to date, then start an instance of Jekyll using:

bundle exec jekyll server --host=MY_SERVER_IP_ADDRESS --limit_posts 10

This allows me to access the site at http://server-ip-address:4000 and work on it from my iPad. I include the limit_posts switch with a low number to reduce the amount of time it takes for Jekyll to regenerate when changes are made. I use Coda to edit the remote files on the server, previewing the changes as I save them–just as I would have done on my Mac.

Coda 2

Once I’m done, I commit the changes on the server and push them to GitLab. Again, Netlify picks up the changes and then rebuilds the site automatically. If I’m working from another branch, I’ll merge the changes to master once everything looks good.

Not only does this entire process allow me to completely manage my site from my iPad, it’s easily replicated on any of my other iOS devices. All of the apps I’ve mentioned are universal, so I can just as easily perform updates or publish new posts from my iPhone. Workflow and Coda are kept in sync using their respective sync services, and my Git repositories are constantly up-to-date via GitLab.

Making changes to my site was one of the only reasons I had for returning to my Mac. Not only is this no longer necessary, but I find using my iPad for this task quicker, easier to maintain, and just a far more enjoyable experience.

  1. There’s no reason images can’t be added to the repository. I’ve just been hosting images on S3 for a while now so it’s a habit I’ve stuck to. I plan to eventually change this so everything is hosted within the repository.