{
  "id": 5582108,
  "title": "One Backend, Every Screen: I Built a Cross-Platform Audio App the 'Wrong' Way",
  "url": "https://urgent.news/2026/09/04/one-backend-every-screen-i-built-a-cross-platform-audio-app-the-wrong",
  "topic": "tech",
  "section": "Tech",
  "published": "2026-09-04T14:58:02.000Z",
  "source": {
    "name": "Dev.to",
    "slug": "dev-to",
    "url": "https://dev.to/kornel_maraz_5e66a3e4e27d/one-backend-every-screen-i-built-a-cross-platform-audio-app-the-wrong-way-28mf"
  },
  "original_language": "en",
  "account": "I embarked on a journey to create a cross-platform audio app, but I took a different approach than most. I didn't start with the smallest possible surface or the lowest-effort solution. Instead, I aimed for a comprehensive product that could run on every device in the household and give the admin real control over the family's audio library. This decision led me down a more challenging path, but I believe it was worth it.\n\nI began by building a backend in Rust with Axum, which provided a solid foundation for the entire app. However, I soon realized that I had built the wrong surface. The web app I initially created was not the ideal interface for the audio experience that people would actually use. Instead, I focused on creating a Mac app that served as the control room for the admin. This app connected to Navidrome and Audiobookshelf, allowing users to manage their library and stream content from various sources.\n\nThe sync client was the most challenging part of the Mac app. It had to handle bandwidth throttling, resumable uploads, and robustness across reconnects. It also needed to understand and process various file types, including music metadata, audiobook identification, artist images, and even AI features like narrating books or translating podcast episodes. This technical hurdle was daunting, but once it was solved, the rest of the app became much easier to develop.\n\nI didn't start working on iOS until the Mac client was complete and fully functional. This approach allowed me to reuse the shared backend code I had already written, making the development process more efficient. The iOS apps were designed to have a distinct interface, tailored to the specific needs of audiobooks, podcasts, and music. This decision ensured that each app had a unique personality, reflecting the nature of the content it was meant to consume.\n\nExtending the app to iPad was relatively smooth, thanks to SwiftUI and native components. The advanced testing and automation capabilities of the Swift ecosystem made the development process enjoyable. However, Android presented its own set of challenges. The fragmentation of libraries and languages made it difficult to maintain a consistent experience across devices. Despite these hurdles, I was ultimately satisfied with the thorough, slow foundation I had built, as it made the subsequent platforms much easier to develop for.",
  "summary": "Every \"build in public\" thread and every YouTube growth guru tells you the same thing: pick the smallest possible surface, ship the lowest-effort thing that gets the biggest effect, validate, iterate. It's good advice. For this project I did almost the exact opposite — on purpose — and I want to be honest about why, and what it actually cost. I'm building own.audio: a private home for the…",
  "key_points": [],
  "editors_take": null,
  "illustration": null,
  "coverage": {
    "outlets": 1,
    "also_reported_by": []
  },
  "ai_generated": true,
  "disclaimer": "Summaries, key points and the editor’s take are written by software from other outlets’ reporting and may contain errors — always check the linked original."
}