Introducing Banksalad Product Language

Banksalad iOS developer Ryu Seong-du introduced Banksalad Product Language(BPL), a language shared and used by all product members. While the existing design system was limited to the design domain, BPL covers the language of the entire product-making process, from planning to development.

Reducing Communication Costs and Unifying Abstraction Units

A significant portion of meeting time was consumed due to terminology mismatches such as 'dialog vs popup' between planners, designers, and developers, as well as differences in UI abstraction units. For example, while a designer recognizes a particular symbol modification as a specific change, iOS tends to perceive it as a modification affecting the entire navigation flow, and Android as affecting the entire app. To solve this, the BPL team adopted a 'Code and Show' culture, building and verifying a product implemented in code first, rather than a clear planning document.

Comparing Code Across Platforms and Establishing Concepts

The BPL team implemented the PageExample screen in code for each platform (Web, Android, iOS) and compared and analyzed them. Through this, they clearly identified the differences between shared concepts such as 'Container' and 'Child' and their actual implementations, and finalized terminology. In particular, they unified abstraction rules by contrasting each platform's structure, such as AssetSection in Web and ListItemContainer in Android.

Leveraging the Similarity Between Figma and SwiftUI

To speed up communication between designers and developers, the team leveraged the structural similarity between Figma and SwiftUI. Figma's Autolayout is similar to SwiftUI's layout system, and Components are similar to SwiftUI's view structure. Developers mimicked the way designers created components in Figma, implementing them as independent classes while avoiding excessive abstraction and maintaining 1:1 correspondence.

Layout Implementation in a Legacy Environment

Since Banksalad must support up to iOS 11, it could not directly use SwiftUI's @State or Combine. Instead, they applied the LayoutDriven pattern, updating layouts by reflecting the latest state in UI elements whenever data changed. This allowed the benefits of SwiftUI's declarative UI paradigm to be applied even in a legacy UIKit environment.