# SwiftUIX: a Swift Package that backfills the SwiftUI gaps with UIKit and AppKit ports

> SwiftUIX is an MIT-licensed Swift package that adds hundreds of components and extensions to the SwiftUI standard library, from CollectionView to keyboard padding. It installs through Swift Package Manager on the master branch, and its own README calls the documentation work in progress.

**SwiftUIX/SwiftUIX** — An exhaustive expansion of the standard SwiftUI library.

- Repository: https://github.com/SwiftUIX/SwiftUIX
- Stars: 8,168 · Forks: 496
- Language: Swift
- License: MIT
- Published: 2026-09-22 · Updated: 2026-09-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/swiftuix-swiftuix

## What SwiftUIX fills in for SwiftUI developers

SwiftUIX is a compatibility layer for teams whose apps target SwiftUI but keep running into standard-library gaps. The README frames the project as an attempt "to fill the gaps of SwiftUI," offering components, extensions and utilities that complement the standard library, and describes itself as the most complete port of missing UIKit and AppKit functionality. That claim is the whole pitch: you get Apple-framework behaviour through SwiftUI-style views instead of writing UIViewRepresentable wrappers yourself.

The audience is narrow but real. A developer shipping an iOS app on a deployment target as old as iOS 13, who needs a collection view, an activity indicator, a link preview or a search bar, has two options: hand-roll a representable wrapper or pull in a package that already did it. SwiftUIX targets the second group. The README's contents table maps UIKit classes to their SwiftUIX equivalents, for example UICollectionView to CollectionView, UITableView to CocoaList, UIScrollView to CocoaScrollView and UIActivityViewController to AppActivityView, which makes it easy to check whether the specific control you miss is present before adding the dependency.

It is not a design system and it is not a state management library. The topics list mentions attributed strings, backwards compatibility, collection views, performance, scrolling, text views and visionOS, and the README's own framing is complementary rather than replacement. If your app already works with plain SwiftUI and you never touch UIKit, the package adds surface area without solving anything.

## How the package is structured and what the ports actually wrap

The repository layout is a single Swift package: Package.swift at the root, sources under Sources/, tests under Tests/, plus Assets/, Scripts/ and a Documentation.md file. There is no separate app target and no binary distribution mentioned, so the unit of consumption is the SwiftUIX.framework the README tells you to link.

Mechanically, the components are SwiftUI views that wrap platform views. The README's table makes the mapping explicit: CollectionView stands in for UICollectionView, CocoaList for UITableView, CocoaTextField for UITextField, SearchBar for UISearchBar and VisualEffectView for UIVisualEffectView. The naming convention matters when reading the API: the Cocoa prefix marks views that sit on the platform list and scroll implementations, while plain names such as ActivityIndicator and PaginationView are higher-level compositions. The README also documents behaviour-level extensions rather than views, including View/isScrollEnabled(_:), View/visible(_:), View/padding(.keyboard) and a set of navigation bar modifiers for colour, translucency, transparency and large titles.

Because the components wrap UIKit and AppKit, the data flow is the familiar representable pattern: your SwiftUI view passes data and closures in, the wrapper builds or updates the platform view, and callbacks such as the onComplete handler on AppActivityView come back out. That is why the package's deployment targets span iOS 13, macOS 11, Mac Catalyst 13, tvOS 13, watchOS 6 and visionOS 1: the ports are only as portable as the frameworks underneath them.

## Installing SwiftUIX with Swift Package Manager

The README calls Swift Package Manager the preferred installation route. The package manifest entry points at the master branch rather than a tagged release, so a fresh checkout tracks whatever is on master at resolution time. The README's snippet uses the branch form:

```swift
/// Package.swift
/// ...
dependencies: [
    .package(url: "https://github.com/SwiftUIX/SwiftUIX.git", branch: "master"),
]
/// ...
```

If you prefer the Xcode UI, the README gives five steps: open File, then Swift Packages, then Add Package Dependency; paste https://github.com/SwiftUIX/SwiftUIX and click Next; for Rules select Branch with the branch set to master; click Finish; then in Project settings add SwiftUIX.framework to Linked Frameworks and Libraries and set its Status to Optional.

Before any of that, check the requirements. The README states Swift 5.10 is the minimum and that Swift 5.9 is no longer supported, Xcode 15.4 or later is required, and CI verifies Xcode 16.x and Xcode 26.x across iOS, macOS, Mac Catalyst, tvOS, watchOS and visionOS.

For a first real use, the README's CollectionView example is the shortest path. Import the module, give the view a data source and a cell builder:

```swift
import SwiftUIX

struct MyCollectionView: View {
    let data: [MyModel] // Your data source

    var body: some View {
        CollectionView(data, id: \.self) { item in
            // Build your cell view
            Text(item.title)
        }
    }
}
```

What you should see is a scrollable collection whose cells are SwiftUI views, with no UIViewRepresentable in your code. A second quick check is the keyboard padding modifier, View/padding(.keyboard), which the README describes as padding a view with the active system height of the keyboard.

## Documentation is the weak point, by the project's own admission

The README states plainly that while the project is stable and heavily used in production, its documentation is work in progress, and that contributions are encouraged. That sentence is the most important one for anyone evaluating adoption, because it sets expectations for what you will find when you go looking for behaviour details.

Documentation is split in two. A generated documentation site at swiftuix.github.io/SwiftUIX/documentation/swiftuix/ holds what has been migrated, and everything not yet migrated lives in the repository wiki. That means the answer to "how does this modifier behave on tvOS" or "what happens when the data source changes" may exist in one place and not the other, and you cannot assume the site is complete. For a package whose value proposition is breadth, hundreds of extensions and views, incomplete reference material is a practical cost: you will read source under Sources/ more often than you would with a fully documented dependency.

There is also a versioning mismatch worth naming. The repository publishes releases, with 0.3.2 on 2026-09-18, 0.3.1 on 2026-07-14 and 0.3.0 on 2026-04-20, yet the README's installation instructions use branch: "master" rather than a version requirement. Nothing in the README explains how to pin to 0.3.2 or what the project's policy is for breaking changes between 0.x releases. If reproducible builds matter to you, that gap is something you have to close yourself with a version rule, and the README does not document rollback or migration between versions.

## Where SwiftUIX is the wrong dependency

The clearest failure mode is a project that already has its own UIKit bridge layer. If your team maintains representable wrappers for a collection view and a text field, adding SwiftUIX duplicates that surface and gives you two places to fix when a platform behaviour changes. The package's value comes from not writing those wrappers, not from coexisting with them.

A second case is any target that cannot link UIKit or AppKit. The contents table is a list of ports over Apple's frameworks, so the package's reach is bounded by them. A pure SwiftUI codebase that deliberately avoids platform view controllers gains an import it did not want, and the deployment targets in the README (iOS 13, macOS 11, Mac Catalyst 13, tvOS 13, watchOS 6, visionOS 1) tell you the floor but not which components are conditionally compiled per platform. The README does not publish a per-component platform matrix, so if you ship on watchOS or visionOS you should check the source for the specific view before assuming it is available.

Finally, treat the documentation warning as a real constraint rather than a caveat. A team that needs a component with stable, documented semantics for edge cases, and that cannot afford to read implementation source, is better served by writing the one wrapper it needs. SwiftUIX is breadth; breadth without complete docs means you own the verification.

## Alternatives and how their approach differs

The closest conceptual alternatives are the smaller, single-purpose SwiftUI component packages that appear alongside SwiftUIX in search results, such as AlertToast for toast presentations and SwiftUIPager for paged layouts. The difference in approach is scope: those libraries solve one presentation problem with a documented API and a narrow surface, while SwiftUIX is a broad port of UIKit and AppKit functionality under one import. A pager library will not give you CollectionView or keyboard padding; SwiftUIX will not give you the focused documentation a single-purpose package usually carries.

On the bridging side, the alternative is doing the work yourself with UIViewRepresentable and NSViewRepresentable. That gives you exactly the behaviour you need, with no dependency to track, at the cost of writing and maintaining the update logic that SwiftUIX already contains for each control. The trade is maintenance versus control, and it favours SwiftUIX when you need several of the ports at once.

For state and data flow, the relevant comparison is not a component library at all. SwiftUIX's README does not position it as a replacement for observable models or for Combine-style pipelines; it complements the standard library with views and extensions. If your gap is architecture rather than missing controls, this package is not addressing it.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-09-18, the same day release 0.3.2 was published. The release cadence visible in the release list is roughly every two to three months across 0.3.0 in April 2026, 0.3.1 in July 2026 and 0.3.2 in September 2026. The README also states the project is stable and heavily used in production, though it offers no numbers, and no star, fork or issue counts are used here as evidence of anything.

Upgrade cost centres on two things the README does document. First, the Swift floor moves: Swift 5.10 is now the minimum and Swift 5.9 is no longer supported, so a toolchain upgrade can be forced by a package update. Second, the minimum Xcode is 15.4, with CI verifying 16.x and 26.x. Because the installation instructions point at the master branch, an update can arrive without a version bump in your manifest, which shifts the burden of testing onto you. Pinning to a release tag is possible in Swift Package Manager, but the README does not describe how the project treats API stability across 0.x versions, so pinning is a precaution rather than a documented guarantee.

The licence is MIT, which permits commercial use and modification; the LICENSE file sits at the repository root. That is a permissive licence with minimal obligations, but this is a description of the licence identifier and not legal advice. If your organisation has specific attribution or notice requirements, read the LICENSE file itself.

## Conclusion

Adopt SwiftUIX if you are building SwiftUI apps on iOS 13 or later and keep hitting missing pieces such as CollectionView, keyboard padding or navigation bar colour, and you accept pinning to the master branch because the README's installation steps use branch, not a tagged version. Do not adopt it if you need a stable versioned dependency with complete documentation, or if you cannot carry UIKit and AppKit imports through your targets, since the ports sit on those frameworks. Verify first that your Xcode version meets the README's Xcode 15.4+ minimum, that Swift 5.10 is available because Swift 5.9 is no longer supported, and that the specific component you need appears in the documentation site rather than only in the wiki.

## FAQ

### How do I install SwiftUIX in an Xcode project?

The README's preferred route is Swift Package Manager. In Xcode, open File, then Swift Packages, then Add Package Dependency, paste https://github.com/SwiftUIX/SwiftUIX, set Rules to Branch with the branch master, and after finishing add SwiftUIX.framework to Linked Frameworks and Libraries with Status set to Optional.

### What Swift and Xcode versions does SwiftUIX require?

Swift 5.10 is the minimum, and the README states Swift 5.9 is no longer supported. Xcode 15.4 or later is required, with CI verifying Xcode 16.x and Xcode 26.x.

### Which platforms does SwiftUIX support?

The README lists deployment targets of iOS 13, macOS 11, Mac Catalyst 13, tvOS 13, watchOS 6 and visionOS 1, and says CI verifies those destinations. It does not publish a per-component platform matrix.

### Is SwiftUIX free to use?

The repository is licensed under MIT, with the LICENSE file at the root. That is a permissive licence, but the README does not go into attribution details, so read the LICENSE file for specifics.

## Sources

- [Issues](https://github.com/SwiftUIX/SwiftUIX/issues)
- [License: MIT](https://github.com/SwiftUIX/SwiftUIX/blob/master/LICENSE)
- [README](https://github.com/SwiftUIX/SwiftUIX/blob/master/README.md)
- [Releases](https://github.com/SwiftUIX/SwiftUIX/releases)
- [SwiftUIX/SwiftUIX on GitHub](https://github.com/SwiftUIX/SwiftUIX)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/swiftuix-swiftuix