GitShow/facebook/QuickLayout
facebook

QuickLayout

QuickLayout is a production-ready declarative layout library for UIKit. Built for large-scale applications, it combines expressive Swift APIs with a lightweight layout engine to deliver high performance reliability, and long-term maintainability.

by facebook
flow-layoutgrid-layouthstackioslayoutlayout-engineno-autolayoutstack-layout
Star on GitHubForkWebsite

Swift

357 stars21 forks34 contributorsActive · 4d agoSince 2025MIT

Meet the team

See all 34 on GitHub →
constantine-fry
constantine-fry13 contributions
saadhzahid
saadhzahid6 contributions
matrush
matrush2 contributions
pcki11
pcki112 contributions
Wilfred
Wilfred2 contributions
nuomi1
nuomi12 contributions
drodriguez
drodriguez1 contribution
jaxtynSong
jaxtynSong1 contribution

Languages

View on GitHub →
Swift86%
MDX10.4%
CSS2.2%
JavaScript1.4%

Commit activity

Last 12 weeks · 15 commits

Full graph →

Community health

4 of 6 standards met

Community profile →
75
✓README✓License✓Contributing✓Code of Conduct○Issue Template○PR Template

Recent PRs & issues

Active · Last activity 4d ago
See all on GitHub →
astralchen
Recommended UIContentConfiguration / UIContentView pattern for table and collection cellsOpenIssue

Question Related to #12, but this question is about UIKit’s configuration-based cell architecture rather than applying directly to each cell subclass. QuickLayout currently special-cases and so that a cell’s QuickLayout body is hosted in . With , UIKit creates and manages a custom . I could not find an example of this pattern and am unsure which object should own QuickLayout layout and sizing. When a generic or receives a custom , is applying to that content view the supported approach? Minimal example Could you clarify: Should live only on the custom , leaving the cell generic, or should the cell also adopt ? For self-sizing table rows and collection items with estimated dimensions, is the generated on the content view sufficient, or is cell-level sizing customization still required as discussed in #12? When applying a configuration that changes the content size, is sufficient? Should , a cell-level invalidation call, or a QuickLayout-specific helper be used? On iOS 16+, should be implemented so UIKit can reuse the existing content view? Are there any differences in the recommended pattern for and ? An official example covering both cell types would be very helpful. Thanks! Environment QuickLayout: at Swift 6 iOS 15+

astralchen · 1w ago
Structured data for AI agents

Repository: facebook/QuickLayout. Description: QuickLayout is a production-ready declarative layout library for UIKit. Built for large-scale applications, it combines expressive Swift APIs with a lightweight layout engine to deliver high performance reliability, and long-term maintainability. Stars: 357, Forks: 21. Primary language: Swift. Languages: Swift (86%), MDX (10.4%), CSS (2.2%), JavaScript (1.4%). License: MIT. Homepage: https://facebook.github.io/QuickLayout Topics: flow-layout, grid-layout, hstack, ios, layout, layout-engine, no-autolayout, stack-layout, vstack, zstack. Open PRs: 15, open issues: 5. Last activity: 4d ago. Community health: 75%. Top contributors: constantine-fry, saadhzahid, matrush, pcki11, Wilfred, nuomi1, drodriguez, jaxtynSong, JonyFang, clocksarestupid and others.

·@ofershap

Replace github.com with gitshow.dev