Controlling Interface Builder with Plists

I have an appearance manager that reads styles from a plist file and applies then throughout the app through the use of the appearance proxy and through notifications to various custom subclasses of the standard UIKit views and controls.

This works great and allows for of a lot of easy features like different coloured themes or dark modes. The major downside right now is that none of the changes to the plist are reflected in Storyboards or Xib files.

I like using Interface Builder as it means less code that I have to write and, therefore, fewer opportunities for bugs, especially when dealing with AutoLayout. Unfortunately, IB has some severe limitations, the major one for me being that there’s no way to set a global default range of styles that is then reflected throughout the Storyboard (other than tintColor).

One of the advantages of having a design tool is to instantly see changes rather than having to build and run an app in order to see them. This advantage is negated somewhat when I have to manually change the font on every control when the design is updated.

Seeing as I’m already using a centralised plist file to manage my app’s appearance, it would be great if I could start seeing changes I made to this file in Storyboards and Xib files too.

After digging into the process that spins up when a custom @IBDesignable class is rendered, I found that Xcode creates a unique environment that is entirely separate to the app. It makes sense to compile only the absolutely minimum it needs to in order to render the views but that does mean that it severely limits the places where the plist file is visible to the process.

Nothing within the app bundle can be called nor can any custom environment variables set, which means that the Appearance manager has no knowledge of the wider app context in which it sits. However, it does have an environment and this environment does include a reference to a location that should exist on any system that is running Xcode, namely the ~/Library/Developer/Xcode/UserData directory.

(The standard FileManager URLs aren’t any more helpful in this context, as their reference are relative to a Simulator Devices directory. For example, the .libraryDirectory points to ~/Library/Developer/Xcode/UserData/IB Support/Simulator Devices/<UUID>/data/Library/, rather than to ~/Library.)

I gave the plist file a generic name (IBAppearance.plist) and then hardcoded this name as a string directly into the Appearance manager. I also created a special method (below) in the appearance manager that is only called when a custom subclass of a standard UIKit view has its prepareForInterfaceBuilder() method called.

This means that none of the Interface Builder code is called when the app is running normally. It also means that, for the appearance styles to work, there needs to be at least one custom view somewhere in the Interface Builder document (once there is, however, all the styles will be applied—even those affecting standard UIKit views).

I then tried a symlinked copy of the plist file that exists in the project bundle instead and it broke everything. The default FileManager does not resolve aliases automatically and I had to add some additional code to check if the file was an alias and, if so, resolve that alias.

Here’s the complete method in the appearance manager that searches for IBAppearance.plist (which itself is a symlink to Appearance.plist in the project workspace) and then loads those styles:

I can now edit the appearance plist file within Xcode and see the changes in Interface Builder. Building and running the app confirmed that the IB changes were an accurate representation of how they’ll be rendered.

An animated gif showing an external plist file updating an Storyboard in Xcode

An animated gif showing whole thing in action

Very satisfying.

(As a bonus, the fonts also use the current user settings for dynamic type, adjusting their size as necessary to reflect the current system accessibility settings).

There are a few downsides to this system:

  1. The one UserData directory is shared over all of the projects that exist on that system, so that folder is filling up with plist files.
  2. Hardcoding the name of the file isn’t great as it means moving or renaming that file when switching between projects.
  3. The location is very fragile. If Xcode changes where the SIMULATOR_SHARED_RESOURCES_DIRECTORY points to, all of this will stop working.

I am still looking for better solutions for these issues, so let me know on Twitter if you have any ideas.

I wanted a way for the Appearance manager to figure out which project it belonged to and then search for a plist file based on this project name but, as noted, these rendered views have almost no knowledge of anything but themselves and so I haven’t yet managed to find a way.

The appearance manager exists as a (currently private) Cocoapod and is a dynamic framework which means adding a constant to any of the appearance manager files to tell it which one to load is also out, as this will be overwritten with any new version.

Protocols and delegates also don’t work, as nothing in the wider app context holds a reference to the appearance manager (it is the custom subviews, also part of the same framework, that call it in this instance).

Overall, though, the improvements are vast. I have already built an Adobe Swatch Exchange to plist converter script which means that named swatches from Adobe products can be injected directly into plists and will be there in IB the next time the project is opened, which helps reduce the friction involved in tweaking or changing designs.

  • Share:

Get all of my latest posts direct to your inbox! Pop in your email address here:

0 Comment (1 pingbacks)