왜 네이티브 개발에는 상태관리 개념이 없는가?

 

iOS네이티브만 하다 플러터로 넘어가니  상태관리 개념이 매우 생소했다. 네이티브에서는 전혀 접하지 않았기 때문..

 

요점: Imperative Programming(명령형 프로그래밍) vs Declarative Programming(선언형 프로그래밍) 차이에 의한 것

 

 

1. iOS 네이티브 개발의 전통적 방식

iOS 네이티브 개발은 Imperative Programming(명령형 프로그래밍) 방식
이 방식에서는 상태를 명시적으로 관리하기보다는, 이벤트나 액션에 따라 UI를 직접 업데이트하고 로직을 구현

주요 특징:

• 상태와 UI 업데이트가 명령형으로 이루어짐.
  • UILabel.text를 직접 수정하거나, UIView의 속성을 변경하는 방식.
  • 특정 이벤트가 발생하면 그에 맞는 UI 업데이트를 명령으로 작성.
• ViewController 중심의 구조(MVC, MVVM, VIPER 등).
  • 상태는 ViewController 내부의 인스턴스 변수 or 모델 객체에서 간단히 관리.
    ex) isLoading 플래그를 Bool 변수로 관리하고, 필요할 때 UI 업데이트
  • 전역 상태 관리보다 개별 화면 단위로 상태를 관리

상태 관리를 별도로 정의하기보다는 특정 컴포넌트(ViewController)나 데이터 모델 수준에서 암묵적으로 관리하는 경우가 많았음

ex. 데이터는 주로 싱글톤, NSNotificationCenter, 혹은 delegate/closure를 사용해 전달.

 

>> RxSwift, Combine 같은 라이브러리를 사용하는 경우, 비동기 작업 결과를 UI와 연결하며 상태 관리가 필요.

 

---

 

 

2. Flutter/React 같은 선언적 UI 프레임워크의 등장

Flutter나 React는 Declarative Programming(선언형 프로그래밍) 기반
UI는 상태(state)에 따라 자동으로 업데이트

선언적 UI의 특징:

• UI를 상태(state)에 종속적으로 정의.
  • 특정 상태가 변경되면 UI가 자동으로 재렌더링.
  • 예: setState로 상태를 업데이트하면 관련된 UI가 갱신.
• 상태 관리를 위한 전용 도구가 필요.
  • 컴포넌트 간 상태 공유나 전역 상태 관리를 위해 Provider, Redux 같은 상태 관리 라이브러리 사용.

 

---

 

요약:

iOS 네이티브 개발에서는 상태를 명시적으로 관리하는 대신, 화면 단위(ViewController)에서 필요한 데이터를 직접 관리하거나, 상태 변경 시 명령형으로 UI를 업데이트하는 방식이 주로 사용

그러나 Flutter나 React는 상태 기반의 선언적 UI 철학을 따르기 때문에 상태 관리의 개념이 더 부각된 것.