DeckKit: card and deck views for SwiftUI

The card view and the deck are separate objects

The library has two central types and it is worth knowing which does what. The Card view renders a card-like view, and the Deck renders a deck of items with support for swipe gestures, edge swipes and shuffling. Separating them is what makes the library usable for things that are not card games. A card is a styled container with a shadow, rounded corners and a slot for content, and the deck is the interaction layer that manages a stack of those cards, where swiping the top one moves it away and the next comes forward. Because the deck is a container of cards rather than a single opinionated widget, you can put anything in it. The documentation shows the pattern with a deck of a custom type and a custom view, where the view is a rounded rectangle filled with a colour, an overlaid text label and a shadow. That is a complete example in a dozen lines, and it establishes the shape of everything else: a collection of identifiable items, a binding to it, and a closure that renders each item.

The item type only has to be Identifiable

The requirement on your data model is minimal, and that is the design decision that lets the library work with any domain. A deck of cards can be created with any type that conforms to Identifiable, and the example defines a small struct with a name, a text and an identifier derived from the name. Nothing in the type is specific to cards, no protocol of your own to implement, no base class to subclass. The deck is driven by a SwiftUI binding to an array of those items, held in state in the example, and the content closure receives the item. The consequence is that DeckKit does not care what your items mean. They can be flashcards, playing cards, onboarding steps, or recipes, and the deck will swipe them the same way. The cost of that flexibility is that the deck owns the ordering and the gesture behaviour but not the content, so a feature like a permanent answer field or a graded scoring system has to live in your own model and your own view, with the deck acting purely as the presentation and input layer.

Installation through Swift Package Manager and the platform floor

The install route is the Swift Package Manager, and the documentation gives the repository URL to add:

https://github.com/danielsaidi/DeckKit.git

The platform support is stated in one line and it is the constraint to check first. DeckKit supports iOS 17, macOS 14, tvOS 17, watchOS 10, and visionOS 1. Those are not old floors, which means the library sits squarely in the current generation of Apple platforms and cannot be dropped into an app that still supports, for instance, iOS 15 without raising its deployment target. The visionOS entry is worth noting because it is a signal about how the library is written, since a SwiftUI component that renders identically on a headset and on a phone is built with that constraint in mind. The repository layout matches a standard Swift package, with a Package.swift at the root, a Sources directory, a Tests directory, Resources for assets such as the icon badge, a Demo folder, a scripts directory, and release notes in a RELEASE_NOTES.md file. There is a swiftlint.yml, so the code is linted, and the build badge in the documentation header names Swift 6.1 as the language version in use, which is a recent version of the language and a reasonable requirement for a package built this way.

The deck view and the page view are two different presentations

The documentation names several view components for presenting decks, and gives two of them explicitly: Deck and DeckPageView. The difference is in the metaphor. A deck is a stack you interact with by swiping the top card, with the remaining cards visible behind it, and that model suits a linear sequence where each card is a decision. A page view is the paginated model, where content advances in pages and there is no physical stack of cards behind the current one. If you are choosing between them, the question is whether the user is going through a sequence of discrete items, in which case a page view is simpler and does not pretend there is a deck, or whether the deck itself is part of the appeal, in which case the stacked presentation is doing work that a page view cannot. The readme lists the deck capabilities as swipe gestures, edge swipes and shuffling, and the two are different interactions. A swipe gesture on the card moves it, and an edge swipe is a swipe that starts from the very edge of the screen, which is how a user swipes a card away without accidentally triggering whatever else the edge of the screen does. Shuffling is a separate capability, and for a deck of flashcards or a set of prompts it is the difference between a fixed sequence and a reshuffled one.

Customisation is the point, not an afterthought

The documentation states that DeckKit can be customised to a great extent, and that you can change colours and fonts and use completely custom views. That second clause is the important one, because a card interface that only looks one way is a widget, and one that accepts your own views is a design system for a metaphor. The example in the documentation is already a custom view rather than a text label on a white rectangle, since it uses a rounded rectangle with a corner radius of 25, filled with the system blue colour, an overlaid text of the item's name and a shadow with a radius of 10. Those three modifiers are the whole card: shape, colour, content and elevation. Swapping them for your own assets or your own design system is a matter of changing the closure, and the library takes care of the stacking, the shadows and the gesture handling around it. The shadow deserves a mention because that is the detail that makes a stack of cards read as a stack rather than as overlapping rectangles, and having it handled for you is one of the small conveniences that add up. Fonts and colours are named as changeable as well, so a themed card can be produced without rebuilding the view.

What is in the repository beyond the library

There is a Demo folder containing an Xcode project and an application that lets you explore the library on iOS, macOS, and visionOS. That is a better evaluation tool than the readme, because a card interface is a visual decision and the only reliable way to judge one is to see it responding to a swipe. The documentation also points to an online getting started guide for more information and to the online documentation for articles and code examples. The authorship and maintenance model are worth a note, because this is a single maintainer project. The readme has a section on supporting the work, explaining that maintaining the various open source tools takes significant time and effort, and that sponsorship helps free up time for creating, maintaining and improving them. It lists contact routes for questions or contributions, including a website, an email address, a Bluesky handle and a Mastodon handle, and the project is MIT licensed with the terms in the LICENSE file. The release history shows steady work: version 3.1.0 on 2026-06-09, version 3.0.0 on 2026-06-05 and version 2.0.0 on 2025-09-30, with the last push on 2026-06-09.

Editorial conclusion

DeckKit is a good fit for an Apple-platform team that needs a card interface, whether that is a flashcard app, a card game or a swipeable onboarding flow, because the gesture handling and the card model are already solved and the visuals remain yours to change. It is the wrong tool for a grid of equally weighted items, since a deck implies ordering and physical metaphor, and it is the wrong tool if you need to support platform versions older than iOS 17, since that is the floor. Before adopting it, read the getting started guide rather than only the example, because the component list is longer than the readme shows and the demo application is there to explore the library on iOS, macOS and visionOS. The project is MIT licensed, the last push was on 2026-06-09, and the current release is 3.1.0 from the same day.

Frequently asked questions

Official sources

1. danielsaidi/DeckKit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases