Wikipedia brings its 'Which came first?' daily game to iPhone after Android debut

Wikipedia has added its daily historical facts game, "Which came first?", to the iPhone version of its app starting today. The game asks you to order five events drawn from things that happened on the current day in history, scores your accuracy, and tracks a streak across days. Previous rounds stay available through an archive, and you launch the whole thing from the Explore feed inside the Wikipedia iOS app.

If that description sounds like something you may have already seen, that's the part worth paying attention to. The game shipped on Android first, and iOS is catching up now. For anyone maintaining apps on both platforms, this is a textbook example of the staggered release pattern that defines most cross-platform mobile work, and it's worth looking at why that gap exists and how teams manage it.

What actually shipped

The feature itself is modest. Five daily questions, each tied to an event from this day in history, presented as an ordering puzzle: given two or more events, pick which came first. Game stats include your average score and gameplay streak, the standard engagement loop that daily games like Wordle popularized. The archive lets you replay earlier days, which means the content is generated server-side or bundled in a way that doesn't depend on a fresh app update to keep playing.

The Wikipedia apps are both open source, which makes this a rare case where you can actually inspect how a feature like this gets built and rolled out. The iOS client lives on GitHub and the Android client has its own repository. Both are maintained by the Wikimedia Foundation rather than a typical product company, so the release cadence reflects volunteer and foundation-staff bandwidth more than a marketing calendar.

Why Android came first, and why that's normal

The order here, Android before iOS, runs counter to the old assumption that iOS always gets new features first. That assumption was never really true for organizations that aren't Apple-centric, and Wikimedia is a good example. When a feature ships on one platform ahead of the other, it usually comes down to a few practical realities rather than any strategic favoritism.

The two codebases are genuinely separate. Wikipedia's iOS app is Swift and Objective-C against UIKit and SwiftUI, while the Android app is Kotlin and Java against the Android SDK. A daily-game feature touches networking, local persistence for streak data, a results UI, and the archive view. None of that shares code across the two platforms in a native-app setup like this one. Whichever team has capacity ships first, and the other follows once the same work is reimplemented in its own stack.

Review pipelines differ too. App Store review can add days of latency that Google Play's faster track does not, so even when two builds finish at the same time, the Android version often reaches users sooner. For teams shipping to both stores, the lesson is to decouple feature launches from a single coordinated date and instead treat each platform's release as its own train.

The cross-platform takeaway

If you're building something similar, the architecture choice underneath this kind of staggered rollout matters. Wikipedia keeps native clients on both platforms, which gives the best fit with each system's conventions but doubles the implementation cost for every feature. The trade-off is real: native means two teams, two test matrices, and two release timelines, but it also means each app feels at home, integrates cleanly with platform features, and avoids the abstraction tax that shared frameworks impose.

The alternative paths each carry their own cost. A shared framework like React Native or Flutter would let a single team ship the game to both platforms closer to simultaneously, collapsing the gap that put Android ahead here. The price is a layer between your code and the platform, plus the work of bridging to native capabilities when the framework doesn't cover them. For a content-heavy reading app with deep platform integration like Wikipedia's, the native approach is a defensible call, and the cost shows up exactly as it did today: one platform shipping a feature weeks or months behind the other.

For day-to-day app maintenance, the practical move is to stop treating feature parity as a launch event and start treating it as a backlog state. A feature is "shipped" per platform, not globally, and your changelog, support docs, and analytics should reflect which build a given user is actually running. Wikipedia's iOS users get "Which came first?" today; their Android counterparts have had it for a while. Both groups are running the same product with a normal, expected lag between them.

The game is live now in the latest Wikipedia iOS app. Update from the App Store, open the Explore feed, and the new card should appear. If you maintain a daily-engagement feature of your own, it's a clean, small reference for how the same idea lands differently across two platforms shipped by the same organization.