Ramblings of General Geekery

The Problem with iOS

These past few months I’ve seen a fair number of articles about people who switched from iOS to Android. Most of those articles talk about the differences between the 2 operating systems, and how some of those differences proved to be significant enough for whoever was switching: multitasking, notifications, the so-called “open vs. closed”, etc. That’s fine, but these specific bullet point list vs. bullet point list comparisons seem to be missing the higher level view of what’s really going on: iOS is just not working the way it should anymore.

When iOS was released in 2007, it made a lot of things easier to do on a phone, compared to the existing competitors. A lot of tasks just felt “right”, or at least “way better”. But it basically stayed there since then. The only real additions, like the notification center or iCloud, are either incredibly badly designed, or are only usable if you have an almost exclusive Apple-based household (which you shouldn’t). When I look at my iPad now, I feel like I’m looking at a computer that hasn’t been updated in years.

If I’m reading something in Safari, I should be able to quickly send it to Pocket, Buffer, Dropbox, or whatever other service I choose to base my workflow on. But on iOS, the only “sharing” services I have access to are those that Apple thinks I should use. For everything else, I need to copy the URL, switch to another app, and find where to paste it. Why?

If I added a few articles to read on Pocket late yesterday evening, I should have them ready on my phone or tablet the next morning so I can read them during the commute. But on iOS, I have to remember to open the Pocket app so it can sync. Why? (note that other apps like Instapaper try to use the Location Notification API but frankly, by the time I leave the house, and therefore lose any WiFi connectivity, it’s already too late).

If I just bought a bunch of PDFs from DriveThruRPG, e23, Arc Dream or Pelgrane, or some comicbooks from Panel Syndicate or Thrillbent, or whatever else I want from whoever I feel like giving money to, I should be able to just download those files onto my device and open them with any application I like. But on iOS, unless it’s coming from iTunes (directly or via in-app purchases, all of which also means 30% of my money doesn’t even go to the people I want to give my money to), I have to jump through many hoops, going first through Dropbox or FileBrowser and then having to re-transfer every. single. file. to each of their application’s sandbox storage. Why? Oh why?

You may not be surprised to learn that all of those things “just work” on Android. And those are just examples of the frustrations I’ve had with my iPad in the past few weeks. You don’t just go “BOOM!” anymore – quite the contrary: you actually have to work harder to make things happen.

Some people might be tempted to boil this down to a simple list of features, like “iOS needs a background service API, shared storage, and more extensibility points for 3rd party apps”. This sounds to me like going back to 2007 and saying “Windows Mobile needs to make the stylus optional, have a grid of icons on the home page, and remove copy/paste”. Really, it’s not just about a bullet point list of features. It’s about the whole philosophy of the system, and of the company behind it. And although Apple seems to be occasionally bowing down to the pressure of the market, like when it released the 7″ iPad Mini, I don’t expect it to change this radically on the design of iOS.

Would I rather have an iPad Mini instead of my Nexus 7 to bring with me everywhere I go? Of course I would. The iPad Mini is thinner, lighter, and has a better screen. But as someone famous once said, “[design is] not just what it looks like and feels like. Design is how it works”. And for me, iOS is just not working well enough. And it never did, really – it’s just that until the competition caught up with the basics, only a minority of users noticed it.

PieCrust 1.0 RC

The past month has been pretty busy, between my next secret project, my day job, and of course fixing PieCrust bugs. But somehow among this chaos seems to be emerging a release candidate for PieCrust 1.0. And it’s only fitting that I announce this on Pi Day!

P365x52-73: Pi(e)

As always, for a complete list of changes, I’ll redirect you to the changelog. But for the highlights, please read on.

Big thanks go to the few people who contributed patches to the PieCrust code, and to the many who reported bugs and had the patience to help me fix them.

Breaking changes

First, the breaking changes. There are a bit more than I’d like, but most of them should not be a problem to 99% of users:

  • Chef’s command line interface has changed: global options now need to be passed first, before the command name. So for example, if you want debug output when baking, you need to type chef --debug bake.
  • The pagination.posts iterator can’t be modified anymore (i.e. calls to skip or limit or filter will fail). You can use the blog.posts iterator instead to do anything custom.
  • The xmldate Twig filter has been renamed to atomdate.
  • There was a bug with the monthly blog archives (accessed with blog.months), where they would be incorrectly ordered chronologically. They are now ordered reverse-chronologically, like every other list of posts.
  • The baker/trailing_slash is now site/trailing_slash, since PieCrust will also generate links with a trailing slash in the preview server, and not just during the bake, when that setting is enabled. The old setting is still available, though.
  • The asset template variable is renamed assets. The old name is still available.
  • Specifying a link to a multi-tag listing page is now done with the array syntax: {{pctagurl(['tag1', 'tag2'])}}. The previous syntax quickly broke down as soon as somebody decided to have tags with slashes in their name 🙂

All those changes should give you an error message that’s easy to understand, or have backwards compatibility in place with a warning telling you about the change. Look out for those.

Sass, Compass and YUI Compressor

Previously available as plugins, the Sass, Compass and YUI Compressor file processors are now part of the core. There were enough people mentioning those tools, especially Compass, that it made sense to include them by default.

The Sass processor is very similar to the one previously available in the plugin. In the site configuration, you can specify include paths with sass/load_paths, output style with sass/style, or any custom option to pass to the Sass tool with sass/options.

Compass support, however, has changed quite a bit, and should be now a lot better:

  • You enable it by setting compass/use_compass to true. This will prevent the default Sass processor to run on your .scss files.
  • If .sass or .scss files are found in the website, the compass tool will be run at the end of the bake. It will by default use any config.rb found at the root of the site. You can otherwise specify where your Compass config is with compass/config_path, or ask PieCrust to auto-generate it for you with compass/auto_config to true.
  • It may be a good idea to add your config file to the baker/skip_patterns list, so that it’s not copied to the output directory.

To enable the YUI Compressor to run on anything that outputs CSS, specify the path to the .jar file with yui/compressor/jar.

Linking feature now official

For a while, there was a link template variable that let you access other pages in the content tree. It was however never really official since I was still iterating on the design.

It’s now official, and available through the siblings template variable. It will return the pages and directories next to the current page.

To return the whole family tree starting from the current page, you can use family. It’s like a subset of site.pages.

Auto-format extensions

Another popular request is the ability to use different file extensions for pages and posts, like .md for Markdown content or .textile for Textile content.

This is now possible with site/auto_formats. This is a list that maps an extension to a format name:

        md: markdown
        mdown: markdown

Here I’m mapping *.md and *.mdown to the Markdown format. Files found with those extensions will be treated as if they were .html files, but will also have their format set to markdown.

Feed preparation

If you write a blog, you most probably want to have an RSS feed. You can have one prepared for you with: chef prepare feed myfeed.xml. It will create a new page that has most of what you want by default. You can then go and tweak it if you want, of course.


A few other important changes:

  • All libraries (including Twig, Markdown or Textile) have been upgraded to their latest versions.
  • It is now possible to specify posts_filters on a tag or cateogory page (_tag.html or _category.html).