FlexLayout: Yoga's flexbox engine wearing a Swift interface

Yoga underneath, and that is the whole trick

FlexLayout does not implement flexbox. It wraps Yoga, which the README describes as a multiplatform CSS Flexbox implementation for iOS and Android, and adds the single most useful piece of information about Yoga's reach: it is also the layout engine of React Native.

That matters because Yoga is therefore exercised on both sides of the bridge you are probably crossing. The Swift code in a React Native app and the layout code in a native iOS screen run through the same C++ engine, so a flexbox behaviour you learn in one place transfers. For a library whose entire job is exposing someone else's implementation, that is the substance of the project, and the README is straightforward about it.

The competitive claim is blunt rather than subtle: Flexbox is an incredible improvement over UIStackView, being simpler to use, much more versatile and amazingly performant. UIStackView remains the comparison point because it is what most iOS code reaches for by default, and its limitations are real: it does not do wrapping, it does not do flex-grow in the CSS sense, and its constraint maths get unwieldy past a couple of levels.

Two steps: define the container, then layout

The README's introductory example states the usage rule plainly. Two steps are needed. First set up the container, which can also be altered later. Second, layout the container, and this must happen from layoutSubviews(), or from willTransition(to:with:) and viewWillTransition(to:with:) when the size changes.

Inside layoutSubviews() the order is fixed: layout the flex container itself, positioning it and optionally setting its size, then call the layout() method to let the flexbox children be positioned.

rootFlexContainer.pin.top().left().width(100%).marginTop(topLayoutGuide)
rootFlexContainer.flex.layout(mode: .adjustHeight)

The declaration side is a chainable DSL. A .define closure receives a flex object and you add items to it, optionally giving the added item its own define block to make it a nested container.

rootFlexContainer.flex.direction(.column).padding(12).define { (flex) in

Every direct item you add becomes a flex child, and the method names mirror the CSS property they set: direction, padding, marginTop, marginBottom, width, height, grow, aspectRatio, backgroundColor. Setting a property on the view's .flex extension returns something you can keep chaining, which is what makes the nesting readable.

Requirements, and why the topic list is out of date

The stated requirements are iOS 13.0 or later, Xcode 13.0 or later and Swift 5.5. Those are reasonable floors rather than aggressive ones, and the Xcode 13 requirement mostly reflects the build tooling rather than any language feature.

The repository topics tell a different story. Alongside css-flexbox, yoga, ios and layout there is swift-3, which was a different major Swift release with different syntax and a different package layout. Either the topic is a historical leftover or the library has carried compatibility claims from that era. Nothing in the README or the recent releases suggests the swift-3 topic is a current support claim, so treat it as noise.

The project also states that it is actively updated and asks readers to star it so they can find it again later, which is a small but honest signal about the maintenance psychology here: the maintainer treats stars as a way to keep the repository findable. The repository was last pushed on 2026-08-30 and the most recent release is 2.2.3 from December 2025, so commits are landing ahead of tagged releases.

PinLayout is a companion, not a competitor

The most useful section of the README is the one about PinLayout, the sibling project from the same author. PinLayout is described as a layout framework inspired by CSS absolute positioning, useful for fine control and animations, giving full control by laying out one view at a time.

The division of labour is stated in three rules. A view can be laid out using FlexLayout, PinLayout, or both. PinLayout can lay out anything, but where you need to lay out many views and do not need the finest control or complex animations, FlexLayout is the better fit. A view laid out with PinLayout can be embedded inside a FlexLayout container and the reverse also holds.

They share similar syntax and method names, which is the point. The first code example above uses PinLayout to position the root container and FlexLayout to lay out what is inside it, and the README calls this out as intentional rather than as a workaround.

The performance section of the README compares the two directly, and the surrounding documentation includes sections on creating and defining containers, container properties, item properties, positioning, adjusting size with width, height, minWidth, maxWidth, minHeight, maxHeight and aspect ratio, then margins and paddings. There is a linked Examples App, generated API documentation and a FAQ section, so this is a documented library rather than a thin wrapper with a demo.

Version 2.2.x, and a Carthage problem fixed with a README edit

The three most recent releases describe the kind of work that only surfaces when a library has real users, and each one is small enough to read in a minute.

Version 2.2.3 added SPM dynamic linking support and fixed an error when dynamically removing views. The removal fix is the more interesting one, and its explanation is worth repeating because it is a genuine architectural difference from React Native. FlexLayout does not guarantee that the UIView hierarchy state matches the Yoga node structure, because nodes are only updated during the layout process by following the UIView hierarchy. Removing a child UIView dynamically and then calling markDirty() caused an error and terminated the program. In React Native, views that become leaves are fixed and used consistently, whereas FlexLayout allows any UIView to become a leaf, so defensive code was added.

Version 2.2.2 added Swift 6 support. Version 2.2.1 fixed a Carthage build failure, and the fix is the interesting part: since version 2.1.0 Yoga had been managed as a separate dependency, so the project could not be built on its own and therefore could not be used with Carthage. Providing a pre-built static framework or adopting a different structure would have required significant changes, so instead the guide and some settings were updated. The README still carries a Carthage-compatible badge as a result.

One open issue, twenty years of Swift versions in the topics

The repository has 2,132 stars, 233 forks and exactly one open issue. That is unusual and worth interpreting carefully. It could mean the library is stable enough that nobody needs the tracker, or it could mean the maintainer handles things elsewhere and closes issues quickly. The README points to a Discord for discussion, which supports the second reading, but it does not settle it.

The repository structure is conventional and well organised for an Xcode project. Sources and Tests sit at the top level alongside FlexLayout.podspec, Package.swift, Package.resolved and a workspace. Example contains separate subdirectories for SPM, CocoaPods and the sample application, which is a useful signal about how many installation paths are actually supported in practice. There is a docs directory alongside docs_markdown, a jazzy configuration for API documentation generation, a swiftlint configuration, a fastlane directory and a Podfile with a lock file.

The Podfile and Package.swift existing together tells you the realistic audience: teams with an existing CocoaPods or Swift Package Manager setup, plus Carthage users who were given a guide rather than a fix. Requirements of Swift 5.5 with Xcode 13 mean you can use it from a fairly old toolchain, and the Swift 6 support in 2.2.2 means modern toolchains work too.

Editorial conclusion

FlexLayout earns its place by making a battle-tested engine pleasant to call from Swift, and its syntax is the reason: you describe the tree once and then let layout() position it. The limitations are equally clear. It is iOS only, it does nothing about size changes on its own, and version 2.2.3 restored Carthage support by changing documentation rather than project structure, which tells you how thin the margin is there. If you already use PinLayout, adopting both is the intended path rather than a compromise.

Frequently asked questions

Official sources

1. Issues
2. layoutBox/FlexLayout on GitHub
3. License: MIT
4. README
5. Releases