A coworker recently started a project that uses a thermal printer to print some information for a top secret purpose and I was immediately inspired to play around with one myself. Unfortunately the thermal printer that they were using was more than £150 and designed for commercial environments and after some searching I ordered one of these ‘cat’ printers from Aliexpress — which was £15 including shipping, 7 rolls of paper and 3 rolls of stickers.
Once I received the printer I hurriedly started trying out lots of iOS thermal printer SDKs — but unfortunately they were mostly all designed for the more expensive commercial printers and refused to connect. I inspected the app bundle that the printer came with, which was an obfuscated react native application, and managed to find where connecting to the printer was handled but I did not relish the idea of spending hours trying to unpick my way through the obfuscation. I went back to searching the internet and eventually found that, though the printer model gave me zero results, I got plenty of results for “cat printer” — happy days.
I used this Python project by rbaron, and confirmed that it could print successfully. I then set about to trying out the printer commands in that repo in my own Swift project and it worked! I built a small Swift SDK that I could use for my own project that prints a CGImage — additionally handling some image processing to prepare the image for the printer. You can use a SwiftUI ImageRenderer to very easily create a CGImage with arbitrary content for printing, but how you create your image is entirely up to the user of the library.
I released CatPrint.swift on GitHub. If you are interested in printing from iOS/macOS/iPadOS please take a look and try it out.
For a long time my personal site was dynamic — built using Django and Python and hosted on Heroku. After falling off from Django as I focused my attention on Swift-er things I decided to switch to a static site builder. I had the following requirements:
- Built with Python
- My requirements aren’t so extensive, but I wanted to be able to understand stack traces when something went wrong
- Markdown support
- Previously I had stumbled into
reStructuredText. I was not a fan anyway, and I find markdown far more intuitive.
- Easily customisable
- I would one day like to have product pages for my apps, with non-html content — e.g. site maps, json, rss.
Lektor fit all of these requirements and I have had a smooth ride ever since. The project is not as active as I would like — e.g. the RSS plugin that I use was last updated 2 years ago — but as everything currently works it will take a while before that becomes a problem. If it does become a problem, my posts are all stored in plain Markdown files.
Lektor comes with a development server, with a built in admin panel for editing content with a GUI which also helps debug pages when something goes wrong. Deployment is easy, I simply run lektor build -O build — and drag and drop the contents of the build folder into an S3 bucket.
This applies only to ‘iOS Developers’
15 years ago Apple introduced the iOS SDK, a critical moment that transformed the software development landscape. We started with novelty fart apps, and not long afterwards started to manage our entire lives from the palm of our hand. While the iPhone’s ubiquity remains unchallenged — the centre of gravity has widened to include many other platforms.
In the early days an iOS developer might only expect to build their app for an iPhone — and at a push the iPad. Today our capabilities extend far beyond, allowing us to build things for Watch, TV, Mac, Siri and Vision Pro with the same shared set of tools and SDKs.
Even if your current project is exclusive to the iPhone, it’s time to consider the landscape beyond a single device with a job title that positions yourself for the future. Here are some ideas:
- Swift Developer
- Covers everything, but often people like to see a clear demarcation between frontend and backend — and theoretically you could have a Swift backend.
- SwiftUI Developer
- This covers all the platforms, but UIKit is still very popular and will be for a long time to come and I’m not sure it’s wise to cull it from your life just yet.
- UIKit Developer
- As with SwiftUI, but in reverse. Despite its early teething problems SwiftUI is clearly the future of native frontend development on Apple’s platforms. If you aren’t looking forwards then what is the purpose of this exercise.
- Apple Platform Developer
- Probably the most technically accurate of these suggestions, but I don’t like how it might sound like you suggest you work for Apple — though people have no problems calling themselves Drupal/Sitecore developers…
- Native Front-end Developer
- You run the risk that people might believe you want to interact with Android. If you do have that particular streak of masochism then go ahead.
All of these options have different tradeoffs, but I believe those tradeoffs are smaller than mentally restraining yourself to a single device. The future of computing is pervasive and we should be positioning ourselves accordingly.