ImageMagick is comprised of number of CLIs for image processing, with a long history stretching back to 1990.
One of the first examples they show off on their command line page is this:
convert label.gif +matte \ \( +clone -shade 110x90 -normalize -negate +clone -compose Plus -composite \) \ \( -clone 0 -shade 110x50 -normalize -channel BG -fx 0 +channel -matte \) \ -delete 0 +swap -compose Multiply -composite button.gif");
Given the complexity of these commands, it was immediately clear to me that ImageMagick was perfect for scripting.
That is, instead of committing all of this (and much, much more) to memory, it would be better to write a script that handles the commands themselves, and let future me simply execute the script and pass in a few command line arguments.
Apple App Store icons
Apple App Store icons seemed like a perfect use case for ImageMagick scripting. In order to submit an app for review on iTunes Connect, you need to prepare versions of your app icon at numerous different sizes.
Above, you can see the results of adding all the required icons to
Assets.xcassets in Xcode.
That’s 9 icons for a Messages Extension alone. We might as well script the repetitive work.
I’ve pushed a shell script to GitHub that I’m using to generate the appropriately sized icons from a source image.
Like many workflow scripts, this script is suited to my particular needs and might not fit exactly into your workflow. I’ve pushed it to be used as a resource for seeing how you might incorporate ImageMagick into your scripts.
If you take a look at the script itself, it’s relatively simple in its use of the ImageMagick
convert CLI. All of the resizing happens at the end of the script, in lines like this:
convert $FILE -resize 54x40! resized/Icon-Appemail@example.com
As the script currently stands, it will produce all of the icons you need for an iOS 10 Messages Extension.
Points to consider
- This is my first crack at exporting icons for iOS. Take the conversions and naming conventions with a grain of salt. (If you spot an issue, please add it as an issue to the GitHub repo!)
- I noticed that sometimes the
-resizegeometry argument wouldn’t exactly hit the target size (e.g., producing 53×40 instead of the requested 54×40). I’m using the bang (
!) operator to force the new image to the exact dimensions requested. I never saw a difference of more than a pixel or two, but be aware of the possibility of some small distortion.