# MyLayout: an Objective-C layout framework that borrows Android's layout classes for iOS

> MyLayout replaces Auto Layout constraints with named container classes such as MyLinearLayout and MyRelativeLayout, plus pos and size objects that read like Android XML attributes. It is a good fit for code-built, dynamic iOS interfaces and a poor fit for teams standardized on Interface Builder and Apple's own tooling.

**youngsoft/MyLinearLayout** — MyLayout is a powerful iOS UI framework implemented by Objective-C. It integrates the functions with Android Layout,iOS AutoLayout,SizeClass, HTML CSS float and flexbox and bootstrap. So you can use LinearLayout,RelativeLayout,FrameLayout,TableLayout,FlowLayout,FloatLayout,PathLayout,GridLayout,LayoutSizeClass to build your App 自动布局 UIView UITableView UICollectionView RTL

- Repository: https://github.com/youngsoft/MyLinearLayout
- Stars: 4,401 · Forks: 886
- Language: Objective-C
- License: MIT
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/youngsoft-mylinearlayout

## The problem MyLayout solves for code-built iOS screens

UIKit gives you two ways to position subviews: set frames by hand, or describe relationships with Auto Layout constraints. Frames are fast but brittle when a container resizes; constraints are expressive but verbose in code and, per the README's own performance table, carry a measurable cost. MyLayout sits between the two. It exposes container classes named after Android's layouts, and each view gets extension properties for position and size that you configure with a small number of method calls.

The intended audience is an iOS developer who writes view hierarchies in Objective-C and wants the mental model of Android's LinearLayout or RelativeLayout. The README states that the framework integrates Autolayout, SizeClass, five Android layout classes, and the float, flexbox and bootstrap ideas from HTML and CSS. That is a broad claim, and the architecture diagram plus the class list are what back it: MyLinearLayout, MyRelativeLayout, MyFrameLayout, MyTableLayout, MyFlowLayout, MyFloatLayout, MyPathLayout, MyGridLayout and LayoutSizeClass.

This is not a general-purpose replacement for UIKit. It is a layout engine you opt into per container, and the rest of your view controller code does not change.

## MyLayoutPos, MyLayoutSize and how a layout pass is described

The architecture section of the README splits the API into two objects. MyLayoutPos represents a view's position, exposed on UIView as leftPos, topPos, bottomPos, rightPos, centerXPos and centerYPos. MyLayoutSize represents a dimension, exposed as widthSize and heightSize. Both support an equalTo method that accepts an NSNumber, another pos or size object, or an NSArray of them. The README gives the equivalence directly: A.leftPos.equalTo(@10) is the same as A.myLeft = 10, and A.widthSize.equalTo(@10) is the same as A.myWidth = 10. The short forms exist for the common case; the long forms exist when you need to relate one view's attribute to another's.

A value can be fractional. In the usage example, A.leftPos.equalTo(@0.2) sets a left margin of 20 percent of the superview's width, and A.rightPos.equalTo(@0.3) sets a 30 percent right margin. Sizes can be multiplied: D.widthSize.equalTo(S.widthSize).multiply(0.5) makes D half the container width. That is the mechanism that separates MyLayout from writing frames: percentages and cross-view references are first-class values, not arithmetic you perform yourself in layoutSubviews.

The container classes then decide the arrangement. MyLinearLayout places subviews in the order they were added, vertically or horizontally, which the README compares to UIStackView and Android's LinearLayout. MyRelativeLayout positions subviews by mutual constraints regardless of add order, which it compares to Auto Layout and Android's RelativeLayout. A container's own height can wrap its content, as the usage example describes for container S.

## Installing MyLayout and building a first vertical layout

The README carries CocoaPods and Carthage badges and the repository root contains MyLayout.podspec, so the two supported package managers are CocoaPods and Carthage. The README does not spell out the pod line or the Carthage command; the podspec name is MyLayout, which is the name you would reference. If you prefer not to use a package manager, MyLayout.xcodeproj is at the repository root and can be added to a workspace directly. The README badge states support for iOS 8 and later.

Once linked, the smallest useful thing to build is a vertical stack with spacing. This is the README's own linear layout sample, trimmed to the container and one child:

```objective-c
MyLinearLayout *S = [MyLinearLayout linearLayoutWithOrientation:MyOrientation_Vert];
S.myWidth = 120;
S.subviewSpacing = 10;

UIView *A = [UIView new];
A.myHorzMargin = 5;
A.myHeight = 40;
[S addSubview:A];
```

The container is created with the MyOrientation_Vert orientation, fixed at 120 points wide, and given a subviewSpacing of 10 points between children. Child A uses myHorzMargin to get equal left and right margins and myHeight for a fixed height, so its width is whatever remains. After adding S to the view controller's view, you should see a 120-point-wide red container holding a green child inset by 5 points on each side and 40 points tall.

The second thing worth trying is a proportional child, because that is where the pos and size objects earn their place:

```objective-c
UIView *D = [UIView new];
D.rightPos.equalTo(@20);
D.widthSize.equalTo(S.widthSize).multiply(0.5);
D.heightSize.equalTo(@40);
[S addSubview:D];
```

D is placed 20 points from the container's right edge, is half the container's width, and is 40 points tall. None of those three values requires a constraint object or a layout pass override.

## What the repository does not document

The README is generous with API examples and thin on operational detail. There is no rollback procedure for a layout that misbehaves, no migration guide from Auto Layout, and no statement about thread safety or whether layout attributes may be mutated off the main thread. The performance tables are the project's own measurements, presented without a described methodology, so treat them as the author's numbers rather than an independent result.

The README also does not document how MyLayout interacts with self-sizing UITableView and UICollectionView cells, even though both appear in the repository topics. The demo and test targets exist in the repository layout (MyLayoutDemo, MyLayoutTests, MyLayoutUITests), so behaviour can be checked there, but the prose documentation does not cover it.

Finally, the README badge states iOS 8 support. That is a floor, not a guarantee that every API behaves identically across that range, and the documentation does not break down behaviour by OS version.

## Where MyLayout is the wrong choice

The clearest case against MyLayout is a team that has standardized on Interface Builder. MyLayout is a code API: you create containers programmatically and set pos and size objects. The repository includes storyboard and xib topics, but the README's examples are all Objective-C construction, and the documentation does not describe a design-time workflow. If your designers hand off storyboards and your engineers edit constraints in the canvas, MyLayout adds a second layout system rather than replacing one.

The second case is a Swift-only codebase. The README states that the Swift version of MyLayout is a separate project named TangramKit. Adopting MyLayout in a Swift app means either bridging Objective-C headers or using that other project, and the two are not the same repository.

The third case is a screen where Auto Layout already works and nobody is fighting it. MyLayout's value shows up in proportional sizing, add-order-driven stacks and cross-view references. A form with a handful of static labels and fields does not need a new layout engine, and introducing one means every future contributor learns a second positioning vocabulary.

## MyLayout compared with UIStackView and Auto Layout

The most direct alternative is UIStackView, which the README itself names as the equivalent of MyLinearLayout. Both arrange subviews in order and both support spacing between items. The difference is scope and control. UIStackView handles distribution and alignment along one axis and expects Auto Layout constraints for anything outside that axis. MyLayout's containers come with their own position and size model, so a MyLinearLayout child can carry a percentage left margin and a width derived from a sibling's width without any NSLayoutConstraint objects existing.

Auto Layout and Masonry are the other comparison points, and the README's performance table lists both. The numbers it reports are per-subview create and layout times, with MyLayout generally below Auto Layout and Masonry on both measures and above raw frame setting. That ordering is plausible given that MyLayout computes positions directly rather than solving a constraint system, but it is the project's own table and the README does not describe the hardware or the test harness.

The practical distinction is what you write. Auto Layout asks you to declare relationships between attributes and let a solver find the geometry. MyLayout asks you to declare the geometry directly on the view, using numbers, percentages and references. The second is easier to read in a diff and harder to reuse across screens.

## Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-03-15, the same day release 2.0.0 was tagged. The release before that, 1.9.8, was tagged on 2020-08-04, so the 2.0.0 line arrived after a gap of roughly five and a half years. Anyone upgrading from 1.9.x should read CHANGELOG.md at the repository root before changing a podspec or Cartfile entry; a major version number after that long a gap is where breaking changes usually live.

The licence is MIT, which permits use in closed-source applications and requires preserving the copyright notice and permission notice. That is the standard reading of the licence text; it is not legal advice, and if your organization has specific obligations around attribution, the LICENSE file at the repository root is the document to read.

Upgrade cost is mostly the cost of the API surface you touch. If you use the short properties such as myLeft and myWidth, the surface is small. If you use equalTo with arrays of pos or size objects and multiply chains, a change to those methods would ripple through every layout you wrote. The podspec, the Xcode project and the Carthage badge all exist, so there are three integration paths to keep aligned with whatever version you pin.

## Conclusion

Adopt MyLayout if you build UIKit screens in code, need RTL support and want layout code that reads like Android's LinearLayout or RelativeLayout without adopting Auto Layout's constraint objects. Skip it if your team is committed to Interface Builder and Apple's Auto Layout, or if you need Swift-native APIs, since the Swift counterpart is a separate project called TangramKit. Before committing, verify three things in the repository: that the podspec version matches the release you intend to pin, that your deployment target is at least iOS 8 as the README badge states, and that the layout classes you plan to use appear in the MyLayout directory listing rather than only in the demo app.

## FAQ

### What is the difference between MyLayout's MyLinearLayout and MyRelativeLayout?

MyLinearLayout arranges subviews in the order they were added, vertically or horizontally, and the README compares it to UIStackView and Android's LinearLayout. MyRelativeLayout positions subviews through mutual constraints regardless of add order, and the README compares it to Auto Layout and Android's RelativeLayout.

### What is MyLayout's MyRelativeLayout equivalent to in iOS?

The README states that MyRelativeLayout is equivalent to Auto Layout on iOS and RelativeLayout on Android. Subviews are positioned by setting constraints on each other rather than by the order in which they are added.

### Which layout class should I use in MyLayout?

The README does not rank its layout classes. It documents each one by analogy: MyLinearLayout for ordered stacks, MyRelativeLayout for mutual constraints, and MyFrameLayout, MyTableLayout, MyFlowLayout, MyFloatLayout, MyPathLayout and MyGridLayout for the other arrangements. Pick the one whose description matches the arrangement you need.

## Sources

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

---

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