디자이너가 뜯어보는 SwiftUI View (작성중)

zam·2023년 5월 10일
0
post-thumbnail

GPT3.5 모델의 답변을 인용했습니다.

참고한 글들
Swift: GeometryReader는 무엇일까?

SwiftUI는 기기 및 화면 크기에 맞게 자동으로 조정되는 레이아웃 시스템을 제공한다고 한다.디자이너가 SwiftUI의 기본 동작을 이해하고 있다면 그를 응용한 디자인을 뽑아낼 수 있을 거라 생각해 SwiftUI가 뷰를 그려내는 구체적인 원리에 대해 궁금해지기 시작했다.

내가 만약 앱을 혼자 개발한다면 디자인과 개발을 최소화하며 SwiftUI로 개발하면 가장 편리할 것 같다는 막연한 직감이 있다.

공부 후에 SwiftUI가 어떻게 설계 되어있길래 그에 맞는 디자인이 뭔지, 디자이너가 꼭 SwiftUI에 맞게 해야하는지, 그 적절선에서 디자이너의 역할은 뭐일지 정의해보기?

SwiftUI가 뷰를 그리는 방식

SwiftUI는 선언적 구문(declarative syntax)을 사용하여 뷰를 그립니다. 이는 개발자가 어떤 뷰를 어떻게 보여줄지를 직접 구현하는 대신, 뷰의 상태와 특성을 설명하는 방식으로 뷰를 구성하는 것입니다.

SwiftUI는 이러한 선언적 구문을 사용하기 위해 state와 binding, view modifier 및 layout system을 사용합니다. state와 binding은 뷰의 데이터 모델링에 사용되며, 뷰 modifier는 뷰의 스타일, 레이아웃, 동작 및 상호작용을 지정하는 데 사용됩니다. 레이아웃 시스템은 뷰의 크기 및 위치를 자동으로 조정하도록 설계되어 있습니다.

또한, SwiftUI는 뷰의 상태가 변경되면 자동으로 다시 그리도록 되어 있습니다. 이는 개발자가 뷰의 레이아웃 및 모양을 갱신하고, 사용자 이벤트에 응답하며, 데이터 모델을 업데이트하는 등의 작업을 자동으로 처리하도록 해주는 장점을 가지고 있습니다.

GeometryReader

내용이 MECE하지 않아서 수정작성중..

SwiftUI에서 GeometryReader는 화면에 대한 정보를 얻는 유용한 방법 중 하나입니다. 그러나 때로는 GeometryReader를 사용하지 않고도 뷰를 레이아웃 할 수 있습니다.

예를 들어, VStack, HStack 및 ZStack과 같은 SwiftUI의 컨테이너 뷰를 사용하면 뷰를 배치하는 데 충분합니다. 이러한 컨테이너 뷰는 뷰를 자동으로 쌓아 올리고 위치를 지정할 수 있으며, 일반적으로 GeometryReader를 사용할 필요가 없습니다.

또한 SwiftUI에는 뷰의 크기 및 위치를 제어하기 위해 다양한 레이아웃 속성이 내장되어 있습니다. 예를 들어, padding, frame 및 offset과 같은 속성을 사용하여 뷰의 위치와 크기를 조정할 수 있습니다.

그러나 GeometryReader를 사용하면 더욱 세밀한 제어가 가능해집니다. 따라서 상황에 따라서는 GeometryReader를 사용하는 것이 좋을 수 있습니다.

GeometryReader도 하나의 Container View이고, 그 Container View가 상위 View로부터 제안받은 크기, 위치에 접근하고 있다

반드시 GeometryReader의 기능이 필요할 때만 사용하는 것이 좋다

반드시 GeometryReader의 기능이 필요할 때는 언제인가?

  • GeometryReader를 사용하면 뷰의 크기와 위치에 대한 정보를 얻을 수 있음
  • GeometryReader는 부모 컨테이너의 크기에 맞게 자식 뷰의 레이아웃을 결정하는 역할을 함

커스텀 배치 또는 레이아웃

  • 뷰를 겹쳐서 배치
  • 뷰의 위치를 다른 뷰에 상대적으로 설정

뷰의 크기에 따른 동적 조정

  • 뷰의 크기나 위치에 따라 동적으로 뷰의 스타일이나 레이아웃 변경
  • 뷰의 크기에 따라 텍스트의 폰트 크기를 자동으로 조정
  • 뷰의 크기에 따라 이미지의 비율을 조절

ex. 다양한 디바이스에 대응하는 배경 이미지

GeometryReader { geometry in
    Image("background")
        .resizable()
        .aspectRatio(contentMode: .fill)
        .frame(width: geometry.size.width, height: geometry.size.height)
}

ex. 동적인 그리드 레이아웃 : 뷰의 개수와 디바이스의 가로 크기에 따라 그리드의 열 수와 아이템 크기를 자동으로 조정

GeometryReader { geometry in
    let numberOfColumns = Int(geometry.size.width / 100)
    let itemSize = CGSize(width: geometry.size.width / CGFloat(numberOfColumns), height: 100)
    
    // 그리드 레이아웃을 위한 뷰 배치
    // ...
}

부모 뷰의 크기에 상대적인 크기 또는 위치를 가지는 뷰 구현

뷰의 크기가 동적으로 변하는 상황에서도 일관된 레이아웃을 유지할 수 있습니다.

뷰의 프레임 정보를 직접 활용할 때

프레임정보

  • 위치 (Origin): 뷰의 화면 내에서의 좌표를 나타냅니다. 일반적으로 좌측 상단이 원점(0, 0)이며, 오른쪽으로 갈수록 x좌표가 증가하고 아래로 내려갈수록 y좌표가 증가합니다.
  • 크기 (Size): 뷰의 가로 너비와 세로 높이를 나타냅니다. 크기는 화면에 표시되는 뷰의 영역을 결정합니다.
  • 경계 (Bounds): 뷰의 좌표계 내에서의 사각형 영역을 나타냅니다. 경계는 뷰의 위치와 크기를 포함하며, 뷰의 내부 내용이 표시되는 영역을 정의합니다.
  • 그래픽 처리: 뷰의 크기와 위치에 따라 그리기 작업을 하거나, 뷰의 프레임에 따라 특정 형태를 그릴 수 있습니다.
  • 애니메이션: 뷰의 위치나 크기가 변경될 때, GeometryReader를 통해 프레임 정보를 추출하고 해당 정보를 기반으로 애니메이션을 적용할 수 있습니다. 예를 들어, 뷰의 크기가 변경될 때, 확대/축소 애니메이션을 적용할 수 있습니다.
  • 레이아웃 조정: 뷰의 프레임에 따라 다른 뷰의 위치를 변경하거나, 뷰의 크기에 따라 다른 뷰의 크기를 조정할 수 있습니다.
  • 반응형 디자인: 뷰의 프레임 정보를 활용하여 다른 디바이스나 화면 크기에 따라 뷰의 배치나 크기를 동적으로 조정할 수 있습니다.

ex. 뷰의 위치에 따른 동적인 애니메이션: GeometryReader를 사용하여 뷰의 위치에 따라 동적인 애니메이션을 적용할 수 있습니다. 예를 들어, 뷰의 위치가 화면 가운데에 오면 페이드 인 애니메이션을 적용하고, 화면 가장자리에 가까워지면 페이드 아웃 애니메이션을 적용할 수 있습니다.

GeometryReader { geometry in
    MyView()
        .opacity(abs(geometry.frame(in: .global).midX - geometry.size.width / 2) < 50 ? 1.0 : 0.5)
        .animation(.easeInOut)
}

실제 사례

커스텀 배치 또는 레이아웃: 만약 SwiftUI의 내장된 레이아웃 시스템으로는 원하는 배치나 레이아웃을 구현하기 어렵다면 GeometryReader를 사용할 수 있습니다. 예를 들어, 뷰를 겹쳐서 배치하거나, 뷰의 위치를 다른 뷰에 상대적으로 설정하거나, 뷰의 크기를 동적으로 조절해야 하는 경우에 GeometryReader를 활용할 수 있습니다.

뷰의 크기에 따른 동적 조정: 뷰의 크기나 위치에 따라 동적으로 뷰의 스타일이나 레이아웃을 변경하고 싶을 때 GeometryReader를 사용할 수 있습니다. 예를 들어, 뷰의 가로 크기에 따라 텍스트의 폰트 크기를 자동으로 조정하거나, 뷰의 세로 크기에 따라 이미지의 비율을 조절하고 싶을 때 GeometryReader를 활용할 수 있습니다.

다양한 디바이스에 대응하는 배경 이미지: GeometryReader를 사용하여 배경 이미지를 디바이스의 화면 크기에 맞게 동적으로 조정할 수 있습니다. 예를 들어, 디바이스의 가로 길이에 따라 이미지의 가로 비율을 조정하고, 디바이스의 세로 길이에 따라 이미지의 세로 비율을 조정할 수 있습니다.

동적인 그리드 레이아웃: GeometryReader를 사용하여 동적으로 변하는 화면 크기에 맞춰 그리드 레이아웃을 조정할 수 있습니다. 예를 들어, 뷰의 개수와 디바이스의 가로 크기에 따라 그리드의 열 수와 아이템 크기를 자동으로 조정할 수 있습니다.

화면의 일부 영역에 대한 조작: GeometryReader를 사용하면 화면의 일부 영역에 대한 접근과 조작이 가능합니다. 예를 들어, 특정 뷰를 화면의 왼쪽 상단에 고정시키고, 다른 뷰를 화면의 우측 중앙에 배치하고 싶을 때 GeometryReader를 사용하여 각 뷰의 위치를 설정할 수 있습니다.

뷰의 위치에 따른 동적인 애니메이션: GeometryReader를 사용하여 뷰의 위치에 따라 동적인 애니메이션을 적용할 수 있습니다. 예를 들어, 뷰의 위치가 화면 가운데에 오면 페이드 인 애니메이션을 적용하고, 화면 가장자리에 가까워지면 페이드 아웃 애니메이션을 적용할 수 있습니다.
4.

GeometryReader는 유연한 레이아웃 구성을 위한 강력한 도구이지만, 필요에 따라 적절하게 사용하는 것이 좋습니다. 단순한 레이아웃 작업에서는 GeometryReader를 사용하지 않고도 SwiftUI의 다른 기능들을 활용하여 원하는 결과를 얻을 수 있습니다.

화면의 일부 영역에 대한 조작

앱의 상단바 또는 탭바와 겹치지 않는 컨텐츠 배치: GeometryReader를 사용하여 화면의 일부 영역에 상단바 또는 탭바가 가려지지 않도록 컨텐츠를 배치할 수 있습니다. 예를 들어, 앱 내에서 헤더 뷰를 화면의 상단에 고정시키고, 해당 헤더 뷰 아래에 컨텐츠를 표시할 때 GeometryReader를 활용하여 헤더 뷰의 위치를 조정할 수 있습니다.

화면 분할 및 멀티뷰: GeometryReader를 사용하여 화면의 일부 영역에 다른 뷰를 겹쳐서 배치하거나, 여러 뷰를 동시에 화면에 나타내는 멀티뷰 인터페이스를 구현할 수 있습니다. 예를 들어, 앱에서 사진을 확대하여 상세 정보를 표시하는 화면을 구현할 때, GeometryReader를 사용하여 확대된 이미지와 상세 정보를 일정한 비율로 배치하거나, 다른 뷰와 겹쳐서 표현할 수 있습니다.

사용자 정의 레이아웃: GeometryReader를 사용하여 사용자 정의 레이아웃을 구현할 수 있습니다. 예를 들어, 캔버스 앱에서 도형 도구를 사용하여 도형을 그릴 때, GeometryReader를 사용하여 캔버스 영역을 정의하고, 도형의 크기와 위치를 조정하는 데 활용할 수 있습니다.

동적인 애니메이션 및 상호작용: GeometryReader를 사용하여 화면의 일부 영역에 대한 터치 이벤트나 제스처를 감지하고, 해당 이벤트에 따라 동적인 애니메이션을 적용할 수 있습니다. 예를 들어, 앱에서 스와이프 제스처를 사용하여 뷰를 드래그하거나 확대/축소하는 동작을 구현할 때, GeometryReader를 활용하여 제스처에 따라 뷰의 위치와 크기를 조정하고, 애니메이션 효과를 적용할 수 있습니다.

특정 뷰를 화면의 왼쪽 상단에 고정시키기:

GeometryReader { geometry in
    VStack {
        Text("Fixed View")
            .frame(width: geometry.size.width * 0.5, height: 50)
            .background(Color.blue)
            .position(x: geometry.size.width * 0.25, y: 25)
        
        // 다른 뷰들...
    }
}

위의 예시에서는 GeometryReader 내부에 VStack을 사용하여 뷰를 배치하고, Text 뷰를 화면의 왼쪽 상단에 고정시키기 위해 position(x:y:)을 사용하였습니다. geometry.size.width를 활용하여 화면 너비의 절반에 해당하는 크기로 설정하고, position을 통해 좌표를 지정하여 뷰를 배치할 수 있습니다.

다른 뷰를 화면의 우측 중앙에 배치하기:

GeometryReader { geometry in
    VStack {
        // 다른 뷰들...
        
        Text("Centered View")
            .frame(width: 200, height: 100)
            .background(Color.red)
            .position(x: geometry.size.width * 0.75, y: geometry.size.height * 0.5)
    }
}

위의 예시에서는 GeometryReader 내부에 VStack을 사용하여 뷰를 배치하고, Text 뷰를 화면의 우측 중앙에 배치하기 위해 position(x:y:)을 사용하였습니다. geometry.size.width와 geometry.size.height를 활용하여 화면의 너비와 높이의 일부분에 해당하는 좌표를 지정하여 뷰를 배치할 수 있습니다.

왜 필요에 따라 적절히 사용해야해?

SwiftUI는 디자인 시스템을 적용하기 쉽게 만들어진 프레임워크이기 때문!

GeometryReader는 뷰의 크기와 위치에 대한 정보를 제공하고, 동적인 레이아웃을 구현하는 데 사용될 수 있습니다. 그러나 GeometryReader는 렌더링 성능에 영향을 미칠 수 있고, 코드의 가독성을 저하시킬 수도 있습니다. 따라서 필요에 따라 적절하게 사용해야 합니다. 여기에 몇 가지 이유가 있습니다:

성능: GeometryReader는 뷰 계층 구조 내의 모든 뷰에 대해 크기와 위치 정보를 계산해야 하므로 성능에 영향을 줄 수 있습니다. 특히, 계산이 복잡하거나 많은 수의 GeometryReader가 중첩되어 있는 경우 성능 저하의 원인이 될 수 있습니다. 따라서 단순한 레이아웃 작업에서는 GeometryReader를 사용하지 않고도 다른 SwiftUI 기능들을 활용하여 성능을 최적화할 수 있습니다.

가독성: GeometryReader는 코드의 가독성을 저하시킬 수 있습니다. GeometryReader를 사용하면 뷰 코드 내에 레이아웃 관련 로직이 섞이게 되므로, 코드가 복잡해지고 유지보수가 어려워질 수 있습니다. 따라서 간단한 레이아웃 작업에서는 GeometryReader를 사용하지 않고도 SwiftUI의 다른 레이아웃 기능들을 활용하여 코드를 간결하고 가독성 있게 유지할 수 있습니다.

디자인 시스템 준수: SwiftUI는 디자인 시스템을 적용하기 쉽게 만들어진 프레임워크입니다. 따라서 디자인 가이드라인에 따라 컴포넌트를 구성하고 레이아웃을 설정하는 것이 중요합니다. GeometryReader를 남용하면 디자인 시스템에 어긋난 레이아웃을 구현할 수 있으므로, 필요한 경우에만 사용하여 디자인 시스템을 준수하는 것이 좋습니다.

결론적으로, GeometryReader는 특정 상황에서 유용한 도구이지만, 필요한 경우에만 적절하게 사용하는 것이 좋습니다. 단순한 레이아웃 작업에서는 GeometryReader를 사용하지 않고도 SwiftUI의 다른 기능들을 활용하여 원하는 결과를 얻을 수 있으며, 이는 성능과 코드의 가독성 측면에서도 이점을 가질 수 있습니다.

SwiftUI는 디자인 시스템을 적용하기 쉽게 만들어진 프레임워크인 이유

선언적인 구문: SwiftUI는 선언적인 구문을 사용하여 UI를 설계할 수 있습니다. UI 요소들을 구조화하고 조합하는 데 필요한 코드를 최소화하고, 직관적인 방식으로 UI를 설명할 수 있습니다. 이러한 선언적인 구문은 디자인 시스템을 적용하기에 효과적입니다. UI 요소들의 계층 구조와 스타일을 명확하게 정의할 수 있으며, UI의 일관성과 재사용성을 높일 수 있습니다.

모듈화와 재사용성: SwiftUI는 뷰를 모듈화하고 재사용할 수 있는 구조를 가지고 있습니다. 커스텀 뷰를 정의하고 조합하여 복잡한 UI를 구성할 수 있습니다. 이러한 모듈화와 재사용성은 디자인 시스템을 구축하고 적용하는 데 매우 유용합니다. UI 요소들을 디자인 시스템의 구성 요소로 추상화하고, 다양한 화면에서 재사용할 수 있는 일관된 UI 패턴을 만들 수 있습니다.

동적인 레이아웃: SwiftUI는 동적인 레이아웃을 쉽게 구현할 수 있는 기능을 제공합니다. 화면 크기, 기기 방향 등과 같은 환경 변화에 따라 UI를 동적으로 조정할 수 있습니다. 이는 다양한 디바이스에 대응하는 디자인 시스템을 구현하는 데 유용합니다. 화면 크기에 따라 뷰의 배치와 크기를 조정하거나, 다양한 기기에서 일관된 UI 경험을 제공할 수 있습니다.

사전 정의된 스타일과 모션: SwiftUI는 사전 정의된 스타일과 모션을 제공하여 디자인 시스템을 적용하기를 쉽게 만들어줍니다. 다양한 스타일을 사용하여 UI 요소들에 일관된 시각적인 효과를 적용할 수 있고, 애니메이션과 모션을 사용하여 UI 요소들의 상호작용을 부드럽고 생동감 있게 만들 수 있습니다.

SwiftUI가 쓰레기인 이유

성능 문제: SwiftUI는 아직 성능 문제가 존재할 수 있습니다. 특히 복잡한 UI나 데이터 바인딩이 많은 경우에는 성능 저하가 발생할 수 있습니다. 이는 뷰 계층 구조의 업데이트나 렌더링 과정에서 발생할 수 있는 문제입니다. 애플은 지속적으로 SwiftUI의 성능을 개선하고 최적화하기 위해 노력하고 있습니다.

완전한 호환성 부재: SwiftUI는 iOS 13 이상에서만 사용할 수 있으며, 이전 버전의 iOS와 macOS에는 완전히 호환되지 않을 수 있습니다. 이는 기존의 앱을 SwiftUI로 전환하는 데에 일부 제약이 있을 수 있다는 것을 의미합니다. 또한, SwiftUI는 아직 모든 UIKit 또는 AppKit의 기능을 완전히 대체하지 못할 수 있습니다.

문서 및 자료의 부족: SwiftUI는 비교적 새로운 프레임워크이기 때문에 문서화 및 온라인 자료의 부족이 있을 수 있습니다. SwiftUI에 대한 자세한 정보와 예제를 찾기 어려울 수 있으며, 문제 해결을 위한 충분한 지원이 제공되지 않을 수 있습니다. 하지만 SwiftUI의 인기와 함께 커뮤니티와 온라인 자료가 점차 확대되고 있습니다.

제한된 커스터마이징 옵션: SwiftUI는 강력한 기본 구성 요소와 스타일을 제공하지만, 때로는 커스텀 UI 요소를 완전히 구현하기 어려울 수 있습니다. SwiftUI는 UIKit 또는 AppKit의 모든 기능을 지원하지 않으며, 특정한 사용자 정의 요구에 대한 제한이 있을 수 있습니다. 이는 일부 개발자들이 기존의 UIKit 또는 AppKit으로 개발하는 것을 선호하는 이유가 될 수 있습니다.

애플리케이션 크기의 증가: SwiftUI를 사용하면 애플리케이션의 크기가 증가할 수 있습니다. SwiftUI는 애플리케이션에 필요한 추가적인 프레임워크 및 라이브러리를 포함해야 하기 때문입니다.

디자이너는 SwiftUI에 맞춰 디자인하는것의 장단점

장점:

실시간 프로토타이핑: SwiftUI는 빠른 UI 프로토타이핑을 가능하게 합니다. 디자이너는 직접 SwiftUI를 사용하여 빠르게 프로토타입을 작성하고, 그 결과를 개발자와 공유하여 협업을 원활하게 진행할 수 있습니다. 이를 통해 디자인 컨셉을 빠르게 시각화하고, 수정 및 개선을 쉽게 수행할 수 있습니다.

디자인 시스템 적용 용이: SwiftUI는 디자인 시스템을 적용하기에 용이한 구조를 가지고 있습니다. 디자이너는 SwiftUI의 선언적인 구문과 재사용 가능한 컴포넌트를 활용하여 일관된 디자인 시스템을 구축하고, 컨텐츠의 일관성과 재사용성을 높일 수 있습니다.

다양한 플랫폼 대응: SwiftUI는 iOS, macOS, watchOS 및 tvOS와 같은 다양한 플랫폼을 지원합니다. 디자이너는 한 번의 디자인 작업으로 다양한 플랫폼에 대응하는 애플리케이션을 구현할 수 있으며, 플랫폼 간의 일관된 사용자 경험을 제공할 수 있습니다.

단점:

제한된 커스터마이징 옵션: SwiftUI는 강력한 기본 구성 요소와 스타일을 제공하지만, 일부 특정한 디자인 요구에 대한 커스터마이징 옵션이 제한될 수 있습니다. 디자이너가 완전히 커스텀한 UI를 구현해야 하는 경우에는 UIKit 또는 AppKit으로 개발하는 것이 더 적합할 수 있습니다.

문서 및 자료의 부족: SwiftUI는 상대적으로 새로운 프레임워크이기 때문에 문서화 및 온라인 자료가 부족할 수 있습니다. 디자이너는 SwiftUI에 대한 자세한 정보와 예제를 찾기 어려울 수 있으며, 문제 해결을 위한 충분한 지원이 제공되지 않을 수 있습니다.

호환성 문제: SwiftUI는 iOS 13 이상에서만 사용할 수 있으며, 이전 버전의 iOS와 macOS에는 완전

UIKit과 SwiftUI가 갖는 장단점 서로 비교하고 앞으로 미래에는 어떤 방식

UIKit의 장점:

성숙한 생태계: UIKit은 오랜 기간 동안 iOS 및 macOS 앱 개발에 사용되었기 때문에 많은 개발자들과 디자이너들이 익숙하고 다양한 리소스와 지원을 제공합니다. 이는 문제 해결을 용이하게 만들어 줄 수 있습니다.

커스터마이징 가능성: UIKit은 매우 유연하며, 개발자와 디자이너는 원하는 대로 UI를 완전히 커스터마이징할 수 있습니다. 이는 고유한 디자인과 사용자 경험을 구현하는 데 도움이 됩니다.

호환성: UIKit은 iOS와 macOS의 이전 버전을 포함한 다양한 플랫폼을 지원합니다. 따라서 이전 버전의 기기에서도 앱을 실행할 수 있습니다.

SwiftUI의 장점:

선언적 구문: SwiftUI는 선언적인 구문을 사용하여 UI를 구축합니다. 이는 코드의 가독성과 유지 보수성을 향상시키며, 개발 및 디자인 작업을 더욱 직관적이고 간단하게 만들어 줍니다.

쉬운 UI 업데이트: SwiftUI는 상태와 바인딩을 이용하여 UI를 업데이트하는 기능을 간편하게 제공합니다. 이는 UI와 데이터 간의 동기화를 자동으로 처리하므로, 개발자는 UI 업데이트에 대한 추가적인 작업을 최소화할 수 있습니다.

멀티 플랫폼 지원: SwiftUI는 iOS, macOS, watchOS, tvOS와 같은 다양한 플랫폼을 지원합니다. 따라서 동일한 코드베이스로 다양한 플랫폼에 대응하는 앱을 개발할 수 있습니다.

앞으로의 방향성:
미래에는 SwiftUI가 더 많은 개발자와 디자이너들 사이에서 주류로 자리 잡을 것으로 예상됩니다. SwiftUI는 혁신적인 프레임워크로 인정받고 있으며, Apple은 SwiftUI를 계속 발전시키고 개선하는 데 주력하고 있습니다. 따라서 SwiftUI를 사용하여 새로운 앱을 개발하거나 기존의 앱을 업데이트하는 것이 권장됩니다

커스터마이징이 좋은걸까? 꼭 필요한 걸까? 커스터마이징이 브랜딩과 연결되는걸까? 장단점 알려줘

커스터마이징은 앱 개발과 디자인에 있어서 장단점이 있습니다. 다음은 커스터마이징의 장단점과 브랜딩과의 연관성을 설명해 드리겠습니다:

장점:

고유한 브랜드 아이덴티티: 커스터마이징은 앱을 특정 브랜드에 맞게 개조하고 디자인할 수 있는 기회를 제공합니다. 고유한 브랜드 아이덴티티를 구축하기 위해 앱의 색상, 로고, 아이콘, 폰트 등을 조정할 수 있습니다. 이는 사용자에게 브랜드를 더 잘 전달하고, 브랜드 인식을 높일 수 있습니다.

사용자 경험 개선: 커스터마이징을 통해 사용자 인터페이스를 개선할 수 있습니다. 앱의 UI 요소를 조정하여 사용자의 요구에 더욱 적합하게 만들거나, 특정 기능을 강조하거나 숨길 수 있습니다. 이는 사용자 경험을 향상시키고, 앱의 유용성과 사용자 만족도를 높일 수 있습니다.

경쟁 우위 확보: 커스터마이징을 통해 앱을 경쟁 우위를 확보할 수 있습니다. 유사한 앱이 많은 시장에서 개인적인 터치나 차별화된 디자인 요소를 제공함으로써 사용자들에게 더 큰 인상을 주고, 다른 앱과의 경쟁에서 두각을 나타낼 수 있습니다.

단점:

개발 및 디자인 시간과 비용: 커스터마이징은 추가적인 개발 및 디자인 시간과 비용을 요구할 수 있습니다. 앱의 모든 요소를 커스터마이징하려면 추가 작업과 자원이 필요하며, 이는 프로젝트 일정과 예산에 영향을 미칠 수 있습니다.

일관성 유지의 어려움: 지나치게 많은 커스터마이징은 일관성을 유지하기 어렵게 만들 수 있습니다. 디자인 요소나 기능을 일관되게 유지하려면 추가 관리와 조정이 필요하며, 이는 유지 보수의 어려움을 초래할 수 있습니다.

사용자 혼동 가능성: 과도한 커스터마이

정렬방식

figma에서 작업하다보면 line-height 때문에 auto layout을 먹여도 묘하게 정렬이 안되어 보인다.

typography system 상 headline과 body를 섞어쓰는 경우 중심으로 정렬이 안되어 보일 것이다.

swiftui에서는 이런 정렬이 어떤식으로 계산되는지 궁금해졌다.
개발에서 알아서 중심 정렬이 된다면 피그마에서 묘하게 틀어지는 건 무시해도 되지 않을까 싶었다.

이런 경우 SwiftUI는 화면을 어떻게 그리나?

Typography system에 따라 line height 크기가 다르기 때문에 Large Title과 Footnote의 텍스트 크기와 라인 높이는 서로 다릅니다. 하지만 SwiftUI에서 HStack을 사용하여 두 개의 텍스트를 쌓으면, 텍스트는 수평적으로 정렬됩니다.

이것은 HStack의 기본 정렬 방식 때문입니다. 기본적으로, HStack은 수평적으로 중앙에 정렬됩니다. 따라서 Large Title과 Footnote 텍스트는 HStack 내부에서 가운데로 정렬되게 됩니다.

하지만 이것은 Apple HIG에서 권장하는 것과 정확히 일치하지는 않습니다. Apple HIG에서는 서로 다른 글꼴 크기와 높이를 가진 텍스트를 수평 중앙에 정렬하는 대신, 수직적으로 중앙에 정렬하는 것을 권장합니다. 이렇게하면 텍스트가 서로 다른 크기를 가지더라도 더 일관된 레이아웃을 만들 수 있습니다.

따라서 Large Title과 Footnote 텍스트를 가지고 작업 할 때는, 수직 중앙에 정렬하는 것이 더 좋습니다. 이를 위해서는 VStack을 사용하여 두 개의 텍스트를 쌓은 후, alignment modifier를 사용하여 수직 중앙에 맞추면 됩니다.

수평정렬과 수직정렬의 차이가 뭐야?

수평정렬
수평정렬은 요소들을 좌우로 정렬하는 것을 말합니다. 보통 요소들을 왼쪽이나 오른쪽, 혹은 가운데로 정렬하는데 사용됩니다.
ex. 컨테이너 내의 요소들이 가로 방향으로 정렬되는 것을 의미합니다. 예를 들어, 가로로 나란히 놓인 버튼들이 모두 같은 간격으로 정렬되어 있으면 수평 정렬이라고 할 수 있습니다.

수직정렬
수직정렬은 요소들을 위아래로 정렬하는 것을 말합니다. 보통 요소들을 위쪽이나 아래쪽, 혹은 중앙으로 정렬하는데 사용됩니다.
ex. 컨테이너 내의 요소들이 세로 방향으로 정렬되는 것을 의미합니다. 예를 들어, 컨테이너 상단에 위치한 텍스트와 하단에 위치한 버튼이 모두 수직으로 중앙에 위치해 있다면 수직 정렬이라고 할 수 있습니다.

Large Title과 Footnote를 정렬한다면?

SwiftUI에서 HStack을 사용하면 자식 뷰들이 수평 방향으로 배열되며, 각 뷰는 가장 큰 높이를 가진 자식 뷰에 맞춰지게 됩니다.

HStack modifier 중 하나인 alignment를 .center로 설정하면 자식 뷰를 수평 중앙에 맞춰주면서 Large Title과 Footnote의 line height 차이에 따른 여백도 자동으로 처리됩니다. 그러나 이는 수직 중앙 정렬이 아니며, 정확한 중앙 정렬을 위해서는 VStack을 사용해야 합니다. 여전히 Large Title과 Footnote의 line height의 차이가 있을 수 있으므로, 정확한 중앙 정렬을 위해서는 VStack으로 두 개의 텍스트를 쌓아서 alignment를 .center로 설정하는 것이 좋습니다.

아직 잘 모르겠어서 SwiftUI에서 직접 그려보면서 확인해봐야할 것 같다

디자인 화면에서 어떤 값을 보고 어떻게 개발 화면을 구현하나?

profile
zam
이전 포스트

클라리넷 A 악보 Bb 으로 이조하기 (실용편)

다음 포스트

토스 Simplicity 23 디자인 컨퍼런스 정리

0개의 댓글