Get Info: #optimisation

Today I shipped 20 apps and a screensaver

by Matt Sephton — Fri, 17 Apr 2026 18:00:00 +0000

Shipping software is hard. My secret to doing it successfully is a combination of careful scoping, with strict avoidance of feature creep. But even then, it’s still insanely difficult to ship something.

Shipping multiple pieces of software one after the other in quick succession would be an even more gruelling task. Nobody in their right mind would choose to do such a thing…right?

Right?

I must have missed the memo because I’m shipping 20 apps and a screensaver…today!

14 × macOS apps (Mac App Store)
3 × macOS apps (TestFlight)
2 × iOS apps (App Store)
1 × macOS app (GitHub download)
1 × macOS screensaver (Web download)

Get them at gingerbeardman.com/apps/

Twenty!?

Yup. So I think it’s a bit of a myth that software takes huge teams to make. Some of the most successful software of all time was created by individuals: MacPaint, HyperCard, Minecraft, RollerCoaster Tycoon, BitTorrent, Stardew Valley, WinAmp, Flappy Bird, Vim, the World Wide Web, HTML, URLs, and HTTP (those last four by the same person, Tim Berners-Lee). Or perhaps it was made by power duos: Photoshop, Doom, Quake, Google, WhatsApp, Figma, Sensible Soccer. It’s still quite common today, especially in the indie scene, but perhaps it’s not talked about as much?

I started making software in 1990 on the Atari ST, moved to Windows and the web in 1995, then to Macintosh in 2000, and iPhone in 2007. My apps and games have been featured in publications around the world, been downloaded millions of times, and one of my games—which happens to be only 39 KB—received a “best game of the year” accolade alongside Mario and Zelda. The only time I wasn’t actively making and releasing software was during my time working for Apple as a Technology Evangelist, because they don’t allow it.

So I had a bunch of apps that I’d built for myself over the years, and friends kept encouraging me to release them. Making an app for yourself is one thing, but shipping an app to the public is much more difficult. If I was to release one app every month it would take me almost two years to release them all! Doing the App Store Dance to that kind of beat is my idea of hell. So I decided to do it “once” for all my apps. It still took a couple of months to get them ready, and a further month to get them all approved. I do not advise anybody else do this, because it was painful. But I did it, and here we are!

WTH!?

To ship this many apps at once I had to optimise my workflow to an unprecedented level: Xcode projects set up as similarly as possible to reduce cognitive load, shell scripts to automate common build and test tasks, a script to generate changelogs ready for submission, another to automate incremental website builds based on changed files, and one more to generate screenshots of my screenshots, followed by asc to automate uploading data to App Store Connect.

Code hygiene got the same treatment. I ran Periphery across every project to find and remove dead/unused code, which shrinks the binary. Then jscpd to spot copy-paste duplication or similar code sections and refactor them into shared helpers, which can sometimes increases binary size slightly, but it’s a price worth paying for maintainability across so many codebases. There are several Xcode/compiler optimisations that can help strip unused data from the final binary, if you’re careful. I also “cheat” by adding only the largest icon size to macOS apps to avoid over 100 KB of additional icon size variations.

For the website I created a static site generator that uses a simple templating system to generate a static site for 20 apps, the whole thing is spat out in only 36ms. Each app has its own markdown content file with YAML front matter, markdown description for the press kit, privacy policy, RSS feed XML (managed by my app Feedit), maybe some FAQs, an SVG icon, and a bunch of screenshots in both light and dark mode. The press kit is zipped up on a full build and the static site is uploaded to my server over WebDAV. I even managed to hide a fun little mini game in there! The time and effort spent on this system over the last couple of months was roughly equivalent to building another app. But it was worth it.

Most of my apps cost a small amount up front. That’s a way to show your appreciation for the time I spent making them. It also means I never need to use ads, tracking, or subscriptions to make it worth me doing this. After all making software is my job, not a hobby. All apps are actively maintained—if an app hasn’t been updated in a while, it means it has reached a stable state, rather than it being abandoned. Supporting older versions of macOS comes for free when you’re not tied to dependencies that have their own requirements and release schedule.

Pricing is kept dead simple: $5, $10, or $15. Three tiers, no tricks, no “Pro” upsells, no subscriptions. Small utilities are $5, mid-size apps are $10, and the most capable or niche apps are $15. A couple are free, and there are some bundles to save money.

Fits On A Floppy

Many of these apps are small enough to fit on a 1.44 MB floppy disk. Not as a gimmick but as a discipline. I use only native frameworks, avoid dependency bloat, and keep features focused. Writing small software is harder than writing big software because every line of code has to earn its place. But the result is apps that download in a blink, launch instantly, and respect your system resources. I don’t miss floppy disks, but I miss the mindset they demanded: that every byte matters, that constraints breed creativity, and that software should be light on its footprint.

Read the full manifesto at fitsonafloppy.com and spread the word! ✨💾✨

The App List

These apps were all built to fill personal needs, but friends have encouraged me to release them for others to use. This is the bit where I was set to claim oldest app was about 8 years old, while the newest apps was about 8 days old. But sadly App Store Review got in the way, by rejecting my oldest app that I’ve had installed on my own phone since 2019 for being “too derivative” (I’ll revisit that and launch it another time), and they took longer to review the newest app than it did for me to develop it. Other fun rejections along the way: inappropriate use of the word “Safari” in an app for managing Safari browser tabs and bookmarks, and use of web server entitlements in a web server app, sending a video of me ejecting a physical CD-ROM drive, the list goes on. But you get the idea: these apps have taken a while to arrive.

Anyway, here they are, have fun with them:

Barfly macOS

Analytics for your itch.io games, right in the menu bar. Track views, downloads, and purchases with delta tracking across configurable time periods from one hour to one week. Refresh on a schedule and keep historic data.

Brutify macOS TestFlight

Lossless image optimisation using 14 engines running in parallel. Drop in images or folders and get perfectly optimised JPEG, PNG, GIF, and WebP assets without any quality loss. Fast, Slow, or Lossy modes to suit any workflow. A modern ImageOptim.

Ditto macOS

Translate text without switching apps. Copy text twice with CMD+C and your clipboard is translated using Apple Translate or DeepL. Includes a floating window for real-time translation as you type. A DeepL alternative.

Dottie macOS TestFlight

A native Mac pixel art editor built from scratch. Drawing tools, layers with onion skinning, frame-based animation, custom palettes with Lospec import, and export to PNG, GIF, SVG, and sprite sheets. A native macOS alternative to Aseprite, Piskel, Pixen, etc.

Driveaway macOS

Removes macOS metadata junk from external drives before you eject them. No more .DS_Store files, Spotlight indexes, and AppleDouble resource forks cluttering up your USB drives and SD cards.

EQer macOS

A system-wide 10-band equaliser that processes every app on your Mac in real time. Pick a preset, drag the curve, or paste your Audiogram and let it calculate the right listening curve for your hearing. Includes per-app control and dynamic range compression.

Feedit macOS

An editor for creating, managing, and publishing RSS 2.0 feeds. Import existing feeds, edit every field, validate against the spec, and publish to a local folder or WebDAV server. Drafts, iCloud sync, and Find & Replace built in. An alternative to Feeder.

Hubble macOS

Interactive USB topology viewer for macOS. See your complete device tree as a zoomable canvas with speed-coded cables, throttle warnings, power diagnostics, and hot-plug animations—all updating in real time.

Last Dance macOS download

Solves a persistent macOS bug where SMB file sharing becomes unresponsive after restart. It automatically disables file sharing before shutdown and re-enables it at login. No worries.

Localmost macOS

Spin up a local HTTP server by dragging a folder onto your menu bar. Multiple servers, automatic port assignment, access logs, and directory listings—all managed from a clean native interface.

Mojibaker iOS free

Create profile pictures with your choice of colours, gradients, images, then overlay emoji, genomji, memoji or stickers. Type a mood to get colour suggestions, compose your design, save presets, and export at high resolution.

Octoping macOS

GitHub notifications in your Mac menu bar. See what needs attention, grouped by repository with colour-coded icons matching github.com. Mark items as read or open them in your browser.

PaperTrail iOS

Full TaskPaper editing on iOS. Projects, tasks, notes, and tags with a powerful search query language, collapsible projects, widgets, and more. Syncs via iCloud and works with TaskPaper on Mac.

Seeports macOS

Shows every TCP port listening on your Mac from the menu bar. Ports are automatically grouped by service—Docker, OrbStack, Kubernetes, and more. Copy a localhost URL, open in browser, search for info on unknown ports, or terminate a rogue process.

Spindle macOS TestFlight

Raw device access for byte-accurate CD and DVD extraction, with support for hybrid ISO 9660/HFS discs and triple hashing for verification. Rip from multiple drives simultaneously.

Stapler macOS free

Bundle related files into logical projects without moving anything. Opening a single .stapled document opens your artwork, code, todo list, and your reference docs—all at once.

Tabulator macOS

A bird’s-eye view of every Safari tab across local windows, tab groups, cloud tabs, and bookmarks. Search, sort, tag, export, and manage tabs from one place. Includes a vertical tabs mode, Safari extension to show open tab count, and automatic daily backup with easy restore.

Tsundoku macOS

Quick access bookmarking for self-hosted services. A global hotkey captures the URL and title from your browser, suggests tags, and posts to Linkding, Raindrop, Shaarli, LinkAce, Karakeep, or Wallabag.

Vanishing Point macOS

Perspective correction for photos and images. Four correction tools with Apple Vision auto-detection, 256+ aspect ratio presets, background removal via Vision framework, colour sampling, plus image adjustments. Export as PNG, JPG, or TIFF. QuickLook and Finder Thumbnails are supported.

Wavelet macOS

Sound effect generator powered by synthesis, based on classic sfxr. One-click presets for laser zaps, coin pickups, explosions, and more. Layer multiple sounds with the built-in mixer and export as WAV, or as code in Lua, or Swift.

“Fits on a Floppy” Screensaver macOS download free

And finally, technically, the 21st release: a macOS screen saver inspired by After Dark and its classic Flying Toasters. It features flying disks that do barrel rolls and spins as they drift across your screen. Thanks to my friend Jason Morley for the idea, which I built while waiting for App Store Review to finish processing the rest. To make this easier, I upgraded the old test harness I built for my Today screensaver back in 2009.

iOS Low Data Mode reveals true app update sizes

by Matt Sephton — Wed, 06 Aug 2025 19:43:00 +0000

An interesting side-effect of iOS Low Data Mode is that it shows you the exact size of an app update for your device, often a tiny fraction of the listed app size. This is because (delta) updates contain only the files that have changed. Even a first-time install is smaller due to app slicing/thinning containing only what is needed for that device.

The larger size is the universal app size containing assets for all devices. It’s simpler and less confusing for everybody to see the same size.

There are more screenshots at the comment links.

YOYOZO (or, how I made a Playdate game in 39KB)

by Matt Sephton — Tue, 21 Nov 2023 23:59:00 +0000

2023-12-27—Ars Technica: YOYOZO wins GOTY accolade! almost unbelievable to be listed alongside such games as: Chants of Sennaar, Cocoon, Dave the Diver, Humanity, The Legend of Zelda: Tears of the Kingdom, Pikmin 4, Puzzmo, Super Mario Bros. Wonder, Venba and Viewfinder.

A game I made for the Playdate handheld was released today! Go buy it and then come back to read this blog post.

It’s called YOYOZO and in it you control a space yo-yo and have to collect stars in a sort of cosmic ballet. Well, at first it might feel a little like being on a fairground ride, but eventually you’ll become good enough for it to feel like ballet. The concept is based on my memory of a game called Pendulumania that I played 20 years ago.

The most amazing thing about this game, for me, is that launch version weighs in at a file size of only 39KiB. I’m using the KiB unit of measurement which equates to 1024 bytes. I still find it hard to believe as the game contains so much! In this blog post I’ll go into some of the nerdy details.

Playdate?

Playdate is a handheld gaming system with a unique crank input method. I don’t use the crank in this game, but I have done in the past and will do again in the future.

If you own a Playdate you can buy the game now at play.date/games/yoyozo/. If you don’t own a Playdate, well, what are you waiting for?

But…why?

The drive to produce a small game started after I sent the first playable version to testers. Steve at Scenic Route Software, purveyor of quality video games, commented how tiny the game was. At that point it was 18KiB, but had no music or sound effects or polish. There was a long way to go.

Even so, I wondered how doable it would be to build the game out with an eye on keeping file size “low”. I thought back to the days of my youth where whole games would fit on a single floppy disk, with room to spare. If they could do it, shouldn’t I give it a try?

It’s worth noting that even with this mindset, I didn’t make a huge sustained effort to meet the goal. On the contrary, it was just something I simply kept in mind as development proceeded. For that reason, I’m sure there are more ways the game could be made even smaller than it is, with the exact same code and content. For example, I never tried finding the most optimal format for things like music and particle data which are the two largest sets of embedded data.

Finally, this is not a challenge, or me throwing down the gauntlet in any way. It’s easy enough to make a smaller game, be it similar or entirely different, you’d just have to make different choices along the way. This was just me doing something nerdy as an additional constraint on top of the already enjoyable constraints of developing for Playdate.

That said, I think every game developer should regularly make a point of writing code for an underpowered device as part of their own personal development—there are so many lessons to learn.

Reasons

The main reason for the small file size is the fact that the game does not use any digital sound files, and very few bitmap images (the launch card and animation have to be bitmaps, and in-game only the logo and fonts are bitmaps). Game graphics are all drawn using only shapes (lines, rects, circles) and fills (black, white, and dither patterns).
A second reason is that whilst I use the base Playdate Lua SDK, I don’t use any of the additional “CoreLibs”. The only extra graphics functions I needed were for drawing outlined or filled circles, so I use two of my own wrapper functions that are similar to those from CoreLibs/graphics but mine are smaller and more specific. For timers, I use a simple frame/tick system, an approach which has pros and cons, but it’s good enough for me.
A third reason is that I made the tough decision to reduce system assets, which means there is no animated launcher card. This was a tough one, but it added so much to the file size I decided against it.
Finally, I noticed that including data inside your game code often trumps how well you can compress it and store it externally. For example I tried compressing the music data and storing it in an external file, but the game final file size was larger than if I embedded the data in my Lua code. Plus, it’s faster as it doesn’t need to load an additional external file.

Breakdown

I thought it would be cool to outline the main features and how each contributes to the total file size. Note that the sizes are expressed as quantities of the compiled binary, rather than uncompiled source code. It’s also worth noting that a blank project with an empty update function results in a compiled binary of only 147 bytes. Playdate compiles to Lua bytecode.

Content	Kilobytes	%
Main code	19	49
Two music tracks	5.5	14
Three bitmap fonts	2.5	6
Synthesized sound effects	2.5	6
Custom particle system	2.0	5
Animated system icon	2.0	5
Animated system card	2.0	5
Pulp music engine (modified)	1.5	4
Online scoring system	0.5	1.25
How to play instructions	0.4	1
Custom soundtrack capability	0.1	0.25

“Main code” contains: physics simulation, game structure and state management, multi-layered scoring and bonus system, score/stat tracking, loading and saving stats and settings, path recording and playback, animated introduction, plus the following dynamic systems: scrolling starfield, screen shake, music system, sound effects system. All running at 40fps.

Abandoned and removed features

I tried a bunch of stuff during development. Such as asteroid fields or meteor showers that introduced obstacles that needed to be avoided, and black holes that would magnetically attract the ball. But I felt they detracted from the pureness of the concept, so I didn’t go any further with them.
The positions of stars are randomly generated, but I have implemented a fixed “daily” layout in the game, which is really fun. It’s a different experience to be able to play the same layout over and over, improving your execution of the same moves and eking out higher and higher scores. I did plan to reintroduce that option when Playdate Catalog got score boards that reset daily, but by the time that happened I was no longer developing Playdate.

Manual/Guide

I really loved the manuals that came with games in the 8-bit and 16-bit era. So I thought it would be fun to write a manual/player’s guide in the old-school style. I love reading those sorts of manuals, where the developer gives you a little glimpse behind the curtain so you get an understanding of how the game works, with some small hints and tips littered throughout—for the most inquisitive players! If that sounds like your thing, download the manual from the game page.

Timeline

I worked on YOYOZO from September 5th to 27th, submitting it to Catalog on 21st and polishing it for the final week after that. After the game was approved I added online score boards one evening just prior to launch. It was in review and waiting for release longer than it was in development!

The purpose of this section is not to say that developing a game quickly is better than developing one slowly, or vice versa, but rather to show the importance of scoping a game well and then sticking to the plan.

2023-09-05—initial prototype
2023-09-07—playable prototype (3 days)
2023-09-07—quick progress (3 days)
2023-09-09—came up with the name (5 days)
2023-09-14—polishing and balancing (10 days)
2023-09-20—revelatory physics tweak (16 days)
2023-09-21—addicted to my own game (17 days)
2023-09-21—submitted to Catalog (17 days)
2023-09-23—game over replay (19 days)
2023-09-26—layout design using spreadsheet (22 days)
2023-09-26—game over stats screen (22 days)
2023-09-27—final version (23 days)

…and then some waiting until:

2023-10-10—approved for Catalog (36 days)
2023-11-19—added online scoreboards (76 days)
2023-11-21—released on Catalog (78 days)

…so that is 78 days (11 weeks) from initial prototype to being live on the Catalog store!

Credits

YOYOZO is a game by Matt Sephton, with music by Jamie Hamshere.

Thanks to CANO-Lab and Testers.

Elsewhere

2024-10-16—Game Republic 2024 Awards: Best Indie Game Made in the North of England
2024-03-08—Playdate Community Awards 2023: Best Arcade Game
2023-12-27—Ars Technica: YOYOZO wins GOTY accolade!
2023-11-30—Ars Technica
2023-11-24—Hacker Newsletter
2023-11-23—Time Extension
2023-11-22—Hacker News
2023-11-22—Tildes

PNGenie image optimiser

by Matt Sephton — Fri, 03 Jul 2009 12:00:00 +0000

PNGenie is lossless PNG optimiser for Mac OS X.

A PNG file contains image related data. This data can be stored in a multitude of different ways and the file size will vary for each storage method—even with the same raw image data. Image files often have an attached resource fork that also artificially increases the size of the file.

PNGenie optimises any given PNG file—trying out different methods of compression—with a goal of achieving the smallest file size. Smaller files are good for a number of number practical reasons as well as, obviously, saving disk space. Let’s say you want to reduce the size of data files belonging to an iPhone application, or you want to speed up loading of a website that uses PNG images, for example. Resource forks, gamma values and software-specific tags are automatically stripped, too.