How I Built a Mobile Game for iOS Solo: The LootShrine Case Study

In the ever-evolving landscape of mobile game development, the narrative of a solo developer creating a polished iOS title from scratch is both inspiring and instructive. This article dissects the real-world journey of the creator behind LootShrine, a mobile game that recently launched on the App Store. Based on a detailed technical post on Habr, we explore the architectural decisions, tooling choices, and the gritty problem-solving that defined the project. Whether you are an indie developer or a tech enthusiast, the lessons from LootShrine offer a rare behind-the-scenes look at modern solo game development.

The Vision and Initial Hurdles

The developer behind LootShrine set out to create a minimalistic yet engaging mobile game. The core idea was a loot-collecting experience with a clean, pixel-art aesthetic, optimized for touch input and short play sessions. However, the path from concept to release was anything but straightforward. The author faced three primary challenges:

  1. Solo resource constraints – No team meant every line of code, every asset, and every sound effect was a personal responsibility.
  2. Cross-device compatibility – Ensuring smooth performance on a range of iOS devices, from older iPhones to the latest models.
  3. App Store compliance – Navigating Apple’s strict guidelines for privacy, performance, and user experience.

Technical Architecture and Tools

The project was built using Unity 2022 LTS as the core engine, chosen for its robust 2D tooling and broad iOS support. The developer opted for a custom C# scripting architecture rather than visual scripting, citing performance and maintainability as key factors. Notably, the game uses Entity Component System (ECS) principles for managing in-game loot items, which allowed for efficient memory management and frame-rate stability even with hundreds of objects on screen.

For graphics, the team employed Aseprite for pixel art creation and Photoshop for UI mockups. Sound design was handled with Bfxr for procedural sound effects and Audacity for mastering. The entire project spanned approximately 8 months of part-time work, with an estimated 400–500 hours of development time.

Tool Purpose Why Chosen
Unity 2022 LTS Game engine Stable 2D support, C# scripting, iOS build pipeline
Aseprite Pixel art creation Lightweight, tilemap-friendly
Bfxr Sound effects Procedural generation, no licensing issues
Git + GitHub Version control Essential for solo developer to track changes

One of the most critical decisions was adopting TestFlight for beta testing. The developer reported that over 60 testers provided feedback during the 3-month beta phase, leading to major UI redesigns and difficulty balancing. This iterative loop was vital for polishing the final product.

Performance Optimization on iOS

Mobile game performance is a make-or-break factor. The LootShrine developer implemented several optimization strategies:

  • Sprite Atlasing – Combined hundreds of individual sprites into a few large atlases, reducing draw calls by over 70%.
  • Object Pooling – Instead of instantiating and destroying loot items repeatedly, the game reuses a pool of objects, eliminating garbage collection spikes.
  • Fixed Timestep – Physics and logic updates run at 60 FPS fixed timestep, while rendering can drop to 30 FPS on older devices without affecting gameplay.

The developer shared benchmark data: on an iPhone 6s, the game maintained a stable 30 FPS with a memory footprint of 120 MB; on an iPhone 14 Pro, it ran at 60 FPS with 80 MB usage. These metrics were achieved after three weeks of dedicated optimization work.

Monetization and App Store Strategy

LootShrine follows a free-to-play model with optional rewarded ads (using Unity Ads) and a single in-app purchase to remove ads permanently. The developer explicitly avoided loot boxes or pay-to-win mechanics, citing ethical concerns and better long-term user retention. The App Store listing was optimized with:

  • A/B tested screenshots using StoreMaven analytics.
  • Keywords focused on "idle loot collector" and "pixel art game."
  • A privacy-friendly approach – no third-party tracking SDKs.

Interestingly, the developer noted that the game’s App Store approval took only 2 days, thanks to strict adherence to Apple’s Human Interface Guidelines and pre-submission testing with Xcode’s Organizer tool for crash logs.

Lessons Learned and Practical Takeaways

For anyone considering a solo mobile game project, the LootShrine case study offers several actionable insights:

  1. Start small, polish hard – The developer cut 40% of planned features to focus on a tight core loop. Scope creep is the enemy of solo projects.
  2. Invest in automated testing – Unit tests for C# logic and manual UI testing on physical devices saved weeks of debugging.
  3. Community matters – The developer actively used Unity forums and Reddit’s r/gamedev for problem-solving, which reduced research time by an estimated 30%.
  4. Embrace constraints – Limited time forced creative solutions, like using a single shader for all loot glow effects instead of multiple particle systems.

The article also highlights the importance of documentation. The developer maintained a personal wiki with daily logs, which later became the basis for the technical post. This habit is recommended for any solo developer to track decisions and rationale.

Conclusion

Building a mobile game solo is a monumental task, but LootShrine demonstrates that with the right tooling, disciplined scope management, and a willingness to iterate, it is achievable. The project’s success lies not in groundbreaking technology, but in meticulous execution of established practices. For indie developers, the key takeaway is clear: focus on a polished core experience, optimize relentlessly for your target platform, and engage your test community early.

The full technical breakdown, including code snippets and performance graphs, is available in the original Habr article. Source

This article is based on publicly available information and aims to provide a neutral, informative analysis of the development process described by the original author.

← All posts

Comments