How SAJA Music got started

During the last few months of 2025, I developed an iOS app called BeatMatrix. It was my first mobile app in at least a decade, and my first time coding in Swift (I think it was Objective-C the last time I wrote Apple software). It was just a little app with a limited feature set, but it was still pretty cool. I wanted to try to create something for practising complex rhythmic patterns that thought differently about standard time signatures and subdivisions, with Konnakol-style exercises. It was quite a lot of fun to code, and it came after a long break from tech, after I had finally left behind the burnout of executive IT life. The whole experience served to remind me that, yes, I do in fact enjoy being a software developer (even if it seems there aren't many of us left these days). And it was also great to work with some amazing talent to bring it together (shout out to graphic designer extraordinaire Amy Tonkin, as well as my partner Sally Howe for her endless requirements and design expertise).

But while the experience of creating this app brought a sense of reinvigoration and renewal, I was also surprised that it left me a little ambivalent. On the one hand, I felt energised by tech again after a long time, and started remembering all that childhood tinkering with Linux boxes and open-source stuff. But I also felt that software development at a small scale was somehow not quite the same as it used to be.

I should be very clear that this is in no way any kind of opinion piece about the Apple platform and mobile app ecosystem. In fact, I actually don't know enough about it to even have an informed opinion. And any kind of critique would be grossly hypocritical. I was there in the early days, programming on those groovy-shaped Macintoshes and turning up to WWDC. I celebrated in the computer science department when the news broke that macOS was becoming a curated Unix. And a Mac is certainly my most convenient flavour of Unix even if it is not that cool. So back then, I was excited by what was to come. But as I created BeatMatrix, I was also grappling with a broader question about creating software where there are such limits on your freedom, and not being able to control all kinds of aspects of deployment and testing that I am pretty opinionated about.

And then my little app started feeling too big

As I was writing the code, I had a strange feeling that I was coding to a system rather than following my own software design principles and workflow. There was a lot of working through certificates, provisioning profiles, agreeing to this and that, reviewing distribution requirements and responding to what felt like the whims of a huge machine. And to be fair, this is all good and fine. I have certainly done the enterprise IT thing ad nauseam at different times. But I could not help thinking that I was developing something very simple on an enormously complicated infrastructure, where I seemed to be stuck in someone else's burn rate. It felt a bit like making a sandwich with a nuclear reactor. Fun, I guess, but weird.

Now, the strangest thing about the whole experience (and perhaps this will be to the chagrin of my collaborators) was that when I was done, I was a little uncomfortable promoting it. Admittedly, this was partly because I was nervous that I didn't know enough about all the tooling I had utilised (which seemed a little unnecessarily necessary), and that is usually not what happens to me as a developer. But I was somehow not sure whether what I had developed was high quality or robust. It passed the curation process for the store with a couple of bugs that I picked up in later testing, which I would have railed against in a code review, so the whole thing threw me. Added to this was something else: as a long-term advocate of free and open software, I felt strange talking it up to people, half of whom probably had phones running a different operating system. And then I thought, well, OK, I'll build another proprietary version. Which is all fine, but it left me feeling a little unsettled.

It feels like software has become aspirational

I have written a tremendous amount of software over the years, much of it, I would argue, of very high quality. I learned to program in the days before the internet, long before the vibe, and have worked across all kinds of technical and organisational settings. You get that weird thing as a seasoned coder where you can just see everything coming. I am the kind of developer who expects to return to a codebase years later and find that it simply works, and that the underlying design still feels elegant and artful. I have been known to be pretty tough on my staff during code reviews (tough on code, not on people, who should be treated with kindness and respect — that is important!). This is because I believe that good software engineering involves more than simply producing something that works today.

When I was writing relatively self-contained programs, in C for example, I had a sense that it was possible to aim for code that would run for years in a stable integration environment. That is not universally true, of course, and early languages like C certainly have their own pain points. But the ambition and possibility of making something durable were real. I want to build software that lasts and is easy to deal with when it reaches end-of-life. It is strange, in a way, that we often forget that computer science rests on ideas of extraordinary longevity. It is informed by age-old mathematical principles, bits that flip in predictable and repeatable ways if you set things up with care, and principles that do not become invalid because a platform releases a new version. I feel like we forget that computer science itself, without the deluge of noise that surrounds it, is a pretty immutable affair.

The Rise of the Machines Maintenance

I have been slowly moving further away from the tools over the past two decades as the pain of the boardroom has beckoned, but I still find myself increasingly puzzled by how much maintenance we've come to regard as inevitable in our software. We now write software knowing it will work, provided we keep updating the frameworks, libraries, tools and operating systems around it, of which there are a multitude. The idea of being robust has come to mean surviving the next update rather than continuing to work through thoughtful design. This is not to say, of course, that software doesn't need security fixes, accessibility improvements and genuine advances. I'm not arguing against change. I'm arguing that change and progress are not synonyms, and the relationship between these things is increasingly murky. And it seems logical that longevity should be a measure of engineering quality too.

BeatMatrix was written in Swift, which is fine as far as languages go. But what I found challenging was that I was drawn into all kinds of frameworks, conventions and models that appeared to be a design methodology of regression towards the mean. The generic hoops that I had to jump through made the whole thing feel almost McLuhanesque, like I was building software without content, which was an expression of the machine in which it existed. The medium seemed to have become the message. Again, none of this is a criticism. It seems to be a result of large-scale risk management models morphing into one another. There is probably a Shannon formula one could apply to it all.

In the end, my decision to build a simple metronome on iOS almost felt like a metaphor. I watched this incredibly simple thing become more and more complicated: generate a sound at precisely timed intervals. It was interesting running into issues using Apple's AVAudioEngine, arguably the best-practice tool for a production-quality app, which opens up an extraordinary web of technical complexity. Suddenly you're managing engine lifecycles, starting, stopping and recovering from interruptions; audio sessions, Bluetooth routing and sample-rate changes; scheduling buffers with enough lookahead to maintain accuracy without compromising responsiveness; synchronising musical time with audio playback timelines; coordinating asynchronous tasks, UI updates and transport controls without race conditions; managing buffer lifetimes and completion callbacks; and rebuilding the audio graph when the system changes underneath you. Audio is always like this, and it's super annoying to deal with. Programming a synth that also needs to take photos and phone calls and remind you to stand up was always going to be challenging.

Perhaps the strangest thing I found was that, I would often be quickly prototyping things in JavaScript (simple because you don't need any setup with it), I found the experience was better. Who would have thought it? JavaScript! And this is not because JavaScript is inherently more reliable, but because it's often much easier to recover from a failure state in simpler technology. In JavaScript, I can generally isolate a problem, reset some state, restart a process and carry on. In iOS, particularly when dealing with AVAudioEngine, one task kicks off something that kicks off something else in an asynchronous system (not benign JavaScript asynchronous programming, but something much more complicated), with thread management and framework-controlled lifecycles. Failures can become deeply entangled. Recovering from one problem can trigger another because so much state is managed implicitly across interconnected systems.

It all makes me reflect on how we build increasingly sophisticated abstractions to make software safer, yet sometimes make it extraordinarily difficult to understand, control and recover when something goes wrong. A system that fails occasionally but recovers predictably can be more robust in practice than one designed to prevent failure but struggles to recover from it.

Most of all, the experience left me thinking about the kind of software we now aspire to build. I have always wanted to create software that is not only functional, but elegant, reliable and durable. Yet increasingly, it feels as though we are building software that depends on the continuous maintenance of an enormous technical ecosystem. I began to wonder whether we have gradually lowered our ambitions for longevity, even as the sophistication of our tools has increased.

Returning to the open web

The unexpected outcome of the whole experience has been a renewed enthusiasm for (wait for it!) HTML, CSS and JavaScript. JavaScript has plenty of peculiarities, and the modern web can be needlessly complicated. But a small application built on established web standards can be published directly and opened on a phone, tablet or computer without an app-store review or a platform-specific installation.

For education, that accessibility matters enormously. A teacher can just share a link with a class. Or a student can practise on the device they already have. Someone elsewhere in the world can use the same resource without creating an account or buying a particular product.

And when I fix a bug, I can publish the change myself. Browsers and standards still evolve, of course, but I can keep the application small, avoid unnecessary frameworks and reduce the number of external decisions that determine whether it works.

Transparency and privacy

Open code also makes it easier to be transparent about what an application actually does. For a rhythm trainer or an ear-training exercise, I don't see why users should automatically need an account, tracking use, running analytics or a spinning up a cloud service. In many cases, the application can run locally in the browser after its files have loaded, without sending a student's answers or practice activity anywhere.

That privacy doesn't happen automatically. A website can collect data just as readily as a native application, and open-source code can still contain security mistakes. But I can design for data minimisation, explain any information that is collected, and make the implementation inspectable. I would rather demonstrate those choices than ask users to take them on trust.

Particularly in education, privacy should be the starting point, not an optional feature.

Why I'm opening up BeatMatrix

Let's face it, no one is going to give a hoot about BeatMatrix's source code becoming available. It is a profound non-event. It's about my own catharsis, which will probably go unnoticed. It's an easily reverse engineer ready tiny piece of music software for sure, but it's also about bookending the experience and making something available that others can study, adapt and improve. Someone may be interested in the rhythmic algorithms, the audio scheduling or the interface. Someone else may want to take the idea in a completely different direction. Have at it and sorry about the syntax.

Publishing the code doesn't remove the application's existing iOS dependencies, and an open repository isn't automatically a cross-platform version. But it makes the work visible and gives others a starting point. Once the repository and licence are published, I'll link them here.

And after all that there was SAJA MUSIC

I feel like the whole process has reminded me of something important to me. Software is still a public good. There's a parallel with music that I keep returning to. A score written centuries ago can still be read and performed today because its notation and musical ideas have endured. Software interacts with changing hardware in ways a score doesn't, but I wonder whether we could be more ambitious about preserving our digital work.

The whole experience reminded me of a music software project I began about fifteen years ago. It was an ambitious idea involving music notation, large scale score-searching, analysis and interactive learning, and over the years I experimented with all kinds of technologies to bring it to life. I had almost forgotten about it, and then my partner Sally showed me all the amazing resources she had developed for her piano students, and I wanted to return to create digital resources for some of those amazing ideas. When I wrote this software years ago I had written all kinds of parsers for MusicXML, explored frameworks such as Angular and Django to speed things up, and worked with languages ranging from C to Java to C++ to Python. The project went through numerous iterations, each shaped partly by the technologies available at the time. Looking back, an extraordinary amount of effort went into trying to make it work, but I could not scale the speed of the tech. But now everything has changed, we have infrastucture to develop amazing things with simple technologies.

Returning to these ideas recently, I realised something interesting. Modern computers are now so extraordinarily powerful that many of the things I once approached with complicated software architectures can be accomplished using relatively simple languages and technologies. Applications that might once have required substantial infrastructure can now run directly in a web browser. And perhaps more importantly, they can be built in ways that are understandable, portable and relatively independent of large software ecosystems.

And so I guess that is really where SAJA Music came about. I wanted to return to developing music software, but with a different philosophy. Rather than building large applications around increasingly elaborate frameworks, I wanted to create smaller, modular, self-contained tools that explore interesting musical and educational ideas. Applications that are easy to share, respectful of privacy, freely accessible and, hopefully, still useful long after I've moved on to something else.

The point isn't to reject modern tools or pretend that older software was perfect. It's to make conscious choices about complexity, dependence and the people our software is meant to serve. There is something appealing about building a small application that does one thing particularly well, using open standards and broadly available technologies, without requiring accounts, subscriptions or an elaborate infrastructure to keep it running.

I am of a vintage where I keenly remember a time before the internet, and then the arrival of the internet. I was once with a dear friend of mine in the University of Sydney Physics Department when I first sensed the gravity of this network for sharing information, and I had this feeling that it promised to expand creativity, intellectual freedom and access to knowledge. I still find that vision compelling. SAJA Music is, in many ways, an attempt to return to that original promise and excitement: using technology not as an end in itself, but as a way of exploring music, sharing knowledge and creating things that might have some lasting value.