Nominations for the Packages Community Showcase on now has a top-level Packages page, and a notable part of that page is a Community Showcase section.

The Community Showcase features packages currently being discussed by the Swift community. The list will be updated monthly, and we are taking nominations for packages to feature in that list via this thread.

The only restriction to qualify for the showcase is that the package must be nominated or discussed by someone other than the package author or maintainer. This helps avoid the problems that come with self-promotion and serves as proof that the community finds it notable.

I will ping this thread each month one week before the update goes live with recent recommendations. If you would like a notification when that ping happens, use the bell icon on the right-hand side of this post and select “Watching” from the drop-down menu to receive notification emails.

Nominations from this thread will go forward to the Swift Website Workgroup, which will make the final decision on which packages make it onto the page.

To nominate a package, please reply to this thread with:

  • Package: The URL to the package repository or the listing on the Swift Package Index. If the package still needs to be added to the index, you can add it here.
  • Reason for nomination: A link to community discussion about the package or a few words describing why you are nominating it. This could be a link to a blog post, podcast episode, newsletter issue, Swift forums thread, or social media post. Or, just a few words saying how you found it useful and why others should take a look.

For example:

Package: Grape by Zhen Li
Reason for nomination: Discussed on Episode 36 of Swift Package Indexing


The Packages page just went live with this announcement blog post.

I'll ping this thread in a few weeks looking for some nominations for the first update to the page. I'm looking forward to seeing the nominations. :+1:


The Composable Architecture is a fool-proof library that enables (and in a way forces) you to cleanly separate business logic from your UI. In doing so, the UI becomes a simple function that renders your state - with the ability to emit user actions back into the system. It uses a reducer pattern for its architecture, and strongly embraces the concept of state machines.

For us, it's been instrumental in streamlining the development process, parallelising work and testing both UIs and UI logic. In our company we start out defining the state and actions as a team. From there on, we have different parallel paths forward to implement the work.

The engineer assigned to UIs can simply consume a struct representing the state, and call a simple function .send(..) to notify the state machine of user input.
This separates the UI from logic entirely, allowing us to stub states without worrying about the impact of user interactions. Therefore, it actually makes Swift previews usable and easy to implement in large projects. In addition, this allows us to snap screenshots of specific scenarios and record animations from state transitions, such as loading a network request or network request errors. This has previously been a daunting task.

On the opposite side, the same or a separate engineer can implement the business logic. State machines are super maintainable and testable, especially once you get more experienced with them. They force you to specify each side effect using the Effect type, such as asynchronous work. And in doing so, we are able to write tests for every nook and cranny in complex apps. In addition, we're able to utilise the simplicity of this system and its use of concrete types to combine it with multiplayer experiences (using Codable), and save entire user sessions to disk in order to replay bugs.

But aside from all this simplicity and power, it's very remarkable how accessible it's being made with their great API design and even better docs.


I use Swift on the Raspberry Pi and find the following packages very useful: They provide APIs to familiar systems which (Excluding GPIO) are available on Apple Systems, but where there is no Apple-provided API on Linux devices.

Alsey Coleman Miller is a developer who works on IOT devices and has built an array of Swift Packages, including this, comprehensive, package which provides Swifty interfaces to the Bluetooth hardware on Linux devices. I have built a system to control an electric gate on a private road which recognises authorised vehicles via Bluetooth LE tokens using this package and found it very useful.

Bouke Haarsma has built a fully-fledged Swift implementation of the HAP stack which powers HomeKit. This excellent package allows hobbyists to build their own (non-certified) HomeKit hardware using Swift and a Raspberry Pi (or similar). I have used this package to build a system to monitor the temperature inside and outside my house. I'm also in the process of using it to build a proxy which controls my Denon AV Amp and add it to HomeKit even though it doesn't natively support HomeKit. (I am aware that other ways to do this already exist!)

This is a relatively simple package written by Umberto Raimondi, who was vital in getting Swift running on Arm devices such as the Raspberry Pi. It allowed me to easily interface with the temperature sensors mentioned above and allows users to interact with the various hardware interfaces on the Pi, encouraging hobbyists to try hardware hacking.

(Hummingbird is amazing as well, but I think you've already got that covered.)


Thanks so much for the nominations, both @Diggory and @Joannis_Orlandos!

If possible, editing your posts to add just a few words about each specific package you're recommending would be useful. I know yesterday the submission format in the first post said (Optional) next to the reason, but a recommendation carries much more weight with a few words specifically about each package.

Also, and I must admit my ulterior motive here. If the first few posts here don't have any links to where they were discussed or words of recommendation, that's setting the precedent for the thread going forward :grimacing:



CalendarKit is a high quality open source implementation of iOS Calendar day view UI that can be easily embedded into an iOS app. For example, multiple university schedule apps have been created with it and it’s already quite popular on GitHub (more than 2 thousands stars).

The library is also very helpful to anyone interested in learning how to build an own UI library or learn more about date and time processing on Apple platforms.

The library has a few mentions in the iOS-related newsletters as well as a dedicated StackOverflow tag: Newest 'calendarkit' Questions - Stack Overflow

It’s actively maintained and supported for all the major iOS versions.


I’d like to mention GitHub - davedelong/time: Building a better date/time library for Swift by @davedelong which is all about using Swift type system so one don’t fall into traps about dates, timestamps, calendars and locales.

It is properly documented and the api is made to guide you toward correctness. 2k stars and properly tested AFAIR.

When I can’t import this I’m jealous of Java/kotlin and their provided time package with LocaleDate and friends. I think the next foundation should provide at least some of those abstractions in a similar easy to use api.


It's time for the first updates to the Packages page! I will included all packages mentioned above already, but if there are any other nominations, or mentions of packages on community blogs, podcasts, etc then please leave them here.

The Swift Website Workgroup will meet on Tuesday and pick six packages to show on the Packages page during December.

1 Like

I'd also like to submit some packages that I have talked about this month:

Package: Variablur by Dale Price
Reason for nomination: Linked in iOS Dev Weekly Issue 637

Package: MemberwiseInit by Galen O’Hanlon
Reason for nomination: Discussed in Swift Package Indexing Episode 37

I'd like to submit

Package: SwiftSummarize by Stef Kors
Reason for nomination: Discussed in Swift Package Indexing Episode 37

Package: typhoon by Nikita Vasilev
Reason for nomination: Discussed in Swift Package Indexing Episode 37


Reason for nomination

This package was adopted for benchmarking in Swift NIO and Swift Foundation, and is an important part of the ecosystem as a feature-rich benchmarking library.