The challenge
We build mobile apps for clients, and every so often it is worth building one of our own from a blank page to the App Store, with nobody else's deadlines in the way. It keeps the whole team current on the full release process, from design and store assets to backend, review and the privacy and support pages Apple requires, and it gives prospective clients something they can download and hold rather than a description.
We picked hand cricket, the playground game where two people throw a number from 0 to 6 at the same time: match the batter and it is a wicket, miss and the batter scores their number. The rules fit on one screen, which made it a good test of the things that are actually hard in a mobile game: making it feel instant, making online play against a friend reliable on ordinary phone connections, and doing all of it without asking anyone to create an account or handing their data to an ad network.
The brief we set ourselves:
- Instant to play. Open the app and be in a match within a few taps, with no sign-up, login or tutorial to get through.
- Two ways to play. Against the computer with no internet at all, or against a friend who could be in the next room or another country.
- Honest online play. Neither player should be able to see the other's number before throwing, and a match should end cleanly when someone walks away.
- Privacy by design. Nothing collected that the game does not need, and a privacy policy a parent can read in a minute.
What we did
We designed and built Hand Cricket Online as a native iPhone app, with a small cloud backend for the online mode.
The game. You choose overs per innings (1, 2, 5, 10 or no limit) and wickets per innings (1, 2, 3 or 5), call odd or even at the toss, and bat or bowl with a row of seven hand-sign buttons. Against the computer everything runs on the device, so it works on a plane or in a car with no signal. The Record tab keeps your win rate, streak, best and average scores, overs batted and bowled and every recent result, all stored on the phone only.
Online play with a code. The Online tab lets a player host a match and get a 6-digit code to send to a friend, who types it in and joins. The host picks the overs and wickets and calls the toss. Each throw is committed to the server and hidden until both players have thrown, so nobody can wait and react. If an opponent goes quiet for about 45 seconds, the other player is told they seem to have left and can end the game and take the win or keep waiting. After a match either player can ask for a rematch, which the other accepts or declines from a pop-up.
A small, private backend. Online matches run on Supabase over encrypted connections. The only things stored are an anonymous player ID that the app generates itself, the player's chosen name (up to 20 characters), the game's settings, throws, scores and results, and a last-active timestamp for presence. There are no accounts, no analytics, no advertising SDKs and no device identifiers, which also kept the App Store privacy questionnaire short and truthful.
Design and identity. The look is a cricket-green scoreboard on cream, with a light and dark theme the player can switch from any screen. The icon is a flip-board number six with a cricket ball, delivered in light and dark variants so it sits well on either kind of home screen.
Everything the store asks for. Alongside the app we produced the screenshots, description and review notes, and published the privacy policy and support page that Apple requires a public URL for. The support page doubles as the in-app help, so the rules and the answers to "my friend's code doesn't work" live in one place.
The results
Hand Cricket Online is released on the App Store for iPhone, and it is the quickest way to show a client what we mean by a finished app: not just screens, but a backend, a release process, a privacy position and a support channel. Playing against the computer works with no connection at all, and two people with the same code can play each other anywhere in the world with their throws kept honest by the server.
The same approach is how we build apps for clients. We design around the few things the app really has to do, keep the data to what the job needs, choose a backend sized to the problem rather than the biggest one available, and take care of the store submission, the policies and the support page so the release is complete rather than nearly complete. If you have an app in mind, for your customers, your field staff or just for fun, talk to us.