SwipeCardView is a lightweight MVVM friendly user control that brings Tinder-style swipe card view into Xamarin.Forms applications.

In this blog post I will talk about card based user interfaces and why they are better than newsfeeds, with the special attention to Tinder approach. Then I will cover in detail the design and the implementation of SwipeCardView.

If you are not interested in the background nor implementation details, feel free to jump to the usage example of this PCL library, which is available on NuGet and GitHub.

What Are Cards?

As defined in Android Material Design Guidelines, a card is a sheet of material that serves as an entry point to more detailed information. Or to put it simple, cards are those little rectangles full of inclusive images and text.

Before web and mobile apps, cards were always all around us — business cards, baseball cards, football sticker albums, and even sticky notes. Thus, it is more intuitive for us to know that these cards are representing piece of content just like in real life.

Panini card: Batistuta

Some of the advantages of cards are:

  • Chunking content: Cards divide content into meaningful sections, similar to the way text paragraphs group sentences into distinct sections.
  • Easy to Digest: Cards are a great tool for communicating stories quickly. Users can easily access the content that they are interested in, and this empowers users to engage in any way they want.
  • Visually pleasing: Card-based design usually heavily relies on visuals, because images draw the user’s eye efficiently and immediately.
  • Responsive: They are a good choice for responsive design since cards act as content containers that can easily scale up or down.
  • Designed For Thumbs: Cards have been developed with mobile apps in mind.
Swiping. Source: Dribble

Cards vs. Newsfeeds

Newsfeeds are useful for reading stories, but not for making decisions.

The problem with newsfeeds is one of information overload. When scrolling through an endless list of options, it’s impossible to reach the end. Since there’s no way to review all the possibilities, it robs the user of a sense of finality.

Instead of infinite content rendered useless by its very vastness, cards connect with users via offering only the best possible content, one piece at a time. It’s the ideal UI for making a decision about now.

Looking at data one piece at a time is more efficient when you consider people you might want to date, restaurants, streaming music, or local events you might want to check out.


Tinder has a terrifically simple card swipe interface — you swipe to the left if you’re not interested, to the right if you are. This card-swiping mechanism is curiously addictive, because every single swipe is gathering information. That means that every time a user browses profiles, it generates personal behavioral data.

Tinder interface

Tinder is not the only app out there with swipe card interface. In fact, there are dozens of apps used in markets like: fashion, jobs, food etc.

Implementation design

Imagine you have to present to the user hundreds of cards, each with different content.

One options is to instantiate UI card control for each one of them, stack them one on top of each other and allow the user to swipe their way through the stack. Of course, this would be impractical in terms of memory and performance.

The other option is to create the minimum number of UI controls to show a card, and switch in the data as the user swipes through the cards. Basically you should instantiate as much UI controls as visible on the screen.

Let’s cover the minimum viable example of 2 visible cards at a time, which is beautifully explained in Xamarin.Forms Swipecard Tutorial by Matchbox Mobile.

Image source: Matchbox Mobile

In starting position we have the front card (visible) and the back card (invisible). The back card is scaled to appear smaller than the front. When the user drags the front card to the left or the right, we’ll rotate the front card and scale up the back card to give the appearance of moving to the front.

We can have as many card data items as we need in a array or list. As the user swipes the front card away, we fill its place with the next card data item and show it at the back. This way we only ever need two UI controls to represent and endless stack of cards.

Matchbox’s example is written in code-behind, which made it hard to reuse and combine with applications that embrace MVVM pattern.


When writing application logic in code-behind, as grow in size and scope, complex maintenance issues can arise. These issues include the tight coupling between the UI controls and the business logic, which increases the cost of making UI modifications, and the difficulty of unit testing such code.

The Model-View-ViewModel (MVVM) pattern helps to cleanly separate the business and presentation logic of an application from its user interface (UI). Maintaining a clean separation between application logic and the UI helps to address numerous development issues and can make an application easier to test, maintain, and evolve. It can also greatly improve code re-use opportunities and allows developers and UI designers to more easily collaborate when developing their respective parts of an app.

Image source: Xamarin


And finally we come to the implementation of SwipeCardView user control.

While creating it I had couple of goals in mind:

  • It has to packed in lightweight and reusable Portable Class Library (PCL), so it could be deployed to NuGet
  • The only dependency should be to Xamarin Forms framework
  • All Xamarin.Forms platforms should be supported
  • It has to be MVVM friendly: to be bindable to ViewModels and to support item templating and commands
  • It should be able to consumed in XAML and any View can be used as a cell

Custom User Control

The concept of User Controls is not new, and exists in many different platforms including ASP.NET, XAML for Windows and Windows Phone as well as Web Forms. The User Control exposes properties allowing you to reuse the control while allowing each instance of the control to have different settings, layout, or behavior.

As per Xamarin documentation, the view which should be mostly used to create user control should be ContentView, and that’s exactly what we need.

ItemSource and ItemTemplate

We will be exposing bindable ItemSource and ItemTemplate properties, which should be used in exactly the same way like you would use ListView properties.

Creating bindable property and accessor:

The ViewModel may change the collection that is bound to the ItemSource. For example the app was presenting cards with dog pictures, and now it changed to cats collection. And even further, collection could be changing over time. The client app may be adding new cat pictures to the collection in background, so user user never see empty card. SwipeCardView should handle both case, and for that reason we have OnItemsSourcePropertyChanged and OnItemSourceCollectionChanged.

On the other hand, OnItemTemplatePropertyChanged has a task to instantiate N views (the number of visible views) using the template defined in the presentation layer of user application.

Swipe Command

User application should be able to easily react on user swipes. That’s where SwipeLeftCommand and SwipeRightCommand come in:

The magic – PanGestureRecognizer

The pan gesture is used for detecting dragging and is implemented with the PanGestureRecognizer class.
We need to know the touch start, moving, and end events, as well as the x and y location.

We will create it in the constructor and attach OnPanUpdated event:

Xamarin Form have simple but powerful animations. In our example we want to use 3 functions on our card View objects:

  • RotateTo
  • TranslateTo
  • ScaleTo

When the touch starts, then only thing we have to do is to reset cardDistance.

The interesting part comes in HandleTouch method. PanGestureRecognizer provides us info how much card translated horizontally. We just have to calculate current rotation angle, where we will use max desired angle – CardRotationAdjuster and current card distance. If the card translation is bigger than maximum card distance, we will update view background, so user can be aware that the card is already in area to be swiped away. At the end we will scale up the back card.

If cardDistance is bigger than the limit needed to swipe card off the screen, HandleTouchEnd will invoke appropriate command. Otherwise, it should translate and rotate card to starting position.

XAML usage

At last, here is the example of how control should be used in XAML of your application:

  • ViewModelItems is an ObrvableCollection defined in your ViewModel
  • TopItem is observable property that should have the same type like the elements of the collection
  • Template represent how each card should look like


Full working example can be found on my GitHub repository. It’s an image gallery app called DailyCat.



Go ahead and try it

You can download library from NuGet or check the source code on GitHub. Grab DailyCat from Play Store and check how SwipeCardView works in practice.

Some of the improvements that are coming:

  • Exposing commands that would invoke swiping programmatically
  • Adding support for custom overlays (as opposed to updating card background)
  • Porting library to .NET standard

What do you think about the plugin? Do you find it useful? Feel free to let me know you opinions and ideas for future improvements.


The new version of the library has a lot of improvements and new features. Check it out at: Introducing SwipeCardView 2.0

Sharing is caring!

3 Thoughts to “Create Tinder-like UI in Xamarin Forms using SwipeCardView”

Leave a Reply

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.