How do I apply Nori styles to a custom UIView subclass?

Extend Nori's Styleable classes, such as StyleableView, and override the intrinsicStyle() method to define your style in Swift code, then set the custom class in Interface Builder. Note that only supported view types are directly covered, so for unsupported views, workarounds may be needed.

Can Nori styles be changed dynamically at runtime?

No, Nori focuses on intrinsic styles defined at compile-time via overridden methods; for dynamic runtime changes, you'd need to manually update view properties or use alternative approaches, as the library doesn't provide built-in mechanisms for this.

Nori vs using UIAppearance for global styles?

Nori offers more granular, per-component styling with live Interface Builder previews, while UIAppearance provides app-wide theming but lacks real-time design feedback. Choose Nori for storyboard-centric projects needing visual iteration, and UIAppearance for broader, static theme enforcement.

How to handle dark mode with Nori?

You can define styles conditionally in Swift code by checking traits or using asset catalogs, but Nori doesn't have built-in dark mode support; you'll need to manually adapt intrinsicStyle() methods to respond to interface style changes.

Is Nori compatible with Swift Package Manager?

The README doesn't specify, but as a GitHub-hosted iOS library, it likely supports manual integration or CocoaPods; check the repository for updated installation instructions, as community-maintained libraries might lack detailed setup guides.

What are good alternatives to Nori for storyboard styling?

Consider libraries like SwiftGen for code-generated assets or manual @IBDesignable implementations; for more flexibility, SwiftUI-based tools like SwiftUIX might be better for modern apps, though they require abandoning storyboards.

Open-Awesome

Nori

MITSwift0.2.0

Apply code-based style guides to iOS storyboards using Swift custom classes.

GitHub

290 stars7 forks0 contributors

What is Nori?

Nori is an iOS library that allows developers to apply code-based style guides to storyboard views. It provides custom `Styleable` UI components (like `StyleableLabel`, `StyleableButton`) that can be designed in Swift code and rendered live in Interface Builder. This solves the problem of maintaining visual consistency between code and storyboard designs.

Target Audience

iOS developers who use Interface Builder storyboards but want to define UI styles programmatically for better consistency and reusability.

Value Proposition

Developers choose Nori because it uniquely bridges storyboard design with code-based styling, offering live previews via @IBDesignable while keeping style logic in Swift for maintainability.

Overview

Easier to apply code based style guide to storyboard.

Use Cases

Best For

Applying consistent typography and colors across storyboard labels
Creating reusable button styles with different states in Interface Builder
Maintaining design systems across iOS storyboard projects
Teams transitioning from pure storyboard design to code-based styling
Projects needing live previews of styled UI components in Xcode
Enforcing brand guidelines across iOS app interfaces

Not Ideal For

Projects built entirely with SwiftUI, as Nori is UIKit and storyboard-specific.
Teams that prefer visual-only styling in Interface Builder without writing any Swift code.
Apps requiring highly dynamic UI styles that change at runtime based on data or user actions.
Large organizations needing extensive documentation, community support, or vendor-backed frameworks.

Pros & Cons

Pros

Live Design Previews

Supports @IBDesignable for real-time rendering of custom styles directly in Interface Builder, speeding up design iteration as shown in the README's GIF example.

Code-Based Consistency

Enables UI styles to be defined in Swift classes like StyleableLabel, ensuring reusable and maintainable components across storyboards, aligning with the philosophy of keeping styling logic in code.

State-Aware Styling

Allows buttons to define different styles for each UIControlState, such as normal or highlighted, providing flexibility for interactive elements without manual state handling.

Core View Support

Covers essential UIKit components including Label, Button, and TextField, making it practical for common UI tasks in storyboard-based apps.

Cons

Limited View Coverage

Only supports six view types, missing complex or custom views like TableViewCell or CollectionView, which limits its use in advanced UI scenarios.

UIKit and Storyboard Lock-in

Heavily dependent on Interface Builder and UIKit, making it unsuitable for modern SwiftUI projects and creating migration challenges for teams adopting newer technologies.

Setup Overhead

Requires creating custom subclasses and overriding methods like intrinsicStyle() for each style, which can be verbose and time-consuming for simple styling needs.

Frequently Asked Questions

Related Projects

infer

A static analyzer for Java, C, C++, and Objective-C

Strong typed, autocompleted resources like images, fonts and segues in Swift projects

Stars9,569

Forks779

Last commit1 year ago

SwiftGen

The Swift code generator for your assets, storyboards, Localizable.strings, … — Get rid of all String-based APIs!

Stars9,552

Forks765

Last commit3 months ago

XcodeGen

A Swift command line tool for generating your Xcode project

Stars8,642

Forks888

Last commit8 days ago

Community-curated · Updated weekly · 100% open source

Found a gem we're missing?

Open-Awesome is built by the community, for the community. Submit a project, suggest an awesome list, or help improve the catalog on GitHub.

Submit a project Star on GitHub