My Heroic and Lazy Stand Against IFTTT

Maciej Ceglowski writes about the breaking up of IFTTT and Pinboard:

Imagine if your sewer pipe started demanding that you make major changes in your diet.Now imagine that it got a lawyer and started asking you to sign things.You would feel surprised.This is the position I find myself in today with IFTTT, a form of Internet plumbing that has been connecting peaceably to my backend for the past five years, but which has recently started sending scary emails.

I’ve been following this on Twitter for the last few days1 and it really seems to be a dick move by IFTTT. Once a small, scrappy web service–it’s increasing popularity seems to have given it a misguided belief that it can now dictate terms to developers.

Terms, as Ceglowski points out, that appear to be grossly unfair.

Update: IFTTT have published a statement (which was also emailed to all of their users with the Pinboard channel activated) explaining that they’ll be continuing support for Pinboard and updating their Terms of Service for developers for the better.

  1. If you’re not following @pinboard, you really should be. 


Finally, iOS Can Finally Perform a Software Update Before Restoring From Backup, Finally

@seanmbrage (via Bradley Chambers) posted a tweet with a photo that shows an iPhone performing a software update, apparently during the backup restore process.

Finally. My guess is that this feature was added 9.2.1, since the device in the photo is updating to iOS 9.3.


Textastic 6 for iOS

My preferred (and, arguably, the best) code editor on iOS, Textastic 6 recently shipped and is now a universal app for iPad and iPhone, including iPad Pro and 3D Touch support. It’s been indispensable for me as I continue to manage and deploy my site with git and Working Copy, thanks to the both apps providing exceptional support for the iOS Document Picker and Document Provider1. I can directly open, edit and save files from either my iPad or iPhone’s local git repository in Textastic.

Textastic 6 is a new app, rather than an free update, and is just $10.

  1. For a great explanation on the benefits of the Document Picker and Document Provider, check out Canvas #2 on


On the Embedded Apple SIM

One feature of the 9.7-Inch iPad Pro is the inclusion of an embedded Apple SIM, rather than a traditional SIM card that is placed inside the iPad’s SIM tray. Unfortunately, Apple’s wording around how the embedded SIM works hasn’t been very clear and it’s led to some confusion and concern that the new iPad Pro has no SIM tray.

To confirm, the 9.7-Inch iPad Pro does have a SIM tray, in addition to the embedded Apple SIM. From the iPad User Guide, available on the iBooks Store:

An Apple SIM card or an embedded Apple SIM is used for your cellular data connection. All iPad Wi-Fi + Cellular models include a SIM card tray. iPad Pro (9.7-inch) Wi-Fi + Cellular also includes an embedded Apple SIM (except in China). If you change carriers or if no SIM card is installed, you may need to install or replace the SIM card.

Embedding the Apple SIM seems like a natural–and smart–progression of this feature from Apple and I’d imagine that all future cellular iPad models (or iPad Pro models, at least) will have this feature.


Updating My Website With Git and iOS

This website is powered by Kirby, a file-based CMS, running on a VPS with Digital Ocean. Instead of the site’s content being stored in a database, Kirby uses Markdown-formatted plain text files, so publishing a new blog post is as simple as adding a new text file to the content directory, after which it’s immediately available on the site.

For a few years now, I’ve had Dropbox running on my server to sync the site’s content directory so that I can easily publish or edit content on any device1 without needing to directly upload any files to the server. This has been especially useful in the past twelve months as the iPad became my primary computing device, so I was able to use any Dropbox-enabled iOS writing app, such as 1Writer, to write and publish blog posts. As soon as I finished a new post, I’d remove the draft tag and it would appear on the site.

I’ve never been fully happy with this workflow, despite it working successfully, because it doesn’t easily fit in with how I develop and version control the site’s source code, and content2, with Git. But thanks to the iOS Git client Working Copy, however, I’ve been able to use Git on my iPad and iPhone in the same way I would on my Mac and even deploy those changes to my server.

A clone of my site's repository in Working Copy

Working Copy is a fully featured Git client that brings with it a range of supported Git features and makes use of some great features of iOS that are often overlooked, such as Document Provider3.

Just like on my Mac, I’ve cloned my site’s repository (named, unimaginatively, from GitHub to make whatever changes or additions I want (either a new blog post or a tweak to the source code), locally. Once I’m done, I commit and push the changes back to the default remote origin repository on GitHub.

Automatic Deployment From iOS

Since Working Copy supports many of Git’s standard features, I’ve been able to take advantage of another common use for Git – automatic website deployment. This has eliminated my need for Dropbox syncing and even publishing site changes via SFTP from my Mac, replacing them both with a process that pushes changes to a secondary remote repository – my server.

To set this up, I followed Digital Ocean’s guide on setting up automatic deployment with Git. In a nutshell, I’ve configured a remote repository located on my server as a secondary remote for within Working Copy, and on my Mac, named live.

On the server, a Git Hook4 listens for any changes that are received, which happens when a push has been completed to the live remote, and runs script that updates the files in /var/www/html. Basically, as soon as I push any changes to live, either from my Mac or iOS devices, the site is automatically updated.

Thanks to Working Copy and automatic deployment, whether I’m on my iPad, iPhone or Mac, I perform the same steps to make changes to my website and deploy them:

  1. Fetch and pull any changes from the remote origin repository (GitHub).
  2. Make any necessary changes, such as adding a new blog post or editing the site’s layout.
  3. Commit and push the changes back to origin.
  4. Push the changes to live (my server) so the site is then automatically updated using a Git Hook.

Finally, Working Copy has a comprehensive URL scheme and supports x-callback-url, making it possible to create powerful workflows and actions with apps like Workflow and Drafts. The URL scheme is extremely powerful and not only can new files be created or edited, but commits and push actions can be performed as well. I plan on looking into the URL scheme in more detail soon, as I’d like to have a workflow that takes a blog post, creates the necessary text file, then commits and pushes the changes.

  1. To protect my personal Dropbox account, I set up a second Dropbox account specifically for the server and shared the content folder between my personal account and the server’s account. Should my server or its Dropbox account be, somehow, compromised, my personal Dropbox data is never at risk. 

  2. Including a site’s content in version control, in many cases, isn’t really necessary (or possible, if your content is stored in a database). Since my site’s content is a directory full of plain text files, it’s worthwhile to include it. 

  3. Using an app that properly supports Document Picker, such as Textastic, Working Copy appears as a Document Provider and files can be directly opened without needing to be copied around iOS. 

  4. Git Hooks are custom scripts that run depending on certain criteria. In this case, the post-receive hook runs a script once a push has been completed that replaces the server’s public HTML files with an updated version. 


Transmission for OS X Suspected of Containing Ransomware in Recent Update


An Apple representative said the company had taken steps over the weekend to prevent attacks by revoking a digital certificate from a legitimate Apple developer that enabled the rogue software to install on Macs. The representative said he could not immediately provide other details.[…]

The malware is programmed to encrypt files on an infected personal computer three days after the original infection, according to Olson.[…]

The project’s website,, on Sunday carried a warning saying that version 2.90 of its Mac software had been infected with malware.

There isn’t much information to go off for the time being and it looks like there’s still a lot of investigation going on about what, exactly, has happened and where the malware was picked up – you’ll find a more technical discussion happening over at Hacker News.

Somewhat related to this, ATP recently had a great discussion on the merits of sandboxing Mac apps that are available outside the Mac App Store and that, if an app can be sandboxed, it probably should.


Typos in Disk Utility

Stephen Hackett discovered some grammatical atrocities within Disk Utility.