Adding Tinder-esque Swipeable Cards to your iPhone App

Difficulty: beginner - advanced

Disclaimer: there are a handful of these articles out there. This interface has become super popular in the last year or two as a staple of encouraging users to sift through a large amount of data. What will distinguish this article is that I will recommend what resources apply to you depending on your current situation.

“I want to build my own from scratch”

If you’re looking to implement your own card swiping system from scratch and are just looking for a way to get started, take a look at this post in Guti’s Blog by Nimrod Gutman, which goes through the absolute basics. Guti demonstrates how to properly have an object move when you touch it, and you learn that you are never really moving an object. Instead, you are attaching a UIPanGestureRecognizer that tells the controller how much the user’s thumb is moving, which you translate directly into card movement.

Pros:

  1. have a bottom-up understanding of your code to maximize customizability.
  2. Don’t have to rely on potentially unreliable dependencies.
  3. In the long run, you won’t run into weird bugs you don’t understand

Cons:

  1. To fully understand, you still have to painstakingly go through Guti’s code, so customizing the right feel you’re looking for will take time.
  2. Takes the most time, which may be precious depending on your situation.
  3. Guti’s code doesn’t offer any systems to deal with lots of information. For example, if you have 100 cards, it loads all 100 right from the get go, which might not be what you want

Estimated Implementation Time: 5–8 hours

Conclusion: this is for the intermediate-advanced developer who is looking to build a long term project and therefore know his/her code inside out to avoid any weird bugs

“I want to use someone else’s code and then forget about it”

This is the other end of the spectrum where you import someone else’s code into your project (check out cocoapods). You’re trusting that this person’s code is solid and that you won’t have to worry about it going out of date. You also want to bank on the tons of features it potentially has. If this is the case, I highly recommend MDCSwipeToChoose, which seems to be a reliable dependency with over 600 stars on github. There are also several branches that seem to allow for undoing swipes and other features. I personally have never used this dependency in any real application, but I have downloaded it and tried it out. The documentation is decent, but it seems that it isn’t being updated anymore (last update was 4 months ago).

Pros:

  1. Drop, forget, and go on with the rest of your project
  2. Tons of potentially beneficial features that you might not have ever thought of.
  3. Big community of coders dedicated to open source software should there be any major flaws
  4. Super, super, super easy
  5. Did I mention how fast it is to do this? it’s like 2 lines of code (unless you’ve never used a pod before)

Cons:

  1. Any issues? Too bad, your whole program is now unusable
  2. Customizability is basically nil, especially if you use it as a pod
  3. You have very little understanding what’s actually happening, so if the dependency doesn’t work right with your particular project, it’ll be near impossible to figure out why.
  4. It doesn’t look like it’s being regularly maintained. With big changes to Swift and other ios8 components, this increases the risk of issues.

Estimated Implementation Time: 10m — 1h

Conclusion: This is extremely useful for the following scenarios: A small project that isn’t meant to run super long term, a project that is short on development budget and/or time, a project where the card swiping plays a minor role, a project that’s using the cards as a proof of concept / minimum viable product.

“I want help building something in between”

Finally, we’re getting to the part I want to talk about. I was in the same position as you.

I found that a drop-in solution wasn’t for me because it wasn’t customizeable and I had no idea what was happening, so I built TinderSimpleSwipeCards, an extremely simple template that’s painstakingly explained and can:

  1. Dictate how many cards are loaded at a time
  2. Drop the view ontop of a ViewController (click for gif).
  3. Dynamically add cards
  4. Super, unbelievably detailed comments on what the hell is going on

The reason I did all this was so that developers of all skills could open my project, read through it, and understand exactly what was happening. This way you are given boilerplate code and you can tell exactly what to change for your particular project. I also mark #warning everywhere you need to insert your own code. Just to give you an example of the kind of detailed comments I included, here are a few snippets:

As you can tell, I spent a lot of time really trying to figure out the code and any questions you might have while building it. Check out the readme for more information on how to implement it directly. I also respond to email and twitter for any questions or pull requests.

Pros:

  1. Understand your code extensively without having to write the boilerplate stuff
  2. Highly customizable
  3. Can be treated as a dependency or a template depending on your particular situation
  4. Adapts easily to you building your own additional features (eg: an undo button)
  5. I can personally address any issues
  6. Very lean with no unnecessary features
  7. A great way to improve your iOS knowledge for beginners

Cons:

  1. Takes time to get into it.
  2. Doesn’t have any additional features other than the basics
  3. Requires a bit of dedication and prior knowledge
  4. For now, there are only 2 people who can resolve any issues
  5. If I push an update, you’ll have to reintegrate the updated code into your project if you want it (it’s not automatic)

Estimated Implementation Time: 1–20 h

Conclusion: this is for anyone who wants to improve their iOS knowledge and anyone who wants to make a long term project that incorporates the swipeable card interface. Contact me at cwrichardkim@gmail.com or @cwRichardKim for any issues/suggestions.

Of course, this template isn’t for everyone, and I’m not trying to misrepresent the code I wrote as a cure-all, but I hope this article helped you in some way if you’re looking to implement this interface.