A few years ago I woke up to a voicemail from some friends that outlined the basic idea of Emojinary—“it’s Pictionary but with Emojis!” After a few days of texting emoji clues back and forth between friends we were convinced this game should exist. From there I started mapping the app out, designing enough to get building, and learning Swift.
Emoinary's homescreen with a feed of clues created by users.
The Idea
Emojinary allows anyone to create a clue for a piece of culture—movies, music, books, etc...—composed of only emojis. They can then share that clue in a global feed of Emojinaries where anyone can guess the answer (or just peak at the answer if they can't figure it out).
Players get points when they guess right. If lots of folks are guessing wrong then the value of an Emojinary can go up. But if they peak at the answer then they don't get a chance to guess or get points.
This isn’t a new idea—people on Twitter have been posting complex emoji representations of whole movie plots and books for a while, but Emojinary gives it structure with a place to create these little emoji stories and give others an opportunity to guess what they are.
Players guess answers to Emojinarys other players created.
Players can choose between eight categories and 1,000s of phrases varying in difficulty. When they write their clue they are limited to only using emojis.
Emojinary keeps track of the clues you guess wrong, guess right, and post yourself. You can come back and share posts you really liked or got you stumped and see how you're doing on a global leaderboard.
A user's profile, clues they posted, and the global leaderboard.
Sharing from the app gives users a link they can post anywhere.
Release
Emojinary is slated to be released some time this summer. The final features are in development now and a very private beta is rolling out to select friends.
Technical Details
Emojinary is my second-ish Swift app for iOS. I had previously dabbled in Objective-C but never built anything substantial. What I learned making my first iOS app, Snaps, influenced a lot of my decisions for Emojinary.
- I prefer to not use (what used to be referred to as) Interface Builder. I feel like there is more control and less issues building and instantiating views in code.
- I put more weight in Views than ViewControllers so ViewControllers don’t become so dogmatic.
- All the screens in the app are organized into coordinators that manage the ViewController hierarchy for each functional area of the app.
- Using Snpkit to layout views saves a ton of time on using Apple’s native auto layout API
- The whole app is built on Firebase. I went back and forth on building and managing my own backend or using a service. The ease and cost of Firebase was worth the investment.