Because I was fighting my way around using nokhwa on macOS, I needed a way to pull snapshots from my MacBook Air's webcam for comparison. And because I didn't find any copy & pasteable command online, let me document it here for future reference:

ffmpeg -ss 0.5 -f avfoundation -framerate 30 -video_size 640x480 -i "0" -frames:v 1 capture_%03d.jpg

If I omit -framerate 30, ffmpeg (or is it AVFoundation under the hood?) prints somewhat helpfully:

[avfoundation @ 0x960c28000] Selected framerate (29.970030) is not supported by the device.
[avfoundation @ 0x960c28000] Supported modes:
[avfoundation @ 0x960c28000]   640x480@[15.000000 30.000000]fps
[avfoundation @ 0x960c28000]   1280x720@[15.000000 30.000000]fps
[avfoundation @ 0x960c28000]   1760x1328@[15.000000 30.000000]fps
[avfoundation @ 0x960c28000]   1328x1760@[15.000000 30.000000]fps
[avfoundation @ 0x960c28000]   1552x1552@[15.000000 30.000000]fps
[avfoundation @ 0x960c28000]   1920x1080@[15.000000 30.000000]fps
[avfoundation @ 0x960c28000]   1080x1920@[15.000000 30.000000]fps

And because the default size is a portrait format (1080 × 1920), that gave me the clue of what other format sizes are supported.

Oh and if you want to get rid of the warning

[avfoundation @ 0xc7ec64000] Selected pixel format (yuv420p) is not supported by the input device.
[avfoundation @ 0xc7ec64000] Supported pixel formats:
[avfoundation @ 0xc7ec64000]   uyvy422
[avfoundation @ 0xc7ec64000]   yuyv422
[avfoundation @ 0xc7ec64000]   nv12
[avfoundation @ 0xc7ec64000]   0rgb
[avfoundation @ 0xc7ec64000]   bgr0
[avfoundation @ 0xc7ec64000] Overriding selected pixel format to use uyvy422 instead.

then add in a -pixel_format uyvy422. That must come before the -i option, to make sure it applies to the input, not the output.

Now for the last hint: The webcam needs some time to adjust exposure. Without -ss 0.5, or even with a wait time of just 0.1 seconds, the image comes out very dark. Half a second does the trick for me.

For my macOS app GalleryMagic, I had the need to do some image manipulation. Browsing for open-source packages both on crates.io as well as on swiftpackageindex.com, I came across photon-rs, claiming to be a "[...] high-performance Rust image processing library".

Low and behold, in only ~50 lines of code, I was able to implement a command line program to resize images. Deciding that this was a good enough fit to be used in the app, now came the time to figure out how to ship this Rust code on the macOS App Store.

Rust makes it easy

What makes shipping Rust code on the macOS App Store somewhat easy, compared to other languages, is that Cargo and the Rust compile compile your program to a static binary out of the box. This means that you can just ship this binary as part of your app bundle and be done with it. So step 1 is literally as easy as running

cargo build --release

and copying the resulting binary to your app bundle. If you drag the binary into Xcode, it will automatically add it to the "Copy Bundle Resources" build phase.

Check out GalleryMagic yourself. Create beautiful galleries of your photos in seconds. It's a free download!

As for calling the binary, I ended up using Command to run the binary from Swift code. Pretty straightforward:

guard let toolPath = Bundle.main.path(
    forResource: "image-manip-cli", ofType: nil
) else {
    fatalError("image manipulation tool not found")
}
let runner = CommandRunner()
try await runner.run(arguments: [toolPath, "--input", sourceUrl.path, "--output", targetUrl.path])

Code signing

Already thinking I was done and ready to submit the app to the App Store, I was in for a surprise. The App Store requires all code to be signed, and that includes the Rust binary. So I had to figure out how to sign the binary. There's a couple of articles and apple development documentation on how to do this. For my use case, it boiled down to running the following command in the "Run Script" build phase of my Xcode project:

codesign -s - -i com.fastapps.magicgallery.image-manip-cli -o runtime --entitlements ../image-manip-cli.entitlements -f image-manip-cli

The entitlements file is a simple file that contains the following:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.inherit</key>
    <true/>
</dict>
</plist>

This tells the code signing tool to sign the binary with the app sandbox enabled, which is required for the App Store, as well as to inherit all capabilities from the main app target. With this in place, I was able to successfully sign the binary and submit the app to the App Store.

Universal Binaries

Straight after that, since I have an M3 Mac, I had to solve also making this work on Intel Macs. Once more, Rust makes it easy, because the cross-compilation experience is great. The first two lines in the "Run Script" build phase of my Xcode project are obvious. Compile for both architectures, x86_64 and aarch64:

cargo build --release --target=aarch64-apple-darwin
cargo build --release --target=x86_64-apple-darwin

Up next is a line which squashes together the two binaries into a single universal binary. You can't really decide in your app itself at runtime which architecture the user's machine is running, you have to defer to the OS here. Using the lipo tool which comes as part of Xcode and is automatically available in the build environment:

lipo -create -output \
  target/universal/image-manip-cli \
  target/x86_64-apple-darwin/release/image-manip-cli \
  target/aarch64-apple-darwin/release/image-manip-cli

And just like that I was able to ship Rust code on the macOS App Store, supporting both architectures the Mac currently runs on and using codesigning/sandboxing to allow the app into the official Mac App Store.

My new macOS app GalleryMagic is available on the App Store. Arguably, it is 20 years late to an already saturated market. I built it anyway.

Check out GalleryMagic yourself. Create beautiful galleries of your photos in seconds. It's a free download!

Ever wanted to send a collection of photos to a friend or family member? Maybe you wanted to share some photos from your last vacation, or a birthday party, or just some random photos you took? There's already a plethora of ways to do this. Flickr, Google Photos, Apple Photos, Dropbox, you name it. But they all have one thing in common: You can't really influence the visual appearance of your gallery all that much. With GalleryMagic you can, based on a set of templates that come with the app (and both existing customization points as well as more to come). With some in-app purchases, you can also publicly host your galleries on the internet, so you can share them with anyone that has a webbrowser

This is what a demo gallery looks like:

Given my sister sometimes has the need for html galleries of her photos, I had dabbled in gallery generation before. Static site generators like Jekyll or Hugo can do this, but they are not for the faint of heart (read: your mom). I have probably four or five abandoned prototypes on my private git repos, all of varying technological background that I was interested in at the time. Ruby code packaged in a way so it can be embedded in a macOS app, a SwiftUI app that tries to embed one of the existing open-source html gallery generators, and so on. None of them ever made it to any real usable state let alone to the App Store.

Fueled by AI

Now what made me start to dabble in this again? The belief that I can build a simple app that does this in a weekend (care to take a guess if this estimation turned out to be the case?), given we now have AI assistants left right and center. I had so far been disappointed by the quality of results the AI assistants could produce. Claude code changed that one evening and I came away impressed. So off I went one evening, vibecoding my way through some rough ideas, and by the following evening I had a working prototype that could generate a simple html gallery from a set of photos. By that point, the app was all local, simple html produced on your machine, no network involved. Claude did help me patching together a SwiftUI interface with a Rust CLI to do the image manipulation. HTML generation is implemented in Swift as well. So far, this turned out to be a great combination. For me, because I like both Swift and Rust, and for the app, because the ecosystems both lend themselves well to the respective tasks.

See Claude struggling to identify the work it did.

Now today, or 601 commits later, the vibecoding part has only been a small part of the development. Out of all commits, only 21 were made by claude. So arguably most of the praise I can give to claude code is that it got me started by making me believe I can ship this quickly. And so I did. I shipped an embarrasingly work in progress app to the macOS App Store on May 2nd 2025, got rejected by App Review twice and finally got approved on May 3rd. Since then I have shipped 10 updates to arrive at version 1.5 today, June 29th.

Development is 30% of the effort

As usual, the development of the app itself has been the easy part. The hard part, for me, is everything else that comes with shipping an app: Marketing content, the App Icon, App Store bureacracy, and most of all getting the app noticed by potential users. So in order to aid visibility, I'll crank out a couple more blog posts about the app. So far, I have already submitted the app to macupdate.com and built a website. I'll also do forum posts, post on slack channels, and try to look into Apple App Store Ads, which I have used in the past for iOS but so far can't grok how to use it for the macOS App Store. My original plan was to, as quickly as possible, get a feel for the potential of the app. Only if there are early signs of there being a market for it, had I planned to invest more time into the app. Given that I enjoy working on it, I haven't been that true to this plan. It's really hard judging an MVP of a product and be willing to ship something you're not proud of or even embarrassed by.

What next?

I'll end this here with the output of cloc as of today. This includes the app itself, the website, the infrastructure code for the hosting as well as the image manipulation CLI. It always surprises me how little code it really takes to build something like this.

----------------------------------------------------------------
Language      files          blank        comment           code
----------------------------------------------------------------
Swift            49            358             85           3552
HTML             12            183             30           1574
Rust              2            105             40            613
Python            7             99             45            553
XML               7              0              0            248
Markdown          4             53              0            183
JSON              7              0              0            182
SVG               6              0              5             60
CSS               1              7              0             50
TOML              3              9              0             49
YAML              3              0              0             32
make              1              2              0              5
----------------------------------------------------------------
SUM:            102            816            205           7101
----------------------------------------------------------------

Software development is full of trip-wires, broken processes, short-living projects and more which often times make a developer's life difficult. Most software being broken all of the time is a very common sentiment in the industry. Developer tooling is also very easily neglegted. Believe it or not, against all expectations, a short while ago I had a pleasant experience:

My iOS App PitBuddy is still on the AppStore, but I had last shipped an update more than two years ago. I don't actively develop it anymore; let's say it is in maintenance mode. However, in iOS 13 I believe, some change in the default iOS styling led to a placeholder text in one of the apps TextViews be difficult to read. Should be easy enough to fix, I thought. Thing is, I hadn't even checked out the repo on my current machine let alone built the Xcode project. The project is a mix of Objective-C, some Swift, Cocoapods for any app dependencies. Now that's where most would assume I would have run into a world of hurt. However, I didn't:

bundle install --path=vendor/bundle

just worked. After that

bundle exec pod install

just worked as well. That's where I started to feel like I'm in a dream. Opening the project via

xed PitbuddyApp.xcworkspace

and building it via Cmd+B ran into a couple of minor warnings, but it completed just fine and I was able to run it in the simulator. By that point there was only one thing left to do: run tests. PitBuddyApp has a number of unit tests which built and passed, so that box was checked. I also have a couple of "Acceptance Tests" in place, using the KIF ui testing framework. So those didnt 't pass. However, I simply bumped KIF to the lastest version, and alas, I was back in the green. All in all, from cloning the repo to a fully passing build and test suite it took me no more than 30 minutes. So what do we take away from this?

• Sometimes things just work
• Dependency pinning (both the Gems as well as the Cocoapods) is good
• The bump from Xcode 10 to 12 needed a bump of KIF

Thanks to everyone helping maintain bundler, cocoapoda, etc!

I have dabbled in iOS development, on and off, for many years now. Starting back when UIKit and Objective-C were still the only platform choices, continuing with exploring RubyMotion, slowly making the transition to Swift, playing with React Native and then seeing SwiftUI come to life ... it's been an interesting journey. For a variety of reasons, none of the opinionated options in building an app ever really caught my fancy. Sure, Apple leaves a lot of questions unanswered for architecting an iOS app, but generic patterns like MVVM or MVC can be applied to iOS development without selling your soul to any large third party framework. The smaller the app is, the easier it also is to kind of get away with not really following a specific pattern.

Let me take a second to advertise Planeton, the iOS game that I will talk about in this article. Planeton is a simple, turn-based strategy game you can play against your friends, or strangers, online. Each player starts out with a single planet and can send ships to conquer neutral or other players' planets.

Past fall I set out to explore SwiftUI, and there's no better way to explore a technology than to build something with it. So I chose to develop an iOS game based on the mechanics of one of my older memories of SUSE Linux: KDE Konquest. A new Xcode project was initialized and off I went. At this point I have to give a shout-out to John Sundell, whose website Swift by Sundell was an essential resource for finding quick and easy examples and explanations about SwiftUI features. As the app grew in size (user facing) and lines of code, I became more and more dissatisfied with the way things were shaping up. Clean, modular code and high test coverage are aspects of my work I value a lot. However, in growing the code base more and more, these aspects kind of fell by the wayside. Now granted, I fully accepted that and made a bit of an experiment out of the project to not care as much as I usually do. Still, deep down inside me I knew: if I ever wanted to release and maintain the game, I needed to find a sustainable way to add features and regression test the application. To make matters worse, the game is supposed to be played via Apple's Game-Center, which makes it notoriously annoying to play-test against yourself. I only own a single iOS device, so testing with my device and a simulator is the only choice I have. And believe me, Game-Center and the Xcode iOS simulators are not best friends!

Meet the Swift Composable Architecture

I had come across Pointfree a decent while ago and have been watching the videos Brandon and Stephen put out. They are excellent, you should subscribe! Amongst other topics, they introduced this iOS architecture they call The Composable Architecture. Now probably this immediately resonated with me because I am in a phase of preferring a functional, compositional style of programming by now, more so than wild mutations all over the place and OOP for the sake of it. Dabbling in React in the past probably also helped me in grasping the concept of unidirectional data-flow. In any case, after being annoyed by some horrible SwiftUI views I had produced, mixing state management, side effects, presentation logic and visual styling, I took the plunge and decided to adopt the composable architecture.