{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreiepvnifrq3icfwvbt4qvp63iheedepmhs5h7i2b7tnvy76zfvaq7u",
    "uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpg7s46po3m2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreidufrkpf5lm4h7oig3gwasuqavwwulxaw5rxhf3owostzpjgeok6y"
    },
    "mimeType": "image/webp",
    "size": 65758
  },
  "path": "/moakkaddev/building-ar-hide-and-seek-shipping-a-solo-indie-lidar-game-to-the-app-store-26ng",
  "publishedAt": "2026-06-29T09:36:39.000Z",
  "site": "https://dev.to",
  "tags": [
    "ios",
    "swift",
    "gamedev",
    "indiedev",
    "moakkad.dev"
  ],
  "textContent": "The idea came from an extremely serious game of hide and seek with my cousins. We were adults, which made it ridiculous, but also strangely perfect. Someone was hiding behind a couch in plain sight, surviving only because the seeker did not look carefully enough.\n\nThat made me wonder: what if looking carefully was not enough?\n\nWhat if the seeker could not freely look around the room? What if they could only see the world through their phone screen, while virtual obstacles blocked parts of their view?\n\nThat became the core idea behind AR Hide and Seek: a local multiplayer hide and seek game where 2-5 players use the space they are already in. The hiders physically hide somewhere in the room, while the seeker views the environment through an iPhone. The phone fills the space with digital clutter, making familiar rooms harder to read.\n\nOne phone. One seeker. Real hiding places. Virtual obstacles.\n\n##  Why LiDAR?\n\nLiDAR on iPhone Pro models gives the phone a real-time depth map of the environment, with centimeter-level understanding of the space around it. That means virtual objects can be placed in ways that respect real-world geometry: a crate can sit on the floor, a wall can align with an actual wall, and obstacles can feel like they belong in the room rather than floating on top of it.\n\nFor a game where the virtual environment needs to feel like it genuinely fills the space, that difference matters immediately. Without reliable depth information, objects can drift, clip, or hover in ways that break the illusion.\n\nThe tradeoff is device requirement. LiDAR is only available on iPhone Pro models, which narrows the audience. But for this game, the better AR experience was worth it. The seeker sees a version of the room cluttered with virtual obstacles. The hiders are still physically hiding behind real furniture; the phone does not make them disappear. It simply makes finding them harder.\n\n##  Designing the Core Loop\n\nThe mechanic is simple on paper, but it took a surprising amount of tuning to make it feel fair.\n\nA round works like this:\n\n  * Hiders get a short window to move into position.\n  * The seeker waits with their eyes closed while a countdown plays.\n  * The seeker scans the room through the phone.\n  * Virtual obstacles fill the mapped space.\n  * The seeker finds and tags each hider through the AR view.\n\n\n\nThe first playtest revealed that the obstacles were too effective. With enough clutter, the seeker was basically navigating blind. I reduced the obstacle density, adjusted the setup timer, and kept testing until the game felt challenging without becoming frustrating.\n\nBalancing an AR game is weirdly similar to balancing a board game. A lot of the work comes down to tweaking numbers, watching how people behave, and adjusting after each round.\n\nThe scanning phase needed its own attention. Before the round starts, the seeker slowly pans the phone around the room so the AR system can understand the space. The more thoroughly the room is scanned, the more convincingly the obstacles can fill it.\n\nTo make that process easier, I added a scanning UI with progress indicators, directional cues, and a radar-style animation. The goal was to guide players without making the setup feel like homework. Once players see the obstacles appear in the room, the concept clicks quickly.\n\n##  Keeping It Local\n\nAR Hide and Seek is local multiplayer: one device, passed between players. That decision was intentional from the beginning.\n\nReal-time AR multiplayer over a network is a very different product. Every device would need to agree on where “here” is in physical space, compensate for latency, and maintain a shared session. That is a fascinating problem, but it was not the right problem for version one.\n\nThe single-device model keeps the experience simple. The seeker holds the phone. The hiders go hide. There is no account setup, no pairing, and no waiting for connections. A round can start in under 30 seconds.\n\nThe cost is that the game is inherently pass-and-play. A future version could explore shared AR sessions across multiple devices, but for the first release, one device let me focus entirely on making the core AR mechanic work.\n\n##  Building It Solo\n\nWhen I started, I had no prior coding experience. Everything I know about making this game came from building it: trial and error, a lot of reading, and mistakes that sometimes cost me days before I understood what had gone wrong.\n\nUnity helped because it gave me a visual environment to work in. When I was still learning how the pieces connected, being able to see objects, cameras, scenes, and interactions made the process much less abstract.\n\nThe hardest part was not one specific technical problem. It was managing scope.\n\nSolo development means every decision about what to build is also a decision about what not to build. The temptation to add more is constant: more obstacle types, more game modes, more settings, more effects. But every feature is time, testing, bugs, and polish that you are responsible for alone.\n\nI cut more ideas than I shipped, and the game is better for it.\n\nThe features I am proudest of are the ones that directly support the core loop: the radar-style scanning animation, the proximity warning that pulses when the seeker gets close to an obstacle, and the countdown audio that builds anticipation before the round starts.\n\nNone of these are flashy by themselves, but together they make the game feel more complete.\n\n##  The App Store Submission\n\nSubmitting to the App Store as a solo developer is its own ritual. For AR apps, the review process can be especially sensitive because the experience depends on hardware, movement, and the physical environment.\n\nMy approach was to make the review process as clear as possible.\n\nI included screenshots showing the AR view in action, with real rooms and virtual obstacles visible on screen. I added a short demo video in the review notes showing a complete round, about two minutes of footage from setup to gameplay. I also made the LiDAR requirement explicit so reviewers would know to test the app on a supported device.\n\nThe first submission was approved without issues. Review took about 28 hours.\n\nThe biggest lesson was that review notes are not just a formality. For hardware-dependent apps, they are part of the product handoff.\n\n##  What I Would Do Differently\n\nThe scanning UX is the roughest edge.\n\nNew players do not instinctively know how important scanning is before the round starts. I have watched players rush through the scanning phase and then wonder why the obstacles feel sparse. The room fills in gradually as the space is mapped, so if the player starts too quickly, the initial layout can look thin.\n\nA more guided first-run experience would help solve that.\n\nI would also think about content variety earlier. The first version shipped with a small set of obstacle shapes. Adding more variety after launch meant revisiting an asset pipeline I had not fully designed for scale.\n\nThe lesson is simple: design your content system before you need it to grow.\n\nThe third thing I would change is playtesting. Most of my early testing was with people who already understood the concept because I had explained it to them. When I later gave the game to people with no prior context, they revealed friction points I had completely missed.\n\nTest earlier with people who are coming in cold.\n\n##  What Is Next\n\nAR Hide and Seek is live on the App Store, and I am continuing to refine it through small updates.\n\nThe next project I am working on is AR Shadow Tag, which builds on some of the same AR foundations but takes the idea in a different direction. More on that when it is closer to ready.\n\nIf you are building AR games for iOS, experimenting with LiDAR, or making your first game as a solo developer, feel free to reach out. I am always happy to compare notes with people working on similar ideas.\n\n_This post originally appeared on moakkad.dev. I write more there about shipping small AR games as a solo iOS developer._",
  "title": "Building AR Hide and Seek — Shipping a Solo Indie LiDAR Game to the App Store"
}