2021Published
Movinder
Swift · UIKit · Firebase
Overview
A Tinder-style iOS app for deciding what to watch together, built at sixteen.
Movinder is a Tinder-style app for deciding what to watch: you swipe on movie cards, add friends by username, and likes collect on lists to plan movie night from. Swift and UIKit with every screen written in code, Firebase as the whole backend, and a movie catalog scripted in from the Netflix library of the day.
It came from a standing problem (two people, one movie night, zero decisions) and one bored February at sixteen. The release plan matched the budget: a direct Xcode-to-USB pipeline onto my friends' iPhones, where it found its first users. The first app of mine that ran on somebody else's phone.
Why does it exist?
Movie night kept stalling on the same step: picking. We could scroll titles all evening and still end up watching nothing. The fix was small on purpose: an app where two people swipe on movies, and what both like turns into a list for the next night in. Movie + Tinder = Movinder.
In February 2021 I was making websites and wanted to learn apps instead, so I learned on this one: Swift, UIKit, and every screen written in code rather than storyboards. Sixteen years old at the time.
How does it work?
The card deck is hand-rolled. Up to ten card views stack in one container, a pan gesture drives the top card, and the rotation follows the drag at one degree per twenty points of travel. Past a hundred points the card springs a thousand points off screen and the swipe counts; short of that, it snaps back to center. The buttons underneath trigger the same animation.
Firebase does everything else: email/password accounts with profile photos on Storage, and six Firestore collections holding users, movies, swipes, matches, friends and requests. Friends are found by username, every liked title lands on your list, and every friendship gets a shared list of its own on top.
Where did the movies come from?
From the backend, in bulk. The catalog was the Netflix library of the day, a few thousand titles with poster, rating, runtime and release year, scripted into Firestore so the app could stay a pure client: open the deck and the movies are already there.
The catalog turned out to be the project's real hard problem, solved outside the app entirely. Lesson banked at sixteen: the data pipeline is the product.
Why Firebase, and why all-code UI?
Firebase because it was 2021 and the fastest route from empty project to working product: accounts, storage and a database with no server to write. The right call for a first app with a one-person team, and it kept the build about the app instead of about the backend.
The all-code UI is the half I would keep from that year either way. Zero storyboards across 43 files means the whole interface reads as source, layout included, and the deck's gestures and spring physics live in reviewable code instead of tool state.
What did it set in motion?
Every app route needs a first entry, and this is mine: the first time I ran the full loop from empty project to an icon on someone else's home screen. The years after it filled the same shelf with a two-sided wardrobe manager, and the brief has not changed since: two people, one movie night, and an app that ends the scrolling.
Field notes
- 43 Swift files, 4,282 lines, 15 view controllers, zero storyboards: every screen is code, laid out by a hand-rolled anchor(...) constraint DSL.
- The swipe deck: up to 10 stacked cards, one pan gesture, rotation = translation.x / 20, a 100 pt commit threshold, a 1,000 pt spring off screen.
- Six Firestore collections (users, movie, swipes, matches, friends, requests), two Storage buckets, email/password auth with profile-photo upload.
- The catalog was scripted in, not fetched: the app reads its movies from a Firestore collection seeded from the Netflix library of the day.
- Written Feb 25 to Mar 22, 2021, per the 43 Xcode file headers; on GitHub since Jul 25, 2021.
Source
github.com/notdezzi/Movinder