Category: macOS

Quick Look plugins for software development

Quick Look already supports multiple file types. But there ist more – especially for software development. Here are some plugins that make Quick Look even better.

Note: some of the plugins might not work instantly after brew install ... when you are on macOS Catalina or later. In this case, it is possible to download the plugin manually and copy the .qlgenerator file to ~/Library/QuickLook. This requires to run qlmanage -r (or a system restart) to enable the plugin.


QLMarkdown provides QuickLook support for markdown files (*.md). This plugin renders the markdown content and shows the result. To install QLMarkdown, use:

brew cask install qlmarkdown

For manual installation, the plugin is available at


This Quick Look plugin provides a file preview for files without extension, e.g. README, INSTALL, Capfile, CHANGELOG, etc. It can be installed using Homebrew:

brew cask install qlstephen

For manual installation, the plugin is available at


This is a Quick Look plug-in that renders source code with syntax highlighting. To install the plugin, use Homebrew:

brew cask install qlcolorcode

For manual installation, the plugin is available at If you want to configure QLColorCode, there are several defaults commands that are described on the download page.

Quick Look Json

This is a Quick Look plug-in that renders json files. To install the plugin, use Homebrew:

brew cask install quicklook-json

For manual installation, the plugin is available at

WebP QuickLook

This is an open-source QuickLook plugin to generate thumbnails and previews for WebP images. To install the plugin, use Homebrew:

brew install webpquicklook

For manual installation, the plugin is available at

Something is missing? Please let me know in the comments, if there are any other plugins that might be helpful for software development.

Photo by Shane Aldendorff on Unsplash

Create certificate for localhost domains on macOS

Step 1: create a self-signed root certificate

First, let’s create a self-signed root certificate:

openssl req -x509 -nodes -new -sha256 -days 390 -newkey rsa:2048 -keyout "RootCA.key" -out "RootCA.pem" -subj "/C=de/CN=localhost.local"
openssl x509 -outform pem -in "RootCA.pem" -out "RootCA.crt"

The parameter -days 390 sets the number of days, this certificate is valid. Starting on September 1st (2020), SSL/TLS certificates cannot be issued for longer than 13 months (397 days), see

If this time is too long, you will receive an NET::ERR_CERT_VALIDITY_TOO_LONG error. In the command above, this value was set to 390 days, which works for me.

Step 2: define domains and subdomains that should be included in the certificate

For this, just create a text file named vhosts_domains.ext and insert the following contents:

keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
DNS.1 = localhost
DNS.2 = *
DNS.3 =

This example includes subdomains for a local development environment for the domain and all subdomains like or

If you plan to use a more general certificate e.g. to include all subdomains under *.*.blog.local, this will not work. The definition only supports ‘first level’ subdomains. It would be great, because this saves a lot of additional setup, but unfortunately this is note supported.

Step 3: create the certificate

Now let’s create the certificate:

openssl req -new -nodes -newkey rsa:2048 -keyout localhost.key -out localhost.csr -subj "/C=de/ST=State/L=City/O=Organization/CN=localhost.local"
openssl x509 -req -sha256 -days 1024 -in localhost.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -extfile vhosts_domains.ext -out localhost.crt

Calling the two commands above will create the localhost certificate that includes all the provided domains and subdomains. Your file listing should look like this:

Step 4: make the certificate available for Apache

Depending on your system, copy all those files into the the configuration folder of the Apache installation. In my case, the installation was done with the help of brew, so the local path is:


At the end, it’s not important where those files are located, because we no add this path to the vhost definitions. For this, open your vhosts file and link the crt and the key file as follows:

<VirtualHost *:80>
    DocumentRoot "/Users/mathias/Sites/"
    ErrorLog "/usr/local/var/log/httpd/localhost-error.log"
    CustomLog "/usr/local/var/log/httpd/localhost-access.log" common
<VirtualHost *:443>
    DocumentRoot "/Users/mathias/Sites/"
    SSLEngine on
    SSLCertificateFile "/usr/local/etc/httpd/cert/localhost.crt"
    SSLCertificateKeyFile "/usr/local/etc/httpd/cert/localhost.key"

If you have additional vhost definitions, you can add the <VirtualHost *:443> part to every server name entry and use the correct paths to SSLCertificateFile and SSLCertificateKeyFile.

After changing the vhost settings, it is required to restart your Apache server!

Step 5: add the certificates to macOS

When opening a local website, the certificate should be used but you might see a NET::ERR_CERT_INVALID error. This is the case, because modern browsers/systems do not trust self-signed certificates by default. to overcome this issue, we have to add the created certificates to the macOS Keychain Access. For this, open the *.crt files in Keychain Access:

So that they are know by macOS:

And finally, update the trust settings of each certificate to “Always trust”:

You should now be able to use a secure connection between your browser and your local server:

Step 6: additional fixes

The steps above might already work for Chrome and Safari. If you have problems with Firefox, just open settings and go to Privacy & Security. Then you have to import the root certificate file RootCA.crt, so that Firefox knows about your certificate.

Android Studio: when shortcuts do not work on macOS

Compared to other IntelliJ® based software, some shortcuts in Android Studio did not work for me. For example cmd + shift + F, which should open the global search did not work.

The reason for this is the keymap setting that was set to IntelliJ IDEA Classic. Setting the keymap to macOS (as shown in the figure below) solved the issue.

Android Studio Keymap settings

PNG – deactivate interlace to avoid ‘libpng warning: Interlace handling should be turned on when using png_read_image’

I stumbled appon a warning message that was thrown by PHP when handling images with GD lib (e.g. imagecreatefrompng()). The message shown was:

libpng warning: Interlace handling should be turned on when using png_read_image

This message even exists, when deactivating ‘interlace’ with the help of:

imageinterlace($img, false);

The only solution is to deactivate for the processed image(s). This is possible with ImageMagick. To deactivate interlace on all images of a folder, the following command can be used:

magick mogrify -interlace none *.png

I used ImageMagick on macos and installed it with with HomeBrew:

brew install imagemagick

CocoaPod Workflow – eine Zusammenfassung

Eine auswführliche Beschreibung, wie man von Grund auf einen CocoaPod erstellt, findet sich unter Ist der CocoaPod erstellt, dann lassen sich Updates mit wenigen Befehlen einpflegen. Hier nun die wichtigsten Schritte:

Zum Testen des Quelltextes:

$ pod lib lint

Vor dem Veröffentlichen zunächst die Versionsnummer anpassen. Dazu die .podspec bearbeiten:

# Versionsnummer anpassen
spec.version      = "0.0.1"
# Tag anpassen
spec.source       = { ... :tag => "0.0.1" }

Hinweis: Wenn der Tag in spec.source als Variable angegeben wird, dann ist es nicht notwendig, diesen immer wieder anzupassen. Der Eintrag sollte dann so aussehen: :tag => "#{spec.version}"

Den Quelltext noch einmal prüfen:

$ pod lib lint

In Git einen Tag erstellen:

$ git add -A &amp;&amp; git commit -m "Release 0.0.1."
$ git tag '0.0.1'
$ git push --tags

Die neue Version veröffentlichen:

$ pod trunk push NAME.podspec

Hinweis: Gelegentlich werden von Xcode Meldungen (Notes) ausgegeben, die keine kritischen Fehler anzeigen, sondern nur einen Hinweis darstellen. Das kann dazu führen, dass eine Veröffentlichung fehlschlägt. Dann lässt sich eine Veröffentlichung mit dem Parameter --allow-warnings durchführen.

$ pod trunk push NAME.podspec --allow-warnings

Sollte es zu einem Fehler kommen:

Authentication token is invalid or unverified.
Either verify it with the email that was sent or register a new session.

Dann muss eine neue Session erstellt werden, bevor der CocoaPod gepusht werden kann:

$ pod trunk register 'Your Name'

Less (CSS) unter macOS installieren

Der einfachste Weg Less auf einem Server zu installieren ist über npm (dem node.js Paketmanager) mit:

$ npm install -g less

Wenn nicht vorhanden: Command Line Tools für Xcode installieren

xcode-select --install

Wenn nicht vorhanden: HomeBrew installieren

ruby -e "$(curl -fsSL"

Wenn nicht vorhanden: Node.js installieren

brew install node

LessCSS installieren

sudo npm install -g less

Nun lassen sich die lessc Befehle ausführen.