Mobile · 2026
PopShot!!
- Year
- 2026 – now
- Scope
- Mobile · Academic
- Role
- iOS Developer (Frontend)
- Team
- Team of 6
- Stack
- Swift, SwiftUI, Go, WebSocket
- Status
- Ongoing
Gamified travel documentation for groups.
An iOS app that turns group travel documentation into a game. Members complete photo challenges during a trip, and the collective album unlocks only once the trip ends.
PopShot!! targets travellers aged 13 to 25 who travel in groups. Instead of taking photos passively, members complete photography challenges together, compete lightly, and end up with a shared album that acts as the reward at the end of the trip.
Read moreShow less
The product rests on three ideas: gamification through challenges, sidequests, and a Gamemaster role; real-time collaboration over WebSocket so every member's screen stays in sync; and a collective album deliberately locked until the trip is marked complete.
A trip is created with a destination type and a challenge type, Color Hunt or Pose Hunt, which generates a six-character invite code for up to ten members. Members gather in a real-time Waiting Room and each claim one exclusive sidequest card before the Gamemaster starts the trip. During the trip the camera screen overlays the active challenge, and photos are filed as main challenge, sidequest, or photo dump.
A real-time iOS social game built around playful group photo missions.
Brief
Problem
Young people come back from a trip regretting how little of it they photographed, either because they were too present in the moment to reach for a camera, or because one person ended up as the group's only photographer. What does get taken is then scattered across WhatsApp, Instagram Stories, and each person's own gallery, and collecting it afterwards falls on whoever cares most.
Solution
Give every member a concrete reason to shoot: timed photo challenges and a personal sidequest, synced live across the group. Withholding the shared album until the trip ends turns the collected photos into a payoff rather than a chore.
My role
- 01
Built the iOS client: authentication, adaptive landing, trip creation and joining
- 02
Implemented the real-time Waiting Room and its WebSocket client
- 03
Built the camera screen with live challenge overlay and categorised photo upload
- 04
Built the Memories screen and the shared album unlocked after trip completion
Features
- 01
Trip creation with destination type and challenge type, producing a six-character invite code
- 02
Real-time Waiting Room where sidequest cards are claimed exclusively
- 03
Gamemaster role that starts and ends the trip for everyone at once
- 04
Camera screen overlaying the active challenge: Color Hunt or Pose Hunt
- 05
Photos filed as main challenge, sidequest, or photo dump
- 06
Shared album locked until the trip is marked complete
- 07
Memories screen showing photo counts per member
Architecture
An iOS client in Swift talking to a Go backend over REST for state changes and WebSocket for live Waiting Room sync. PostgreSQL holds trip and member data, photos go to Google Cloud Storage, and the backend runs on a GCP VPS.
- Front end
- Swift, SwiftUI
- Back end
- Go, WebSocket, JWT
- Data
- PostgreSQL
- Infrastructure
- Google Cloud Platform, Google Cloud Storage
- Tools
- Figma
Challenges
- 01
Problem
The team was handed "travel" as one of three possible topics, and the space turned out to be enormous. They opened by listing every problem they personally had on a Miro board and picking one to solve, and by day four of a six-week window the discussion had stalled.
Solution
The head of the Apple Developer Academy @BINUS in Bali looked at the board on day four and gave two pieces of feedback: stop running a problem-then-solution flow, because the board itself was forcing the idea to narrow before it was understood, and stop rushing; four days into six weeks is not behind. The team deliberately slowed down, spent time bonding first, and re-ran the discussion from there. That is where the real problem statement came from.
- 02
Problem
The reframed problem statement was still just something the six of them believed, arrived at by talking to each other.
Solution
Ran interviews with people matching the target profile to test the statement before committing the remaining weeks to building on top of it.
Lessons
- 01
Four days into a six-week window is not behind. Rushing the framing cost more than the speed it bought.
- 02
A board full of listed problems quietly steers a team into problem-then-solution thinking, which narrows an idea before anyone understands it.
- 03
A team assembled at random needs shared footing before it can make decisions together, bonding was not a detour from the work, it was what unblocked it.
- 04
The problem statement that finally held was specific about the moment it described, not about the category it sat in.