Emojify your Wi-Fi (Netgear R6300 edition)

After reading Brian Jordan’s post Emojify your Wi-Fi where he adds emoji to his Wi-Fi SSID, I decided to blatantly rip him off I got inspired to do the same on my Netgear R6300 router.

Adding the emoji directly from the admin panel didn’t work though, when I tried to I got this alert:

Character not allowed alert dialog

Following in Brian’s footsteps, I found the Javascript function which validates the characters in an SSID and overrode it to always return true. This was enough to get an emoji character accepted as part of the SSID!

To do this yourself you can follow these steps:

  1. Go to your Netgear admin panel and craft your beautiful emoji-enriched SSID Wi-Fi admin panel
  2. Open up the developer console
  3. Override the validation function by typing in window.checkData = function() { return true; } (and then pressing Return) Dev console
  4. Craft your beautiful emoji-enriched SSID
  5. Save and enjoy your new SSID… you finally fit in with the neighbours

    New SSID updated

How to use the San Francisco Mono typeface before macOS Sierra is released

Apple’s new San Francisco Mono typeface comes bundled in with the latest Xcode 8 beta, and it’s beautiful! If you’re impatient like me and want to use San Francisco Mono in your other apps before macOS Sierra is released, you can grab its otf files from the Xcode 8 Beta app package and install them manually:

  1. Download and install the Xcode 8 beta (you’ll need an Apple Developer account)
  2. Open Finder and push CMD + SHIFT + G to open the “Go to Folder dialog”, then paste this path (its prefix may differ depending on where you installed Xcode): /Applications/Xcode-beta.app/Contents/SharedFrameworks/DVTKit.framework/Versions/A/Resources/Fonts Go to dialog
  3. Open all the font files starting with “SFMono”: Select all fonts
  4. Choose “Install Font”: Install fonts

The San Francisco Mono fonts should now be available to use throughout your entire system. Enjoy!

Disabling App Transport Security in your development environment

iOS 9 introduced App Transport Security, which by default forces apps to communicate over HTTPS instead of HTTP. This is a great default for production apps, but it can get in the way of connecting to development servers which are less likely to be configured with a HTTPS connection, especially when running on your local machine.

To get around this an exception can be added for localhost (or any other known development environment domain) which will allow your app to send and receive unencrypted HTTP requests. In your Info.plist add the following:


If you’re editing your Info.plist visually in Xcode, you should have these entries:

App Transport Security info.plist screenshot

Swift: A nicer way to tell if your app is running in Debug mode

Often while working on an iOS app there’s functionality that you want exposed only when the app is running in a Debug build configuration. Previously I would use build environment variables and preprocessor macros to determine this, but thanks to the great answer on this Stack Overflow question I now use a runtime check to tell whether the app is running in Debug or Release mode:

// Returns true if the app is running in a Debug build
_isDebugAssertConfiguration() -> Bool

// Returns true if the app is running in a Release build
_isReleaseAssertConfiguration() -> Bool

// Example usage: only printing to the log when the app is running in Debug
if _isDebugAssertConfiguration() {
  print("Log: User \(user) logged in")

Note: these functions aren’t publicly documented in Swift’s API, and are only available from Swift 2.1 onwards. As kennytm says in his Stack Overflow answer, there is a risk of this function being removed in a future update.

If you do want to use this in your codebase, I have created a convenient helper around the function in my Swift helper library: APSwiftHelpers.

Development environment config overrides in Jekyll

While building this website using Jekyll I found that there were a few places where I needed to override config variables when the site is running in a development environment. Some examples of dev only overrides I wanted to do are:

  • Skip minifying the SASS output so it’s easily debuggable
  • Show all draft posts by default
  • Run the server on port 4000, accepting all incoming connections

The best way I found to do this was by having two config files; a base config used in production (_config.yml), and an override config used only in development (_config_dev.yml):

# _config.yml - Base config used in production

  style: compressed

show_drafts: false
# _config_dev.yml - Dev environment configs and overrides

show_drafts: true

# Accepts connections on port 4000 from any source
port: 4000

# Don't compress SASS output
  style: full

As you can see, any dev-specific config options just need to go into the _config_dev.yml file. This can be a Jekyll option you need to override, or an option for any of your Jekyll plugins.

To launch the Jekyll server in a dev environment I then run the following command - note that _config_dev.yml must be specified last so that its config items override _config.yml.

$ jekyll serve --config "_config.yml,_config_dev.yml"

This command will first load in the normal config, and then the dev only overrides. To make this even easier to launch I put the command under a script/dev file so I can launch it without having to type out the names of both the config files. You can see an example of this in my repo for this website.

Since I’m deploying this using GitHub pages I didn’t need to do anything extra to have this working in production. GitHub pages compiles Jekyll using the _config.yml file by default and ignores all other config files, but if your deployment is slightly different all you’d need to do is exclude the _config_dev.yml from the jekyll build command when doing your Jekyll build, and you should be good to go!

Setting up SwiftLint on Travis CI

SwiftLint is a great tool for enforcing code conventions in your Swift projects.

You can use it locally while you develop, but having it run as part of your continuous integration process makes sure that any contributions made to your project are checked for good code style too.

This post will guide you through setting up SwiftLint to run locally on your machine, as well as how to integrate it with your Travis CI build process.

If you’re completely new to Travis CI, I’d recommend you read this excellent getting started tutorial first, as this guide assumes that you already have a Swift project on GitHub integrated with Travis CI.

TLDR: This GitHub repo shows an example SwiftLint + Travis CI implementation.

Let’s get SwiftLint running locally

Installing SwiftLint is dead simple, just do a $ brew update && brew install swiftlint and you should be good to go!

Once installed, you can verify that Swiftlint works by opening your terminal, cd-ing to your repo’s root directory and running $ swiftlint.

This will scan your source code and show you places where improvements can be made. Once the scan is complete you should see something like this:

$ swiftlint
Linting Swift files in current working directory
Linting 'AppDelegate.swift' (1/4)
Linting 'UIColor+RandomColor.swift' (2/4)
Linting 'ViewController.swift' (3/4)
Linting 'UIColor+RandomColorTests.swift' (4/4)
UIColor+RandomColorTests.swift:16:26: error: Force Cast Violation: Force casts should be avoided. (force_cast)
UIColor+RandomColorTests.swift:17: warning: Trailing Whitespace Violation: Lines should not have trailing whitespace. (trailing_whitespace)
Done linting! Found 2 violations, 1 serious in 4 files.

This command line output is good, but what’s even better is getting these hints inline in XCode.

To do this you’ll need to add a new “Run Script Phase” to your XCode build process which contains the following script:

if which swiftlint >/dev/null; then
  echo "warning: SwiftLint not installed, download from https://github.com/realm/SwiftLint"

Adding build phase

Then CMD+B to rebuild your code and you should see lint hints appear inline in XCode like this:

Inline SwiftLint hints

You can now go ahead and do what the hints suggest, but don’t take their advice as gospel. If you want to ignore a particular hint SwiftLint gives you several ways of doing this, outlined here. I prefer to be explicit when ignoring SwiftLint hints by adding the ignore directive inline with my code:

Disabled hint

Installing SwiftLint on Travis CI

Now that your code has been de-linted locally, it’s time to add SwiftLint to your Travis CI build too. Since the default Mac OS X image on Travis doesn’t have SwiftLint installed, we need to install it manually before each build.

Before integrating with SwiftLint my total build time on Travis CI was around 50 seconds. I tried a few approaches to installing SwiftLint to see which would work the fastest:

# Approach 1: Installing via Homebrew
# Time to run build: 3min 18sec
$ brew update && brew install swiftlint

# Approach 2: Compiling from source
# Time to run build: 5min 16sec
$ git clone https://github.com/realm/SwiftLint.git /tmp/SwiftLint &&
  cd /tmp/SwiftLint &&
  git submodule update --init --recursive &&
  sudo make install

# Approach 3: Download and install precompiled .pkg file
# Time to run build: 1min 13sec (!!!)
$ wget --output-document /tmp/SwiftLint.pkg https://github.com/realm/SwiftLint/releases/download/0.9.1/SwiftLint.pkg &&
  sudo installer -pkg /tmp/SwiftLint.pkg -target /

Downloading and installing the precompiled pkg file was the fastest by far, only taking 23 more seconds to run the build.

So as to keep the Travis config file as clutter free as possible I created a bash script install_swiftlint.sh to handle the install. In the unlikely situation that the SwiftLint.pkg file isn’t available for download I’ve included a fallback which compiles SwiftLint from source:


# Installs the SwiftLint package.
# Tries to get the precompiled .pkg file from Github, but if that
# fails just recompiles from source.

set -e



if [ -f $SWIFTLINT_PKG_PATH ]; then
  echo "SwiftLint package exists! Installing it..."
  sudo installer -pkg $SWIFTLINT_PKG_PATH -target /
  echo "SwiftLint package doesn't exist. Compiling from source..." &&
  git clone https://github.com/realm/SwiftLint.git /tmp/SwiftLint &&
  cd /tmp/SwiftLint &&
  git submodule update --init --recursive &&
  sudo make install

Once you create that script, make sure to do a $ chmod u+x install_swiftlint.sh to give execute permissions execute permissions it. If you don’t do this the Travis build will crash.

Open up your .travis.yml config file and update it to call our SwiftLint install script by adding these lines:

  - ./install_swiftlint.sh

  - swiftlint

You can see the script parameter has a new swiftlint call added to it, and the install parameter adds a call to our shell script install_swiftlint.sh.

It’s time to commit and push! The new Travis CI build should appear immediately, but may take a few minutes to start up. If all goes well it should exit with a 0 status and happy green color!

Passed Travis build

Example code

I’ve set up an example repo on GitHub which shows shows this method of running SwiftLint. Check it out here.