SDAutoLayout: chained Auto Layout for Objective-C views and self-sizing cells

What SDAutoLayout replaces, and for whom

Writing Auto Layout by hand in Objective-C means either verbose NSLayoutConstraint calls or the NSLayoutAnchor API, and both spread one visual relationship across several statements. SDAutoLayout compresses that into a chain hung off a property called sd_layout, so a view's left inset, top inset, height and width ratio appear as four method calls on one expression. The README's own framing is "一行代码搞定自动布局", one line of code to finish automatic layout, and the usage examples are written as single chained statements even when they are split across lines for readability.

The audience is narrow and specific: iOS developers working in Objective-C, since the library is written in Objective-C and the examples are Objective-C. The repository also contains an SDAutoLayoutSwiftDemo directory, so a Swift demo exists in the tree, but the README documents the Objective-C API. Beyond plain views, the library targets three cases that are tedious to solve directly: a UILabel whose height should follow its text, a UIScrollView whose content size should follow its children, and a table view cell whose height should follow its content. The cell case is the one the README spends the most space on, and it is the reason the library exists as more than a syntax wrapper.

How the sd_layout chain and the height cache actually work

The chain is a set of methods grouped by naming convention, and the naming convention is the whole API surface. Methods containing "SpaceToView" take a reference view and a CGFloat distance, so leftSpaceToView(self.view, 10) means ten points from the left edge of self.view. Methods containing "RatioToView" take a reference view and a multiplier, so widthRatioToView(self.view, 0.4) means forty percent of the parent's width. Methods containing "EqualToView" take one reference view and copy the matching attribute. Methods containing "Is" take a single CGFloat and set an absolute value. Once you internalise those four families, the rest of the chain reads without documentation.

The repository description says the library is "Based on runtime". That matters for how you debug it: constraints are created through Objective-C runtime dispatch rather than through a compile-time DSL, and the README exposes a macro for that path. In UIView+SDAutoLayout.h there is a commented-out line, //#define SDDebugWithAssert, and the README's closing note says to enable this macro if you want to debug the program with assertions. That is the library's own debugging switch, and it is off by default.

For cells, the mechanism is a two-part contract. The cell calls setupAutoHeightWithBottomView:bottomMargin: after its subviews are laid out, naming the subview that sits lowest and the margin beneath it. The table view's heightForRowAtIndexPath then asks the library for a computed height instead of returning a stored value. The README gives two variants: a simplified version that passes a model, a keyPath, a cell class and a content view width, and an upgraded version for table views with fewer than 100 cells that passes a cell content view width. The README also notes that when height adaptation is used, a subview must not be laid out against the cell's bottom edge, because that edge is what the library is calculating.

Installing SDAutoLayout and laying out a first view

The README lists CocoaPods as the supported distribution channel and gives one pod line. The version constraint in that line is written as '~> 2.1.3', so a fresh install under that constraint will not necessarily pick up the newest published podspec. The repository also ships SDAutoLayout.podspec, a Podfile and a Podfile.lock at the top level, which is consistent with a CocoaPods-first project.

pod 'SDAutoLayout', '~> 2.1.3'

After running pod install, the README's first real example is a pair of sibling views. The instruction attached to it is explicit: add the views to their superview first, then apply the layout chain. The example lays out view0 with a left inset, a top inset, a fixed height and a width ratio, then places view1 to the right of view0 using view0 as the reference for both the left spacing and the height ratio.

UIView *view0 = [UIView new];
UIView *view1 = [UIView new];
[self.view addSubview:view0];
[self.view addSubview:view1];

view0.sd_layout
.leftSpaceToView(self.view, 10)
.topSpaceToView(self.view, 80)
.heightIs(100)
.widthRatioToView(self.view, 0.4);

view1.sd_layout
.leftSpaceToView(view0, 10)
.topEqualToView(view0)
.heightRatioToView(view0, 1)
.rightSpaceToView(self.view, 10);

For a label that should size to its text, the README gives a single call. Passing 0 makes the height follow the text; passing a value greater than 0 sets the height-to-width ratio instead. That distinction is easy to miss, and it is the difference between a label that grows with its content and one that holds a fixed proportion.

_label.sd_layout.autoHeightRatio(0);

For a self-sizing cell, the README's recommended simplified path is two steps. First, after the cell's layout is set up, tell the cell which subview is the bottom one and how much margin sits below it. Second, return the computed height from the table view delegate method, passing the model, a keyPath, the cell class and the content view width.

[cell setupAutoHeightWithBottomView:_view4 bottomMargin:10];

- (CGFloat)tableView:(UITableView *)tableView heightForRowAtIndexPath:(NSIndexPath *)indexPath
{
    id model = self.modelsArray[indexPath.row];
    return [self.tableView cellHeightForIndexPath:indexPath model:model keyPath:@"model" cellClass:[DemoVC9Cell class] contentViewWidth:cellContentViewWith];
}

The library caches computed heights, and the update log records cache work over several entries: automatic cache management when new cell data is inserted into a table view (2016.08.12), automatic adjustment of the height cache when a cell row is deleted (2016.06.23), and partial-refresh cache management (2016.01.21). If your table view mutates its data without going through paths the library observes, the cache is the first place to look when heights look stale.

Where SDAutoLayout stops being the right tool

The bottom-view contract is a real constraint, not a style preference. If a cell's design has two subviews whose vertical order changes with content, naming a single bottom view is wrong, and the README's own warning is that you must not lay out a subview against the cell's bottom edge when height adaptation is on. The upgrade log shows the library has been patched around this area more than once, including a 2016.01.13 entry adding a cell height method for the case where the bottom view is uncertain, which suggests the simple contract does not cover every layout.

The README also carries a maintenance signal worth reading carefully. The newest release listed is 2.2.1 from 2018-07-06, whose note describes fixing a centering constraint that failed in some layout combinations. The release before it, 2.2.0 from 2017-07-17, addresses developers reporting App Store review rejections caused by the string "UITableViewCellContentView". The last push to the repository was on 2026-05-21, but the release history has been quiet since 2018, and the update log's most recent entry is dated 2018.11.28. There is no changelog entry after that date. Treat the project as finished rather than evolving, and check whether the App Store rejection class of problem applies to your submission before you commit.

Finally, the README's `pod 'SDAutoLayout', '~> 2.1.3'` line is a version constraint, not a recommendation. If you need the 2.2.1 centering fix, verify what version your Podfile actually resolves to rather than copying the README line unchanged.

SDAutoLayout against plain NSLayoutAnchor and Masonry

The closest comparison in the same language and platform is Masonry, which also offers a chained Objective-C syntax over Auto Layout. The difference is what sits underneath the chain. Masonry's chain builds NSLayoutConstraint objects; SDAutoLayout's chain, per the repository description, is based on runtime, and it ships the height-caching and scroll content-sizing behaviour as part of the same library. If you already use Masonry for plain view layout, switching to SDAutoLayout buys you the cell height cache and the label and scroll view adaptation, not a different constraint vocabulary.

Against Apple's own NSLayoutAnchor API, the trade is control for brevity. NSLayoutAnchor is first-party, has no third-party release cadence to track, and will not produce a rejection over a private-looking view class name. SDAutoLayout gives you a shorter expression and the cell height machinery, at the cost of a dependency whose latest release is from 2018 and whose constraint creation happens through runtime dispatch rather than a documented public API. For a new Swift project, neither Masonry nor SDAutoLayout is the natural choice; Apple's layout APIs plus a first-party self-sizing cell configuration cover the same ground without the dependency.

Editorial conclusion

Adopt SDAutoLayout if you maintain an Objective-C iOS codebase, you are comfortable with a runtime-based constraint layer, and you want cell height caching handled by the library rather than by hand. Do not adopt it for SwiftUI, for AppKit, or for a project that requires an actively developed dependency: the last push was on 2026-05-21 but the newest release listed is 2.2.1 from 2018-07-06. Before wiring it into a shipping target, verify three things in your own build: that the setupAutoHeightWithBottomView call sits on the last bottom view of each cell, that no subview is laid out against the cell's bottom edge, and that the sd_layout chain is applied after addSubview.

Frequently asked questions

Official sources

1. gsdios/SDAutoLayout on GitHub
2. Issues
3. License: MIT
4. README
5. Releases