Open Music Event, Native Apps, and the Shape of an ATProto Festival Platform
I’m going to start brain dumping more consistently about Open Music Event, or OME, to hopefully start garnering some ATProto developer ecosystem interest.
Open Music Event is going to be in a public open beta by August 15th.
It’s an ATProto app for concerts, music festivals, and other similarly shaped events.
I’ve been working on this project, as a Swift-based iOS app, for almost a decade. The first commits I can find are from 2019, but I was working on this before I understood version control well enough to preserve them
The focus has remained consistent. I was going to large music festivals and fumbling through folded paper schedules, or using unfortunately bad apps, to find when and where an artist was playing. I was learning Swift in college, and used this app as a playground to practice app development and learn UX design.
Festival Apps Are a Hard Proving Ground
Festivals are a hard proving ground for tech, and apps have it especially hard. These events are hyperstimulating. You may be in, uh, “different” headspaces. And you sure as fuck don’t want to be on your phone. You want to be participating in the awesome real-world event in front of you.
But that doesn’t mean there’s no room for technology, or software applications that can add real quality of life to the in-person festival experience. It just means the tools have to be precise, well designed, and intuitive.
If not, users bounce off immediately, and they have every right to.
A hard requirement for these festivals is native, offline-first iOS and Android applications. Service is hit or miss, and there are a lot of misses, as attendee count overwhelms cell towers that usually have to be brought on site.
This meant that a web app was not acceptable for an MVP.
Additionally, I was a big fan of the Apollo Reddit client, built by Christian Selig. Its focus on making the UI feel like an Apple app was very influential.
Apple and Google design the look and feel of their platforms intentionally, and the general public uses their phone, via iOS or Android, as a daily driver for 99% of their software use. Apps that follow platform conventions can lean into that intuition and knowledge, and “disappear” into the OS.
For Open Music Event and the needs of a festival, that made the choice clear: fully fledged native app, with platform UI. As a Swift developer, that was the easy path for iOS anyways.
First Versions
I built a prototype, manually entered an extensive schedule, and brought it to Shambhala Music Festival so I could use it in 2019ish. It was useful for me, and solved a lot of the problems I wanted it to.
Then the pandemic happened, and I wasn’t going to events anymore. I still worked on it, although during this time I did the first of many full rebuilds of this project, mostly to experiment with tools like The Composable Architecture and SwiftUI.
But as the pandemic wound down, I contacted a real world event, Wicked Woods in Canada. and they were kind enough to let me be the “official app” of the festival, in its infant state. It's about 5k people, and was the right size to start putting the app in attendees hands.
I got light, but positive feedback during the app’s first event, a wish to continue in the future, and a hard requirement of an Android app.
I was expecting this eventually, but wasn’t looking forward to it. I was growing as a Swift developer and didn’t use Android daily. The codebase wasn’t going to work on Android, and even though there were cross-platform solutions, like Flutter, they didn’t fill my needs of platform-native UI.
So I built a parallel Android app.
The first version was Java and the old XML system.
I Managed to ship it for Wicked Woods 2023. It was puny, and feature-lacking compared to iOS, and I wasn’t excited to maintain two codebases.
Got more good feedback that year, and further commitment from Wicked Woods.
Over the next year, Jetpack Compose was mature enough to adopt it on Android. Its similarities to SwiftUI meant that I could share a mental model, and use deterministic Swift-to-Kotlin conversion tools to get the codebases closer.
For Wicked Woods 2024, I shipped the rewritten Jetpack Compose Android app, alongside some requested features like push notifications, so Wicked Woods could communicate with attendees.
Android still lagged behind in terms of features, and the dread of parallel codebase maintenance lingered.
SKIP
But hope was on the horizon.
[Skip](https://skip.tools) started to become a real viable option for cross-platform development, and actually fit my needs, unlike the legacy solutions.
It let me build a Swift app with SwiftUI. At that time, it transpiled Swift to Kotlin and SwiftUI components to Jetpack Compose to run swift apps on Android.
This meant I could keep native OS UI on both platforms, write mostly normal Swift, and maintain platform parity as I introduced features.
But, I had built an app with TCA, and the transpilation tooling wasn’t going to support it.
So, rebuild #5.
Pure Swift, but able to run on Android.
I shipped that for Wicked Woods 2025, last summer. This was the first year that really felt like I had fulfilled the MVP for everybody that used it.
I Got positive feedback across the board and had a grand old time.
The Bigger shape
I always intentionally limited the scope of this app. But I always built this with the knowledge that it could serve more people.
I focused on the user experience during events. In the festival world, it’s pretty normal to work all year on something that’ll just be experienced for the weekend.
I’m also a mobile front-end guy, not a database/server engineer. I knew that I didn’t want to own Wicked Woods data, and I wanted to make that data live long term as an archive of these community events.
The CMS structure for Wicked Woods 2025 was built with this intention in mind.
I would later learn that I made some very ATProto shaped decisions when I designed it.
The source of truth was plaintext in a Wicked Woods-owned GitHub repo, now on Tangled:
Pipelines sent it to S3 for attendees to consume. This is really similarly shaped to the PDS -> AppView model that we now know.
This CMS structure had another intention.
As more people needed to contribute to content in the app, and I talked to the media management at Wicked Woods, their needs really resembled distributed version control that we know as engineers.
They wanted many people to edit, with approvals over final publishing. That smells a lot like how we do distributed engineering work in software.
I hadn’t built UI for editing festival content, but I was able to teach a few non-devs to make plaintext changes and make their first PR.
That was really painful, and wasn’t a long-term solution.
But forms and editing UI is something I’d done a lot of professionally, and would come in time, and is now mostly built out on my machine
ATProto connected the dots.
In early March 2026, I stumbled upon Dan Abramov’s [Open Social](https://overreacted.io/open-social/) article.
It connected so many dots for me. I was honestly blown away.
People were doing things that I didn’t even know I needed to allow my single-event app to become a real platform that could not only serve people, but also participate in a real solution towards fixing the internet.
ATProto had all the tools I needed to commit to rebuilding Open Music Event again, on protocol.
This rebuild came at a good time. Skip moved away from transpilation towards shipping the pure swift binary, and TCA 26 compiles on Android. I finally got to centralize my codebase, with my preferred toolchain.
So since AtmosphereConf, I’ve been heads down rebuilding Open Music Event for hopefully the last time.
Doubtful.
First lexicons will be coming soon, then a private alpha period, and a public launch party on August 15th.
It’ll ship with the ability to hydrate festivals as deeply as Wicked Woods, on ATProto.
It’ll be a superset of Atmo RSVP and the community.event lexicon.
There’ll be a Performance lexicon, bidirectional contributor claiming, and more.
A community “calendar listing” lexicon would be useful too.
Composable Atmosphere
In service of this, I’ve been building an ATProto Swift SDK, built with and for the Point-Free Composable Architecture stack.
It’s called Composable Atmosphere:
This provides the core types for doing ATProto stuff in Swift.
For now, it’s a lot of XRPC and OAuth tooling. Eventually lexicon stuff will land there as well.
It’s integrated in OME already, and its first use was a toy Bluesky client:
I would love to eventually turn this into a high-quality, native mobile, open social “fork”.
I don’t have the time to maintain that at my standard while I’m launching OME, but if someone was interested in contracting me to do it, that would be cool.
All that to be said, a lot more is coming soon! Much more publically.
Sign in to leave a note.