The Star Rating Problem

Every movie lover has faced it: you open a ranking app, see a movie you love, and try to give it a rating. 4 stars? 4.5? You end up paralyzed by a deceptively hard question — not "how good is this movie?" but "how good is this movie compared to everything else I've seen?"

That's the core problem I set out to solve when I built Montir, a movie ranking iOS app. Star ratings feel precise but they're actually pretty arbitrary. You might give Inception 5 stars on Monday and realize on Thursday you'd rate The Shining the same — but you definitely don't think they're equal films.

The insight that changed everything: humans are much better at pairwise comparisons than absolute ratings. It's easier to answer "is Parasite better than Interstellar?" than "what exact score out of 10 does Parasite deserve?"

The ELO Solution

ELO is a rating algorithm originally developed for chess — it's what determines player rankings based on wins and losses. The key insight is that a rating should reflect relative standing, not absolute quality.

Here's the beautiful part: when you win against a higher-rated opponent, you gain more points. When you lose to a lower-rated opponent, you lose more. The system is self-correcting over time.

For movies, this translates perfectly:

• Start every movie at 1000 ELO
• Show two movies and ask: which one do you prefer right now?
• Update both ratings based on the outcome
• Repeat until rankings stabilize

After ~20-30 matchups, a surprisingly accurate ranked list emerges — one that genuinely reflects your taste, not just a global average.

Technical Implementation in Swift

The ELO calculation itself is clean and elegant in Swift:

struct ELOCalculator {
    static let kFactor: Double = 32.0

    static func expectedScore(ratingA: Double, ratingB: Double) -> Double {
        return 1.0 / (1.0 + pow(10, (ratingB - ratingA) / 400.0))
    }

    static func newRatings(winner: Movie, loser: Movie) -> (winnerRating: Double, loserRating: Double) {
        let expectedWin = expectedScore(ratingA: winner.eloRating, ratingB: loser.eloRating)
        let expectedLoss = expectedScore(ratingA: loser.eloRating, ratingB: winner.eloRating)

        let newWinnerRating = winner.eloRating + kFactor * (1.0 - expectedWin)
        let newLoserRating = loser.eloRating + kFactor * (0.0 - expectedLoss)

        return (newWinnerRating, newLoserRating)
    }
}

The kFactor of 32 controls how dramatically ratings shift per match. Higher values = more volatile rankings that respond faster to new data. Lower values = more stable but slower to update.

For data persistence, I used SwiftData (Apple's new Core Data successor), which integrates cleanly with SwiftUI:

@Model
class Movie {
    var title: String
    var year: Int
    var eloRating: Double
    var matchCount: Int
    var posterURL: String?

    init(title: String, year: Int) {
        self.title = title
        self.year = year
        self.eloRating = 1000.0
        self.matchCount = 0
    }
}

Matchup Selection Algorithm

Here's something that isn't obvious: showing random matchups is wasteful. If you have 100 movies, random pairs might show two films with wildly different ratings — the outcome is already obvious and gives you little information.

I implemented an uncertainty-weighted selection approach:

1. Prefer movies with fewer total matchups (they need more data)
2. Among those, prefer matchups where ratings are close (more "informative" comparisons)
3. Introduce occasional random matchups to surface surprises

func selectNextMatchup(from movies: [Movie]) -> (Movie, Movie) {
    // Sort by match count, prioritize less-seen movies
    let sorted = movies.sorted { $0.matchCount < $1.matchCount }
    let candidate = sorted.first ?? movies.randomElement()!

    // Find a good opponent: close in rating, but not too recently seen
    let opponents = movies.filter { $0.id != candidate.id }
        .sorted { abs($0.eloRating - candidate.eloRating) < abs($1.eloRating - candidate.eloRating) }

    // Pick from the top 5 closest, with some randomness
    let poolSize = min(5, opponents.count)
    let opponent = opponents.prefix(poolSize).randomElement()!

    return (candidate, opponent)
}

This made rankings converge roughly 40% faster in testing compared to pure random selection.

What Worked

SwiftUI animations were a joy. The card-swipe interface for choosing between two movies felt natural to build. The declarative syntax meant I could prototype interactions in minutes that would have taken hours in UIKit.

The ELO model just works. Users who tested early builds consistently said "this list actually feels right" — which is harder to achieve than it sounds. The algorithm surfaces genuine preferences even when people haven't consciously thought about their rankings.

TMDB API integration was smooth. Pulling in poster images, genres, and metadata via The Movie Database API made the experience feel polished. async/await in Swift made the networking clean.

What Didn't Work (At First)

Onboarding is hard. A fresh install shows zero movies. Users need to add content before the ELO system can do anything useful. I went through three different onboarding flows before landing on one that felt right: suggest popular films based on the user's stated genres, let them add 10-20 to start, then immediately show the first matchup.

Rating convergence takes longer than users expect. Early feedback was "why does my ranking keep changing?" The fix was adding a visual stability indicator — a small badge that fills as a movie accumulates more matchups — so users understand the system is still learning.

SwiftData had rough edges. The migration tooling was limited during early development. I hit a few cases where schema changes caused crashes that took a while to debug. If you're starting a new project now it's much more stable, but plan for some friction.

Try It

Montir is live on the App Store. If you've ever wanted a ranked list of your movies that actually reflects how you feel — rather than a pile of 4-star ratings — give it a try.

Download Montir on the App Store

The ELO approach turned out to be genuinely better than star ratings for this problem. I'd love to hear if others have used similar pairwise comparison techniques in their apps — drop a comment below.