SwiftUI 기초: SwiftUI로 멋진 앱 빌드하기

안녕하세요 야호! 재밌죠?

안녕하세요, 쿠퍼티노에 있는 Apple 개발자 센터에 오신 것을 환영합니다. 제 이름은 리아 워멜스도르프이고, 기술 전도사입니다.

오늘은 SwiftUI 의 기본 원리를 여러분과 공유하게 되어 기쁩니다. 다뤄야 할 내용이 많습니다. 하지만 먼저 저희 공연장에 대해 좀 더 자세히 말씀드리고 싶습니다. 개발자 센터는 Apple Park 의 일부입니다. 그리고 이곳은 오늘 행사에 아주 적합한 장소입니다. 이곳에는 소통과 협업을 위한 다양한 영역이 있습니다.

이 방은 빅서에 위치해 있으며, 멋진 공간과 훌륭한 시설을 갖추고 있습니다. 이는 다음과 같은 다양한 활동을 지원하도록 설계되었습니다. 대면 프레젠테이션, 스튜디오 녹음 및 생방송.

실험실과 브리핑룸도 있습니다. 또한 이와 같은 활동을 비롯한 다양한 활동을 주최할 수 있는 회의실도 갖추고 있습니다.

이곳은 전 세계에 있는 네 곳의 개발자 센터 중 하나로, 디자이너들을 초청하여 워크숍을 진행하는 곳입니다. 세션, 실습 및 워크숍을 위한 개발자도 있습니다. 여기 계신 분들 중에 개발자 센터에 이미 가보신 분 있나요? 반갑습니다. 다시 오신 것을 환영합니다. 처음 오신 분이든 다시 오신 분이든 상관없이, 오늘 여러분을 맞이하게 되어 정말 기쁩니다.

지금 온라인으로 많은 분들이 함께해 주고 계십니다. 안녕하세요. 시청해 주셔서 감사합니다. 저희 개발자 관계팀은 여러분과의 소통을 언제나 환영합니다. 개발자들과 협력하여 Apple 플랫폼에 최적화된 최고의 앱을 만듭니다.

WWDC 이후, 저희는 랩, 워크숍 등 300개 이상의 활동을 주최했습니다. 그리고 프레젠테이션.

이번 주 후반에 쿠퍼티노에서 저희 팀이 새로운 디자인에 대한 워크숍을 진행하고 있습니다. 개발자들은 Liquid Glass 직접 사용해 볼 수 있는 경험을 갖게 될 것입니다. 코드와 디자인을 업데이트하면서.

가까운 지역에서 열리는 행사에 대한 자세한 정보를 알아보려면 다음을 참조하세요. 개발자 를 확인해 보세요. 오늘 일정을 시작하기 전에, 이 자리에 계신 분들께 몇 가지 팁을 드리고 싶습니다. 하루 종일 연결 상태를 유지하기 위해. Apple Wi-Fi 네트워크를 사용하시고, 필요할 경우 언제든지 충전하세요. 모든 좌석에서 전원을 사용할 수 있습니다. 오늘 방송을 시청하시는 모든 분들을 위해 팔걸이 앞에 있습니다. 이 프레젠테이션은 오직 당신만을 위한 특별한 경험이 되도록 기획되었습니다. 온라인과 오프라인 모두에서. 그러니 동영상 촬영은 자제해 주시기 바랍니다. 또는 발표 중에 실시간 스트리밍을 제공합니다.

반면에 사진 촬영은 전적으로 환영이니, 마음껏 찍으세요.

행사가 끝난 후, 추가 정보와 자료를 보내드리겠습니다. 놓치는 것 없이 모든 것을 확인하실 수 있도록 하세요. 그 작은 요청은 이제 끝났으니, 오늘 행사에 대해 더 자세히 이야기 나눌 수 있게 되어 기쁩니다. SwiftUI 는 Apple의 선언적 사용자 인터페이스 프레임워크입니다.

다른 모든 도구와 마찬가지로 SwiftUI 기본 개념이 있습니다. 이러한 개념들을 배우는 데 시간을 투자하면, 여러분은 그것을 잘 활용할 수 있게 될 것입니다. 그리고 놀라운 무언가를 만들어내세요.

SwiftUI 사용하면 최종 결과물은 단순한 앱이 아닙니다. 이 앱은 모든 Apple 기기에서 원활하게 작동할 수 있습니다. 처음 사용하는 사람이라도 직관적이고 친숙하게 사용할 수 있습니다.

SwiftUI 앱은 최신 업데이트를 통해 항상 최신 상태를 유지할 수 있습니다. 운영 체제에. Liquid Glass 처럼, SwiftUI Apple 에서 새로운 앱 개발의 기반으로 널리 사용되고 있습니다. 그리고 UIKit 으로 시작된 기존 앱들의 진화 과정.

점진적 도입을 최우선으로 고려하여 설계되었습니다. 그러면 코드베이스에 점진적으로 사용할 수 있습니다.

지금이야말로 시간을 내는 것이 그 어느 때보다 중요합니다. SwiftUI 의 기초를 배우기 위해서입니다. 코드를 작성하는 방법은 정말 다양합니다. 한 줄씩 작성하든, LLM과 에이전트를 사용하든 상관없이. 기초를 이해하면 다음을 이해할 수 있습니다. 그리고 여러분의 코드에 더 큰 자신감을 갖게 될 것입니다. 저희 팀은 위시리스트라는 새로운 앱을 개발 중입니다. 이건 SwiftUI 로 100% 제작되었습니다.

위시리스트는 오늘 발표의 모든 내용의 기초입니다. SwiftUI 의 기본 요소들이 어떻게 결합되어 실제 앱을 만드는지 보여주기 위해서입니다.

저와 제 팀원들은 여행을 매우 좋아합니다. 그리고 저는 다음 휴가 계획을 세우는 게 정말 즐거워요.

저는 여행을 최대한 알차게 보내기 위해 여행 계획을 꼼꼼하게 세우는 것을 좋아합니다. 내가 갈 장소뿐만 아니라, 거기서 할 일들도 포함해서요.

위시리스트는 여행 버킷리스트 앱입니다.

우리는 가고 싶은 장소들을 기록하기 위해 이 앱을 만들었습니다. 우리가 하고 싶은 활동들, 그리고 우리가 이룬 진전을 되돌아보고 스스로에게 책임을 묻도록 합시다. 큰 꿈을 꾸고 새로운 것에 도전해 보세요. 앱에는 크게 두 가지 유형의 데이터가 있습니다. 바로 이동 기록과 활동 기록입니다.

여행은 제가 가고 싶은 장소들을 말하는 거예요. 예를 들어 하와이 코나처럼요.

그리고 액티비티는 제가 여행에서 하고 싶은 것들이에요. 스노클링이나 고래 관람 같은 걸 좋아해요.

앱에서 할 수 있는 주요 작업은 세 가지입니다. 툴바에서 더하기 버튼을 탭하면, 제목, 사진, 그리고 여행 시기를 추가하면 새로운 여행 계획을 세울 수 있습니다.

여행 중에는 해야 할 일 목록에서 하나씩 체크할 수 있어요. 쥐가오리와 함께 스노클링하는 것처럼요.

저는 제 발전 과정을 되돌아볼 수도 있습니다. 예를 들어, 저는 올가을에 몬태나로 여행을 다녀왔습니다. 그리고 저는 이러한 경험들을 헤쳐나가기 위해 가을 탐험가 배지를 획득했습니다. 위시리스트는 탭 보기 방식을 사용합니다.

일관된 탐색을 위해 탭 보기 방식을 선택했습니다. 제 동료 마요가 이러한 결정들 중 일부를 설명해 드릴 것입니다. 그녀의 디자인 프레젠테이션에서.

위시리스트 탭에는 세 개의 탭이 있습니다. 스크롤을 내려서 계획된 모든 여행을 살펴보거나 새로운 여행을 추가할 수 있습니다.

코나 딥 다이브 같은 카드를 탭하면, 여행 세부 정보 페이지로 이동하여 항목을 체크할 수 있습니다.

목표 탭에서는 수상을 향한 제 진행 상황을 확인합니다. 맨 윗줄에는 제가 최근에 받은 상들, 예를 들어 가을 탐험가 상 같은 것들이 보이네요.

스크롤을 내리니 다음 목표 달성을 향한 제 진행 상황을 확인할 수 있었습니다. 저는 이미 7가지 활동을 완료했습니다. 이제 10가지 활동 달성 상까지 세 가지만 남았어요.

세 번째 탭은 검색 탭입니다.

저는 원하는 것을 빠르게 찾기 위해 검색 기능을 사용합니다. 이미 여러 여행을 추가했어요. 원하는 정보를 정확하게 검색하고 자세히 알아볼 수 있어서 정말 도움이 돼요.

제 동료들이 앱 개발 과정에 대해 더 자세히 설명해 드릴 겁니다. 하지만 어쩌면 더 중요한 것은 각각의 결정을 내리는 데 필요한 기본적인 개념들일 것입니다.

오늘 여러분이 꼭 챙겨야 할 가장 중요한 것은 바로 이러한 기본 원칙들입니다. 이 이론을 여러분의 코드에 적용해 보세요. 그러면 여러분은 그것에 대해 확신을 가지고 추론할 수 있을 것입니다. 위시리스트 만드는 건 정말 재밌었어요. 아이디어 구상부터 디자인까지 모든 단계에서 그리고 이 앱에서 실제로 구현해 보면 상황이 명확해집니다. 오늘 나머지 발표를 위해. 향후 몇 주 안에 위시리스트 기능의 샘플 코드를 제공해 드릴 예정입니다. 저희 웹사이트에서 다운로드하세요. 정말 기대돼요. 학습 과정을 따라가면서 학습 내용을 확실히 다지는 데 아주 좋은 방법입니다. 예제나 SwiftUI 에 대해 궁금한 점이 있으면 언제든지 문의해 주세요. Slido를 사용하면 Apple 엔지니어에게 질문할 수 있습니다.

저희 팀은 여러분을 지원할 준비가 되어 있습니다.

예제에 대한 질문이나 SwiftUI 관련 질문을 자유롭게 하실 수 있습니다.

다른 개발자들이 올린 질문에 투표하고 답변을 읽을 수도 있습니다. 학습에 아주 좋은 자료이니 꼭 한번 살펴보시길 권합니다.

좋습니다. 이제 본격적인 회의 안건을 살펴보겠습니다.

오늘 발표에서는 SwiftUI 의 기초적인 주제들을 다룹니다.

그리고 이건 정말 중요해요. 기초는 처음 시작하는 사람이든 아니든 유용합니다. 혹은 이미 경험이 있으신가요? 그리고 프레임워크에 대한 이해를 더욱 심화시키고 싶습니다.

SwiftUI 에 이미 익숙하더라도, 기초에 대한 더 깊은 이해를 발전시키는 것이 도움이 될 것입니다. 더 나은 실행 전략을 선택하세요 그리고 앱에서 발생하는 문제를 해결하세요.

먼저 SwiftUI 에 대한 개요부터 시작하겠습니다.

이어서 마조가 SwiftUI 활용하여 시스템을 통해 디자인하는 방법을 공유할 예정입니다.

그럼 잠시 휴식을 취한 후 태평양 표준시 기준 11시 15분에 다시 만나겠습니다.

그러면 Cat이 SwiftUI 의 레이아웃 시스템에 대해 안내해 드릴 것입니다. 커트는 이어서 SwiftUI 활용한 모션 기술에 대해 설명할 예정입니다. 애니메이션 및 시각 효과 분야.

그다음에는 점심 식사를 하면서 간단한 다과를 즐기고 재충전하는 시간을 갖겠습니다. 우리는 130 퍼시픽에서 다시 만날 겁니다. 콜이 여러분의 의도를 모델링하는 방법을 시연할 때. SwiftUI 에서 의도를 고려하여 데이터를 모델링하세요. 그리고 오늘 특별 손님이 오셨습니다. AllTrails의 CTO인 제임스 그레이엄이 핵심적인 교훈을 공유할 예정입니다. SwiftUI 점진적으로 도입해 온 그들의 여정에 대하여 복잡하고 완성도 높은 UIKit 앱.

잠시 쉬면서 스트레칭도 하고 커피도 한잔 마시겠습니다. 그리고 SwiftUI 엔지니어링 분야의 리더들이 참여하는 패널 토론으로 하루를 마무리할 예정입니다. 그들은 오늘 가장 많이 나온 질문 몇 가지에 답해줄 것입니다. 그리고 쿠퍼티노에 있는 사람들을 위한 기본 틀에 대한 그들의 비전을 공유합니다. 그 후에는 간단한 다과와 함께하는 네트워킹 시간이 있을 예정입니다. Apple 엔지니어 및 디자이너와 소통할 수 있는 기회입니다.

좋습니다, 이제 SwiftUI 필수 요소에 대한 제 발표를 시작하겠습니다.

저는 리아이고, 기술 전도사입니다. 저는 복음 전도팀에 합류하기 전에는 Apple 에서 엔지니어로 근무했습니다.

저는 제가 가장 좋아하는 앱들, 예를 들어 피트니스 앱과 운동 앱 개발에 참여했습니다. 그리고 건강 앱도 개발했고, 2021년 기조연설에 잠깐 출연하기도 했습니다. 이거 꽤 멋지죠? 촬영하는 게 정말 재밌었어요. Apple Park 뛰어다닐 수 있었어요. 저는 SwiftUI 발표된 해인 2019년에 Apple 에 입사했습니다.

지난 몇 년 동안 저는 프레임워크에 대해, 그리고 그것을 사용하는 방법에 대해 많은 것을 배웠습니다. 하지만 더 중요한 것은 그것을 잘 활용하는 방법입니다. SwiftUI 처음 사용하기 시작했을 때, 시제품을 빠르게 만들 수 있다는 점이 정말 마음에 들었어요. 단 몇 줄의 코드로 앱에 실제 작동하는 기능을 구현할 수 있습니다. 나는 뭔가 실질적인 것을 만들어낼 수 있어. 정말 멋졌어요.

이는 많은 소프트웨어 엔지니어들이 겪는 과정입니다. 도구나 프레임워크에 관계없이. 화면에 뭔가를 보여줄 수 있다는 건 정말 신나는 일이에요. 하지만 때로는 예상대로 되지 않을 수도 있습니다. 그래서 저는 한 발짝 물러나서 기본부터 다시 시작해야 했습니다.

SwiftUI 어떻게 작동하는지 이해해야 했습니다. 더 나은 품질의 소프트웨어를 만들 수 있도록 하기 위해서입니다. 오늘은 SwiftUI 작동 방식을 이해하는 데 핵심적인 개념들을 공유하겠습니다.

이러한 개념들은 여러분이 더 나은 코드를 작성하는 데 도움이 될 것입니다. 그리고 그것들은 오늘 나머지 발표들을 위한 배경을 마련해 줄 것입니다.

먼저 SwiftUI 뷰에서 자주 사용되는 용어를 자세히 살펴보겠습니다.

다음으로 SwiftUI 에 내장된 뷰에 대해 설명하겠습니다.

그리고 새로운 사용자 지정 뷰를 만드는 데 필요한 논리.

마지막으로, 코드 의존성과 의도적인 코드 구조화 방법에 대해 다루겠습니다.

각 섹션에서 가장 중요한 개념들을 공유하겠습니다. 그리고 그것들이 글쓰기라는 더 큰 그림과 어떻게 관련되는지. 훌륭한 SwiftUI 코드입니다. 알겠습니다. SwiftUI 에서 '뷰'라는 용어는 여러 의미를 내포하고 있습니다. 문맥에 따라 세 가지 다른 의미를 가질 수 있습니다. 이 부분이 다소 혼란스러울 수 있습니다.

많은 프레임워크에서 '뷰'는 사용자 인터페이스와 화면의 픽셀을 의미합니다.

SwiftUI 에서 뷰는 프로토콜이기도 합니다. 화면에 표시되기를 원하는 내용을 설명하는 것입니다.

각 뷰는 구조체이기 때문에 각 뷰 인스턴스는 특정 값을 가집니다.

이 세 가지 개념은 모두 서로 관련되어 있습니다. 화면의 픽셀은 화면에 나타나는 이미지에 대한 설명의 결과물입니다. 그리고 해당 뷰 구조체의 실제 값입니다.

전망에 대한 설명 그리고 이를 좌우하는 값들이 최종적으로 화면의 픽셀을 결정짓습니다.

'보기'라는 단어의 세 가지 의미는 앱의 여러 영역에서 나타납니다.

설명은 코드 그 자체입니다.

해당 값은 메모리에 있는 인스턴스입니다. 따라서 SwiftUI 픽셀을 렌더링할 수 있습니다. 화면의 픽셀은 최신 정보를 표시해야 합니다. 가장 정확한 정보입니다.

본문에서 관점이라는 단어의 다양한 의미에 대해 하나씩 자세히 살펴보겠습니다. 제 발표 자료입니다.

맥락이 중요합니다 그리고 이는 여러분이 자신의 SwiftUI 코드에서 발생하는 문제를 해결하는 데 도움이 될 것입니다. 먼저 견해를 설명으로 시작하겠습니다.

SwiftUI 에서 뷰는 의도적인 구성 방식을 담은 설명입니다.

스노클링을 즐기는 멋진 수중 풍경 이미지를 원한다고 가정해 봅시다.

영어로. 이를 설명하자면, 저는 '수중 스노클링 이미지'라는 문구를 쓸 거예요.

SwiftUI 에서는 뷰 프로토콜을 사용하여 이 설명을 구성합니다.

Image는 SwiftUI 뷰이고, Deep Sea는 이미지의 이름입니다.

제 영어 표현과 똑같아요. 뷰. SwiftUI 에서 원하는 것을 설명해 주세요.

SwiftUI 뷰를 받아서 화면에 무엇을 렌더링할지 다음과 같이 결정합니다. 멋진 사진이네요.

모든 SwiftUI 뷰는 코드로 작성된 설명입니다.

이는 뷰에 내장되었는지 여부와 관계없이 사실입니다. 또는 직접 작성하는 사용자 지정 뷰.

이 이미지는 SwiftUI 에 내장된 뷰의 예시입니다.

뷰는 모든 앱의 기본 구성 요소입니다. 내장된 보기 기능은 시작하기에 아주 좋은 방법입니다. SwiftUI 에는 다양한 내장 뷰가 있습니다. 그리고 각각의 이름은 그것이 만들어내는 것을 설명합니다.

예를 들어, 이미지가 이미지를 시각화하는 방식과 유사하게,

컬러는 프레임 전체를 특정 색상으로 채우는 시각적 표현입니다. 보라색처럼요.

SwiftUI 내장 뷰를 하드웨어와 통합하기 때문에 강력한 기능을 제공합니다.

여기서 이 보라색은 실제로 맥락에 따라 색이 달라지는 보라색입니다.

실제 색상 값은 기기의 상황에 따라 조정됩니다. 예를 들어 휴대폰이 밝은 모드인지 어두운 모드인지에 따라 다릅니다. 혹은 화면에 햇빛이 밝게 비치는지 여부와 상관없이.

텍스트는 Kona Deep Dive와 같은 문자열을 시각화합니다.

색상과 마찬가지로 텍스트 보기는 텍스트가 존재하는 맥락에 최적화되어 있습니다.

SwiftUI 적절한 글꼴을 사용하여 문자열을 그립니다. 현재 플랫폼의 경우. iMac 과 같은 대형 디스플레이의 경우, 텍스트 뷰는 작은 텍스트 뷰보다 물리적으로 더 클 것입니다. Apple Watch 처럼요. 텍스트 뷰는 접근성 기능인 Dynamic Type) 도 지원합니다.

Dynamic Type 사용자가 기기에서 보이는 텍스트 크기를 조절할 수 있도록 해줍니다. 그래서 그들이 편안하게 읽을 수 있도록.

여기서 오른쪽에 있는 휴대폰의 시스템 글꼴 크기가 더 큽니다.

SwiftUI 코드에서 텍스트 뷰가 자동으로 크기 조절됩니다. 내용이 여전히 읽기 쉽도록 하기 위해서입니다. 그리고 이 작업은 제 쪽에서 추가적인 코드를 작성할 필요가 없습니다. 각 보기, 이미지, 색상 및 텍스트에 대해 뷰의 이름은 제가 원하는 것을 설명하는 것입니다.

딥씨, 퍼플, 코나 딥 다이브의 가치와 결합되었습니다. 그 결과 화면에 픽셀이 나타납니다.

내장된 전망은 훌륭한 출발점입니다. 그 이유는 단순히 있는 그대로 유용할 뿐만 아니라, 맞춤 설정도 가능하기 때문입니다.

뷰를 사용자 지정하면 앱의 고유한 개성을 표현할 수 있습니다. SwiftUI의 내장 뷰 기능을 활용하면서 동시에 여러 이점을 누릴 수 있습니다. SwiftUI 에서 뷰를 사용자 지정하는 방법은 여러 가지가 있습니다.

이전에 만든 TextView도 괜찮아 보이지만, 더 기억하기 쉽게 만들 수 있을 것 같아요. 뷰 수정자는 개별 뷰를 사용자 지정하는 도구입니다. 이제 코드를 좀 살펴볼게요.

텍스트 뷰를 사용자 지정하는 방법은 여러 가지가 있습니다. 예를 들어 글꼴 크기나 색상을 변경하는 것 등이 있습니다. 그건 저희 위시리스트 앱에서 많이 했던 기능이에요. 일단은 간단한 것부터 시작해 볼게요. 텍스트 뷰가 밝은 배경에서 시각적으로 돋보이도록 하고 싶습니다.

배경 수정자는 내 뷰의 배경을 설정합니다. 어떤 풍경이든 배경으로 사용할 수 있습니다. 저는 주황색을 선택했어요.

배경은 뷰 수정자의 한 예입니다.

뷰 수정자는 텍스트와 같은 특정 뷰에서 호출되는 메서드입니다. 그리고 원본을 포함하는 새로운 뷰를 반환합니다.

원래 텍스트 뷰는 뷰 수정자의 변경 사항으로 감싸져 있습니다. 그리고 그것은 새로운 관점을 제시합니다. 저는 뷰 수정자를 뷰를 감싸는 래퍼라고 생각하는 것을 좋아합니다.

함께 사용하면 이 두 줄의 코드는 원래 문자열인 "Kona Deep Dive"를 생성합니다. 주황색 배경. 기존 텍스트 보기에서 약간 수정된 버전입니다.

여러 뷰 수정자를 적용하여 복합적인 사용자 지정 효과를 만들 수 있습니다.

패딩은 또 다른 뷰 수정 요소입니다. 이 기능은 적용된 뷰의 가장자리에 점을 추가합니다. 이 경우 패딩은 텍스트 뷰의 네 면 모두에 포인트를 추가합니다. 그리고 나서 주황색 배경이 그 안을 채웁니다. 배경 패딩이 그 앞의 모든 것을 감싸는 것과 같습니다. 그러니까 이 세 줄의 코드는 모두 하나의 큰 뷰를 나타냅니다. 뷰 계층 구조에서.

뷰 수정자에 대한 마지막 참고 사항입니다. 순서가 중요합니다. 각 뷰 수정자는 바로 위에 있는 코드 줄에만 영향을 미칩니다.

만약 배경이 먼저 오도록 순서를 바꾸면요. 주황색은 원래 텍스트 보기 영역만 덮습니다.

회색 점선 상자로 표시된 여백이 나머지 부분에 적용됩니다.

뷰 수정자의 순서를 의도적으로 정하세요. 코드가 예상대로 작동하지 않는다면, 뷰가 논리적인 순서로 구성되어 있는지 확인하세요.

뷰 수정자는 개별 뷰를 사용자 지정하는 반면, 구도는 여러 시점을 결합하는 기법입니다.

기존 뷰들을 조합하여 자신만의 사용자 지정 뷰를 만들 수 있습니다.

제가 이런 줄 중 하나를 만들고 싶다고 가정해 보겠습니다. 위시리스트의 검색 탭에서 Kona Deep Dive를 검색하세요.

이전에 만들어둔 내장 뷰들을 일부 사용할 수 있습니다.

먼저 SearchRow 뷰를 정의하겠습니다.

구조체이며 뷰 프로토콜을 준수합니다.

그다음에는 제 의견의 본문을 추가하겠습니다. 이는 모든 관점에 필수적인 요소입니다.

그리고 심해의 이미지를 추가하겠습니다. 그리고 제

TextView에는 Kona Deep Dive라고 적혀 있습니다. SwiftUI 기본적으로 요소들을 세로로 쌓습니다.

나는 그들이 나란히 서 있기를 원한다. 그래서 이미지와 텍스트처럼 가로로 쌓거나 H자형으로 쌓는 요소를 추가할게요. HStack은 뷰입니다.

하지만 이미지처럼 무엇을 렌더링할지 설명하는 대신, 이 문서에서는 SwiftUI 스택을 사용하여 렌더링하는 방법을 설명합니다. 이미지와 텍스트 같은 모든 하위 뷰를 가로줄로 배열하세요.

오늘 오후에 Cat은 도구에 대해 더 자세히 설명할 예정입니다. 레이아웃 및 SwiftUI 관련 기술. 보다 정교한 견해를 제시하면서도 한 가지를 분명히 지적하고 싶습니다. 핵심 개념은 동일합니다.

내 검색 행은 내가 원하는 것에 대한 설명입니다. SwiftUI 해당 설명을 바탕으로 화면에 픽셀을 렌더링합니다.

코드 작성을 통해 코드를 더 읽기 쉽게 만들 수 있습니다.

그리고 검색 행을 만들고 나면, 단 한 줄의 코드로 앱의 다른 영역에서도 사용할 수 있습니다.

내 검색 보기에서는 세 개의 스택, 세 개의 이미지가 필요한 대신, 그리고 세 가지 텍스트 보기 방식이 있습니다. 저는 복합 SearchRow 뷰 세 개만 사용했습니다.

그리고 나중에 뭔가를 바꾸고 싶을 때 검색 행의 배경을 보라색으로 바꾸고 싶습니다. 해당 뷰에 맞춰 로컬에서 처리할 수 있습니다. 이렇게 하면 작성해야 하는 코드의 양이 줄어듭니다. 읽고 이해하기 쉽게 만들어줍니다.

뷰는 구조체이기 때문입니다. 가볍기 때문에 시야를 분산시키는 데에도 좋습니다. 이처럼 더 작은 뷰로 분할해도 성능에는 영향을 미치지 않습니다.

내장 뷰와 마찬가지로, 사용자 정의 뷰는 우리가 무엇에 대해 설명하는지에 대한 설명입니다. SwiftUI 화면에 그림을 그려야 합니다. SearchItemView와 같은 이름은 중요합니다. 하지만 더욱 중요한 것은 신체 내부의 모습입니다. 그리고 나열된 순서도 중요합니다. SwiftUI 설명을 사용합니다. 화면에 픽셀을 그리는 코드에 해당 내용을 넣으세요.

이제 저는 이 내용을 한 단계 더 발전시키고 싶습니다. 제가 만든 검색 행은 의도했던 디자인에 꽤 가깝지만, 완벽하진 않습니다.

지금 저는 코나 딥 다이브를 세 번이나 실행했는데, 여러분은 어떠신지 모르겠네요. 하지만 저는 매년 휴가지를 바꾸는 걸 좋아해요. 앱은 동적이며 변화하는 데이터를 나타냅니다.

버킷리스트에 있는 다른 여행들도 보여줄 수 있도록 이 화면을 전환하는 방법이 필요해요.

이것으로 제가 마지막으로 말씀드릴 주제가 나옵니다. 종속성.

SwiftUI 뷰는 데이터에 의해 구동됩니다. 그 데이터가 그대로 유지되든 아니든, 내 심해 이미지와 코나 딥 다이브라는 문자열처럼 또는 데이터가 변경될 수도 있습니다.

오늘 제가 보여드린 모든 견해는 데이터에 기반합니다.

화면의 픽셀은 이미지와 같은 설명의 결과 중 일부입니다. 그리고 데이터의 일부는 심해와 같습니다.

앞서 모든 뷰는 구조체라고 언급했습니다. 즉, 모든 뷰는 값 유형이라는 뜻입니다. 그리고 모든 뷰 인스턴스는 값을 가지고 있습니다.

저는 뷰의 이름을 사용하여 뷰의 인스턴스를 이렇게 시각화하는 것을 좋아합니다. 위쪽은 이미지처럼 보이고, 아래쪽은 심해처럼 데이터가 표시됩니다.

SwiftUI 뷰의 특정 인스턴스를 가져옵니다. 화면에 픽셀을 렌더링하는 데 필요한 데이터를 포함합니다.

픽셀 렌더링이 완료되면 SwiftUI 해당 인스턴스를 폐기합니다. 더 이상 필요하지 않아요.

이것이 '관점'의 세 번째 의미입니다. 관점은 가치이다.

뷰의 인스턴스들입니다. 특정 값들이 화면의 픽셀들을 구성합니다.

각 뷰 인스턴스는 일시적으로만 존재합니다. 그것들은 수명이 짧습니다. 그것들은 만들어집니다. 필요할 때 SwiftUI 메모리에 상주합니다. 그리고 픽셀이 렌더링되면, 뷰의 역할이 완료되었으므로 인스턴스는 폐기됩니다.

그것들을 버리는 것이 나쁘거나 심각한 일은 아니라는 점에 유의하세요. 뷰는 가볍고 생성하기 쉽습니다.

저는 뷰를 마치 똑같은 결과를 찍어낼 수 있는 템플릿처럼 생각합니다. 화면에 픽셀을 생성하는 것. 이러한 템플릿은 유연하고 동적인 데이터를 나타내는 경우가 많습니다.

예를 들어, 제 앱에서는 심해에 초점을 맞추고 있습니다. 하지만 교토의 다른 이미지도 필요해요.

이것은 뷰의 또 다른 예입니다. 하지만 이것은 약간 다른 값을 가지고 있습니다. 이미지의 이름인 교토는 심해와 다릅니다.

SwiftUI 서로 다른 값을 가진 이러한 이미지 뷰를 사용합니다. 이미지 이름 때문에 서로 다른 이미지가 생성됩니다.

이제 이러한 유연성을 활용하여 SearchRow 코드를 다시 살펴보겠습니다.

이제 이미지와 텍스트의 이름을 하드코딩하는 대신, 내 SearchRow는 이미지 이름을 인수로 받습니다. 그리고 여행의 제목.

이번 버전의 SearchRow는 더욱 유연합니다. 저는 여전히 그것을 이용해서 코나 딥 다이브 로잉을 할 수 있습니다. 하지만 다른 여행에도 사용할 수 있어요.

이렇게 하면 실제 디자인에 더 가까워집니다. 검색 보기에서 새 검색 행을 사용할 때,

저는 다양한 이미지를 모두 제공합니다. 그리고 Mammoth Blush와 Kyoto Mystique 같은 여행 이름도 있습니다. 이게 훨씬 낫네요.

데이터가 화면의 픽셀을 움직이고 있습니다. 그리고 저는 여전히 컴포지션을 통해 얻은 깔끔한 코드를 활용할 수 있습니다.

검색 보기의 이 구현은 아직 개발 중이라는 점을 유념해 주세요. 위시리스트 최종 버전을 간소화한 것입니다.

실제 검색은 데이터를 동적으로 조회합니다. 그런 다음 이미지를 기반으로 검색 행을 채웁니다. 그리고 검색 필드에 입력된 문자열입니다.

이 검색 행에 대해 한 가지 더 강조하고 싶은 점이 있습니다.

이전 이미지 보기와 마찬가지로, SearchRow의 각 인스턴스는 서로 다른 값을 가집니다. 여행 이름과 사진 이름에 대해.

SwiftUI 이 둘을 쉽게 비교하여 같지 않다는 것을 알아챌 수 있습니다.

SwiftUI 화면에 픽셀을 그린 후, 뷰의 인스턴스를 해제합니다. 픽셀이 렌더링되었기 때문에 더 이상 필요하지 않습니다.

이제 SwiftUI 의존성을 다루는 방식에 대해 좀 더 자세히 이야기해 보겠습니다.

내 검색 행의 설명은 뷰 코드입니다.

뷰의 값이 다르면 화면의 픽셀 값도 달라집니다.

SwiftUI 중요한 값들을 종속성과 함께 추적합니다. 그리고 중요한 가치라고 하면, 삶을 변화시킬 수 있는 가치들을 의미합니다. 픽셀은 데이터에 따라 올바르거나 잘못된 것으로 판단됩니다.

작동 방식은 다음과 같습니다. SwiftUI body를 처음 실행할 때, 이 프로그램은 읽어들인 모든 값을 그래프로 추적합니다.

이 그래프의 첫 번째 부분은 SearchRow에 대한 노드입니다.

본문에서 SwiftUI 이미지 뷰의 사진 이름 값을 읽습니다.

그래서 사진 이름을 입력하는 노드와 SearchRow를 가리키는 아래쪽 화살표가 추가됩니다.

SwiftUI 여행 이름 값도 읽습니다. 그래서 SwiftUI 추적 시스템에 여행 이름에 대한 노드와 화살표를 추가합니다. 픽셀이 정확하려면, 사진 이름과 여행 이름을 정확하게 입력해야 합니다.

그 둘 중 하나라도 바뀐다면. 예를 들어, 새 사진 이름을 지정하면 다음과 같습니다. 저는 이 빨간 점으로 표시하고 있습니다. 그러면 검색 행의 픽셀이 최신 상태가 아니게 됩니다. 그리고 SwiftUI 새로운 차트를 그려야 합니다. 종속성은 뷰의 입력과 같습니다.

SwiftUI 여러 장점을 가진 이유 중 하나는 의존성 추적 기능 때문입니다. 업데이트 속도가 매우 빠릅니다.

조회수와 데이터 양이 많은 앱에서. 한 가지가 바뀔 때마다 모든 것을 바꾸는 것은 극도로 비효율적일 것입니다. SwiftUI 모든 것을 다시 그려야 했습니다.

앱에서는 데이터가 자주 변경됩니다. 이렇게 되면 불필요한 업데이트가 많이 발생할 것입니다.

대신 SwiftUI 종속성을 추적합니다.

저는 여기서 화살표로 그것을 나타내고 있습니다. 그리고 그것들은 어떤 관점이 특정 데이터에 의존하는지를 나타냅니다.

이 시스템에서는 한 가지가 바뀌면, SwiftUI 하위 단계에서만 요소를 다시 계산하고 다시 그립니다.

의존성 추적은 빠르게 변화하는 환경 속에서도 SwiftUI 효율성을 유지해줍니다. 그리고 앱에서도 자주 볼 수 있습니다. 이건 정말 정교한 기술이고, 아주 좋은 소식이 있습니다. 이 그래프를 직접 만들 필요는 없습니다.

SwiftUI 의존성 그래프에 해당 파일을 자동으로 생성해 줍니다.

본문은 각 뷰가 실행될 때마다 읽는 속성을 추적합니다.

이 시스템은 그래프를 지속적으로 최신 상태로 유지합니다.

이 그래프를 직접 구축하거나 유지 관리할 필요는 없지만요. 코드를 작성할 때 여전히 몇 가지 유의해야 할 사항이 있습니다.

관점을 구축할 때는 관점을 가볍게 유지하세요. SwiftUI 에 본문에 필요하다고 알려준 정보가 무엇인지 생각해 보세요. 그리고 그러한 견해의 변경이 전체 견해를 무효화해야 하는지 여부.

뷰는 의존성을 최소화하여 간결하게 유지하는 것이 가장 좋습니다. SwiftUI 중요한 경우에만 화면을 다시 그립니다.

그렇다고 해서 복잡한 관점을 가질 수 없다는 의미는 아닙니다.

즉, 복잡한 관점을 더 작고 세분화된 부분으로 나누어야 한다는 뜻입니다. 이전에 검색 보기의 행을 구성했던 것처럼 더 간단한 작업입니다.

데이터를 표현하는 데 적합한 도구를 사용하고, 변경 사항을 전달하는 방법만 숙지하십시오. 화면의 픽셀을 언제 변경해야 할까요? 뷰가 데이터에 의존하는 방식에는 몇 가지 종류가 있습니다. 한 가지 방법은 제가 앞서 했던 것처럼 해당 데이터를 뷰에 직접 전달하는 것입니다. 이미지와 여행의 구체적인 이름을 제공함으로써.

데이터를 생성하는 또 다른 방법은 상태를 이용하는 것입니다.

제 동료 콜이 이 문제에 대해 더 자세히 설명해 드릴 겁니다. 그리고 그의 발표에서 제시된 데이터 흐름에 대한 다른 모든 옵션들, 하지만 저는 몇 가지 기본 사항을 다루고 싶습니다.

해당 주에 포함된 속성입니다. SwiftUI 해당 정보를 저장하도록 지시합니다. 전망의 전체 수명 동안.

뷰가 뷰 계층 구조에 존재하는 전체 기간입니다. 간단한 예를 들어 설명하겠습니다.

위시리스트의 검색 탭에서 검색창에 입력을 시작하면, 결과가 필터링됩니다.

J라는 글자를 추가하면, 최근 항목들은 제 여행 기록으로 교체되었습니다. 하이킹, 조슈아 트리와 같은 검색어가 포함된 활동 그리고 절벽 점프.

글자 'O'를 추가하면 검색 결과가 계속해서 줄어듭니다.

제가 앱에 추가한 모든 여행과 활동 중에서, Joshua Tree는 문자열 "j o"를 포함하는 유일한 항목입니다. 내 앱의 상태입니다. 내가 입력한 문자열입니다. 검색 필드에 입력된 내용이 검색 결과와 화면의 픽셀을 결정합니다.

상태가 어떻게 작동하는지 보여주기 위해 간단한 예제를 만들어 보겠습니다.

이는 검색 화면의 간소화된 버전입니다. 제가 '간단한 검색'이라고 부르는 기능입니다.

실제 검색 화면의 핵심 기능을 갖추고 있습니다. 하지만 디자인이 다소 단순화되었습니다.

본문에는 뷰가 두 개뿐입니다. 텍스트 필드와 텍스트 뷰를 사용하고 있습니다.

텍스트 보기란 단순히 "여기에 결과가 있습니다"라고 표시하는 자리 표시자일 뿐입니다. 이건 제가 프로토타입을 만들 때 자주 하는 작업입니다. 임시로 넣어둔 거예요. 나중에 제대로 바꿀게요. 검색 결과를 보여주는 사용자 지정 보기가 있습니다.

TextField는 SwiftUI 에 내장된 또 다른 뷰입니다. 사용자 의견을 수집하기 위한 것입니다. 사람들이 그것을 탭하면, 키보드가 열리고 제가 입력한 문자열이 표시됩니다.

여기에 시작 프롬프트 유형을 제공합니다. 그런 다음 SwiftUI 입력된 문자열을 저장하도록 지시합니다. 검색 값이라는 변수에 저장됩니다.

달러 기호는 바인딩에 대한 구문입니다. 이는 콜이 나중에 자세히 설명할 또 다른 데이터 흐름 도구입니다.

저는 속성 검색 값을 At 상태 속성 래퍼로 꾸몄습니다.

이는 SwiftUI 업데이트가 진행될 때 검색 값의 값을 유지하도록 지시합니다.

초기값은 빈 문자열입니다.

텍스트 입력란을 탭하면 커서가 깜빡이며 입력할 수 있음을 나타냅니다.

제가 J라는 글자를 입력하는 순간, 검색 값의 값이 빈 문자열에서 j SwiftUI 로 변경되었습니다. 해당 값을 저장해 두면 SimpleSearch의 픽셀 값을 그에 따라 업데이트할 수 있습니다.

똑같은 일이 일어납니다 SwiftUI 에서 Joshua Tree 방향으로 필터링을 계속하려면 문자 O를 추가해야 합니다. 검색 문자열 jo의 값으로 이를 통해 업데이트 전반에 걸쳐 지속적인 발전을 이룰 수 있습니다. 상태는 유지되어야 할 정보를 모델링하는 가장 간단한 방법입니다. 귀하의 시청 기간 전체에 걸쳐.

제가 검색 탭에 있는 동안 내내, 내 검색 값은 저장되므로 계속해서 값을 추가할 수 있습니다.

탭에서 나갔다가 나중에 다시 돌아오면, 해당 값은 빈 문자열로 다시 처음부터 시작됩니다.

이는 위시리스트에 실제 검색 화면을 구축하는 첫 번째 단계일 뿐입니다. 다음으로, 자리 표시자 텍스트 뷰를 여행 일정으로 바꿔야 합니다. 그리고 검색 값 문자열과 일치하는 활동입니다.

지금은 국가의 이러한 측면에 집중하십시오.

`state`는 SwiftUI 에서 속성을 감싸는 래퍼입니다. 속성이 표시된 경우. SwiftUI SwiftUI 상태 8에서 자신이 내 앱의 진실의 원천임을 알고 있습니다. 그리고 업데이트가 진행되더라도 해당 값은 그대로 유지됩니다. 그 모습은 평생 동안 기억 속에 남아 있다.

이는 앱이 역동적이고 누적되는 데이터를 표시할 수 있음을 의미합니다. 텍스트 필드에 입력한 문자열처럼요.

SwiftUI 에서 의존성을 구성하는 방법은 여러 가지가 있습니다. 그리고 콜은 나중에 각각의 항목에 대해 자세히 설명할 것입니다. 지금 제가 강조하고 싶은 한 가지는 바로 시간을 투자하라는 것입니다. 이러한 도구들이 어떻게 작동하는지 배우기 위해서입니다. 이렇게 하면 종속성이 제대로 작동하도록 모델링할 수 있습니다. SwiftUI 사용합니다.

오늘 설명드린 것처럼 뷰는 SwiftUI 의 기본 구성 요소입니다. 그것들이 사용되는 다양한 맥락에 대해 더 잘 이해함으로써, 프레임워크뿐만 아니라, 하지만 코드의 품질을 향상시키세요.

오늘 남은 발표는 다음과 같습니다. 위시리스트의 다양한 영역을 탐색하면서, 저는 여러분이 이러한 해결책의 이론적 배경에 집중하시기를 권장합니다.

이렇게 하면 배운 내용을 자신의 앱에 적용할 수 있습니다.

제 발표 내용을 통해 다음 사항들을 꼭 기억해 주세요.

SwiftUI 의 내장 뷰를 활용하여 사용자 지정 뷰를 직접 만들 수 있습니다. 앱의 고유한 특징을 표현하기 위해 다양한 수식어를 살펴보세요.

새로운 관점을 구축하거나 기존 관점을 재검토할 때, 의견은 간결하게 유지하는 것을 잊지 마세요. 각 뷰가 실제로 어떤 데이터에 의존해야 하는지 고려해 보세요. 복잡한 관점을 더 단순하고 작은 부분으로 나누어 보세요.

마지막으로, 시간을 내어 SwiftUI 에 대해 알아보세요. 이러한 기본 원칙들을 염두에 두면, 앞으로 닥쳐올 어려움에 대해 더 잘 추론하고 대처할 수 있게 될 것입니다. 함께해 주셔서 정말 감사합니다. 이제 제 동료인 마요에게 넘겨줄 생각에 설레네요. 그녀는 시스템을 이용해 위시리스트를 어떻게 디자인했는지에 대해 더 자세히 설명해 줄 것입니다. 마요를 무대 위로 환영해 주시기 바랍니다.

안녕하세요 여러분. 와주셔서 감사합니다. 아, 죄송합니다. 통제 중입니다. 발표자 안내문을 좀 더 크게 해주실 수 있을까요? 읽기가 어려워요.

팀원 전원이 참석해 주셔서 감사합니다. 위시리스트는 여러분과 이번 이벤트를 위해 특별히 제작되었습니다. 그리고 저희는 그 과정이 어떻게 이루어졌는지 여러분과 공유하게 되어 매우 기쁩니다. 그러니 여러분이 조금이라도, 아시다시피, 전달해 주실 수 있기를 바랍니다. 제가 수년간 배우고 경험한 것들과 디자인 과정을 여러분과 공유하고자 합니다. 그럼 시작하겠습니다. 앱 탐색부터 시작할게요. 이는 콘텐츠를 위한 구체적인 섹션을 만드는 것에서 시작됩니다. 그리고 여러분의 기능들. 저는 그런 식으로 시작하는 걸 좋아해요. 우리가 무엇을 정확히 지을지부터 계획을 세워야 해요. 항해는 좀 지루한 주제일 수도 있지만, 저는 개인적으로 아주 좋아합니다. 그럼 그 부분부터 시작해 볼까요? 다음으로 레이아웃에 대해 설명하겠습니다. 화면에 콘텐츠를 표시하는 가장 좋은 방법을 찾는 것에 대해 이야기해 보겠습니다.

마지막으로 시각 디자인에 대해 이야기해 보겠습니다. 이것이 바로 구성 요소와 시각적 요소가 결합되어 명확성을 제공하는 모습입니다. 그리고 앱에 개성을 더하세요.

네, 앞서 말씀드렸듯이, 이 앱은 제가 처음부터 직접 디자인했습니다. 그리고 제가 제일 먼저 한 일은 앱 내비게이션에 대해

생각하는 것이었습니다. 앱의 콘텐츠와 기능을 결정합니다. will have는 내게 좋은 틀을 제공할 것이다. 그러면 명확하게 구축할 수 있습니다. 그러면 상단 바와 같은 탐색 구성 요소를 사용하는 방법을 알게 될 것입니다. 그리고 툴바.

저는 먼저 브레인스토밍을 하고 팀원들이 해야 할 모든 일을 목록으로 작성하는 것으로 시작했습니다. 그리고 저는 앱이 갖추고 있어야 하고, 또 그렇게 하기를 바랐습니다. 우리는 골을 축하하고 싶었고, 모든 아이디어를 환영했습니다. 우리는 브레인스토밍 단계에 있었어요.

디자이너는 단 1분만 말했다. 그 후, 저는 이를 단순화했습니다. 그리고 저는 여행 버킷리스트 앱(예: 여행 만들기)에 필요한 필수 항목만 남겨두었습니다. 사진을 추가하고, 검색하고, 그런 다음 뒤로 물러섭니다. 여행, 활동, 진행 상황 등 관련된 아이디어들을 함께 묶어서 그룹화합니다. 그리고 완료된 여행을 축하합니다.

이 그룹들은 앱에서 가장 인기 있는 세 가지 섹션을 나타냅니다. 그래서 저는 그것들을 '위시리스트 목표'라고 이름 붙이고 검색해 봤습니다.

이것이 바로 저희 앱입니다. 그리고 이것이 여러분에게 어떤 의미인지 알려드리겠습니다.

앱을 처음부터 개발하든 기존 앱을 다시 개발하든 상관없이. 이 연습을 해보는 것은 매우 유익합니다. 저는 개발자 센터에서 개발자들과 함께 이 작업을 해왔습니다. 워크숍에 참여하는 동안 항상 많은 것을 깨닫게 됩니다. 그러니 여러분도 그렇게 하시기를 권합니다. 그래서 생각을 정리하는 데 도움이 됩니다. 그리고 브레인스토밍을 통해 머릿속에 있는 이러한 막연한 아이디어들을 모두 정리해 보세요. 이제 연결된 화면들을 구축할 준비가 되었습니다.

이 모든 것이 SwiftUI 와 어떻게 연결되는지 설명해 드리겠습니다. 당신이 바로 그 일을 위해 여기에 왔다는 것을 알고 있습니다. iOS 에서도 그 단계에 도달하고 있어요. 앱 탐색을 지원하는 구성 요소는 두 가지입니다. 상단 바와 툴바.

먼저, 상단 메뉴바가 어떻게 작동하는지 보여드리겠습니다. 상단 바에는 앱의 최상위 섹션이 표시됩니다. 그리고 모든 화면에서 계속해서 볼 수 있습니다.

이 예시에서 앱은 실제보다 더 복잡하게 느껴질 수 있습니다. 이러한 앱에서 흔히 볼 수 있듯이, 기능이 많을수록, 해야 할 일도 많아집니다. 상단 바가 계속 거슬리긴 하지만, 많은 사람들이 그걸 좋아하지는 않아요. 상황이 매우 복잡해집니다. 제가 항상 추천하는 것 중 하나는 탭 수를 적게 유지하는 것입니다.

단순함을 유지하는 데 도움이 되고 예측 가능성이 매우 높습니다. 의사결정 과정을 간소화합니다. 그래서 앱을 열 때마다 어떤 옵션을 사용할 수 있는지 정확히 알 수 있습니다.

둘째, 탭 바는 기본 기능을 유지하세요. 오늘 빙고 카드에 이게 있나요?

아시다시피 SwiftUI 컴포넌트는... 탭 바처럼 애니메이션과 같은 내장 동작이 함께 제공되는 경우도 있습니다. 및 접근성 지원. 이러한 행동 양식은 사용자 정의 과정에서 쉽게 사라질 수 있습니다.

하지만 걱정 마세요, 다른 곳도 많을 거예요. 개성을 표현할 수 있는 앱입니다. 상단 바는 그중 하나가 아닙니다.

마지막으로, 상단 표시줄에 명확한 기호를 사용했는지 확인하십시오. 그리고 각 탭의 내용과 일치하는 레이블이 있습니다.

위시리스트에는 공통된 기호가 없죠? 그래서 저는 무지개를 골랐습니다. 여전히 알아볼 수 있고 사람들이 꿈꾸는 여행의 모습을 담고 있지 않나요? 희망적인 느낌이 드네요.

반면에 목표는 보다 명확한 기호를 사용하는 것입니다. 더 명확하고, 제목과도 아주 잘 어울립니다. 그리고 그 안에 있는 많은 수집품들과 같은 모양을 하고 있습니다. 저는 그게 참 좋은 아이디어라고 생각했어요. 탭 바도 마찬가지로 효과적일 수 있습니다. 다음 지침 중 일부를 따르면 효율성을 높일 수 있습니다.

자, 이제 잠깐 다른 이야기로 넘어가겠습니다. 디자인이나 탭 바에 대해 좀 더 자세히 알아보고 싶으시다면,

휴먼 인터페이스 가이드라인 참조하십시오. 저희가 전에도 말씀드렸던 내용입니다. 헤이그는 디자인 지침의 본거지입니다. 모든 Apple 플랫폼 및 기술 전반에 걸친 모범 사례.

저희를 찾아오시기 전에 궁금한 점이나 조언을 얻으실 수 있는 첫 번째 곳입니다. 이제 드디어 헤이그로 가는 링크를 찾을 수 있습니다. 개발자 웹사이트의 디자인 섹션에서, 여기에는 매우 귀중한 Apple 디자인 자료도 포함되어 있습니다.

위시리스트 앱 디자인 그리고 제가 디자인한 거의 모든 다른 앱들 저는 일상생활에서 이 라이브러리의 네이티브 컴포넌트를 사용하고 있습니다.

그리고 둘러보시는 동안 SF Symbols 앱을 다운로드하지 않음으로써 디자인 도구를 구축하는 데 도움이 될 수 있습니다. 그것은 상징적인 사과 사이다입니다. 여기에는 복사할 수 있는 7000개 이상의 기호가 7개 있습니다. 디자인이나 코드에 붙여넣으세요.

이것들은 제가 상단 바에 사용하는 것들이고, 앞으로도 계속 사용할 겁니다. 오늘 저는 그것을 참고하겠습니다. 자, 그럼 다시 본론으로 돌아가죠. 상단 바와 툴바 모두 앱 탐색을 지원합니다. 하지만 차이점이 있죠, 그렇죠? 그들은 서로 다른 수준에서 작용합니다. 사용자는 상단 바를 사용하여 앱 내외부를 탐색합니다. 최상위 탐색이라고 말씀드렸죠. 하지만 조치를 취하고 특정 섹션으로 들어가야 할 때가 되면, 툴바를 사용하겠습니다.

툴바에는 탐색을 지원하는 다양한 요소가 있습니다. 먼저 현재 화면의 제목입니다. 이 화면에서 사람들을 볼 수 있습니다.

그들은 자신들이 위시리스트에 있다는 것을 알 수 있습니다. 죄송합니다. 그들은 위시리스트에 있습니다. 이것은 위시리스트 섹션에 있습니다. 그리고 그들은 화면 내용에 대한 어느 정도의 맥락을 알고 있습니다. 분위기를 조성하는 역할을 하는 것 같아요. 그러면 툴바에 컨트롤이 표시됩니다. 화면에서 가장 중요한 동작들을 보여줍니다.

여기서 가장 중요한 작업은 여행을 생성하는 것입니다. 그래서 저는 그렇게 할 수 있도록 오른쪽 상단에 컨트롤을 배치했습니다.

툴바의 세 번째 요소는 탐색 컨트롤입니다. 여행 상세 정보에서, 사람들이 이전 단계로 돌아갈 수 있도록 뒤로 가기 버튼을 추가했습니다. 그리고 위시리스트로 다시 이동합니다. 스캔하기 쉽도록 하기 위해서입니다. 저는 행동 횟수를 최소화합니다. 상단 메뉴와 동일한 안내입니다. 그리고 친숙한 SF Symbols 선택하여 의미가 명확하게 전달되도록 하세요.

예를 들어, 항목이 너무 많을 때. 이 예시에서 분명히, 사람들은 자신이 먼저 무엇을 해야 하는지 이해하기 어려워합니다. 이 문제를 해결하려면 빈도가 낮은 행동을 찾으면 됩니다. 아니면 더 고급 기능이 있어서 '더보기' 메뉴 뒤에 숨겨져 있는 걸까요?

툴바는 주요 작업에 대해 눈에 띄는 스타일을 제공하기도 합니다. 생동감 넘치는 색감을 더하고 즉각적인 시선을 사로잡는 포인트가 됩니다. 앱을 디자인할 때, 화면당 하나의 동작에만 이 스타일을 사용하도록 하세요. 최상단에서는, 우리가 원하는 중요한 기능들이 많이 있다는 것을 알고 있습니다. 강조하고 싶은 부분이지만, 아시다시피 모든 것이 중요하다면 아무것도 중요하지 않죠.

그렇다면 이 경우에는 여행을 하나도 하지 않은 여행 버킷리스트가 어떻게 될까요? 그래서 저는 그 점을 강조하고 싶습니다.

마지막으로 툴바에 대해 말씀드리자면, 탭 바와 마찬가지로, 네이티브 버전을 유지하는 것이 가장 좋습니다. 우리 함께 말해야 해요.

배경 같은 걸 추가하는 건 사실 별 의미가 없잖아요. 그것은 당신의 콘텐츠와 경쟁합니다. 기능성과 모르핀 효과 면에서 경쟁 관계에 있습니다. 그리고 나중에 커트가 그 부분에 대해서도 조금 이야기할 거예요.

지금까지는 앱의 구조에 집중해 왔습니다. 그리고 사람들이 그 안에서 어떻게 움직일 것인가. 이제 화면에 콘텐츠를 담을 차례입니다. 그리고 그것을 어떻게 발표할지 결정합시다.

이것이 바로 제가 레이아웃이라고 말하는 것입니다. 제가 좋아하는 레이아웃 패턴 두 가지를 예시로 보여드리겠습니다. 리스트와 컬렉션을 사용하기 위해서입니다.

두 옵션 모두 매우 유연하므로 어느 쪽이든 자유롭게 선택하셔도 좋습니다. 둘 중 하나겠지만, 곧 상황에 따라 다르다는 걸 알게 될 거예요. 보여주고 싶은 콘텐츠와 사람들이 그 콘텐츠를 어떻게 활용해야 하는지에 따라 달라집니다. 두 가지 선택지 중 하나가 다른 하나보다 더 낫다.

예를 들어, 내용이 텍스트 기반일 때는 목록을 사용합니다. 네. 그리고 표시해야 할 항목이 여러 개 있습니다. 그리고 이는 사람들이 내용을 매우 빠르게 훑어볼 수 있도록 도와줍니다. 그래서 이 레이아웃이 여행 활동에 적합한 것입니다.

여기서는 필요에 따라 '엣지 투 엣지'라는 스타일을 사용하고 있습니다. 콘텐츠를 분류해야 할 때는 그룹 스타일을 사용합니다. 그러니까 미묘한 차이라는 거죠. 하지만 삽입된 부분, 삽입된 레이아웃은 둥근 모서리가 각기 다른 카테고리를 명확하게 구분해줍니다. 목록에 넣을 수 있는 콘텐츠입니다. 그래서 제 앱에는 이런 스타일이 딱히 필요하지 않았어요. 다운로드하고 게임을 시작하면 그것으로는 이 예시를 찾을 수 없겠지만, 저는 원했습니다. 제가 어떻게 할 수 있는지 보여드리겠습니다. 왜냐하면 항상 이런저런 혼란이 좀 있기 때문이죠. 엣지 투 엣지 방식과 인셋 방식은 언제 사용하나요? 우리는 이런 식으로 합니다.

마지막으로, 사람들이 목록을 통해 빠르게 움직이고 행동할 수 있도록 도와주시나요? 저는 액세서리와 컨트롤러를 사용합니다. 이미지와 같은 액세서리 자막은 사람들이 필요 없이 항목을 더 빨리 인식하는 데 도움이 됩니다. 한 줄씩 읽고 선택 버튼과 같은 컨트롤을 사용할 수 있습니다. 이는 사람들이 다른 관점으로 넘어가지 않고도 행동을 취할 수 있도록 도와줍니다. 이는 매우 흔한 일입니다. 앱이 때때로 너무 복잡해지기도 합니다. 조회수를 추가하고 있기 때문입니다. 목록 보기에서 간단히 처리할 수 있는 몇 가지 작업에 대해서만 그렇습니다.

추가할 수 있는 컨트롤 유형은 매우 다양합니다. 또한 다양한 기능을 지원합니다. 그러니 여러분께서 직접 가서 이용 가능한 것들을 살펴보시기를 권장합니다. 레이아웃을 간소화할 수 있는 기회가 있는지 살펴보세요. 여기에는 스텝퍼, 토글 스위치, 슬라이더 등 여러분이 직접 사용해 볼 수 있는 다양한 제품들이 있습니다.

그리고 이는 사람들이 텍스트를 빠르게 탐색하는 데 도움이 되는 목록을 포함합니다. 하지만 사진, 동영상 또는 제품을 둘러보는 것이 목적이라면, 컬렉션이 훨씬 더 적합합니다.

SwiftUI 컬렉션은 기본적으로 StackView와 같습니다. 화면 밖으로 콘텐츠가 확장될 수 있도록 ScrollView를 사용하면, 그리고 사람들이 스크롤하면서 안에 무엇이 있는지 발견하도록 유도합니다. 하지만 위시리스트 탭의 주된 목적은 둘러보는 것입니다. 그래서 저는 레이아웃을 만들기로 했습니다. 다양한 컬렉션 변형과 함께

여행을 더욱 시각적으로 표현하고 개인적이고 흥미로운 느낌을 주는 방식입니다. 사람들이 업로드한 사진들을 보여줍니다.

컬렉션의 경우 모든 콘텐츠가 한 번에 표시되는 것은 아니라는 점을 유념해 주세요. 대부분은 화면 밖에 있습니다. 따라서 적절한 기대감을 조성하고 사람들이 스크롤하면서 살펴보도록 유도하기 위해, 제목과 이미지를 효과적으로 추가하도록 하겠습니다. 그게 무슨 뜻인가요?

자, 이 예시에서 이미지가 가치를 더한다고 생각하시나요?

좀 뜬금없어 보이지 않나요? 네. 네. 정말 뜬금없네요. 바로 그 점 때문에 콘텐츠에 대한 신뢰도가 떨어지는 경우가 종종 발생합니다. 이미지가 전혀 말이 안 되기 때문입니다. 인위적으로 기획된 것 같지 않아요. 그런 다음 길이가 일정한 제목을 추가할 수 있습니다. 그렇지 않으면 레이아웃이 다소 투박해 보입니다. 그리고 정렬이 안 된 것처럼 보입니다. 그래서 이는 소장품에 피해를 줄 뿐만 아니라, 하지만 아래에 다른 콘텐츠가 있을 때는 세로 스크롤이 되는 것도 문제입니다. 지금 모든 게 약간 불안정해 보이네요. 그래서 여러분을 위해 몇 가지 규칙을 정하는 것이 깔끔하고 좋을 것 같습니다. 컬렉션 콘텐츠에 포함되어 있습니다.

네, SwiftUI 이미 제가 원하는 많은 디자인 원칙들을 지원하고 있습니다. 제 설명 전반에 걸쳐 조금씩 언급해 왔습니다. 하지만 위계질서, 정렬, 근접성 같은 것들은 그것들은 모두 구성 요소의 일부입니다. 하지만 레이아웃을 만들 때 이러한 요소들을 직접 탐색해 보시는 것도 권장합니다. 그리고 그것은 시각 디자인의 중요한 부분입니다.

그래서 우리는 텍스트 색상과 이미지를 사용하여 시선을 유도할 것입니다. 그리고 당신의 개성을 표현하세요. 지금까지 우리는 효과적으로 일하려고 노력하면서 꽤 제 역할을 다해왔습니다. 자, 이제 당신의 매력을 조금 더 끌어낼 수 있는지 한번 볼까요? 그래서 저는 시각 디자인에서 가장 큰 영향을 미치는 세 가지 측면에 집중하려고 합니다. 그리고 가장 초기의 영향. 직물, 의미론적 색상 및 일관성.

이 모든 요소들이 합쳐져 앱을 더욱 즐겁고 이해하기 쉽게 만들어줍니다. 그리고 제가 아주 좋아하는 것이기도 해요. 앱이 성장함에 따라 패턴을 재사용할 수 있도록 지침을 제공할 것입니다.

먼저 직물부터 시작해서 스타일의 위계질서를 설명하겠습니다. 그들은 미안해. 그들은 위계질서를 만들었어. 또한 다양한 화면 크기와 환경에서 가독성을 높이도록 노력합니다. 그래서 저는 시스템 텍스타일을 사용할 건데, 그러면 바로 계층 구조를 얻을 수 있습니다. 하지만 중요한 것은 목적에 맞는 적절한 섬유를 선택하는 것입니다. 앱에서요. 저는 이걸 꾸준히 사용해요. 예를 들어, 제목 3은 '여름의 빛'과 같은 모든 섹션 제목에 사용됩니다. 화면 전체의 균형감과 세련미를 한층 높여줍니다. 구체적인 콘텐츠 섹션들이 있기 때문입니다. 그리고 내가 위계질서를 나타내는 것을 알고 있는 직물을 보는 순간, 저는 그 내용이 정확히 무엇을 의미하는지 알고 있습니다.

제가 시스템 텍스타일을 선호하는 또 다른 이유는 Dynamic Type 입니다. 많은 사람들이 편안함을 위해 큰 사이즈의 직물을 사용합니다. 또는 때로는 둘 다에 해당될 수도 있습니다. 그리고 Dynamic Type 사용하면 이러한 텍스타일의 이름이 동일하게 지정됩니다. 하지만 크기는 일관적으로 더 큽니다. 그러니 부디 사용해 주세요.

폰트 애호가라면, 앱 전체에서 Apple 시스템 폰트인 SF Pro 사용하고 있다는 것을 알 수 있을 겁니다. 하지만 저는 당연히 한 가지 스타일만 사용하는 건 아닙니다. SF Pro 에는 사용자의 개성을 표현할 수 있는 다양한 옵션이 포함되어 있습니다. 앱의 가독성을 해치지 않으면서. 저희는 좀 더 스포티한 분위기를 원했어요. 그래서 저는 제목에서 강조하기 위해 '확장됨'이라는 단어를 사용해 왔습니다. 그리고 일부 오버레이에서만 드물게 압축합니다.

여기서도 마찬가지로, UI가 의도적으로 느껴지도록 선택지를 최소화하고 싶습니다. 또한 앱을 유지 관리하고 확장하기가 더 쉽습니다. 그럼 이제 다시 섬유 이야기로 돌아가 볼까요? 아, 그렇군요. 확장 기능은 언제 사용하나요? 코나는 언제 사용해야 하나요? 이제 우리는 다양한 직물과 다양한 변형 제품을 보유하고 있습니다. 그리고 폰트 종류도 엄청 많네요.

앞서 컬렉션에 대해 설명드렸듯이, 앱의 시각적인 측면에서 이미지가 큰 역할을 한다고 언급했습니다. 따라서 의미론적 색상은 UI를 보완하는 좋은 요소입니다. 둘은 매우 비슷한 역할을 하지만 훨씬 더 구체적입니다.

이는 상태 및 피드백에 관한 것입니다. 예를 들어, 저는 앱 전체에서 인디고 색상을 사용합니다. 예를 들어, 여기에서도 마찬가지입니다. 완료된 활동 목록의 상단 메뉴바에 있는 선택된 탭에서 확인할 수 있습니다.

저는 장식용으로 남색이나 그와 아주 비슷한 색을 사용하는 것을 피합니다. 그렇지 않으면 사람들이 "이게 상호작용적인 거야, 아니면 그냥 그런 거야?"라고 이해하지 못할 수도 있어요. 그것이 무슨 의미가 있나요? 저는 이 색상의 이름을 인디고로 설정했습니다. 그리고 그 전에 우리는 의미론적 색상에 대해 설명하고 있습니다. 그러니까 그건 주변에 있는 색깔이 아니에요. 네, 그냥 무작위로 골랐어요.

시스템에서 제공하는 것이고 각 색상은 기본 색상입니다. 죄송합니다. 각 네이티브 구성 요소는 고유한 색상을 가지고 있습니다. 그래서 배경을 설정하지 않았어요. 구분선 색상을 설정하지 않았습니다. 이 모든 것들은 제게 이미 익숙한 것들입니다. 제가 선택한 유일한 것은 이 포인트 색상입니다.

이 색상들은 밝은 모드와 어두운 모드에 자동으로 맞춰지기 때문입니다. 또한 Liquid Glass 와 다양한 화면 환경도 포함됩니다. 맞춤 설정을 너무 과하게 하지 않는 것이 좋습니다. 특히 버튼과 조작 버튼의 경우 더욱 그렇습니다.

앱에서 색상 팔레트도 보셨을 겁니다. 네온 그린 색상이 포함되어 있는데, 강조를 위해서만 사용합니다. 진행 표시기나 부제목처럼요. 다시 말해, 의미와 이러한 시각적 은유를 파악하려고 노력하는 것입니다. 그러므로 색깔은 의미론적인 것이 아닙니다. 저희 키트에는 그게 포함되어 있지 않습니다. 그래서 저는 명암 대비가 충분한지 확인합니다. 저는 정말 다양한 배경에서 테스트해봤어요. 그리고 저는 대비 증가를 위한 값도 제공했습니다.

시스템 색상이 아닌 다른 색상을 사용하기로 결정했다면, 이 규칙처럼 몇 가지 간단한 규칙만 잘 지키면 됩니다. 계속 테스트하면서 앱이 여전히 표현력이 풍부한지 확인하세요. 하지만 사용성에 영향을 미치지 않습니다. 이제 거의 끝에 다다랐네요. 즉, 모든 것이 최상의 상태로 보이도록 점검하기에 좋은 시기라는 뜻입니다. 그리고 마지막으로, 다시 돌아가서 모든 요소가 제대로 정렬되었는지 확인하겠습니다. 그리고 일정한 간격으로 배치되어 있습니다.

이렇게 하면 디자인이 훨씬 더 세련되고 시각적으로 균형 잡힌 느낌을 줍니다. 전문가처럼 보이네요. 또한 이는 사람들이 정보를 받아들이고 다음에 무엇을 해야 할지 결정하는 방식에도 도움이 됩니다. 만약 좁은 공간에 많은 부품들이 빽빽하게 들어차 있다면 어떻게 될까요? 우리는 스트레스를 받아요. 생각할 여유도, 시간도 없는 것 같아요. 그리고 UI에 숨 쉴 공간을 조금 더 주면, 그때부터 멋진 경험이 시작되었어요. 사람들에게 생각할 시간을 주는 곳.

그래서 네이티브 컴포넌트를 사용할 때도 같은 방식으로 사용하려고 주의합니다. 다른 화면에서도 동일한 방식으로 작동합니다. 저는 사람들이 같은 일을 할 수 있는 여러 가지 방법을 제공하는 것을 피합니다. 때때로 그런 일이 발생하기도 합니다. 저희는 새로운 화면을 만들 때면 항상 설레고, 처음부터 다시 시작합니다. 하지만 가장 좋은 점은 개발을 단순화할 뿐만 아니라, 사람들이 경험하게 될 것은 이러한 구성 요소들을 재활용하는 것입니다. 그들은 그것을 어디서 본 적이 있는지, 어떻게 아는지 알고 있습니다. 그들은 자신들의 행동 방식을 알고 있다. 그리고 그들은 자신들에게 무엇이 기대되는지 정확히 알고 있습니다. 예를 들어, 진척도 지표 같은 것들이죠. 여기서는 동일한 강조 색상과 동일한 모양을 사용하세요. 하지만 크기는 그것보다 조금 더 작습니다. 그것들은 내가 아는 맥락 속에 있습니다. 네. 그들이 뭘 했는데요? 그리고 그러한 꾸준함은 여러분의 발전에도 도움이 됩니다. 조립해야 할 부품 수가 줄어듭니다.

컬렉션을 설명하면서 이미지에 대해 간략하게 언급했지만, 이미지에는 여러 종류가 있습니다. 물론 시각 디자인의 일부입니다. 그러므로 이미지와 삽화를 선택할 때, 두 개를 나란히 놓고 겉모습이 비슷한지 살펴보세요. 세부 묘사의 정도와 전반적인 분위기. 그런 다음 세부적인 조정을 할 수 있습니다. 그래서 그들은 자신들이 같은 브랜드의 일원이라고 느끼게 됩니다. 같은 컬렉션에 속해야 할 것 같은 느낌이 든다면, 직감을 따르세요. 그들의 말이 맞을지도 모릅니다. 예를 들어 위시리스트에서는 사람들이 자신의 사진을 업로드합니다. 하지만 다시 한번, 이 점을 설명하기 위해 말씀드리자면, 이미지들을 사용해서 코드에서도 어떻게 해당 기능을 구현할 수 있는지 보여드렸습니다. 당신은 해당 이미지들에 접근할 수 있게 될 것입니다. 보시다시피 저희가 거쳐온 패턴이 대략 이렇습니다. 그래서 저는 역동적인 하늘을 선택하려고 합니다. 피사체가 작거나 공간과 상호작용하는 경우가 매우 많습니다. 하지만 핵심은 사진보다 사용자 인터페이스가 더 중요하다는 것입니다. 하지만 분명히 당신이 평가해 볼 만한 사항입니다. 앱들의 일관된 디자인을 유지하기 위해서입니다. 돌이켜보면, 앱 디자인에 대한 공로는 상당 부분 제가 가져갔다고 할 수 있습니다.

약간은 그럴 수도 있지만, SwiftUI 디자인 결정의 많은 부분을 처리하고 있습니다. 제게는요. 그리고 그건 정말 솔직한 대답이에요.

하지만 그건 사실이에요. 저는 엔지니어들과 함께 일하는 걸 정말 좋아해요. 이 앱을 개발하면서, 제가 디자인한 모든 것들이 이렇게 멋지게 구현된 걸 보니 정말 감격스럽네요. 코드로 번역하면 매우 유사한 형태입니다. 그래서 저희는 이 소식을 여러분과 공유하게 되어 매우 기쁩니다. 그리고 당신이 그것을 가지고 놀 수 있다는 것입니다. 그리고 바라건대 여러분이 이 팁들 중 몇 가지라도 활용하실 수 있기를 바랍니다. 여러분의 프로세스를 원활하게 진행하고, 여러분이 알고 계시는 불확실성을 조금이라도 줄여줄 수 있습니다. 가끔은 창의력을 발휘하고 싶을 때 그런 일이 생기기도 하죠. 마치 임의의 시점처럼 혹은 단순히 처음에 창의력을 발휘할 수 있는 공간을 제공하는 것일 수도 있습니다. 결정을 내리고, 아이디어를 구상한 다음 코딩을 시작하세요.

그러므로 업무에 복귀하시면 구조와 그 구조를 탐색하는 방법을 정의하거나 평가하십시오. 구성 요소를 신중하게 사용하십시오. 이는 여러분이 명확한 결정을 내리는 데 도움이 될 것입니다. 그러니까 코딩을 시작하는 순간, 자신이 어디로 가고 있는지 정확히 알게 되는 거죠. 당신은 당신이 만들어가는 바로 그 모습입니다. 네, 그러면 훨씬 더 의도적인 앱을 만들게 될 겁니다. 좋아요, 그럼 SwiftUI 와 파트너십을 맺어볼까요? 시스템이 어려운 작업을 대신하도록 맡기고, 당신은 최선을 다해 개성을 표현해 보세요. 창의성과 인간미가 어우러진 작품이네요. 정말 감사합니다. 만드는 과정이 즐거우셨으면 좋겠고, 저는 앱을 사용해 보고 있어요. 디자인 측면에서는 이게 전부입니다. 와주셔서 감사합니다. 자, 이제 리아에게 다시 넘겨드리겠습니다.

와. 정말 멋졌어요. 마요. SwiftUI 시스템 컴포넌트 덕분에 작업이 훨씬 쉬워져서 정말 좋아요. 사람들이 사용법을 빠르게 익힐 수 있는 앱을 디자인하는 것. 위시리스트는 아름다운 앱이며, 잠시 멈춰서 생각해 볼 만한 가치가 있습니다. 각각의 결정 뒤에 숨겨진 생각을 이해하게 되면, 그 결정의 가치를 더욱 높이 평가하게 됩니다. 완전히 새로운 것을 프로토타입으로 만들든 기존 앱을 개선하든, 저는 항상 시스템 구성 요소를 활용할 수 있는 기회를 생각해 보려고 노력합니다.

자, 그럼 잠시 쉬어가도록 하겠습니다. 우리는 SwiftUI 레이아웃에 대한 프레젠테이션을 위해 태평양 표준시 기준 11시 15분에 다시 모일 예정입니다. 그럼 그때 뵙겠습니다.

다시 오신 것을 환영합니다. 휴식을 잘 보내셨기를 바랍니다. 그리고 다과를 즐기거나 잠시 휴식을 취할 기회가 있었습니다. 이제 제 동료 Cat이 SwiftUI 레이아웃에 대한 가이드를 공유해 드리겠습니다. 캣의 무대 등장을 함께 환영해 주세요.

안녕하세요. 여러분. 제 이름은 캣이고, Apple 에서 개발 도구 엔지니어로 일하고 있습니다.

지난 몇 년 동안, 저는 Apple Watch 용 생체 정보 앱과 같은 프로젝트에 참여했습니다. iPhone 과 iPad 의 건강 앱에서 제공되는 수면 경험 또한 마찬가지입니다. 네, 이러한 경험들은 직관적이어야 하고 아름답게 보여야 합니다. 손목시계를 보든, 휴대폰을 보든 상관없이.

이 작업을 통해 저는 강력한 UI 레이아웃의 중요성을 배웠습니다. 기본기는 오늘날 이러한 것들을 가능하게 하는 토대입니다. SwiftUI 레이아웃의 보편적인 구성 요소인 원칙들을 다루겠습니다. 어떤 플랫폼에서 작업하든 상관없습니다.

먼저 SwiftUI 의 몇 가지 개념적 구성 요소를 다시 살펴보겠습니다. 레이아웃에 특히 중요한 요소들입니다.

이어서 SwiftUI 레이아웃 메커니즘이 설명됩니다.

그럼 이제 어떻게 하는지 예시를 통해 설명해 드리겠습니다. SwiftUI 사용하여 예측 가능한 결과를 얻으려면.

그럼 기본부터 시작하겠습니다. 오늘 아침 리아가 묘사한 풍경들, SwiftUI 뷰는 화면에 표시될 내용을 설명하는 가벼운 템플릿입니다.

뷰는 위치, 크기 및 계층 구조를 나타내는 템플릿입니다.

SwiftUI 화면에 표시되는 내용을 설명하는 경량 뷰 구조체를 생성합니다. 그리고 업데이트가 있을 때마다 기존 구조체를 버리고 새로운 구조체를 생성합니다.

SwiftUI 업데이트 엔진은 변경된 UI 부분만 업데이트합니다. 상태 변화에 따라 예측 가능하고 효율적인 결과를 보장합니다.

이러한 효율성은 SwiftUI의 로컬 업데이트 모델에서 비롯됩니다. 뷰 계층 구조의 한 부분에서 발생한 변경 사항이 관련 없는 하위 트리에 연쇄적으로 영향을 미치지 않습니다. 따라서 영향을 받는 하위 뷰만 다시 렌더링됩니다.

그리고 SwiftUI 뷰 템플릿이 위치 지정부터 모든 것을 제어합니다. 크기 조정부터 렌더링 및 상태 업데이트까지.

뷰가 무엇인지, 그리고 SwiftUI의 업데이트 엔진이 어떻게 작동하는지 설명드렸으니, 이제부터는... 이 개념들이 어떻게 결합되는지 그 작동 방식을 보여드리겠습니다. SwiftUI 레이아웃을 수행할 때.

레이아웃 메커니즘에 대해 설명하면서, 저는 위시리스트 앱에서 만든 여행 카드에 집중해서 설명하겠습니다.

여행 카드(TripCard)는 SwiftUI 어떻게 처리하는지 보여주는 훌륭한 예시입니다. 다양한 상태에 따라 달라지는 동적 레이아웃.

그리고 SwiftUI 레이아웃은 상태에 따라 결정됩니다. 여기서 '상태'라고 할 때, 이는 '상태' 속성 래퍼를 의미하는 것이 아닙니다. 제 말은 국가 전체를 말하는 겁니다. 예를 들어, 여기 캘리포니아 해안 트레일과 같은 여행 이름처럼요.

또는 여행 사진의 URL. SwiftUI 본질적으로 레이아웃과 상태를 추상화합니다.

이는 다른 UI 프레임워크에서도 가능합니다. 하지만 어느 정도 노력과 훈련이 필요합니다. 하지만 이러한 추상화는 SwiftUI 의 필수적인 부분입니다.

상태에 따라 UI를 동적으로 제어하여 레이아웃을 결정합니다.

상태는 또한 이러한 각 뷰의 내부 내용을 채웁니다. 화면에 표시되는 문자열과 이미지처럼요.

다른 프레임워크에서는 상태 변경 시 수동 업데이트가 필요합니다. 사용자 인터페이스의 특정 부분을 전달하기 위해,

SwiftUI 상태 변경은 영향을 받는 뷰 템플릿을 자동으로 다시 생성합니다. 항상 최신 정보를 유지하도록 보장합니다.

이제 위시리스트 앱에서 여행 카드 레이아웃을 어떻게 구성했는지 설명하겠습니다. 여기에서 보여주는 것처럼 레이아웃을 상태에서 추상화하는 방법을 설명합니다.

여행 일정표는 단순한 검은색 배경에 표시되어 있습니다.

여기에는 여행을 나타내는 이미지가 포함된 VStack이 있습니다.

그리고 여행 이름이 표시된 텍스트 보기가 있습니다. 여행 이미지 보기에는 활동 수를 표시하는 오버레이가 있습니다.

단, 활동 횟수가 0보다 큰 경우에만 해당됩니다. 그렇지 않으면 텍스트가 생성되지 않습니다. SwiftUI 액티비티 오버레이를 렌더링하지 않습니다.

뷰의 상태는 모델의 Trip에 의해 독립적으로 제어됩니다.

Trip 모델에는 여행 제목을 나타내는 이름 문자열과 사진 URL이 있습니다. 여행에 사용할 이미지를 결정하기 위해.

마지막으로, 활동 사전이 있습니다. 사전의 활동 개수가 사용됩니다. 활동 오버레이가 표시되는지 여부를 확인합니다.

이는 SwiftUI 상태를 제어하는 ​​간단한 예입니다. 레이아웃과 값의 의미. 이 예시에서는 활동 횟수가 사용됩니다. 뷰의 레이아웃을 사용자 지정합니다.

다음으로 SwiftUI 에서 레이아웃이 어떻게 작동하는지 설명하겠습니다.

SwiftUI 레이아웃의 기본 전제는 컨테이너가 크기를 제안한다는 것입니다. 하위 뷰로 이동합니다.

이 제안의 크기는 컨테이너 뷰에 의해 제한됩니다. 그리고 이전의 모든 컨테이너 뷰.

각 서브뷰는 선호하는 크기를 계산하여 보고함으로써 응답합니다.

각 뷰와 SwiftUI 서로 다른 적정 크기를 선호합니다.

색상으로 보는 관점은 항상 제시된 그대로를 주장합니다. 그것은 자라면서 이용 가능한 공간을 채웁니다.

ImageView는 제공되는 공간이 더 작더라도 항상 전체 크기를 표시합니다. 이는 이미지가 포함된 뷰의 범위를 벗어날 수 있음을 의미합니다.

이 설정을 재정의하려면 크기 조정 수정자를 사용하십시오. 그러면 색깔처럼 주어진 공간을 차지하게 될 것입니다. 설령 이곳 해안가 꽃들처럼 찌그러진 모습으로 나타나더라도 말입니다.

이미지의 원래 가로세로 비율을 유지하기 위해. 콘텐츠 모드를 맞춤 또는 채우기로 설정하세요.

텍스트에는 최소한 생략 부호를 표시할 수 있는 충분한 공간이 있습니다. 텍스트는 내용에 필요한 공간만 차지합니다.

레이아웃과 SwiftUI 는 계층적으로 구성됩니다.

컨테이너 뷰는 각 하위 뷰에 크기를 제안합니다.

제안된 크기가 구체적이라고 가정해 봅시다. 예를 들어, 이 주황색 상자는 제안서가 어떤 모습일 수 있는지 보여줍니다.

컨테이너 뷰가 앱의 루트 뷰인 경우. 제안 내용은 장치 크기 또는 프레임 수정자를 적용하는 경우입니다. 제안 내용은 액자의 크기에 관한 것입니다.

반면에, 때로는 제안된 크기가 명시되지 않은 경우도 있습니다.

또는 양방향 모두.

이는 컨테이너 뷰가 원하는 바를 의미합니다. 서브뷰가 아무런 제약 없이 사용될 경우 얼마나 많은 공간을 필요로 하는지 알기 위해서입니다. 이것이 서브뷰의 이상적인 크기입니다.

각 서브뷰는 제안된 크기를 고려하여 자신이 선호하는 크기로 응답합니다.

이는 SwiftUI 의 특별하고 독특한 동작 방식입니다. 다른 뷰 시스템과 비교합니다. 제안은 아래로만 가는 게 아니라 위로도 올라갑니다.

이 레이아웃 프로세스는 재귀적입니다.

제안은 루트 뷰에서 전체 뷰 계층 구조를 따라 아래로 흐릅니다.

그러면 답변이 다시 위로 올라옵니다.

사이즈를 확인했으니, 루트 뷰는 모든 하위 뷰에게 어디에 그려야 하는지 알려줍니다. 그들은 하위 관점들을 설명하고, 이런 식으로 모든 관점이 그려질 때까지 계속됩니다.

자, 이제 같은 경로를 다시 한번 안내해 드리겠습니다. 이번에도 마찬가지로, 실제 조회수와 실제 값이 포함된 트립카드를 살펴보겠습니다.

여행 카드 정보는 가로 방향의 ScrollView 안에 가로 방향으로 쌓여서 표시됩니다.

저는 모든 여행 카드를 갖고 싶어요. 칼리, 교토 등도 같은 높이를 가져야 한다. 원본 이미지의 크기나 여행 이름의 길이에 관계없이.

고정 높이 프레임을 사용하면 그것을 구현할 수 있습니다.

SwiftUI 무제한 너비를 제공합니다. 또한 TripCard의 루트에 있는 VStack의 높이는 220으로 고정됩니다.

그러면 스택은 크기를 제공합니다. 여행 이미지 보기에서 높이를 220으로 설정하세요. 다음은 단지 예시입니다. 고정 높이 프레임.

이미지 뷰는 필요한 정확한 크기인 185x150 픽셀로 응답합니다.

외부 스택은 반환된 높이를 뺍니다. 그런 다음 남은 공간에 여행 이름이 포함된 텍스트를 입력합니다.

이름 텍스트는 15x130포인트 크기의 필요한 공간을 확보하여 응답합니다. 마지막 뷰에 도달했습니다.

이제 각 뷰는 필요한 크기로 응답했습니다.

활동 오버레이를 제외한 모든 보기가 그렇습니다. 그 부분은 발표 후반부에 다시 ​​다루겠습니다.

절차를 완료합니다. VStack은 내부 이미지, 뷰 및 텍스트의 요청된 크기를 결합합니다. 그리고 뷰의 최종 요청 크기를 반환합니다.

이것이 바로 SwiftUI 레이아웃이 작동하는 방식입니다.

요약하자면, SwiftUI 레이아웃은 위에서 아래로 순회됩니다. 크기 정보는 어떤 수준에서든 루트로 다시 공유됩니다. 사용 가능한 공간은 컨테이너 뷰에서 제공됩니다.

필요한 공간은 서브뷰에 따라 결정됩니다. 아마도 자체 하위 뷰를 확인하여 알 수 있을 것입니다. 레이아웃은 상태가 변경될 때만 다시 계산됩니다.

뷰 템플릿은 항상 다시 생성됩니다.

상태가 콘텐츠를 제어하므로 여행 값이 변경되면 화면이 자동으로 변경됩니다.

멋지네요. 이제 멋진 SwiftUI 뷰를 만들어 볼 시간입니다.

제가 SwiftUI 를 처음 시작했을 때, 뷰를 만들 때 예상했던 결과가 나오지 않는 경우가 종종 있었습니다. 다음으로 몇 가지 지침을 공유하겠습니다. 레이아웃을 단순하고 구성 가능하게 유지하면 예측 가능한 결과를 얻을 수 있습니다.

첫 번째 고려 사항 예측 가능한 레이아웃을 위해서는 레이아웃 우선순위가 사용됩니다. 뷰의 간격 및 크기 조정을 위한 레이아웃 순서를 결정합니다.

원하는 경관을 감상할 공간이 부족할 경우, 레이아웃 우선순위가 높은 뷰에 더 많은 공간이 할당됩니다. 레이아웃 우선순위가 설정되었습니다. 레이아웃 우선 순위 수정자와 함께 사용되며 기본값은 0입니다. 값이 높을수록 우선순위가 높아집니다. 예를 들어, 우선순위 3의 보기는 더 높은 우선순위를 갖게 됩니다. 우선순위 1번 관점보다.

이는 아마 여러분이 버그 접수 대기열에서 익숙한 것과는 정반대일 것입니다. 여기서 p1은 최우선 순위입니다. 하지만 이 경우에는 정반대입니다. 숫자가 높을수록 우선순위가 높습니다.

그리고 위시리스트 앱도 있죠. 카드 너비를 더 넓게 만든 여행 일정 섹션을 만들었습니다.

위시리스트 앱 디자이너인 마조와 이야기를 나누고 있었어요. 저희는 이러한 다양한 여행용 카드가 완벽한 선택이라고 생각합니다. 추가 공간을 활용하기 위해 여행의 부제목과 생성 날짜를 표시합니다.

컨테이너 뷰 안에 여러 개의 텍스트 뷰가 있는 경우가 있습니다. 텍스트는 사용 가능한 공간에 따라 잘리거나 줄 바꿈될 수 있습니다.

이 예시에서는 자막을 추가한 후 하와이 미국 텍스트의 날짜 카드 왼쪽 하단 모서리 부분이 잘렸습니다.

사용 가능한 공간이 얼마나 되는지 정확히 모를 수도 있습니다. 예를 들어, 기기의 크기에 따라 다를 수 있습니다.

그리고 저는 제가 얼마나 많은 공간이 필요한지 모를 수도 있어요. 일부 여행 상품은 자막 줄이 더 깁니다. 따라서 레이아웃에서 다양한 텍스트의 중요도를 표시하는 것은 여러분에게 힘을 실어줍니다. 어떤 텍스트를 잘라낼지 결정하기 위해.

텍스트의 레이아웃 우선 순위를 높이면 그렇게 할 수 있습니다. 기본값인 0에서 1과 같은 더 높은 값으로 변경합니다.

앞서 말씀드렸듯이, 스택은 우선순위가 높은 뷰에 먼저 공간을 제공합니다.

그래서 자막이 필요한 모든 공간을 확보할 수 있습니다. 하지만 이렇게 하면 오른쪽 하단의 날짜 텍스트가 잘리게 됩니다.

이 레이아웃 문제를 디자이너인 마조에게 이야기했습니다. 그녀는 공간이 부족할 경우 생성 날짜를 숨기는 것을 제안했습니다. 그래서 '여행'이라는 부제가 완전히 보입니다.

문자열 잘림을 방지할 수 있으므로 아주 좋은 조언이라고 생각합니다. 이제 그 방법을 보여드리겠습니다.

HStack을 ViewThatFits 뷰 안으로 옮겼습니다. ViewThatFits는 하위 뷰를 평가합니다. 초기화 프로그램에 제공하는 순서대로입니다.

제안된 크기 범위 내에 이상적인 크기를 가진 첫 번째 서브뷰를 선택합니다. 이는 선호도 순서대로 의견을 제시한다는 의미입니다. 일반적으로 이 순서는 큰 것부터 작은 것 순입니다.

그래서 부제목만 표시하는 텍스트 뷰를 추가했습니다. HStack의 뷰가 잘릴 때, ViewThatFits는 텍스트 뷰를 선택합니다.

이러한 변화들이 디자이너 마조를 기쁘게 할 거라고 확신해요.

다음으로 스택 정렬을 살펴보겠습니다. 스택은 뷰를 정렬이 일치하도록 배치합니다. 기본 정렬은 가운데 정렬이지만, 다른 정렬 방식을 지정할 수도 있습니다.

센터 외에도, HStack의 뷰는 상단이나 하단을 기준으로 수직 정렬될 수도 있습니다. 또한 firstTextBaseline 또는 lastTextBaseline에도 적용됩니다.

VStack의 뷰는 앞쪽 가장자리를 기준으로 수평으로 정렬될 수도 있습니다. 후연부 및 기타.

여행 컬렉션 섹션 헤더 위시리스트 앱이 완벽한 예시입니다. 기본적으로 스택은 뷰를 정렬하기 위해 가운데 정렬을 사용합니다.

하지만 여러 요소가 연속적으로 배치될 경우, 정렬이 어긋나 보이는 경우가 있습니다. 이 경우에는 모든 것을 기준선에 맞춰 정렬하는 것이 가장 좋습니다.

여기서 섹션 부제목의 하위 보기는 기본 정렬을 사용합니다. 즉, 쇼의 모든 것이 시각적 경계선 위에 떠 있다는 뜻입니다. 자막 텍스트에 의해 설정되었습니다.

HStack 정렬을 firstTextBaseline으로 변경하면 저는 자막에서 설정된 시각적 구도에 맞춰 쇼 전체를 이끌어갑니다.

이제 SwiftUI 에서 레이아웃을 만들 때 고려해야 할 몇 가지 사항을 더 공유하겠습니다.

가능한 한 명시적인 레이아웃 대신 반응형 레이아웃을 사용하십시오. 반응형 레이아웃을 사용하면 다양한 기기 크기에 더 쉽게 적응할 수 있습니다. 창 크기 및 플랫폼.

뷰 프레임을 명시적으로 조작하는 대신 명시적인 높이를 사용하십시오. 그리고 뷰의 너비입니다. 그것들이 이용 가능한 공간을 채울 만큼 자라도록 하십시오.

프레임이나 위치와 같은 뷰 수정자만 사용하십시오. 원하는 레이아웃을 적응형의 유연한 방식으로 구현할 수 없을 때.

Zstack과 유사합니다. 뷰에 깊이를 더하려면 다음을 사용하세요. 배경 또는 오버레이 수정자를 사용할 수 있습니다.

오버레이 및 배경 수정자는 레이아웃 크기 조정에 포함되지 않습니다. 그리고 항상 수정하는 뷰와 동일한 크기를 유지합니다.

이것이 바로 레이아웃 트리 순회 예제에서, 이전에는 활동 오버레이가 레이아웃 계산에 포함되지 않았습니다. 컨테이너 뷰의 계산된 크기를 상속받았습니다. 기본 이미지 보기입니다.

레이아웃 문제는 발생할 수 있습니다. 나는 여전히 가끔 그들을 만난다. 이제 제가 식별에 사용하는 몇 가지 기술을 공유하겠습니다. 그리고 레이아웃 문제를 수정합니다.

이러한 도구들 중 상당수는 신속한 프로토타이핑을 위한 SwiftUI 의 강력한 기능을 기반으로 합니다. 약간의 수정만 하면 결과가 즉시 나타납니다.

간단한 기법 중 하나는 이미지에 빨간색과 같은 색깔 테두리를 추가하는 것입니다. 그리고 제가 여기 여행표에서 한 것처럼 글자를 파란색으로 하세요.

이 기법은 스택 레이아웃을 이해하는 데 특히 유용합니다. 그리고 뷰 주변에 여백을 추가합니다. 때때로 임시 경계선이 겹치기도 합니다. 그리고 하위 뷰의 크기와 위치를 더 명확하게 표현하고 싶습니다. 이 경우에는 반투명 색상의 오버레이 수정자를 사용합니다. 하위 뷰의 전체 범위와 그것들이 어떻게 겹쳐지는지를 드러내기 위해서입니다.

뷰가 렌더링될 때 속성 값을 출력하는 것도 유용할 수 있습니다.

print 함수를 사용해 보셨지만 컴파일 오류 때문에 실망하셨을 수도 있습니다.

여기서 오류 메시지는 "빌드 표현식을 사용할 수 없습니다"라고 표시됩니다. 이 표현은 견해와 일치하지 않습니다.

이 오류는 Swift 의 print 표현식에 반환 값이 없기 때문에 발생합니다.

따라서 반환 타입은 void입니다. 그리고 공허는 관점이 아닙니다. 하지만 뷰의 본문에서는 변수 선언을 지원합니다.

자리 표시자 변수를 선언하면 이 오류를 해결할 수 있습니다. 이제 등호 오른쪽에 출력 표현식을 쓸 수 있습니다. 이 코드는 오류 없이 컴파일되고 실행 시 콘솔에 출력을 출력합니다.

다음으로 Xcode 미리보기 캔버스를 미리 보여줍니다. Xcode 어떤 뷰가 어떤 코드와 연결되는지 빠르게 확인할 수 있는 도구입니다. 캔버스 하단에 있는 마우스 포인터 아이콘을 클릭하세요. 미리보기를 선택할 수 있도록 하기 위해서입니다. 그런 다음 편집기에서 코드를 선택하면, 미리보기에서는 관련 뷰가 강조 표시되며, 미리보기에서 뷰를 선택하면 Xcode 편집기에서 해당 코드를 선택합니다.

내 도구 상자에서 가장 강력한 도구 레이아웃 문제를 디버깅하려면 Xcode의 뷰 디버거를 사용하면 됩니다. 앱을 실행한 다음 뷰 디버거를 사용하여 중지하면, 모든 뷰를 펼쳐본 다음, 개별 하위 뷰를 선택하여 집중할 수 있습니다. 이 기술은 SwiftUI 와 UIKit 함께 사용할 때 특히 효과적입니다. 이제 중요한 점을 말씀드리겠습니다.

SwiftUI James처럼 UIKit 레이아웃과 호환됩니다. AllTrails의 Graham이 나중에 공유해 줄 것입니다. 더 자세한 내용을 알아보려면 WWDC 22 영상을 확인하세요. UIKit 과 함께 SwiftUI 사용하세요.

SwiftUI 레이아웃의 기본 사항을 설명드렸으니, 이제 다음 단계로 넘어가겠습니다. 이제 이러한 개념들을 실천에 옮길 때입니다.

가장 좋은 학습 방법은 직접 만들어보는 것입니다. 저는 마음에 드는 앱에서 화면 하나를 골라 SwiftUI 로 다시 만들어보는 것부터 시작했습니다.

Xcode 미리보기는 다양한 레이아웃을 빠르게 시험해 볼 수 있는 좋은 방법입니다. 그리고 접근 방식.

인쇄와 같은 간단한 기술을 사용하세요 또한 색상 오버레이를 사용하여 레이아웃 문제를 진단할 수 있습니다. 문제를 얼마나 빨리 파악하고 해결할 수 있는지 놀라실 겁니다.

오늘 함께해 주셔서 감사합니다. 자, 이제 SwiftUI 사용해서 특별한 것을 만들어보고 남은 시간도 즐겨보세요.

정말 멋졌어, 캣. 레이아웃 경험을 늘리는 방법에 대한 팁이 정말 마음에 들어요. 기존 뷰를 재현하려고 시도 중입니다. 여러 가지를 시도해보고 머릿속으로 자신만의 모델을 만들어보세요. 다음으로, 제 동료 커트가 SwiftUI 에서의 모션 구현에 대한 자세한 내용을 설명할 예정입니다. 커트를 무대 위로 환영해 주시기 바랍니다.

고마워, 리아.

안녕하세요, 저는 커트입니다. 저는 기술 전도사입니다. 전 세계 개발자 관계 팀에서, 오늘 여러분과 함께하게 되어 정말 기쁩니다. 온라인에 접속하신 모든 분들을 환영합니다. 개발자 관계 부서에 합류하기 전에, 저는 SwiftUI 엔지니어로 근무하면서 내비게이션 개발에 집중했습니다. 그리고 API 설계.

오늘은 움직임을 도입하기 위한 기초적인 내용에 대해 이야기하겠습니다. SwiftUI 사용하는 앱에서.

기기의 성능이 향상됨에 따라 인터페이스도 더욱 역동적으로 발전해 왔습니다. 이러한 움직임은 제대로 구현될 경우 기기를 더욱 생동감 있고 개인적인 느낌으로 만들어줍니다. 모션 기능을 통해 앱과 플랫폼을 더 쉽게 이해할 수 있습니다. 맥락을 제공하고 사람들의 관심을 유도합니다. 게다가, 그건 정말 재밌잖아요.

이러한 역동적인 상호작용을 만들어내는 데에는 여러 가지 요소가 복합적으로 작용합니다. 사람들이 한 관점에서 다른 관점으로 넘어가는 전환점이 있습니다. 설정 앱에서 특정 보기로 이동하는 것과 같은 방식입니다. 또는 집중해야 할 사항들을 정리한 자료를 제시하는 것 그리고 사람들이 기기와 직접 상호작용하는 제스처, 지도를 확대해서 더 자세한 내용을 보거나 앱 사이를 스와이프하는 것과 같은 동작들입니다.

마지막으로 화면상의 객체가 움직이거나 커지는 애니메이션이 있습니다. 또는 Dynamic Island 의 실시간 활동과 같은 시각적 속성을 변경합니다. 이 모든 요소들이 함께 작용하여 유연하고 상호작용적인 인터페이스를 만들어냅니다.

SwiftUI 는 앱에 부드러운 움직임을 구현하는 가장 좋은 방법입니다.

SwiftUI 의 모션 기능은 매우 다양합니다. 가장 간단하게는 자동 번역 전환 기능을 사용할 수 있습니다. SwiftUI 에 내장된 컴포넌트만 사용하면 됩니다.

상태 기반 애니메이션으로 한 단계 더 나아가세요. 애니메이션을 직접 선택할 수 있습니다. SwiftUI 애니메이션 방법을 알려주는 수정자 메뉴 중에서 선택할 수 있습니다. 특정 속성이 변경될 때,

또는 사용자가 직접 지정하는 완전히 맞춤형 애니메이션을 사용해 보세요. 프레임별로 정확히 어떤 일이 일어나야 하는지.

오늘은 이 스펙트럼 전반에 걸친 사례들을 살펴보겠습니다. 그러면 적절한 도구를 선택할 수 있습니다. 앱에 적합한 역동적인 동영상 환경을 구축합니다.

SwiftUI 많은 뷰는 부드러운 모션 효과를 자동으로 제공합니다. 위시리스트 앱에서 몇 가지 예를 공유하겠습니다. 그리고 이러한 자동 효과를 조정하는 방법을 보여드리겠습니다. 앱에서 원하는 느낌을 불러일으키기 위해서입니다. 다음으로는 상태 기반 애니메이션을 추가하는 방법에 대해 설명하겠습니다. SwiftUI 수정자와 속성을 사용하여 앱에 적용하세요. 이 애니메이션들의 기본 원리를 설명드리겠습니다. 그래서 여러분은 당면한 과제에 맞는 올바른 기술을 선택할 수 있게 됩니다. 마지막으로 SwiftUI 에서 사용자 지정 애니메이션의 강력한 기능을 보여드리겠습니다. 더 자세히 알아볼 수 있는 자료들을 알려드리겠습니다.

SwiftUI 에서 내장 뷰를 사용할 때, 다양한 모션 효과가 자동으로 적용됩니다.

이 위시리스트 앱은 NavigationStack 푸시 기능의 강력한 효과를 보여주는 훌륭한 예입니다. 누군가가 여행 썸네일을 탭했을 때. 체크 표시와 같은 기호는 상호 작용을 나타냅니다. 세부 정보가 썸네일 이미지에 다시 나타나고, 시트가 애니메이션 효과와 함께 화면에 표시됩니다. 팝업 메뉴는 Liquid Glass 버튼에서 변형되어 나타납니다. 스크롤 뷰는 사용자가 스와이프할 때 자동으로 가속되고 스와이프할 때 자동으로 감속됩니다. 사용자가 스와이핑을 멈출 때, 선택적으로 특정 화면에서 멈출 수 있습니다.

SwiftUI 사용할 수 있는 네 가지 뷰에 대해 설명하겠습니다. 이러한 모션 효과를 자동으로 얻기 위해서입니다. 이와 같은 내비게이션 스택부터 시작해 보겠습니다. 여행 세부 정보가 표시되는 위시리스트 탭에서 확인할 수 있습니다.

위시리스트 앱은 각 탭 내부에 NavigationStack을 사용합니다.

이 더미 안에는 다양한 여행에 필요한 타일들이 모두 들어 있습니다. 저는 모든 여정을 순회하는 for each 루프에 집중하겠습니다. 제 가을 휴가 사진 모음처럼요.

각각의 썸네일 이미지는 탐색 링크를 통해 표시됩니다. 목적지 보기와 레이블이 표시됩니다.

레이블은 사용자가 탭하는 인터페이스의 부분입니다. 그렇게 하면 대상 뷰가 스택에 푸시됩니다. 기본적으로는 후방 가장자리에서 안쪽으로 미끄러져 들어갑니다.

뒤로 가기 버튼을 누르거나 화면을 스와이프할 때. 목적지 화면이 애니메이션 효과와 함께 사라집니다. 예를 들어 음악이나 뉴스 같은 일부 앱은 줌 전환이라는 기술을 사용하여 이러한 밀고 당기는 효과를 더욱 정교하게 다듬으세요.

NavigationStack에 확대/축소 전환 효과를 적용하는 방법은 단 세 단계입니다.

먼저 뷰의 속성에 네임스페이스를 추가합니다. 네임스페이스는 SwiftUI 사용할 수 있는 고유 식별자입니다. 다른 두 코드 조각을 연결하기 위해.

둘째, 대상 뷰에 탐색 전환 수정자를 추가합니다. zoom 매개변수에 고유 ID와 네임스페이스를 전달합니다.

마지막으로 링크 레이블에 일치 전환 소스 수정자를 추가합니다.

이제 위시리스트 앱에서 여행 사진을 탭하면 확대/축소 효과가 적용됩니다.

뒤로 돌아가면 상세 보기 화면이 축소되어 썸네일 크기로 바뀝니다.

줌 전환 효과가 아주 잘 작동합니다. 목적지가 레이블에 포함된 콘텐츠를 반복할 때, 자이언 국립공원의 이 아름다운 사진처럼요.

때로는 내비게이션 링크의 레이블이 더 자세할 수 있습니다. 위시리스트 검색 탭에서 찾은 이 제품처럼요.

여행 이름 옆에 축소판 사진이 표시됩니다. 이런 경우에는 일치하는 전환 소스를 추가하세요. 링크 레이블의 하위 뷰로 이동합니다. 다음은 SearchItemView라는 사용자 지정 뷰를 사용하여 이러한 행을 그리는 방법입니다. 이 기능은 썸네일 이미지와 여행 이름이 포함된 HStack을 사용합니다.

여기에 일치하는 전환 소스 수정자를 추가했습니다. 전체 검색 항목 보기 대신 이미지 썸네일로 이동합니다.

주변 NavigationStack에서 네임스페이스를 속성으로 전달했습니다. 이제 행을 탭하면 상세 페이지가 축소되어 미리보기 이미지가 사라집니다.

다시 돌아오면 페이지가 축소되어 썸네일 이미지로 돌아갑니다. 저는 이런 세심한 배려가 정말 마음에 들어요. 재미있기도 하고, 사람들이 처음 시작했던 줄로 시선을 돌리게 해줍니다.

오늘 다룰 두 번째 내장 뷰 유형은 시트입니다. 위시리스트 앱의 시트 코드에 대해 설명해 드리겠습니다. 위시리스트 탭의 내비게이션 스택을 다시 보여드리겠습니다. 부동산 매물을 소개하고 있습니다. 여행 일정을 추가하여 시트가 표시되는지 여부를 확인합니다. 스택 내부에는 툴바 수정자가 부착된 스크롤 뷰가 있습니다.

툴바 안에 더하기 버튼이 있습니다.

이러한 구조가 갖춰지면 자료를 제시하는 데는 단 두 단계만 거치면 됩니다. 먼저, 툴바의 버튼을 클릭하면 isPresentingAddTrip

속성이 true로 설정됩니다. 둘째로, 시트 수정자는 무엇을 표시해야 하는지 지정합니다. isPresentingAddTrip이 true일 때. 여기서 수정자는 속성에 바인딩됩니다. 달러 기호는 그런 의미입니다. 콜은 잠시 후 바인딩에 대해 더 자세히 설명할 것입니다. 하지만 지금 중요한 점은 이것이 SwiftUI 설정할 수 있도록 해준다는 것입니다. 사용자가 스프레드시트를 닫으면 isPresentingAddTrip 속성을 다시 false로 되돌립니다.

이러한 설정이 완료되면 버튼을 누르면 화면 아래쪽에서 종이가 위로 미끄러져 올라옵니다. 닫기 버튼을 누르면 다시 아래로 내려갑니다.

내비게이션에서 그랬던 것처럼, 제 3단계 프로세스를 적용하면 이것을 확대/축소 전환 효과로 바꿀 수 있습니다. 둘. 먼저 뷰의 속성에 네임스페이스를 추가합니다. 둘째, 네비게이션 전환 수정자를 추가합니다. 확대/축소 매개변수를 전달하여 시트 콘텐츠를 표시합니다.

마지막으로 버튼 레이블에 일치하는 전환 소스 수정자를 추가합니다.

이제 버튼을 누르면 시트가 그 안에서 변형되어 나타납니다.

내가 그 파일을 닫으면, 파일은 원래 모습으로 돌아갑니다. 이러한 동작은 사람들이 버튼과 시트를 연관 짓도록 도와줍니다.

SwiftUI ScrollView는 내장된 모션 효과도 제공합니다. ScrollView의 눈은 사용자가 스와이프할 때 부드럽게 감속하며 움직입니다. 그리고 콘텐츠 말미에 기분 좋은 반전이 있습니다. 위시리스트 앱에서 획득한 배지를 보여주는 ScrollView입니다. ScrollView는 사용자가 스크롤할 수 있는 콘텐츠를 보여주는 Subview를 인수로 받습니다. 여기, 제 배지를 모두 보여주는 타일들이 쌓여있네요. ScrollView는 선택적으로 무엇을 지정할지 나타내는 매개변수를 받습니다. 스크롤할 수 있는 방향입니다. 여기서는 가로 방향입니다.

위시리스트 앱의 배지에 대해, ScrollView가 항상 화면 중앙에 배지를 표시하도록 하고 싶습니다. 단 두 단계만으로 SwiftUI 이 작업을 수행하도록 지시할 수 있습니다. 먼저 SwiftUI 스크롤 대상을 알려주기 위해 스크롤 대상 동작 수정자를 추가합니다. 뷰에 맞춰 정렬되도록 중지합니다.

그런 다음 SwiftUI 에 스크롤 대상 레이아웃 수정자를 추가합니다. 어떤 뷰 스택이 이 동작에 참여하기를 원하십니까?

이제 그렇게 설정했으니, 배지를 스와이프하면 ScrollView는 항상 화면 중앙에 배지를 표시한 상태로 멈춥니다.

재밌겠네요. 이 배지들에 약간의 기발함을 더하면 재밌을 것 같아요. 화면에서 나타났다 사라지기를 반복합니다. 책이나 스포츠 앱 같은 것들이 이런 종류의 모션 효과를 사용합니다. 그들은 스크롤 전환 수정자를 사용하여 이를 구현합니다.

변형하려는 뷰에 수정자를 적용합니다. 이게 제가 달성한 목표 타일입니다.

저는 전환 과정을 상호작용적으로 만듭니다. 그래서 수동 스크롤에 반응하고 방향을 가로로 설정합니다.

수정자는 클로저를 인수로 받습니다. 전환 과정을 정의합니다. SwiftUI 콘텐츠에 대한 프록시와 애니메이션 단계를 클로저에 전달합니다.

이 단계는 전환 과정에서 마이너스 1만큼 떨어진 지점을 나타냅니다. 맨 앞쪽 가장자리에서 완전히 스크롤되어 사라졌습니다. 화면에 완전히 표시되면 0입니다. 그리고 끝부분이 완전히 스크롤되어 사라진 것에 대해 +1점을 줍니다.

이 단계를 사용하여 내용을 수정하세요.

여기서는 목표 타일이 화면 밖으로 이동할 때 크기를 줄이고 있습니다.

그리고 수직축을 따라 3D 회전을 적용합니다.

잘 보세요. 가장자리 부분이 마치 감싸듯이 보이는 게 보이시죠? 마치 회전목마의 일부인 것처럼? 그거 좋네요.

오늘 마지막으로 다룰 내장 뷰 유형은 이미지 뷰입니다. SF Symbols 와 함께.

마조가 앞서 말했듯이. SF Symbols 는 7000개 이상의 심볼을 포함하는 아이콘 라이브러리입니다. 이 화면에는 중복된 항목이 없습니다.

SF Symbols 샌프란시스코와 완벽하게 어우러지도록 설계되었습니다. 애플 플랫폼의 시스템 글꼴입니다.

Apple 개발자 웹사이트에서 다운로드할 수 있는 Mac 용 SF Symbols 앱입니다. 라이브러리를 탐색하고 사용 사례에 맞는 기호를 찾을 수 있습니다. 예를 들어, 위시리스트 앱은 활동 목록에 체크 표시를 사용합니다.

내 앱에 체크 표시를 추가하려고 합니다. SF Symbols 앱의 코드에 SwiftUI 이미지를 추가합니다. 원하는 기호를 컨트롤 클릭으로 선택합니다. 체크 표시, 원 채우기 등을 선택할 수 있습니다. 그리고 '이름 복사'를 선택하세요.

그런 다음 Xcode 에서 이미지 선언 부분에 해당 이름을 붙여넣습니다.

그리고 여기 제 체크 표시가 있습니다. SwiftUI SF Symbols 애니메이션 효과를 적용하는 여러 가지 방법을 제공합니다. 세 가지 예를 들어 설명하겠습니다.

지속적인 작업을 나타내려면 무기한 효과를 사용하십시오. 채팅에서 누군가 답장을 보내주기를 기다리는 것과 같아요. 이러한 효과는 활성화되어 있는 동안 지속적으로 지속됩니다. 예시로는 가변성, 색상, 크기 및 숨쉬기 효과 등이 있습니다.

SF 심볼에 이러한 효과 중 하나를 추가하려면, 심볼 효과 수정자를 Isactive 매개변수와 함께 사용하십시오. 이 인자 값이 참일 때마다 효과가 실행됩니다.

다운로드와 같은 이벤트를 나타낼 때는 개별적인 효과를 사용하세요. 완료 중입니다. 이러한 효과는 이벤트 발생 시 발동됩니다. 예를 들면 튀어 오르다, 맥박치다, 흔들리다 등이 있습니다. SF 심볼에 이러한 효과 중 하나를 추가하려면, 값 매개변수와 함께 심볼 효과 수정자를 사용하십시오. 이 인자 값이 변경될 때마다 효과가 실행됩니다.

심볼을 다른 심볼로 교체할 때 contentTransition 효과를 사용하세요. 예를 들어 원에 체크 표시를 할 때처럼요.

SF 심볼에 이러한 효과 중 하나를 추가하려면 다음과 같이 하세요. 심볼 효과 유형과 함께 contentTransition 수정자를 사용하십시오. 선택한 심볼이 변경될 때마다 전환 효과가 실행됩니다.

SF Symbols 앱을 사용하면 애니메이션도 시험해 볼 수 있습니다.

여기서 애니메이션 인스펙터로 전환합니다. 호흡 애니메이션을 선택하고 실행하도록 설정하세요. 재생 버튼을 눌러 테스트해 봅니다. 그다음 복사 메뉴를 사용하여 애니메이션 설정을 복사합니다.

Xcode 로 돌아가서, 제가 설정한 옵션이 포함된 수정자를 붙여넣습니다. SF Symbols 앱에서.

숨을 들이쉬고 내쉬세요.

SwiftUI 스택, 시트, 스크롤 뷰와 같은 뷰 기능을 내장하고 있습니다. 이미지에는 다양한 내장 효과가 있습니다. 앱에 맞는 효과를 더욱 세밀하게 적용하기 위해 수정자를 자동으로 추가합니다.

다음으로, 또 다른 종류의 애니메이션을 소개하겠습니다. SwiftUI 의 상태 기반 애니메이션. 제가 설명해 드리겠습니다. 앞서 리아는 SwiftUI 가 데이터를 화면의 픽셀로 어떻게 변환하는지 설명했습니다. 그리고 캣은 하나의 관점이 보여지는 예를 보여주었습니다. 또는 위시리스트 레이아웃에 따라 숨겨져 있습니다. 데이터 모델에서 속성 값에 따라 달라집니다.

이런 식으로 사용되는 데이터를 뷰의 상태라고 합니다.

다음은 위시리스트 앱의 예시입니다. 이 화면은 여행 상세 정보 화면으로, 하단에는 제가 계획한 활동 목록이 있습니다. 이 이미지 위에는 백분율을 나타내는 텍스트가 떠 있습니다. 제가 완료한 활동들, 게다가 완료할수록 채워지는 진행률 표시줄도 있습니다.

활동을 완료 표시하면, SwiftUI 해당 액티비티가 완료되었음을 기록하기 위해 관련 상태를 업데이트합니다. 이 상태에 의존하는 뷰는 자동으로 업데이트됩니다. 상태가 변할 때.

현재로서는 활동을 완료 표시하면 모든 변경 사항이 즉시 적용됩니다. SwiftUI 에게 애니메이션 효과를 적용하도록 하겠습니다. 애니메이션 기능을 사용하여 그렇게 하세요. 방법은 다음과 같습니다. 다음은 해당 버튼을 표시하는 코드입니다. 이는 여행 상세 페이지에 있는 활동을 나타냅니다.

이 버튼을 누르면 완료 상태가 전환됩니다. 관련 활동의 일부입니다.

이 토글 동작을 애니메이션 함수로 감쌌습니다. 이는 SwiftUI 발생하는 모든 뷰 업데이트에 애니메이션 효과를 적용하도록 지시합니다. 래핑된 상태가 변경된 결과입니다. 업데이트 내용을 다시 한번 알려드립니다. 이제 제가 활동을 완료하면, 백분율 텍스트가 막대 채우기 및 활동 색상과 함께 서서히 사라집니다. 그리고 체크 표시 크로스페이드.

이러한 변화를 애니메이션으로 표현하기 위해 애니메이션을 추가했습니다. 나머지는 자동으로 진행됩니다.

애니메이션의 힘은 바로 그 단순함에 있다. 상태 변화를 함수로 감싸기만 하면 됩니다. 그리고 그 상태에 따라 달라지는 여러분의 견해의 모든 속성 그리고 애니메이션으로 제작될 수 있습니다. 반면에 앱의 일부 기능에는 보다 정밀한 접근 방식이 필요할 수 있습니다.

그것을 설명하기 위해, 저는 집중하겠습니다. 위시리스트 앱의 완료 표시 오버레이에만 해당됩니다.

앱에서 이 세 가지 보기에는 텍스트 완료율이 표시됩니다. 진행률 표시줄과 부제목은 사용자 지정 ActivityProgressView에 포함되어 있습니다.

스타일링 수정자 몇 가지와 부제목은 생략하고 핵심에 집중하겠습니다. 애니메이션에 대해. ActivityProgressView는 완료를 받습니다. 0에서 1 사이의 값을 가지는 속성값으로, 완료율을 나타냅니다.

서식이 적용된 텍스트 보기에서 완료율이 표시됩니다.

이 투명도 수정자는 완료 값이 0일 때 텍스트를 숨깁니다.

저는 연두색 막대에 둥근 직사각형을 사용합니다.

막대의 너비는 상수 막대를 곱하여 설정됩니다. 완료 값에 따른 너비,

그리고 다시 말해, 불투명도 수정자는 뷰를 숨깁니다. 완료 값이 0일 때.

이제 위시리스트 콜의 디자인이 공개되었습니다. ActivityProgressView가 사용되는 모든 곳에서 애니메이션을 적용하기 위한 것입니다. 애니메이션 수정자를 사용하면 됩니다.

이 VStack에 애니메이션 수정자를 적용하면, SwiftUI 특정 시점이 지날 때마다 이러한 뷰들을 애니메이션화하도록 지시합니다. 완료 시 값이 변경됩니다.

지금까지의 작동 방식은 다음과 같습니다. 제가 애니메이션 기능을 사용해서 얻었던 것과 완전히 똑같은 애니메이션입니다.

애니메이션 수정자는 애니메이션을 사용하는 대신 사용할 수 있는 대안입니다. 상태가 변하는 시점. 애니메이션은 무언가를 원할 때 좋은 선택입니다. 하지만 모든 상태 변화 원인이 애니메이션을 트리거하는 것은 아닙니다.

반면에 애니메이션 수정자를 사용하세요. 뷰가 상태의 출처와 관계없이 항상 애니메이션되도록 하려면 이 방법을 사용합니다. 애니메이션을 사용하여 둘 다 변경하세요. 애니메이션 수정자를 사용하면 애니메이션의 타이밍을 변경할 수 있습니다. 속도, 가속도 및 반발력. 이 기능을 사용하여 애니메이션의 느낌을 더욱 세밀하게 제어할 수 있습니다.

예를 들어, 막대가 살짝 흔들리면 축하 분위기를 더할 수 있을 것입니다. 증가할 때 그렇게 할 수 있습니다. 애니메이션 수정자에 bouncy를 전달하면 됩니다. 그 모습은 다음과 같습니다. 녹색 막대가 새로운 값으로 안정되기 전에 약간 흔들립니다.

탄력을 더할 수도 있어요.

이제 무슨 일이 일어나는지 확인해 보세요. 이 바는 활기 넘치는 분위기를 가지고 있습니다. 뭔가 텍스트에 오류가 있는 것 같아요. 그럼 다시 실행하고 애니메이션 도중에 멈추겠습니다.

제 애니메이션이 너무 탄력적이어서 목표값을 훌쩍 지나쳐 버렸어요. 그러다가 원래 위치로 되돌아간 후 마침내 정착합니다. 그리고 숫자로 보면, 이 후퇴는 너무 멀어서 숫자가 점점 희미해지기 시작합니다. 원래 값으로 되돌립니다. 이 문제는 두 번째 애니메이션 수정자를 추가함으로써 해결할 수 있습니다.

텍스트 뷰에만 부드러운 애니메이션을 추가합니다.

이제 탄력 있는 애니메이션이 VStack 전체에 적용됩니다. 하지만 저는 텍스트에 대해서만 해당 애니메이션을 무시합니다. 하위 보기.

이제 숫자 관련 오류는 사라졌습니다. 막대 그래프는 튕기지만, 숫자는 부드럽게 사라집니다.

이제 그 문제는 해결됐으니, 분위기를 좀 풀어야겠네요. 텍스트에 모션 효과를 하나 더 추가합니다.

숫자 텍스트 인수를 사용하는 contentTransition 수정자는 SwiftUI 다음과 같이 알려줍니다. 숫자가 변경될 때 특별한 카운터 애니메이션을 사용합니다. 이제 숫자가 순서대로 나열되면서 변화가 눈에 띕니다.

저거 정말 좋아해요.

요약하자면, SwiftUI 뷰는 데이터를 픽셀로 매핑합니다. 상태 기반 애니메이션을 사용하면 동작을 제어할 수 있습니다. 픽셀이 데이터 또는 상태 변화의 결과로 업데이트될 때.

해당 애니메이션이 어떻게 동작해야 하는지 지정하려면 래핑 방식을 사용하세요. 너비 애니메이션 기능의 실제 상태 변화, 또는 뷰에 애니메이션 수정자를 추가하여도 됩니다. 자, 다음으로 넘어가기 전에, 제가 사용하는 선택적 매개변수에 대해 간단히 설명드리겠습니다. 막대 애니메이션의 탄력성을 조절합니다. 이 선택적 매개변수는 애니메이션의 타이밍을 제어합니다. 제 말은 이렇습니다. 저는 막대에 통통 튀는 애니메이션 효과를 사용합니다. 애니메이션이 목적지를 지나쳐 버린 후 다시 되돌아옵니다. 내장된 애니메이션 중 가장 장난스러운 애니메이션입니다.

시간에 따른 값의 그래프에서. 값이 최종 수준에 도달하기 전에 과도하게 상승합니다.

반면, 빠른 애니메이션은 최종 값에 빠르게 도달합니다. 정밀함과 전문성을 느끼게 해줍니다.

그래프는 값이 최종 수준에 도달하는 지점에서 뚜렷한 변곡점을 보여줍니다.

부드러운 애니메이션은 탄력성과 경쾌함 사이의 적절한 균형을 이루고 있습니다. 빠르게 안정되지만, 빠른 애니메이션보다는 좀 더 자연스러운 느낌입니다.

곡선이 더 완만하고 최종 높이에 더 천천히 접근합니다. Smooth는 다용도로 활용하기 좋은 애니메이션입니다. 사실, 이는 애플의 모든 플랫폼에서 기본 설정입니다.

마지막으로, 스프링 애니메이션을 사용하여 스프링의 모든 속성을 사용자 지정할 수 있습니다. 이를 통해 세밀한 제어가 가능합니다. 애니메이션의 탄력성을 조절하려면 바운스 값을 조정하세요. 0.6의 반등에서 값은 여러 번 진동합니다. 마침내 정착하기 전까지. 스프링의 길이도 조절할 수 있습니다. 그리고 다른 스프링 기반 애니메이션과의 상호 작용 방식까지도 살펴봅니다.

일반적으로, 이름이 붙은 스프링 중 하나는 탄력 있고 톡톡 튀는 성질을 가지고 있습니다. 또는 매끄럽다는 표현이 적절할 것입니다. 하지만 필요할 때 통제할 수 있다는 걸 아는 건 좋은 일이죠. 애니메이션과 SwiftUI 내부 작동 방식에 대한 자세한 내용은 다음을 참조하세요. SwiftUI 애니메이션 탐색 기능을 확인해 보세요. 그다음 기술적인 부분을 위해 스프링을 이용한 애니메이션으로 넘어가세요. 애니메이션 타이밍에 대한 디자인 지침.

두 영상 모두 W 23에서 가져온 것입니다.

위시리스트 앱이 SwiftUI의 내장 뷰를 어떻게 활용하는지 공유했습니다. 아름다운 모션 효과를 자동으로 얻으려면, 또한 앱이 상태 기반 애니메이션을 사용하여 완성도를 높이는 방법에 대해서도 설명합니다.

SwiftUI 로 만든 사용자 지정 효과 몇 가지 예시를 보여드리면서 마무리하겠습니다.

이러한 예시들은 현재 위시리스트 앱에 포함되어 있지 않습니다. 하지만 어떻게 추가할 수 있는지 설명해 드리겠습니다. 이런 식으로 실험해 보는 것은 감을 잡는 데 아주 좋은 방법입니다. SwiftUI 에서 가능한 것들을 보여드리겠습니다. 첫 번째 예시는 튀는 공입니다. 이것은 로딩 표시기 역할을 할 수 있습니다. PhaseAnimator를 사용하여 이를 구현하십시오.

이 애니메이션은 네 단계로 구성되어 있습니다. 먼저, 새해맞이 공이 떨어집니다. 그러고 나서 찌그러집니다. 그건 전문 용어예요.

공이 다시 팽창한 다음 위로 올라갑니다.

이 주기는 반복됩니다. 열거형은 단계를 정의하는 데 아주 좋은 방법입니다. PhaseAnimator의 경우, 이 예시에서는 떨어뜨리고, 찌그러뜨리고, 확장하고, 솟아오르게 합니다. 그런 다음 애니메이션을 적용하려는 각 속성에 대한 속성을 추가합니다. 이 예시에서는 먼저 속성에 y 오프셋을 추가합니다. 각 단계가 끝날 때 값을 반환합니다. 오르막길 끝에서, 공은 원래 위치보다 40점 더 높습니다. 스퀴시가 끝날 무렵, 공의 점수는 5점 낮아집니다.

나머지 두 단계가 끝나면 공은 원래 위치로 돌아옵니다. 다음으로, 공의 크기를 나타내는 속성을 추가합니다.

공을 눌렀을 때, 평소 모양보다 폭은 약간 넓고 길이는 약간 짧아집니다.

그렇지 않으면 단계를 정의한 후 라운드가 됩니다. 뷰에 PhaseAnimator를 추가합니다.

열거형을 일치시켜 애니메이터가 모든 단계를 순회하도록 하세요. CaseIterable을 생성하고 모든 케이스를 PhaseAnimator에 전달합니다.

SwiftUI 애니메이터의 첫 번째 클로저를 호출합니다. 각 단계를 차례로 통과합니다. 그러니 떨어지고, 줄어들고, 늘어나고, 올라가세요. 다음으로, 여기에 애니메이션 뷰를 그리세요. 그게 바로 순환 구조입니다. 그런 다음 해당 단계의 인수를 읽어 수정자를 적용합니다. 여기서는 위상 y 오프셋 값만큼 오프셋을 적용합니다.

그리고 위상 스케일 값으로 스케일링합니다.

마지막으로 두 번째 폐쇄에서, 각 단계에서 사용할 애니메이션을 정의합니다. 여기서는 드롭 및 확장 애니메이션에 이징(ease)을 사용하고 있습니다. 이것들은 시작은 느리고 끝은 빠릅니다. 그리고 저는 찌그러짐과 팽창에 Ease Out을 사용하고 있습니다. SwiftUI 에서 단계 애니메이션을 만드는 네 가지 단계는 다음과 같습니다. 각 애니메이션 속성에 대한 단계를 정의합니다. 각 단계가 끝날 때 값을 정의하십시오. 애니메이션 효과를 적용하여 원하는 장면을 그려보세요. 마지막으로, 각 단계별 애니메이션을 지정하세요.

위상 애니메이터에 대해 더 자세히 알아보려면 다음을 참조하세요. 고급 애니메이션을 통해 이야기를 펼쳐보세요. WWDC23에서 소개된 SwiftUI 입니다. 두 번째로 공유할 커스텀 효과는 전환 효과입니다. 위시리스트에서 배지를 획득한 사람을 축하하기 위해.

이 효과는 멋지지만 너무 빨리 끝나서 다시 재생해야겠어요.

SwiftUI 뷰를 추가하거나 제거할 때 전환 효과를 적용할 수 있습니다. 또는 하나를 다른 것으로 교체하십시오.

이 배지 전환에는 두 가지 주요 단계가 있습니다. 먼저, 하나의 뷰를 다른 뷰로 바꾸는 코드를 작성하세요. 여기서는 배지의 흑백 버전부터 시작하겠습니다. 그런 다음 컬러 버전으로 교체하세요.

전후 이미지를 담을 그룹을 만드세요. if 문을 사용하여 컬러 이미지를 표시하세요. 배지를 획득했거나 흑백 복사본을 받은 경우. 그렇지 않으면, 이제 설정이 true로 변경되면 회색 배지가 대체됩니다. 색깔 있는 걸로요.

두 번째 단계는 이 교체 과정을 애니메이션으로 구현하는 것입니다. 이렇게 하려면 그룹에 전환 수정자를 추가하세요. 이는 SwiftUI 모션 효과를 적용하도록 지시합니다. 그룹 내부의 뷰가 서로 바뀔 때. 여기에 사용할 수 있는 내장 전환 효과가 몇 가지 있습니다. 불투명도나 크기 조절처럼요. 하지만 배지가 뒤집히도록 하려면 사용자 지정 전환 효과를 사용해야 합니다.

규격에 맞는 구조체를 선언하여 사용자 지정 전환을 생성하세요. 전환 프로토콜로 이동합니다.

전환 프로토콜에는 본문 메서드라는 단 하나의 요구 사항만 있습니다. 제가 이전에 공유했던 스크롤 전환 수정자처럼요. 사용자 지정 전환의 본문은 콘텐츠 매개변수를 받습니다. 이는 추가되거나 제거되는 뷰에 대한 프록시입니다. 본문에는 뷰가 표시되는지 여부를 알려주는 단계도 있습니다. 혹은 사라지는 것.

신체 내부에서 효과를 발휘합니다. 해당 단계를 조건으로 사용하여 콘텐츠 프록시에 전달합니다. 해당 위상은 항등 속성을 가지고 있습니다. 그 말은 풍경이 보일 때 맞는 말입니다. 배지를 뒤집으려면, 위상이 동일할 때 회전 없이 3D 회전 효과를 적용합니다.

그렇지 않으면 180도 양수 또는 음수입니다. 뷰가 나타나는지 사라지는지에 따라 다릅니다.

화면 전환 중에 배지를 점진적으로 숨기거나 표시하려면 불투명도 수정자를 적용하세요.

사용자 지정 전환이 정의되었습니다. 해당 인스턴스를 전환 수정자에 전달합니다.

이제 애니메이션 블록이 있는 A 내부에서 토글이 발생하면, 회색 배지가 애니메이션 효과와 함께 사라집니다. 그리고 색상이 있는 배지는 사용자 지정 플립 전환 효과를 사용하여 애니메이션으로 나타납니다.

앱에서 사용자 지정 모션 효과를 만드는 방법에 대해 자세히 알아보려면 다음을 참조하세요. 이 영상을 추천합니다. 웹24에서 SwiftUI 사용하여 사용자 지정 시각 효과를 만들어 보세요. 디자인 가이드도 참고하세요. 휴먼 인터페이스 가이드라인 의 모션 섹션을 확인해 보세요. 개발자)에서 모션 효과를 어디에 사용할지 고려해 보세요. 앱에서 SwiftUI 사용하세요. 내장된 보기 및 제어 기능을 통해 다양한 모션 효과를 사용할 수 있습니다. 앱에 맞는 효과를 더욱 세밀하게 적용하기 위해 수정자를 자동으로 추가합니다.

상태 기반 애니메이션을 사용하여 이벤트에 반응하도록 하세요. 그리고 사람들의 관심을 중요한 것에 집중하도록 이끌어줍니다. 엄선된 맞춤 애니메이션 세트로 앱을 차별화하세요.

SwiftUI 의 모션 효과에 대한 이번 투어에 함께해 주셔서 감사합니다. SwiftUI 사용하여 무엇이 가능한지 이해하는 데 도움이 되었기를 바랍니다. 자, 이제 빅서 무대에 다시 돌아온 리아를 환영해 주세요.

정말 멋졌어요! SwiftUI 덕분에 개성을 쉽게 표현할 수 있다는 점이 정말 좋네요. 모션을 통해 앱에 연결합니다. 저는 초록색의 통통 튀는 얼굴 애니메이션이 정말 마음에 들었어요. 정말 멋졌어요. 잠시 점심 식사를 위해 휴식을 취하겠습니다. 그러니 잠시 시간을 내어 다과를 즐기세요. 질문을 하거나 새로운 사람을 만나보세요. 오후 일정이 꽉 차 있습니다. 그럼 12시 15분 태평양 표준시에서 다시 만나요.

휴식 시간을 잘 보내셨고 질문할 기회도 가지셨기를 바랍니다. 혹은 새로운 사람을 만나고 싶으시다면, 즐겁고 알찬 오후를 보내실 수 있도록 준비했습니다. 다음으로, 제 동료 콜이 SwiftUI Dataflow에 대한 자세한 내용을 설명해 드리겠습니다. 그럼, 무대 위로 모실 분을 함께 환영해 주시기 바랍니다.

안녕하세요 여러분. 제 이름은 콜이고, Apple 에서 핵심 기술 전도사로 일하고 있습니다. 오늘은 앱의 데이터에 대해 이야기해 보겠습니다. 그리고 SwiftUI 뷰로 어떻게 전달하는지 알아보겠습니다. 위시리스트 앱은 제가 하루 종일 사용하는 훌륭한 예시입니다. 데이터를 접할 수 있는 몇 가지 방법을 보여드리겠습니다. SwiftUI 앱의 흐름.

위시리스트 앱도 비슷한 기능을 많이 제공합니다. 앱에 필요할 수 있는 데이터를 포함하고 있습니다. 또한, 데이터 유형에 따라 접근 방식이 달라집니다.

가장 중요한 몇 가지부터 설명드리겠습니다. 특정 장소들이 있습니다 이 앱에서는 인터페이스 상태가 변경됩니다. 누군가가 그것과 상호작용할 때. 예를 들어, 누군가가 여행 일정을 변경할 때, 앱은 사용자 인터페이스가 편집 모드인지 아닌지를 추적해야 합니다.

이런 상황이 발생할 수 있는 곳은 몇 군데 있습니다. 버튼을 누른 후 시트가 표시되는 시점을 추적하는 것과 같은 것 말입니다. 또는 경고 메시지를 표시해야 할 때. 저는 일반적으로 이러한 사례들을 뷰스테이트(Viewstate)라고 부르겠습니다.

이 앱에는 데이터 모델도 있습니다.

위시리스트 앱의 목표는 다음과 같습니다. 제가 다녀온 멋진 여행과 활동에서 얻은 풍부한 데이터를 모두 보여드리고 싶습니다. 예를 들어, 이번 교토 여행은 즐길 거리가 풍부하다는 것을 보여줍니다. 그곳에 있는 동안 사원을 탐험하는 것과 같은 경험을 할 수 있습니다. 해돋이 시간에 운하 산책로를 걷는 것 등. 그래서 앱에서 이 데이터를 모델링해야 합니다. 그리고 그 내용을 제 모든 SwiftUI 뷰에 반영합니다.

앱은 사용자가 설정한 선호 사항도 추적해야 합니다. 앱에서. 예를 들면, 앱에는 여행 일정 목록에 정렬 ​​버튼이 있습니다. 제목, 날짜 또는 활동 완료 여부별로 정렬할 수 있습니다. 앱은 사용자가 마지막으로 선택한 정렬 방식을 추적해야 합니다. 그러면 다음에 이 화면이 표시될 때 동일한 정렬 방식을 사용하게 됩니다.

그리고 마지막으로, 저는 앱을 만들고 싶습니다. 죄송합니다. 저는 지속성을 위한 접근 방식을 구축하고 싶습니다. 지속성은 앱이 데이터를 저장할 수 있도록 하는 접근 방식입니다. 기기의 저장소에 파일처럼 저장됩니다. 그러면 다음에 누군가가 앱에 다시 접속했을 때, 앱이 재출시되더라도 모든 변경 사항은 그대로 유지됩니다.

이번 시간에는 이러한 사용 사례들을 각각 자세히 살펴보겠습니다. 자세히 설명드리겠습니다. 여기에는 뷰 상태에 대한 데이터가 포함됩니다. 풍부한 데이터 모델 구축, 환경 설정 및 구성 처리 그리고 지속성을 위한 몇 가지 기법.

이번 회기가 끝날 때쯤에는, 여러분은 이러한 각 사용 사례에 대해 논리적으로 추론할 수 있는 능력을 갖추게 될 것입니다. 그러면 여러분은 따라할 수 있는 패턴을 알게 될 것입니다. 여러분의 앱에서도 비슷한 요구 사항을 해결하기 위해서입니다. 먼저 Viewstate부터 시작하겠습니다.

앞서 말씀드렸듯이, 앱은 때때로 단순히 데이터 조각을 생성해야 할 때가 있습니다. 인터페이스 자체의 상태를 추적하기 위해서입니다. 이러한 현상은 대개 일시적이며, 뷰가 사라지면 안전하게 재설정할 수 있습니다. 예를 들어, 샘플 앱은 여행 일정이 편집 모드인지 여부를 추적합니다. 아니면 아닐 수도 있습니다. 누군가가 이 여정에서 벗어나 다른 길로 이동한다면. 그러다가 나중에 다시 그 문제로 돌아온다. 사용자 인터페이스가 더 이상 편집 모드가 아닌 것은 당연합니다. 완료 버튼을 누르지 않았더라도요.

인터페이스에서 추적해야 하는 상태의 또 다른 예는 다음과 같습니다. 이 앱의 위시리스트 탭에서 확인할 수 있습니다. 툴바에 추가 버튼이 있습니다. 커트가 앞서 애니메이션을 다듬을 때 이 버튼에 대해 이야기했었죠. 이 버튼을 누르면 사용자가 작업을 시작할 수 있는 시트가 나타납니다. 앱에 추가할 새로운 여행의 세부 정보를 입력합니다.

따라서 앱은 상태를 추적하기 위한 데이터가 필요할 것입니다. 현재 화면에 시트가 표시되어 있는지 여부.

또한, 스프레드시트 자체에 변경 사항을 저장하거나 여행 추가를 취소하는 버튼이 있습니다. 따라서 시트 내의 해당 작업들은 상태를 업데이트하는 방법을 필요로 합니다. SwiftUI 시트를 닫도록 하기 위함입니다.

SwiftUI 에서 이 추가 버튼을 구현하는 방법은 다음과 같습니다. WishlistView 본문에 시트를 넣으면, 심볼 레이블이 있는 SwiftUI 버튼이 있습니다. 그리고 시트를 표시하기 위해 버튼 동작에 코드를 추가해야 합니다.

자료 자체를 제시하기 위해. 뷰에 추가되는 `sheet isPresented` 수정자를 사용해야 합니다.

자, 이 코드를 완성하기 전에 SwiftUI 결정을 내려야 합니다. 추적하는 데이터는 무엇입니까? 아니면 이 시트가 지금 화면에 실제로 표시되어 있는 건가요?

이건 at state API를 활용하기에 아주 좋은 사례네요. 작동 방식은 다음과 같습니다. isPresentingAddTrip이라는 새 속성을 만들겠습니다. 그리고 at 상태를 사용하여 장식하며 기본값은 false입니다.

`at` 상태를 사용하면 SwiftUI 일정 기간 동안 유지되는 새로운 데이터를 생성하게 됩니다. 이 견해가 유효한 한. 이 값의 수명에 대해서는 조금 후에 더 자세히 설명드리겠지만, 지금은 다음과 같습니다. 이제 정의를 내렸으니 뷰의 나머지 부분에서 사용할 수 있습니다. 버튼 동작에서 isPresentingAddTrip을 true로 설정하겠습니다. 버튼을 누르면 항상 시트가 나타나야 하므로, 만약 해당 스프레드시트가 이미 표시 중이라면 버튼을 비활성화하겠습니다. 상태를 disabled 한정자에 전달함으로써.

뷰 본문이 isPresentingAddTrip 값을 다음과 같이 읽기 때문에 이 점에 유의하십시오. 이 수정자에서 WishlistView는 이 값에 대한 종속성을 설정합니다. 언제든지 발표할 수 있습니다. 여행 일정 변경 사항을 추가하세요. SwiftUI 이 화면을 업데이트합니다.

또한 isPresentingAddTrip 속성을 시트 수정자에게 전달하겠습니다. 이 달러 기호 표기법을 사용하면 이 상태에 바인딩을 전달할 수 있습니다. 이 코드가 해당 값을 시트와 공유하도록 하여 둘 다 읽을 수 있도록 합니다. 그리고 그것을 수정하세요. 바인딩에 대해서는 잠시 후에 더 자세히 설명해 드리겠습니다.

부동산을 꾸미는 것 at state는 SwiftUI 이 속성이 포함하는 뷰의 소유임을 알려줍니다.

이 속성의 가치는 뷰가 존재하는 한 존재합니다.

그리고 이것은 제가 앞서 언급했던 중요한 점입니다. 상태 속성은 인터페이스에서 뷰의 수명과 일치합니다. 뷰 구조체 자체의 수명과는 무관합니다. 그럼 이게 실제로 어떻게 작동하는지 좀 더 자세히 알아볼게요. 오늘 레아가 앞서 이야기했듯이, SwiftUI 뷰는 템플릿처럼 수명이 짧은 설명일 뿐입니다. WishlistView가 인터페이스에 나타나면, SwiftUI 화면의 UI를 업데이트하기 위해 본문을 실행합니다. 하지만 그러면 해당 인스턴스가 삭제됩니다.

그리고 이 과정은 SwiftUI 뷰를 렌더링할 때마다 반복됩니다.

그렇다면 isPresentingAddTrip 속성이 왜 초기화되지 않는 걸까요? 기본값이 false이므로 이 뷰가 다시 초기화될 때마다 발생합니다.

네, 그건 SwiftUI 특별한 처리를 해주기 때문입니다. 이와 같은 국유 재산에서.

내부적으로는 SwiftUI 자체 데이터 저장소를 가지고 있습니다. 국가 소유의 모든 관점에 대해. SwiftUI 이 뷰를 처음 인스턴스화할 때, 내부 저장소에 공간을 할당합니다. 이 부동산은 다른 관점과 함께 국가가 소유한 모든 부동산과 함께 고려됩니다.

이 저장소는 뷰의 식별자로 인덱싱됩니다.

그 항등식을 대응하는 것으로 생각해 보세요. 이 뷰의 렌더링 결과가 화면에 표시되는 수명에 해당합니다. SwiftUI 뷰를 처음 렌더링할 때, 뷰에 고유한 식별자를 할당합니다. 그리고 누군가가 이 화면에서 벗어나 다른 화면으로 이동하면, SwiftUI 저장소에서 해당 항목을 삭제합니다. 만약 그들이 나중에 그 관점으로 돌아온다면, SwiftUI 새로운 식별자를 할당하고 저장소에 새 항목을 추가합니다.

자, 이제 시트를 보여주는 제 버튼이 어떻게 작동하는지 보여드리겠습니다. 누군가가 위시리스트 뷰로 처음 이동할 때 탭됩니다. SwiftUI 저장 공간을 할당합니다. 이 뷰의 isPresentingAddTrip 상태 속성에 기본값을 사용합니다. False의 값입니다.

그런 다음 구조체를 인스턴스화합니다. 또한 isPresentingAddTrip의 값을 SwiftUI 의 내부 저장소와 일치하도록 설정합니다. 그런 다음 WishlistView의 본문을 실행하여 화면에 렌더링합니다. 그런 다음

뷰 인스턴스를 버립니다. 앱 사용자가 버튼을 탭하면. 액션 클로저 실행 설정은 광고 여행을 참으로 표시합니다. 하지만 이곳은 국가 소유 재산이기 때문에, 이 과제는 SwiftUI 의 내부 저장소를 수정합니다. 뷰의 본문이 이 상태에 의존하기 때문에 SwiftUI 업데이트를 트리거합니다. isPresentingAddTrip 값을 채워 넣는 새로운 뷰 구조체를 생성합니다. 실행 전에 내부 저장소의 새로운 실제 값을 사용합니다.

SwiftUI 이러한 내부 저장소를 통해 상태를 유지합니다. 인터페이스에서 뷰가 표시되는 동안. 구조체 자체는 일시적이지만 말입니다.

네, 그럼 이 내부 저장소는 상태 속성이 SwiftUI 에 어떻게 요청되는지 설명해 드리겠습니다. 인터페이스에서 이 뷰의 수명 동안 부울 값을 추적합니다. 하지만 상태는 단일 뷰 선언 내에서만 유용한 것은 아닙니다. 또한 바인딩이라는 것을 사용하여 다른 뷰와 공유할 수도 있습니다.

시트 수정자에 있는 이 달러 기호를 사용하면 바인딩에 접근할 수 있습니다. 이것은 PresentingAddTrip 상태입니다.

바인딩이란 앱의 특정 상태에 대한 읽기/쓰기 참조를 의미합니다.

뷰를 만들 때 특히 유용합니다. 상위 뷰에서 값을 읽어오고 필요에 따라 해당 값을 변경해야 할 수도 있습니다.

바인딩은 SwiftUI 전반에서 사용됩니다. 해당 설정은 토글 버튼과 텍스트 필드의 매개변수에서 찾을 수 있습니다. 시트 수정자 등도 포함됩니다. 이것들은 해당 데이터에 의존하고 이를 수정할 수 있는 캡슐화된 제어 기능입니다. 필요할 때. 예를 들어, 다음은 여행 추가 화면의 일부입니다. 이는 시트 자체 내부의 모습입니다.

이는 바인딩을 사용하여 포함하는 뷰로부터 참조를 받습니다. 뷰 본문에 시트가 표시되는지 여부를 추적하는 상태로 이동합니다. 스프레드시트를 닫을 수 있는 버튼이 있습니다. 이를 위해 isPresented 바인딩 값을 false로 설정했습니다. 그들의 행동 마무리에서. 이로 인해 SwiftUI 해당 뷰에 의존하는 모든 뷰를 업데이트하게 됩니다. 저와 같은 주에서요. 화면을 닫으면 시트가 닫힙니다.

제가 단순히 진행 상황을 추적하고 싶은 시트 같은 곳들이요. 누군가가 인터페이스와 상호 작용할 때, 그것은 아주 적합합니다. 현재 상태입니다. 이는 뷰가 사라지면 초기화되는 임시 데이터입니다. 또는 뷰가 존재하는 동안에만 존재해야 하는 객체가 있는 경우입니다.

하지만 상태 정보는 제 데이터 모델과 같은 다른 유형의 데이터에는 가장 적합하지 않습니다. 그러한 경우에는 상태 유형을 표현하는 방법이 필요할 것입니다. 다른 코드 부분에서 소유하고 있는 SwiftUI 대해, UI 자체에서 소유하는 것이 아닙니다.

그래서 다음 사용 사례인 위시리스트의 데이터 모델에 대해 이야기해 보겠습니다. 데이터 모델은 이 앱의 핵심이자 영혼입니다. 여기에는 사람들이 앱으로 다시 돌아오도록 유도하는 데 필요한 모든 정보가 포함되어 있습니다. 예를 들어, 여행마다 이름, 사진, 활동 내역 등을 기록하고 싶어서요. 이 예시처럼, 여행 목적지의 이름은 Peru Off-Road입니다. 그리고 이와 관련된 멋진 사진이 있습니다.

이러한 객체들 사이에도 관계가 존재합니다. 예를 들어, 여행에는 여러 가지 활동과 프로그램이 포함될 수 있습니다. 이름과 같은 고유한 속성을 가지고 있습니다. 그리고 활동이 완료되었는지 여부를 추적하는 부울 값입니다.

그래서 저는 여행을 나타내기 위해 클래스를 사용하는 데이터 모델을 만들었습니다. 이 앱의 활동 및 기능.

각 클래스는 이름, 사진, 날짜와 같은 속성을 저장하는 속성을 가지고 있습니다.

또한 서로에 대한 참조를 순서대로 저장합니다. 이러한 객체들 간의 관계를 모델링하기 위해서입니다. 예를 들어, 여행 객체에는 여러 개의 활동이 연결될 수 있습니다. activities 속성에 해당 항목에 대한 참조를 저장함으로써 이를 활용할 수 있습니다.

그리고 이러한 객체들은 편집도 가능합니다. 사용자가 UI에서 이러한 속성을 변경할 수 있기 때문입니다. 예를 들어 누군가가 텍스트 필드에서 여행 이름을 수정할 때처럼요.

저는 DataSource라는 클래스도 만들었습니다. 앱 내에서 이러한 모든 객체를 관리하기 위해서입니다. 앱이 필요한 모든 객체를 찾아볼 수 있는 단일 장소입니다. 사용자 인터페이스에 표시하기 위해, 예를 들어 모든 여행 목록을 가져오는 것과 같은 기능을 합니다.

이와 같은 데이터 모델을 갖는 것은 훌륭한 출발점입니다. 하지만 SwiftUI 에서 이 데이터 모델을 제대로 사용하려면 한 가지 간단한 작업을 추가해야 합니다.

데이터 모델은 속성 변화가 언제 발생하는지 알 수 있어야 합니다. SwiftUI UI를 업데이트할 수 있도록 하기 위함입니다. 그리고 이것이 바로 Observable 매크로의 용도입니다. 이 한 줄의 코드로, SwiftUI 속성에 대한 종속성을 설정할 수 있는 권한을 부여할 수 있습니다. 수업 시간에요.

Observable 매크로는 각 클래스 속성에 업데이트 추적 기능을 추가합니다. 사용하려면 각 클래스에 `at Observable` 매크로를 추가하기만 하면 됩니다.

이제 데이터 모델이 Observable이 되었으니, SwiftUI 이제 모델 속성에 대한 종속성을 직접 설정할 수 있습니다.

이 예제에서 TripCard 뷰는 참조를 받습니다. 여행 객체에 표시되어야 합니다.

참고로, 그런 것은 없습니다. 주 또는 구속력 있는 곳에서. 사실 이 참고 자료에는 장식이 전혀 없습니다. 이 뷰가 작동하는 이유는 뷰 본문 내부에 다음과 같은 내용이 있기 때문입니다. 여행 사진의 photoURL 속성입니다. 이는 SwiftUI TripCard에 필요한 것이 무엇인지 알려줍니다. 이 Observable 클래스의 photoURL 속성이 변경될 때마다 업데이트됩니다.

그리고 이것은 계산된 속성을 통해서도 작동합니다. 예를 들어, 임시 사진을 사용하고 싶다고 가정해 보겠습니다. 아직 사진이 저장되지 않은 여행의 경우. 이를 사용자 인터페이스에서 처리하려면, Trip 객체에 photoURL 또는 placeholder라는 이름의 계산 속성을 정의할 수 있습니다. 이 계산 속성은 정의된 사진이 없는 경우 자리 표시자 사진을 반환합니다. 여행을 위해서요. 그리고 나서 새로 계산된 속성을 사용합니다. 사진 URL 대신 뷰 본문에 넣으세요.

SwiftUI 기본 속성인 photoURL이 빨간색임을 판단할 수 있습니다. 이 뷰 본문에서 계산된 속성에 접근할 때. 따라서 SwiftUI 기본 사진 URL이 변경될 때마다 TripCard를 업데이트합니다.

자, 정리하자면, 이 앱은 여행 정보를 구조화된 데이터 모델로 표현합니다. 그리고 Activity 객체입니다. 각 객체를 모델링하기 위해 참조 타입 또는 클래스를 사용합니다. 이렇게 하면 참조를 사용하여 이러한 객체 간의 관계를 모델링할 수 있습니다. 또한 이러한 속성은 사용자 인터페이스 어디에서든 쉽게 편집할 수 있습니다.

이러한 클래스의 데이터가 SwiftUI 로 전달되도록 하려면, 각 정의에 Observable 매크로를 추가하기만 하면 됩니다. 그러면 SwiftUI 뷰에서 뷰 본문의 속성을 직접 읽을 수 있습니다.

이제 제가 해야 할 일이 하나 더 남았습니다. 지금까지 보여드린 방법은 아주 잘 작동합니다. 뷰가 이미 여행(Trip)과 같은 객체에 대한 참조를 가지고 있는 경우.

앞서 말씀드렸듯이 이 모든 물건들은 다음 사람들의 소유입니다. DataSource 클래스, 하지만 뷰에서 어떤 데이터 소스 인스턴스를 사용해야 하는지 어떻게 알려줄 수 있을까요?

음, 사실 저는 이미 이 방법을 사용하는 한 가지 방법에 대해 설명드렸습니다. 그리고 그것은 주 정부 차원에서 시작됩니다. 우리가 특정 상태에서 생성할 객체는 그 객체가 존재하는 동안 계속 존재한다는 것을 기억하십시오. 뷰가 그러하듯이요. 그래서 제 앱 맨 위에는, 데이터 소스 객체를 저장하는 at 상태 속성을 만들 수 있습니다. 이 앱 선언에 상태를 넣으면 일정 기간 동안 존재하는 객체가 생성됩니다. 앱이 하는 것처럼 처리한 다음 뷰로 전달할 수 있습니다.

이 방법은 앱 내에서 매우 간단한 뷰 계층 구조를 가진 경우에는 잘 작동할 수 있습니다. 사용자 인터페이스의 여러 부분에서 데이터 소스에 접근해야 할 수 있습니다. 예를 들어, 전체 여행 목록을 보려면 그리고 매우 간단한 뷰 계층 구조를 가지고 있습니다. DataSource와 같은 객체를 그대로 전달하는 것은 전혀 문제가 없습니다. 그것을 필요로 하는 사람들에게.

하지만 앱이 복잡해짐에 따라, 이러한 접근 방식은 번거로워지기 시작할 수 있습니다. 사용 계층이 여러 겹으로 중첩된 앱은 결국 특정 조건을 충족해야 할 수도 있습니다. 데이터 소스에 대한 참조를 저장합니다. 더 깊은 관점을 필요로 하는 사람들에게 전달할 수 있도록 하기 위해서입니다.

이러한 문제를 피하려면, 이러한 사례는 해당 환경에 잘 어울릴 수 있습니다.

환경을 필수적인 속성으로 생각하십시오. 앱의 일부를 구성하는 설정이며, 자주 변경되지 않습니다.

이 경우, 저는 상태를 나타내는 데이터 소스 객체를 생성하겠습니다. 그리고 해당 객체를 뷰 환경에 설정하겠습니다. 이 설정은 데이터 소스가 필요한 뷰를 구성합니다. 이 특정 사례에서는 그렇습니다.

데이터 소스 객체 자체가 교체되지 않으므로 안전합니다. 아주 자주 발생합니다. 관찰 가능합니다. 그리고 다양한 견해들이 존재합니다. 제 앱에서 해당 항목에 대한 참조가 필요할 수도 있습니다. 따라서 데이터 소스를 환경에 배치함으로써 가능합니다. 해당 참조가 필요한 뷰는 직접 하나를 가져올 수 있습니다.

환경 설정은 해당 환경이 적용된 전체 뷰 계층 구조를 통해 흐릅니다. 어떤 관점이든 환경으로부터 가치를 얻어내야 한다는 질문만 하면 된다. 그리고 SwiftUI 그것을 제공할 것입니다. 예를 들어, 뷰 계층 구조에서 더 깊은 곳에는, RecentTripsPageView는 참조를 얻습니다. 환경 변수를 사용하여 속성을 꾸며 데이터 소스에 적용합니다. SwiftUI 이 참조의 값을 채울 것입니다. 환경에서 일치하는 유형의 객체와 함께.

DataSource는 Observable이므로, 뷰는 종속성을 설정할 수 있습니다. 뷰 본체 내부에서부터 해당 속성에 대한 정보를 얻을 수 있습니다. 여기서는 최근에 추가된 Trips 속성이 이 뷰 본문에서 읽힙니다. 따라서 최근 여행 페이지 보기는 새로운 여행이 추가될 때마다 업데이트됩니다. 여행 일정이 앱에 추가되었습니다.

그래서 Viewstate와 제 데이터 모델은 제가 필요로 하는 데이터 흐름의 상당 부분을 처리합니다. 이 앱에서는 현재까지는 이 정도지만, 다른 활용 사례도 몇 가지 더 있습니다. 약간 다른 접근 방식을 취합니다. 그럼 이제 선호도에 대해 계속 이야기해 보겠습니다. 이 앱의 설정 및 구성.

앞서 말씀드렸듯이 누군가가 여행을 탭하면, 표시되는 활동 목록을 이름순으로 정렬할 수 있습니다. 또는 완료 여부에 따라.

앱은 이 설정을 저장해야 합니다. 그래서 누군가가 이러한 견해를 갖게 될 때마다, 그들이 선호하는 정렬 방식을 사용합니다. 지금으로서는 선호도가 잘 맞지 않습니다. 앞서 설명한 데이터 모델 내부로 들어가 보겠습니다. 왜냐하면 이것은 여행 자체와는 사실상 아무런 관련이 없기 때문입니다. 사람들의 선호도를 추적하는 것입니다. 앱의 다양한 기능을 사용하기 위해서입니다.

따라서 이 정렬 기능을 구축하려면 다음과 같은 단계를 거쳐야 합니다. at state를 사용하여 새로운 상태를 정의하는 것으로 시작할 수 있습니다. 어떤 정렬 방법이 사용되고 있는지 추적하기 위해서입니다.

이 예시에서는 sortOption이라고 합니다. 그러면 액티비티 서브뷰가 sortOption을 읽게 됩니다. 활동 계획을 세울 때.

이제 제대로 작동하고, 활동들이 사용자가 선택한 순서대로 정렬됩니다. 메뉴에 있습니다.

하지만 이와 같은 상태 속성은 저장만 된다는 점을 기억하세요. 그 전망이 지속되는 동안. 그래서 누군가가 이 화면을 떠났다가 다시 돌아오면, 정렬은 항상 기본 정렬 방식인 제목순으로 되돌아갑니다. 누군가가 여행 상세 보기 화면으로 다시 돌아올 때마다 다음과 같은 메시지가 표시되도록 하고 싶습니다. 이전에 선택했던 방식 그대로 정렬되어 있습니다.

이렇게 하려면 AppStorage의 상태를 변경해야 합니다. 또한 설정에 대한 고유 식별자를 제공합니다.

AppStorage는 상태와 매우 유사하게 작동합니다. 이는 앱 전체에 적용되는 전역 상태 변수를 선언합니다. 그리고 이 방법은 간단한 Codable 유형과 함께 사용할 때 가장 효과적입니다.

AppStorage 값은 실제로 자동으로 디스크에 저장됩니다. 내부적으로는 Apple 플랫폼에서 '사용자 기본 설정'이라는 API를 사용합니다. 앱에 사용할 키와 값 집합을 저장하는 곳입니다.

그리고 이곳은 설정하기에 아주 좋은 장소입니다. 환경 설정 및 앱 구성 세부 정보.

이제 정렬 기본 설정을 앱 저장소 속성에 저장함으로써, 이제 활동 목록은 항상 사용자가 마지막으로 선택한 옵션 순으로 정렬됩니다. 다양한 여정을 탐색하는 동안에도 시야를 확보하고 있습니다.

마지막으로 오늘 논의하고 싶은 마지막 사용 사례는 영구 저장입니다.

방금 보여드린 예시에서 정렬 기본 설정을 저장했습니다. AppStorage를 사용하는 것 자체가 영구 저장소의 한 예입니다. SwiftUI 사용자 기본 설정 API를 자동으로 사용합니다. 디스크에서 이 키의 값을 얻으려면, 그런 다음 뷰의 값을 그에 맞게 설정합니다.

그리고 sortOption에 다른 값이 할당되면, AppStorage는 해당 새 값을 사용자 기본 설정에 저장합니다. 그래서 누군가가 하루 뒤에, 혹은 일주일 뒤에 다시 앱에 접속하더라도, 한 달 후에도 sortOption 속성은 그대로 유지됩니다. 바뀌기 전까지는 똑같다.

하지만 물론, 당신이 고수하고 싶은 것은 단지 선호도만이 아닐 수도 있습니다. 이 앱은 풍부한 데이터 모델을 가지고 있습니다. 사람들은 분명히 위시리스트를 며칠 동안 저장해 두고 싶어할 겁니다. 또는 몇 주 이상.

앱에서 영구 저장 기능을 갖춘 이러한 데이터 모델을 구축하려면 다음과 같이 하면 됩니다. SwiftData는 훌륭한 선택지 중 하나입니다.

SwiftData는 앱에 영구 저장 기능을 빠르게 추가할 수 있도록 해주는 프레임워크입니다. 최소한의 코드로 외부 의존성 없이 작동합니다.

이 앱은 매크로 및 속성 래퍼와 같은 최신 Swift 언어 기능을 사용합니다. 이를 통해 Swift 코드만으로 모델을 설명할 수 있습니다.

기본적으로 Core Data의 검증된 영구 저장 기능을 활용합니다. SwiftData의 기술과 모델은 모두 자동으로 관찰 가능합니다.

SwiftData에 대해 더 자세히 알아보려면 동영상을 시청하고 SwiftData를 만나보세요. SwiftData를 사용하여 앱을 구축하세요. 앞서 말씀드렸듯이 데이터 모델은 몇 가지 클래스로 구성되어 있습니다. 그리고 그것의 각 속성 그리고 서로 간의 관계는 속성으로 저장됩니다. 각 수업에 대해. 현재 이러한 클래스에는 Observable 매크로가 적용되어 있습니다.

하지만 SwiftData를 사용하여 해당 데이터를 영구 저장하고 싶다면, Observable 매크로를 model 매크로로 바꾸기만 하면 됩니다.

모델 매크로는 이러한 클래스를 SwiftData 모델로 변환합니다. 그리고 다시 말하지만, 이렇게 하면 자동으로 관찰 가능해집니다.

재미 삼아 한번 해 볼까요? 샘플 코드가 제공되면 다운로드하여 사용해 보실 수 있습니다. 그리고 이 앱을 SwiftData로 이전하기 위한 몇 가지 단계를 진행하고 있습니다. 관심 있는 분들을 위해, 코드에서 변경해야 할 몇 가지 핵심 사항을 설명해 드리겠습니다. 먼저 모델에 메타데이터를 추가해야 합니다. 앱의 뷰 내부에서 데이터를 가져오거나 쿼리하는 방식을 개선할 수 있습니다. 그리고 모델을 저장할 컨테이너를 설정하게 됩니다. 그럼 각 단계를 간단히 설명드리겠습니다.

먼저, 모델을 Observable에서 model로 전환한 후, 모델들을 차례로 살펴보게 될 겁니다. 원하는 위치에 속성에 주석을 추가하세요. SwiftData에 그들에 대한 더 많은 정보를 제공하기 위해서입니다. 예를 들어, 여행 모델에서, 활동 속성에 대한 관계를 사용할 수 있습니다. 여행과 활동 간의 관계를 정의하기 위해. 여기서는 삭제 규칙을 연쇄적으로 설정하여 여행이 삭제될 때, 해당 계정의 모든 활동 내역도 삭제됩니다.

또한 여행 속성에 대한 역관계를 "죄송합니다"로 설정했습니다. 여행 속성과 활동 간의 역관계. 즉, 이러한 활동의 ​​여행 속성은 항상 이전 위치를 가리킨다는 의미입니다. 그것이 속한 여행에.

SwiftData를 사용하면 데이터를 가져오는 것이 매우 쉬워졌습니다. 쿼리를 사용하여 뷰 내에 모델을 표시할 수 있습니다. SwiftData에 정렬된 모델 배열을 요청하기만 하면 됩니다. 원하는 방식으로 필터링할 수 있습니다.

이 코드 조각에서는 앞서 보여드렸던 RecentTripsPageView를 업데이트했습니다. 예전에는 데이터 소스 객체를 사용했습니다. 최근 추가된 여행 목록을 보려면, 하지만 SwiftData를 사용하면 Query를 바로 사용할 수 있습니다. 이 쿼리는 SwiftData에 정렬된 여행 목록 배열을 제공하도록 요청합니다. 생성일자를 기준으로 내림차순으로 정렬합니다.

뷰 본문은 최근에 추가된 여행 배열을 ForEach 루프에서 사용합니다.

SwiftData는 쿼리 결과가 변경될 경우 이 뷰를 업데이트합니다. 예를 들어 새로운 여행 일정이 보기에 추가될 때처럼요. 마지막으로 앱 선언에서, 앱을 구성할 때 모델을 저장할 컨테이너를 사용하게 됩니다. 모델 컨테이너 수정자를 추가하여 그리고 모델 유형의 이름을 전달합니다. 앱은 모델에 기본 컨테이너를 사용합니다.

그래서 이 세 가지 변화가 있습니다. 속성 메타데이터 추가. 쿼리를 다듬고 모델 컨테이너를 추가하는 것이 시작하는 데 핵심입니다. 이로써 SwiftData는 이와 같은 앱에 강력한 데이터 영구 저장 기능을 제공합니다.

자, 이제 위시리스트 앱의 데이터 흐름 사용 사례를 모두 살펴보았습니다. 그리고 여러분은 SwiftUI 앱에서도 이와 유사한 접근 방식을 취할 수 있습니다. 앱의 뷰가 간단한 UI 상태만 추적하면 되는 경우, 마치 버튼을 눌렀을 때처럼요. 상태를 사용한 다음 바인딩을 사용하여 다른 뷰에서 사용할 수 있도록 합니다. 또는 제어 장치들이 해당 상태의 일부를 공유합니다. 풍부한 데이터 모델을 구축할 때 Observable 매크로를 사용하는 것을 고려해 보세요. 클래스와 같은 참조 유형을 사용합니다.

데이터를 저장하고 싶을 때. 그러니 데이터를 저장 장치에 저장하여 영구적으로 보관하세요. AppStorage는 설정 및 환경설정과 같은 작은 파일들을 저장하는 데 사용하세요. 모델 데이터에는 SwiftData 프레임워크를 사용하는 것을 고려해 보세요. 시간 내주셔서 감사합니다. 남은 행사도 즐겁게 보내시길 바랍니다. 그리고 리아 얘기로 돌아가서. 네.

정말 멋졌어요. 시간을 내는 건 정말 중요해요. 데이터 흐름의 기본 원리와 각 도구를 언제 사용해야 하는지 배우기 위해서입니다. 다음 순서로 특별 게스트인 올트레일즈의 CTO 제임스 그레이엄을 모셨습니다. 복잡한 환경에서 SwiftUI 도입한 경험을 공유할 예정입니다. 완성도 높은 UIKit 앱입니다. 함께해 주세요. 제임스 님, 무대에 오신 것을 환영합니다.

안녕하세요, 여러분. 좋은 아침 또는 좋은 오후입니다. 질문이 하나 있습니다. 어쩌면 이 말이 공감될지도 모르겠네요. 기존 UIKit 코드베이스를 살펴본 적이 있습니까? 아마 4년 전에 작성된 엄청나게 큰 뷰 컨트롤러를 보고 '이런, 큰일 났네'라고 생각했을지도 몰라요. 이 코드는 대대적인 리팩토링이 필요합니다. 이 이야기는 잠시 접어두고 처음부터 다시 시작해 봅시다. SwiftUI 사용자분들, 손들어 보세요. 이런 일 경험 해보신 적 있으세요? 와, 정말 많네요. 손을 든 분들이 정말 많아요. 온라인 시청자가 훨씬 더 많을 거라고 확신해요. 매력적인 생각이긴 하지만, 우리가 운영하는 규모에서는 재작업은 불가능합니다. 엔지니어의 노력에서 비롯된 것이든 AI 기반 워크플로에서 비롯된 것이든, 이는 엄청난 위험을 초래합니다. 안녕하세요, 제 이름은 제임스 그레이엄입니다. 저는 AllTrails의 CTO입니다. 오늘 제가 이야기하고 싶은 것은... 재작업 없이 어떻게 현대적인 개발 속도를 달성했는지에 대해 알려드리겠습니다. SwiftUI 우리를 강제로 받아들이는 것이 아니라, 오히려 우리가 SwiftUI를 받아들이도록 만든 방식을 보여드리겠습니다. 위에서 아래로의 도입. 본론으로 들어가기 전에, 이야기의 줄거리를 먼저 설명드리겠습니다. 먼저 AllTrails가 무엇인지, 규모와 제약 조건에 대해 말씀드리겠습니다. 그다음에는 코드 재작성 없이 SwiftUI 어떻게 우리 코드베이스에 통합되었는지에 대해 이야기하겠습니다. 혹은 위임장이죠. 그 후에 전환점을 보여드리겠습니다. SwiftUI 실험적인 단계를 벗어났을 때 그리고 기본 선택 사항이 되기 시작했습니다.

마지막으로, 현재 상황이 어떤지 말씀드리면서 마무리하겠습니다. 그리고 우리가 하이브리드 아키텍처를 어떻게 바라보는지에 대해서도 이야기해 보겠습니다. 우리의 기술적 결정을 이해하려면 우리의 규모를 이해해야 합니다. 오늘, AllTrails는 세계에서 가장 인기 있는 트레일링 앱입니다. 야외 탐험을 위한 신뢰할 수 있는 플랫폼입니다. 우리의 임무는 간단합니다. 사람들이 바깥세상으로 나갈 길을 찾도록 돕는 것입니다. 우리는 사람들이 등산로를 발견하도록 돕습니다. 자신감 있게 길을 찾고 트레일에서의 경험을 향상시키세요. 최신 등산로 정보와 사진 투어 등의 기능을 제공합니다. 여정 중에 찍은 사진들을 강조해서 보여줍니다. 동네 공원 산책이든 며칠에 걸친 하이킹이든, 저희가 도와드리겠습니다. AllTrails에는 9천만 명이 넘는 커뮤니티 회원이 있습니다. 전 세계에 50만 개의 트레일이 있습니다. 그리고 우리 회원들은 19억 마일 이상을 주행했습니다.

저희 서비스는 14개 언어로 제공됩니다. 즉, 우리가 내리는 모든 기술적 결정은 영향을 미칩니다. 다양한 기기와 지역에 걸쳐 수백만 명의 회원이 있습니다. 결정적으로, 연결 수준이 다릅니다.

저희는 다양한 관심사와 선호도를 가진 폭넓은 회원층에게 서비스를 제공합니다. 한편으로는 간편한 방법을 찾는 일반 회원이 있습니다. 비교적 평탄한 오후 산책로로, 인근 호수의 아름다운 경치를 감상할 수 있습니다. 그리고 다른 한쪽에는 모든 것을 정복하려는 열정적인 등산객이 있습니다. 하프돔 하이킹, 휴대폰 서비스 없이 오프라인으로 탐색하며 진행.

그러한 다양성은 신뢰성, 배터리 수명 등에 엄격한 제약을 가합니다. 그리고 UI 성능도 중요합니다. 결함 있는 코드를 배포할 수는 없지만, 저희 앱은 정적인 앱이 아닙니다. 새로운 표면과 새로운 기능 깊이가 추가되면서 끊임없이 진화하고 있습니다.

SwiftUI 등장했을 때, 그것은 약속을 담고 있었습니다. AllTrails는 이미 규모가 크고 성숙하며 성공적인 UIKit 앱이었습니다. 그러한 진화의 한 예로, 지난 몇 년간 저희 홈페이지가 어떻게 변화해왔는지 보여드리겠습니다.

저희는 매주 새로운 버전을 출시했고, 두 서비스 모두 무료로 제공했습니다. 그리고 유료 체험 활동.

그리고 제가 우리의 유산에 대해 가장 중요하게 말씀드릴 것은 바로 이것입니다. UIKit 코드는 수정해야 할 문제가 아니었습니다. 그것이 바로 우리가 규모를 확장할 수 있게 해준 기반이었습니다. 그렇기 때문에 우리는 등산로를 폐쇄하고 변경할 수 없었습니다. 우리는 그것을 유지 보수해야 했고, 업그레이드해야 했습니다. 등산 중.

SwiftUI 등장했을 때, 그것은 우리가 간절히 원했던 것들을 약속했습니다. 데이터 변경 시 자동으로 업데이트되는 더욱 깔끔한 상태 관리 보기입니다. UI가 동기화되지 않는 버그 유형을 완전히 제거합니다. 모델이 코드보다 간단합니다. UIKit 과 비교했을 때 40% 감소라는 의미입니다. 이는 유지 관리, 업데이트 및 읽기에 필요한 코드가 40% 줄어든다는 의미입니다.

실시간 미리보기를 통해 디자인 변경 사항을 즉시 적용해 볼 수 있습니다. 하지만 이미 완성된 앱을 처음부터 다시 개발하는 것은 기술적으로나 조직적으로나 불가능한 선택이었습니다. 우리는 다른 접근 방식이 필요했습니다. 그렇게 SwiftUI 조용히 우리 코드베이스에 들어왔습니다. 그것은 의무 사항도 아니었고 로드맵 항목도 아니었습니다. 우리는 샌드박스를 만들었습니다. 그리고 우리는 이를 시제품 제작을 위한 저위험 실험에 사용했습니다. 그리고 분리된 서비스들. 덕분에 우리는 릴리스 후보 버전을 위험에 빠뜨리지 않고 프레임워크를 배울 수 있는 기회를 얻었습니다. 그 위에.

첫 번째 실질적인 결정은 UIKit 할지 SwiftUI 사용할지에 대한 것이 아니었습니다. 그들이 어떻게 함께 성공적으로 지낼 수 있을까 하는 문제였다. 우리는 일찌감치 상호운용성에 투자했습니다. 여기 있는 코드 조각을 살펴보세요.

이것이 바로 우리의 다리입니다. 우리는 트레일 코디네이터와 같은 SwiftUI 기능을 사용합니다. 우리는 그것을 HostingView로 감쌉니다. 그리고 우리는 그것을 표준 UIKit StackView에 바로 넣습니다.

그런 다음 ScrollView에 추가합니다. 이 페이지를 아래로 스크롤하면, HostingView의 일부 영역에는 SwiftUI 서브뷰가 포함되어 있는 것을 볼 수 있습니다. 우리는 이 패턴을 일찍부터 확립했습니다.

이는 절차상의 결정이었습니다. 경계가 명확하도록 보장함 그리고 두 세계는 같은 언어를 사용할 수 있게 되었다.

시간이 흐르면서 자연스럽게 두 개의 평행한 길이 형성됩니다. UIKit 여전히 대부분의 작업을 처리해 줍니다. 앱 생명주기 탐색 및 복잡한 또는 트레일 페이지나 커뮤니티 활동 페이지처럼 깊이 통합된 표면도 있습니다. 성숙한 사용자용 앱에서 보세요. stable을 다시 쓰는 건 의미가 없었어요. 실전에서 검증된 화면을 프레임워크만 바꾸면 됩니다. 그래서 우리는 등산 도중에 잘 표시된 등산로를 바꾸는 것을 피했습니다. 그리고 우리는 명확한 사용자 만족을 제공하는 곳에 새로운 투자를 집중했습니다. SwiftUI 측면에서 속도 향상이 있었습니다. 우리는 의도적으로 고립된 사람들에게 가장 적합한 곳에 그것을 사용하고 있습니다. 경계가 명확한 표면, 무거운 풍경과 새로운 실험을 표현합니다.

그 두 가지 예를 여기에서 볼 수 있습니다. 트레일 리뷰 흐름은 동적 상태를 가진 독립적인 표면입니다. 또한 UI 업데이트는 Swiftui의 선언적 모델과 잘 맞아떨어집니다.

Apple Intelligence 기반으로 구축된 "트레일에서 무엇이든 물어보세요" 경험은 비교적 최근에 도입되었습니다. 보다 실험적인 서비스. SwiftUI 사용하면 여기서 빠르게 반복 작업을 수행할 수 있습니다. 그리고 경험을 너무 밀접하게 연결시키지 않고 발전시켜 나가세요. 앱의 핵심 아키텍처에. SwiftUI 디자인 시스템으로서 매우 뛰어난 또 다른 영역입니다. 저희 앱을 한번 살펴보겠습니다. 디버그 모드에서는 Denali라는 디자인 시스템을 시각화할 수 있습니다. 데날리는 매일 규모가 커지고 있으며, 저희는 디자인 전반에 걸쳐 협력하고 있습니다. 시스템, 디자인 및 엔지니어링 팀 모든 새로운 기능이 이 시스템을 활용하도록 하기 위함입니다.

모든 핵심 구성 요소, 버튼, 세그먼트, 컨트롤, 여기 보이는 배지들은 저희 디자인 시스템의 일부입니다. 디버그 모드에서 저희 앱에서 확인하실 수 있으며, 현재 SwiftUI 로 개발되었습니다.

예전에는 수백 줄의 정형화된 코드가 필요했던 작업입니다. 이제 그중 일부를 가져다가 보세요. 새로운 변형을 추가하거나 간격을 조정해야 할 때, 이는 모든 곳에 퍼져나가는 간단한 변화입니다. SwiftUI 사용하면 코드베이스를 불필요하게 늘리지 않고도 디자인 시스템을 확장할 수 있습니다.

SwiftUI 도입하면서 예상치 못한 일이 발생했다는 점도 발견했습니다. 그것이 우리 건축에 영향을 미치기 시작했습니다.

뷰 모델의 크기는 종종 3분의 1 정도 작아졌습니다. UI와 상태를 동기화하기 위한 연결 코드를 더 이상 작성하지 않기 때문입니다.

또한 명시적인 배관 관련 내용을 훨씬 덜 작성했고, 게시자 수도 줄였으며, 운영자 수도 줄였습니다. 그리고 수명주기 관리가 훨씬 덜 필요합니다. SwiftUI 상태 전파를 처리해 주었기 때문입니다.

UI 상태와 동작이 함께 존재하기 때문에 변경 시 수정해야 하는 코드 라인 수가 더 적습니다. UI 관련 풀 리퀘스트 크기가 30~40% 정도 작아졌습니다. 그리고 코드 검토 속도가 눈에 띄게 빨라졌습니다.

그때부터 SwiftUI 더 이상 UI 실험처럼 느껴지지 않게 되었습니다. 그리고 이것이 시스템을 구축하는 올바른 방법이라고 느끼기 시작했습니다. 저희는 엔지니어들에게 SwiftUI 사용을 강요한 적이 없습니다. 그들은 마찰이 적다는 이유로 새로운 작업에 이 재료를 선택했습니다. 인지적 부담을 줄여주었다.

올바른 선택을 하면 코드 도입률이 40% 낮아져 자립적으로 유지될 수 있습니다.

우리가 얻은 결론은 다음과 같습니다. SwiftUI 널리 퍼진 것은 우리가 사람들에게 사용하라고 권유했기 때문이 아닙니다. 그것이 가장 빠른 진전의 길이었기 때문에 퍼져나갔습니다. 프레임워크가 인지적 부담을 줄이고 복잡성을 제거할 때, 엔지니어들은 설득이 필요 없습니다. 우리는 그냥 손을 뻗으면 돼요. 하지만 코드베이스는 하룻밤 사이에 바뀐 게 아닙니다. 기울어졌습니다. UIKit 여전히 ​​깊숙이 자리 잡고 있습니다. SwiftUI 그 주변에서 발전합니다. 우리는 기능별 코드 라인 수 감소와 같은 성공 지표를 측정합니다.

더 빠른 반복 주기, 또한 SwiftUI 의 특정 기능에서 발생하는 회귀 오류가 줄어듭니다.

우리는 상호 운용성이 인프라라는 것을 깨달았습니다. 우리는 호스팅 래퍼, 공유 애니메이션에 투자했습니다. 다리 역할을 하는 요소들과 통일된 테마. 다리가 견고할 때, SwiftUI 더 이상 새로운 느낌을 주지 않고, 기본적인 요소처럼 느껴지기 시작합니다.

이것의 완벽한 예가 바로 저희 Apple Watch 앱입니다. 저희 나침반과 지도 앱은 모두 SwiftUI 로 개발되었습니다. 저희 지도는 MapKit 사용합니다. 이는 핵심 성능을 어떻게 제공할 수 있는지 보여줍니다. 현대적인 아키텍처를 활용한 섬세한 기능 구현.

우리가 SwiftUI 선택한 이유는 멋있어서가 아닙니다. 하지만 그 덕분에 더 빠르게 반복 작업을 진행할 수 있었기 때문입니다. 기존 탐색 로직을 건드리지 않고 복잡한 표면에서 작동합니다.

그렇다면 우리는 오늘 어디에 와 있을까요? AllTrails는 SwiftUI 로 마이그레이션되지 않았습니다. 앱 전체를 다시 작성할 필요 없이도 이러한 이점을 누릴 수 있습니다. 우리는 방향성을 가진 하이브리드 시스템입니다.

UIKit 안정성을 제공합니다. 복잡한 컬렉션 뷰와 같은 심층적인 UI 사용자 정의에는 여전히 매우 유용합니다. 또는 복잡한 탐색 모음.

SwiftUI 우리의 성장을 정의합니다. 빠르게 따라잡고 있어요. 그리고 여기에 보이는 식물 식별 기능은 100% SwiftUI 로 구현되었습니다.

지금까지 설명한 내용은 모두 AllTrails라는 플랫폼의 규모에 특화된 내용입니다. 우리 구성원, 우리 제약 조건. 그건 의도적인 겁니다.

팀들이 흔히 저지르는 실수는 도입 여부를 양자택일로 여기는 것입니다. SwiftUI 도입해야 할까요?

더 나은 구도는 다음과 같습니다. 어떤 조건에서 도입은 위험이 아닌 추진력을 만들어낼까요?

실제로 효과가 있었던 요소를 살펴보니 버그 감소와 빠른 배송이 나타났습니다. 팀 간 확장성이 향상되었습니다. 단순히 기술적인 선택 하나만은 아니었습니다. 이는 의도적으로 내려진 일련의 결정들이었습니다.

제가 자주 듣는 질문 중 하나는 UIKit 과 SwiftUI 안전하게 공존할 수 있느냐는 것입니다. 오늘 제가 보여드린 내용을 보면, 답은 분명히 '예'입니다. 그래서 어떤 동물을 입양해야 할지 직접 말씀드리는 대신, 입양을 평가하는 데 사용할 수 있는 세 가지 질문을 드리겠습니다. 여러분의 맥락에서 생각해 보세요. 첫째, 상호 운용성은 인프라로 간주됩니까? 상호 운용 가능한 상호 운용성이 취약하거나 임시방편적이라면, 실제 제품 출시 압력이 가해지는 순간 도입은 정체될 것입니다.

두 번째. 새로운 도구가 인지 부담을 줄여주는가? 도구가 정신적 부담을 진정으로 줄여줄 때, 입양은 강제할 필요가 없습니다. 엔지니어들은 자발적으로 그것을 선택할 것입니다. 그리고 세 번째로, 당신은 전환율이 아닌 모멘텀을 측정하고 있는 건가요? 추진력이 생기면 PR 규모가 작아지고, 검토 속도가 빨라지며, 회귀 오류가 줄어듭니다. 코드베이스를 얼마나 변환했는지에 따라 달라지는 것이 아닙니다.

그러니까 여기서 얻을 수 있는 교훈이 있다면, 다시 쓰지 않아도 진전을 이룰 수 있다는 뜻입니다. 방향 제시가 필요하시군요. 오늘 시간 내주셔서 정말 감사합니다. AllTrails 이야기를 공유할 수 있게 해주셔서 감사합니다. 등산로에서 뵙겠습니다.

정말 고마워요, 제임스. SwiftUI 덕분에 기능 출시가 얼마나 쉬워지는지 직접 들으니 정말 고무적입니다. 또한 유지보수 비용을 줄여줍니다. 그리고 SwiftUI UIKit 코드베이스와 매우 원활하게 공존할 수 있다는 점입니다. 저는 AllTrails의 열렬한 팬입니다. 그리고 제작 과정의 비하인드 스토리를 배우는 것도 저에게는 재미있습니다.

자, 이제 잠깐 쉬었다 가겠습니다. 그리고 나서 225 Pacific에서 리더들과 함께 패널 토론을 위해 다시 만납니다. SwiftUI 엔지니어링 분야에서. 그럼 그때 뵙겠습니다. 휴식을 잘 보내셨기를 바랍니다. 자, 이제 SwiftUI 엔지니어링 분야의 세 명의 리더와 함께하는 패널 토론 시간입니다. 자, 그럼 닉, 러셀, 테일러를 무대 위로 따뜻하게 맞아주세요.

멋지네요, 리아.

저는 이전에 여러분 모두와 함께 일할 수 있는 기회를 가졌지만, 이번에는 시청자 여러분을 위해, 자기소개를 해주시고, 저희에 대해 좀 더 자세히 말씀해 주세요. Apple 에 얼마나 오래 근무하셨나요? 안녕하세요, 제 이름은 닉 타일러입니다. 저는 Apple 에서 약 6년 동안 근무했습니다. 처음에 MapKit 팀에 합류한 것만으로도 이미 꿈이 이루어진 기분이었어요. 왜냐하면 저는 MapKit 엔지니어들이 어떻게 그런 일을 하는지 방금 알게 되었기 때문입니다. 객체 지향 프로그래밍을 개척했다. 그리고 Next에 함께했던 사람들과 다시 협력할 수 있는 기회는 여전히 존재합니다. 그리고 당시 Apple 도 마찬가지였죠. 그래서 제가 그 일에 참여하게 된 겁니다. 정말 멋지네요. 저는 러셀이고, 현재 SwiftUI 매니저로 일하고 있습니다. 하지만 저는 Apple 에서 9년 동안 근무했습니다. 저는 주로 UIKit 엔지니어로 일했습니다. 최근까지 제 경력의 대부분을 이곳에서 보냈습니다. 하지만, 저는 대학 졸업 후 바로 여기로 왔습니다. 저는 테일러예요. 제가 13살이니까 여기 있는 사람들 중에 제가 제일 나이가 많겠죠. 저도 예전에 SwiftUI 로 넘어오면서 Nick처럼 MapKit 시작했었습니다. 그리고 가장 최근에는 정말로 원점으로 돌아왔습니다. MapKit 및 Catalyst 관련 업무를 일부 다시 맡게 되었습니다. 이곳에 오게 되어 정말 기쁩니다. 여러분 모두가 상호 운용성에 대해 이야기하고 있는 것 같아요. MapKit 과 UIKit 간의 상호 운용성 이야기 그리고 SwiftUI 당신의 경력과 경험 덕분에 충분히 사용할 만하다고 생각합니다. 그렇다면 성전환을 결심하게 된 동기에 대해 좀 더 자세히 이야기해 주시겠어요? SwiftUI 활용하고 프레임워크의 장점을 살려보세요. 음, Appkit 사람들과 협업한 후에 객체 지향 설계를 개척하던 테일러를 배웅했습니다. 또 다른 팀에서는 선언적 프레임워크 설계를 개척하고 있습니다. 그래서 저는 그곳이 다음에 가야 할 곳이라고 생각했어요. 네. 제 말은, 거기에 덧붙여서 말하자면, 선언적이라는 거죠. 저도 그런 명확한 표현 방식에 매료되었던 것 같아요. 특히 Swift 로 개발되었다는 점이 마음에 들었습니다. 예를 들어 선언적 시스템을 작성하고 백업하는 방법은 다음과 같을 수 있습니다. 서술적이라고 말할 때, 우리는 다음을 의미합니다. 아시다시피, 프레임워크에 원하는 바를 알려주는 겁니다. 그 일이 일어나기까지의 모든 과정을 거치는 것보다, 그 일이 일어나도록 하는 것 자체가 더 중요하다. 이것이 바로 사물을 구축하는 필수적인 방식입니다. 그래서 이건 정말 강력한 아이디어였고, 그걸 실제로 구현할 수 있다는 점이 좋았습니다. Objective-C 포함한 모든 언어로 작성된 선언적 시스템. 하지만 Swift 이 글을 훨씬 더 자연스럽고 표현력 있게 쓰도록 만들었다. 그래서 그것은 일종의 특별한 기회였습니다. 이러한 아이디어들을 진정으로 탐구하기 위해. 저도 바로 그 점에 매료되었죠. 응. 아, 죄송합니다. 말을 끊으려던 건 아니었어요. 아, 저도 그걸 일종의 시도라고 생각해요. 제가 항상 해결하고 싶었던 문제를 해결하기 위해서요. 이는 UI에서 앱을 만드는 것을 더 쉽게 만들어줍니다. 프레임워크들은 서로 그다지 다르지 않습니다. 그리고 SwiftUI 에 명령형적인 측면이 전혀 없는 것도 아닙니다. 레이아웃 프로토콜이나 캔버스, 경로 같은 곳으로 내려가 보면, 예를 들어, 선언적 API를 갖는 것은 추상화 계층을 하나 더 추가하는 것일 뿐입니다. 그것은 그러한 종류의 문제를 해결하는 데 유용합니다. 우리는 항상 해결하려고 노력해 왔습니다. 러셀은 항상 버그 없는 앱이 있는 미래에 대한 꿈을 이야기하곤 합니다. 앱은 당신이 원하는 대로 작동하고, 세상 모든 것이 완벽해 보입니다. 네, 저는 그런 현실 속에서 살고 싶어요. 들어갈 방법이 있는 것 같은데, 좀 도와주시겠어요? 제 생각엔 이거 같아요. 로고도 있고 모든 게 다 준비됐잖아요. 정말 크네요. 음, 단순함을 묘사하신 방식이 정말 마음에 들었어요. SwiftUI 추구하는 바이며, 제 생각에는 그렇습니다. 프레임워크를 사용하기 시작한 순간부터 성과를 거두었습니다. 선언적 인터페이스는 단순히 보기 좋게 만드는 것 이상의 의미를 지닙니다. 하지만 배우는 것도 재밌고 시간을 투자할 만한 가치가 있다. 그리하여 SwiftUI 도입되었습니다. 2019년에 출시되었는데, 어떤 문제를 해결하고자 했는지 좀 더 자세히 설명해 주시겠어요? 그리고 또한 그 문제 진술이 어떻게 작용하는지도 궁금합니다. 그리고 그 접근 방식은 시간이 지남에 따라 발전해 왔습니다. 뛰어내릴게요. 테일러. 당신이 선임이시잖아요, 그렇죠? 응. 대부분의 해에는, 그러니까, 제 생각에는, 뭐랄까, 제가 해결하려고 했던 문제는 그것을 만드는 것과 같은 것이었습니다. 앱 개발 진입 장벽을 낮추는 것이죠. 그리고 선언적 시스템과 같은 것들을 활용하는 것이죠. 아시다시피, 우리는 진실의 단일한 원천을 정말로 원한다고 설명해 왔습니다. 그러면 당신은 그런 상황에 처하지 않을 것입니다 그렇지 않으면 발생할 수 있는 다양한 종류의 버그들 다른 유형의 앱에서. 그래서 실제로 이러한 목표들이 있습니다. 우리는 많은 것들의 중심에 있습니다. 우리가 하고 있던 일의 일부였죠. 그래서 처음 몇 년은 정말 그랬습니다. 이러한 원칙들을 기반으로 삼아 발전시켜 나가는 것입니다. 그리고 그 이후로는 매년 추가적인 기능을 더하는 데 중점을 둡니다. 아시다시피, UIKit 에는 매우 오랜 역사를 가진 다양한 기능들이 있습니다. Appkit이 제공하는 것과 같은 기능을 제공하는 것이 우리의 목표입니다. 우리는 오늘날까지도 그 목표에 도달하지 못했습니다. 하지만 저는 우리가 감명받을 만한 수준에 도달했다고 생각합니다. 사람들이 만들 수 있는 앱의 종류와 관련해서요. 테일러의 말에 덧붙여 말하자면, 처음부터 변함없이 이어져 온 한 가지는 바로 우리가 글을 쓴다는 점이라고 생각합니다. API를 통해, 아시다시피, 저희는 "한 번 배우고 어디서든 작업하세요"라는 슬로건을 내세우고 있습니다. 하지만 일단 익숙해지면 괜찮다는 생각도 있죠. 프레임워크의 각 부분에 익숙해지게 됩니다. API의 다른 많은 부분들도 자연스럽게 익숙해지게 됩니다. UIKit 떠올려 보세요. UItableview가 있는 곳 그리고 UItableView API의 모든 기능에 대해 배우게 됩니다. 그런 다음 다른 구성 요소로 이동합니다. 그러면 당신은 '아, 이건 좀 다른 패턴들도 있네'라고 생각하게 되죠. 저는 익숙해져야 합니다. 하지만 SwiftUI 는 처음부터 모든 것이 친숙하게 느껴지도록 설계되었습니다. 그래서 그것은 꾸준히 이어져 왔습니다. 꾸준한. 마치 추진력처럼. 네. 그리고 저는 그게 단순히 API를 실제로 사용하는 것뿐만 아니라, 또한 하나의 코드 조각을 가져와 다양한 플랫폼에서 사용할 수 있도록 하는 것도 중요합니다. 그리고 다른 하드웨어 또한 다양한 상황에서 앱의 존재 여부를 확인할 수 있습니다. 그리고 여러분의 기술을 향상시키세요. 제 생각에 러셀이 다른 토론에서 지적했던 것 중 하나는 바로 이것이었던 것 같습니다. 아시다시피, 우리가 모든 것을 마무리 짓는 단계에 접어들면서 앱이 기대하는 기능 세트는 일종의 다음 단계와 같을 것입니다. 그리고 저는 우리가 진정으로 중요한 것이 무엇인지에 대한 움직임으로 점차 옮겨가고 있다고 생각합니다. SwiftUI 로 만들 수 있는 독특한 것들과 관련 도구들에는 어떤 것들이 있을까요? 네. 왜냐하면, 제 생각에는 우리가 처음 시작했을 때, 우리에겐 좋은 아이디어의 씨앗이 있는 것 같아요. 아이디어가 정말 확실해지면, 하지만 그 후로는 다른 나라들과 동등한 위치에 오르기 위해 수년간의 노력이 필요했습니다. 프레임워크요. 그리고 지금 우리가 그 단계에 접어들면서, 우리는 우선순위를 다시 핵심적인 부분들로 돌릴 수 있습니다. 예를 들어, 우리가 기존 체계에 도입할 수 있는 새로운 아이디어는 무엇일까요? 그리고 핵심 프레임워크 자체처럼 진화할까요? 네, 전적으로 동감입니다. 제게 떠오르는 예시는 바로 이것입니다. ScrollView API가 도입되었고 어떻게 작동하는지 그리고 당신은 저보다 그들과 더 잘 이야기할 수 있을 거예요. 하지만 개발자 더 쉽게 사용할 수 있도록 한 단계 더 나아가는 거죠. 코드를 많이 작성하지 않고도 매우 정교한 뷰를 구현할 수 있습니다. 네, 맞아요. 그 점을 언급해 주셔서 정말 기쁩니다. 청중 여러분께 간단한 질문 하나 드리겠습니다. 여러분은 앱에서 SwiftUI 얼마나 사용하고 있나요? 그리고 ScrollView 안에 GeometryReader가 있습니다. 자, 여기 있어요. 올려놓으세요. 좋아요. 알겠습니다. 나는 몇몇 손들을 봤다. 이제 그건 필요 없을 거예요. 2년 동안 존재해 온 다른 API들도 있습니다. 그리고 더 긴 길이는 이러한 인체공학적 설계를 더욱 강화하기 위해 명시적으로 만들어졌습니다. 그리고 가능합니다. 당신도 마찬가지입니다. 스크롤 위치 수정자에 대해 이야기해 보겠습니다. 스크롤 위치 수정자. 애니메이션들을 서로 연결하는 정말 멋진 방법들이 있어요. ScrollView를 사용하여 애니메이션을 구동하세요. 그리고 그에 대한 세션도 마련되어 있습니다. 과거에는 2023년까지 거슬러 올라가야 했을지도 모릅니다. 어쨌든, 우리는. 버리세요. 스크롤링 페이지를 보세요. 페이지 줄. 스크롤링 커트가 해냈어, 스크롤. 목표 동작, 스크롤, 목표 레이아웃. 레이아웃 프로토콜 자체도 이러한 요구 사항 중 일부를 충족하고 있었습니다. Geometryreader에 필요한 것과 같은 것입니다. 그래서 저는 이것들이 피드백 루프를 보여주는 훌륭한 예시라고 생각합니다. 사람들이 물건을 사용하다가 문제를 겪는 모습을 볼 때처럼 말이죠. 이를 통해 우리는 프레임워크를 개선하기 위한 다음 단계가 무엇인지 생각해 볼 수 있습니다. 마찬가지로, 그렇습니다. 가능하다면 누군가가 정말 멋진 일을 할 수 있도록 도와주세요. 지금으로서는 정확히 설명하기 어렵습니다. 하지만 당신은 좌표 공간을 사용합니다. 그리고 ScrollView의 좌표 공간에 접근할 수 있습니다. 스크롤 프록시인 것 같습니다. 그래서 스크롤 리더 프록시 그리고 흥미로운 일들을 많이 합니다. 그렇게 하면 무효화 주기 없이도 문제가 해결됩니다. Geometryreader가 때때로 가져올 수 있는 것입니다. ScrollView에 대해서는 끝없이 이야기할 수 있을 것 같아요. 아시다시피, 할 이야기가 많아요. 하지만 저는 개발자의 영향에 대해 말씀하셨던 내용으로 다시 돌아가고 싶습니다. 그리고 사람들이 프레임워크를 어떻게 사용하는지 살펴보는 것 그리고 SwiftUI UIKit MapKit 과 동등한 수준에 머무르지 않도록 만들고 싶었습니다. 하지만 실제로 다음 단계로 나아가세요. 더욱 즐거운 경험을 쉽게 만들 수 있도록 도와줍니다. SwiftUI 에 개발자 커뮤니티가 미치는 영향에 대해 말씀해 주시겠습니까?

그것이 원래 이유였습니다. 제가 테일러 씨에게 "당신 팀에 합류하고 싶습니다"라고 말했을 때, 그는 이렇게 반응했습니다. 무엇을 좋아하니? 라고 스스로에게 물었더니, UI와 SwiftUI 사용자 인터페이스를 의미하는 것이 아닙니다. 그건 당신과 나를 의미해요. 그게 다예요. 하지만 그건 정말 사실이에요. 마치 누구를 만날 때와 똑같아요. 그리고 공통된 취미가 있어서 누군가를 만나면 그 사람은 이렇게 말하죠, 두 분 다 달리기를 좋아하시거나 특정 영화 장르를 좋아하시는군요. 저는 여행을 다니면서 다른 나라에서 정말 많은 사람들을 만났어요. 방금 연락한 사람은 우리 둘 다 UI 프레임워크를 좋아해서입니다. 그러면 곧바로 공통된 언어가 생겨납니다. 솔직히 말해서 세상을 보고 사람들을 만나는 데 정말 좋은 방법이에요.

네. 제 말은, 제가 설명한 이 피드백 루프 같은 게 있다고 생각해요. 매년 초에 우리는 우리가 생각하는 차세대 핵심 사항들을 공개하기 위해, 사람들이 무엇을 만들고 있는지, 그리고 그들이 어떻게 반응하는지 살펴보고 거기서부터 개선해 나가세요. 그러니까, 아까 말씀드렸듯이, 원래 목표는 앱 개발에 대한 진입 장벽을 낮추는 것이었습니다. 그것이 목표였음에도 불구하고, 우리는 여전히 어느 정도 감명을 받았어요. 그리고 SwiftUI 출시하자마자 놀랐습니다. 이전에는 앱을 만들어 본 적이 없는 사람들이 처음으로 앱을 만들고 있었습니다. 아시다시피, 디자이너들은 이런 부류의 사람들 중 하나였고, 그 외에도 많은 사람들이 있었습니다. 아시다시피, 생성형 AI 도구도 좋은 예입니다. 사람들에게 실질적인 힘을 실어준 것들이죠. 매일매일 그런 모습을 보고 있어요. 제가 정말 하고 싶었던 일을 담아 새로운 앱을 만들었어요. 그리고 제가 앱을 만들어본 건 이번이 처음이에요. 이렇게 멋진 결과물을 보니 정말 감격스럽네요. 그리고 나서 보세요, 아시잖아요. 새로운 유형의 앱 개발자들이 겪는 어려움은 무엇일까요? 그렇다면 어떻게 하면 그 경험을 더욱 좋게 만들 수 있을까요? 저는 거기에 더해서 덧붙이기도 합니다. 내가 아침에 일어나는 유일한 이유는 새로운 것을 추가하기 위해서다. 여러분 모두가 멋진 앱을 만들 수 있도록 말이죠. 저는 여기 오기 전에 개발자 커뮤니티 출신입니다. 제가 코딩을 배우게 된 방법 중 하나는 독서였어요. iOS 앱 제작 방법에 대한 Apple의 문서입니다. iPhone 화면에서 뭔가를 움직이게 하는 건 정말 어려운 일이었어요. 전에 쓰던 터미널 앱보다 훨씬 더 마법 같네요. 그러니까, 거기에 덧붙이자면, 언젠가는 다시 졸업할 수도 있겠죠. 앱을 만드는 방법에 대해. 네. 저희가 영상 마지막 부분에서 "~처럼"이라고 말할 때 말이죠. 우리는 종종 "당신이 무엇을 만들어낼지 정말 기대돼요"라고 말하곤 합니다. 정말 그래요. 가장 즐거운 일 중 하나는 바로 그곳이죠. 당신은 일 년 내내 이 API를 연구하고 구축하는 데 시간을 쏟았습니다. 그리고 당신은 머릿속에 그것을 가지고 있죠. 당신은 사람들이 그것을 어떻게 사용할지 상상해 보셨군요. 그러다가 누군가가 "이 API를 이용해서 이렇게 해봤어요"라고 말하는 걸 보게 되죠. 그러면 당신은 '아, 그렇구나'라고 생각하게 되죠. 그건 좋은 좋아요 같았어. 처음에는 '이렇게 될 줄은 몰랐어'라는 생각이 들죠. 그리고 그들은 실제로 정말 멋진 일을 하고 있어요. 그리고 그것은 우리가 목표를 달성했다는 것을 의미합니다. 일반적으로 동작하는 구성 가능한 API를 만드는 측면에서 예상치 못한 방식으로 일을 처리할 수 있습니다. 예상치 못했네요. 정말 멋져요. 아니요, 프레임워크의 발전 과정은 정말 즐거웠습니다. 단순히 얼마나 세련되어졌는지뿐만 아니라 얼마나 매력적인지 보기 위해서입니다. 그리고 저는 이렇게 여기 계신 개발자분들과 직접 소통할 수 있는 행사를 정말 좋아합니다. 온라인에서 질문도 하고, 이러한 API들이 실제로 어떻게 사용되는지 직접 확인해 보세요. 그리고 그들이 하고 있는 일은 정말 훌륭해요. 그리고 앱의 요구 사항을 더욱 효과적으로 충족할 수 있는 방법에 대해서도 논의할 것입니다. 그래서 저는 그게 굉장히 보람 있는 일이라고 생각해요. 그리고 우리 모두를 대표해서 말씀드리자면, 정말 보람 있는 일입니다. 정말 보람 있는 일이에요. 이건 Slido에 대한 질문입니다. 많은 사람들이 추천에 대해 문의했습니다. SwiftUI 에서 권장되는 앱 아키텍처에 대한 내용입니다. 그 부분에 대해 좀 더 자세히 설명해 주시겠어요? 이 질문은 정말 자주 받아요. 그리고 우리가 그런 시도를 할 수 있었던 시절에 비해 세상은 정말 많이 발전했다고 생각합니다. 하나의 건축 양식을 추천하고 모든 상황에 맞는 단일 솔루션이라고 말하는 것은, 그리고 나서 우리는 사람들을 이 하나의 건축 양식의 길로 이끌어 갑니다. 알고 보니 앱이 서버 의존도가 매우 높을 수도 있습니다. 그래서 건축 분야는 당신에게 맞는 선택이 아니었던 거죠. 그래서 SwiftUI 목표는 실제로... 모든 건축물에 필요한 기본 구성 요소를 제공합니다. 우리는 커뮤니티가 구축하고 있는 모든 건축물에 대해 잘 알고 있습니다. 제가 특히 강조하고 싶은 한 가지는 바로 이것입니다. Observable 매크로는 시작하기에 좋은 곳입니다. Observable을 사용하는 것과 같은 ViewModel 기반 아키텍처를 가지고 있다면, 그 원자 구성 요소를 사용하세요 또한 SwiftUI 와의 뛰어난 통합 기능을 통해 뷰모델을 구축할 수 있습니다. 또한 Observable은 다음과 같은 용도로 사용될 수 있습니다. UIKit 에서도 일반성을 잃지 않고 사용할 수 있다는 점이 정말 좋습니다. 그리고 이를 더욱 강화하는 것은 전체적인 맥락이 핵심 중 하나라는 점입니다. 목표는 상호 운용성입니다. 그러니까, 우리는 AllTrails가 어떻게 입양했는지에 대한 이야기를 봤잖아요. SwiftUI 점진적으로 사용하세요. 그리고 그건 수많은 앱에 해당되는 이야기입니다. 그리고 이러한 앱들은 각각 다른 곳에서 출시되었습니다. 건축적인 측면에서 말이죠. 그리고 정말 그렇습니다. SwiftUI 맞춤형 서비스를 제공할 수 있다는 점이 매우 중요합니다. 앱이 어디에서 왔는지에 관계없이. 네. Apple 내부에서도 수많은 앱들이 상호 운용성에 의존하고 있죠. 네, 물론이죠. 정말 중요한 건, 무엇이 당신의 팀을 가능하게 하는가 하는 점입니다. 팀원 모두에게 공감을 불러일으키는 것은 무엇일까요? 그리고 그들이 가장 빠르게 건설하는 방법을 알고 싶어하는 방식 그리고 그들이 가장 우아하다고 생각하는 것은 무엇일까요? 그리고 활용할 수 있는 자료가 정말 많아요. 예를 들어, 현재 앱의 UI가 UIKit 기반인지 MapKit 기반인지에 따라 다릅니다. 그리고 당신은 SwiftUI 도입을 언제 시작할지 고민하고 있겠죠. 개발자 웹사이트에는 WWDC 영상 등 정말 많은 자료가 있습니다. 그 과정을 안내해 드리기 위해서입니다. 정말 많은 사람들이 다니는 길이죠. 그리고 저는 그 첫걸음을 내딛는 데 도움이 될 훌륭한 자료들이 정말 많다고 생각합니다. 응.

Slido에서 또 다른 질문이 들어왔습니다. 이건 좀 더 포괄적인 수준입니다. 많은 사람들이 구체적인 질문들을 했어요. 특정 플랫폼에서 이러한 동작을 구현하는 API는 무엇입니까? 아니면 뷰에서 이 기능을 어떻게 구현하나요? 그리고 저는 더 높은 차원에서 호기심을 갖고 있습니다. 다양한 동작에 필요한 API를 사람들이 어떻게 찾도록 추천하시겠습니까? SwiftUI 사용하시나요? 어떤 도구를 추천하시나요? 저는 지금까지 많은 성공을 거두었습니다. Xcode 에 다양한 모델을 통합하는 것과 관련하여. 적어도 그건 확실해요. 아주 좋은 출발점이죠. 어떤 언어로 말하든 상관없기 때문에 언제든지 그렇게 말할 수 있습니다. 사실, 사실, 저는 테스트된 모델들을 아직 보지 못했습니다. 다양한 언어로 말할 수 있지만, 자연어로 말해야 합니다. 당신이 찾고 있는 것을 찾으면, 곧바로 온갖 잡동사니가 쏟아져 나오게 됩니다. 수식어와 제안. 그리고 그건 실제로 시작하기에 정말 도움이 되는 지점입니다. 네. 지능형 기능이 정말 멋지네요. 그리고 그것들은 프로토타입 제작의 장벽을 실제로 낮춰줍니다. 그건 제가 그냥 시작을 해보려고 찾은 거예요. 제가 잘 알지 못하는 분야일 수도 있습니다. 그런 다음 제 이해를 더욱 구체화할 수 있습니다. 최근 출시된 게임들은 그런 점에서 정말 멋집니다. 하지만 저는 그게 중요한 거라고 생각해요. 그것은 무언가를 만들어낼 것이고, 보여주려고 할 것이다. 당신에게 어떤 일이 일어날 수도 있지만, 개발자 로서 그런 점에 대해 의문을 제기하는 것이 당신의 역할입니다. 그리고 그게 무슨 역할을 하는지 확실히 이해해야 해요. 우리 모두 환각 같은 것들에 대해 잘 알고 있죠. 그래서 그런 점을 확인하는 것 외에도, 저는 이것이 강력한 학습 도구라고 생각합니다. 저는 당신이 이 일을 시작한 방식이 괜찮다고 생각합니다. 이러한 효과를 얻기 위해 다음과 같은 수정자 세트를 제안했습니다. 나는 저것들이 실제로 무슨 역할을 하는지 제대로 이해하고 있는가? 그러면 관련 문서를 찾아볼 수 있습니다. 그리고 우리의 목표 중 하나는 모든 문서가 제대로 작성되었는지 확인하는 것입니다. 간단한 예제 코드가 포함되어 있다고 설명합니다. 따라서 직접 시작해 볼 수 있습니다. 이런 유형의 학습을 통해 정신적 모델을 구축하기 위해서 말이죠. 저는 그게 멋지다고 생각해요. 네. 그리고 그것이 바로 우리가 오늘 여기에 모인 이유입니다. 기초를 다지는 것이죠. 오늘 그 단어를 열 번쯤, 어쩌면 그 이상 쓴 것 같아. 우리가 세어볼게요. 하지만 시간을 내는 것처럼요. 기초를 이해하면 코드에 대한 자신감을 갖는 데 도움이 됩니다. 그리고 만약 이해가 안 되는 부분이 있다면, LMM이 그 부분을 설명해 줄 수도 있습니다. 그 시간을 활용할 수는 여전히 있습니다. 아직 자신감이 부족한 분야에 노출되어 배우는 것이 중요합니다. 정말 멋지네요. 그건 한 가지 이유죠. 네, 특히 배우려고 할 때는 더욱 그렇죠. 저는 학습과 앱 개발을 동시에 하는 경우가 거의 없습니다. Xcode 프리뷰를 통해 항상 새로운 것을 배우고 있어요. 그리고 일단 기초를 다지고 나면, 그런 다음 그 정보를 앱에 입력하면 다른 모든 부작용이 나타납니다. 그리고 복잡한 상황이 동시에 발생하지만, 적어도 그런 모델은 가지고 있습니다. 원래 이렇게 작동하도록 설계된 것입니다. 뭔가 이상하거나, 내가 뭔가 이상한 짓을 저질렀을 때, 어디를 찾아봐야 할지, 어디서부터 시작해야 할지 감이 안 잡히네요. 네. 미리보기 기능은 제가 가장 좋아하는 도구 중 하나입니다. 단순히 버그를 쉽게 분리하고, 명시하고, 재현할 수 있다는 점 때문만은 아닙니다. 어쩌면 뭔가 이상한 행동이 있을지도 몰라요. 그리고 상태를 빠르게 주입해서 어떻게 동작하는지 확인할 수 있습니다. 하지만 빠르게 프로토타입을 만들고 레이아웃을 확인하는 데 있어서, 저는 레이아웃 미리보기를 정말 좋아합니다. 제가 가장 좋아하는 도구 중 하나입니다. 방금 생각난 또 다른 자료는 개발자 포럼입니다. 따라서 문서 자료와 WWDC 영상 외에도, 이는 제가 다양한 API에 대해 배우는 방식일 뿐만 아니라, 그 이상의 의미를 지닙니다. 하지만 그것들을 샘플 앱이라는 더 큰 맥락에서 바라보는 것도 중요합니다. 그리고 다양한 요소들이 어떻게 떠오르는지 살펴보세요. 그런 식으로요. ScrollView 영상은 제가 생각해낸 아이디어 덕분에 정말 멋졌어요. 애니메이션 아이디어가 너무 많아요. 하지만 개발자 포럼 또한 훌륭한 자료입니다. SwiftUI 나 UIKit 같은 프레임워크를 기준으로 질문할 수 있기 때문입니다. 하지만 watchOS 나 Vision OS와 같은 플랫폼별 질문도 할 수 있습니다. 그리고 설령 그 순간에 질문이 없더라도, 어쩌면 당신은 그저 배우고 싶고, 다양한 종류에 대해 알고 싶을지도 몰라요. 미래에 대해 생각해 볼 만한 것들. 정말 훌륭한 자료입니다. Apple 엔지니어와 지원팀이 이를 중재하고 있습니다. 그래서 제작 과정에서 훌륭한 참고 자료가 될 것입니다. 그리고 개발자 로서의 여정을 계속 이어가세요.

SwiftUI 어떻게 도움이 되는지에 대해서도 조금 이야기해 보겠습니다. Liquid Glass 사용하면 올해에도 앱을 최신 상태로 유지할 수 있습니다. 그것은 iOS 26 과 다른 운영 체제들의 중요한 특징 중 하나였습니다. SwiftUI 앱의 최신 상태를 유지하는 데 어떻게 도움이 되는지 좀 더 자세히 설명해 주시겠어요? Apple 플랫폼용인가요? 원하세요? 우선, 한 가지 말씀드릴 수 있는 건, 다음과 같은 것이 있다는 것입니다. SwiftUI 많은 고급 시맨틱 API를 제공하는 것처럼, 과거에 제공되었던 UIKit 및 Appkit보다 훨씬 더 높은 수준입니다. 이를 통해 훨씬 더 많은 유연성을 제공할 수 있습니다. 앱이 이러한 의미론적 개념, 예를 들어 다음과 같은 것들을 포함하여 구현될 때, Liquid Glass 동적 다크 모드가 나오기 훨씬 이전부터도, 이것들은 마치 적응형 개념과 같아서, 그런 것들이 변할 때, 앱이 방금 업데이트되었고 Liquid Glass 많은 훌륭한 기능을 갖추고 있습니다. 구성 요소이기도 하지만, 여러 면에서 하나의 주제이기도 합니다. 따라서 앱의 핵심 구조가 반드시 바뀌는 것은 아닙니다. 그리고 이러한 의미론적 개념을 적용하면 자동으로 업데이트됩니다.

하지만 이는 사용자 지정 컨트롤에도 적용됩니다. 그러므로 설령 여러분이 맞춤 제작을 하더라도, 그 부분은 약간의 조정이 필요할 수도 있습니다. 하지만 SwiftUI 처럼 유리 효과 컨테이너와 같은 다른 API도 있습니다. 특히 다른 프레임워크들이 제공하는 방식보다 더 나은 기능을 제공했습니다. 매우 유연한 API 덕분에 그렇습니다. 유리용 API 표면. 유리처럼 보이는 용기가 아주 작습니다. 제 생각엔 그게 유일한 견해인 것 같아요. 그리고 나서 공개 수정자가 3~4개 정도 있을 수 있습니다. 그런데도 상황은 이렇습니다. 이 작품에는 다양한 전환 효과와 여러 요소들이 합쳐지고 변형될 수 있는 특징이 있습니다. 그리고 명령형 UI 프레임워크가 얼마나 어려움을 겪을지 상상해 볼 수 있을 겁니다. 간결한 API를 제공하기 위해, 기존에 있던 부품들을 최대한 많이 사용한 것은 이해할 만하다. 그래서 저는 SwiftUI Liquid Glass 개발에 정말 많은 도움이 되었다고 생각합니다. 제 생각엔 이건 닉이 예전에 학습에 관한 이런 표현을 언급했던 것과 관련이 있는 것 같아요. 그리고 어디에나 적용 가능합니다. 단순히 프레임워크 간에만 적용되는 것이 아닙니다. 하지만 이러한 개념 안에서도 마찬가지로, 그건 마치 여러분이 배웠을지도 모르는 모든 애니메이션 기법과 같아요. 다른 목적에 적용되는 사항은 이 맥락에서도 동일하게 적용됩니다. 그래서 저는 이것이 삶의 원칙을 보여주는 또 다른 좋은 예라고 생각합니다. 네. 제 생각에는 그건 마치 언제 용기를 사용해야 할지 아는 것과 같아요. 그리고 그런 것들을 아는 것, 다시 말해 기초를 아는 것, 이러한 기반을 아는 것이 계속해서 중요해집니다. 그리고 브랜딩을 어디에 정확히 적용해야 할지 아는 것. 또는 당신의 앱을 특별하게 만드는 것은 무엇인가요? 그리고 시간이 흘러도 변함없이 견고한지 확인하는 것도 중요합니다. 운영 체제는 진화하기 때문에, 그에 맞춰 변화하는 것을 확인하고 싶을 것입니다. 당신이 그런 사람이 아니라는 뜻이에요. 상황에 따라 변경해야 할 작업이 많지 않아서 부담이 없습니다. 앱 아키텍처 설계 방식에 대해 말씀해 주세요. 그래서 만약 여러분이 그러한 특별한 경험들을 적절한 곳에 배치한다면, 그럼 가져가시면 됩니다. 아주 멋진 애니메이션이 있다면요. 좋아요 버튼을 누르면 무언가가 튀어 올라 빙글빙글 돌며 춤을 춥니다. 그러면 모든 플랫폼에서 즉시 적용되고 변화에 매우 강건합니다. 그리고 미래에도 충분히 보장될 것입니다. 네, 개발자들과 워크숍을 하면서 제가 깨달은 점이 있어요. Liquid Glass 워크숍, 만약 탭 뷰와 같은 네이티브 컴포넌트로 개발했더라면 어땠을까 하는 점입니다. 그리고 시스템 제어를 사용하여, iOS 26 으로 다시 컴파일하면 해당 앱들이 자동으로 설정됩니다. UIKit 이든 SwiftUI 이든 상관없이, Liquid Glass 의 모던한 디자인을 활용하기에 더할 나위 없이 좋은 위치에 자리 잡고 있습니다. Apple 플랫폼에서. 그런 다음 다음 단계의 정교화 작업을 시작할 수 있습니다. 그리고 내비게이션이나 브랜딩을 재검토할 수 있는 기회를 생각해 보고 있습니다. 정말 멋진 경험이었어요. 마치 마법 같았어요. 그리고 저는 그게 SwiftUI의 기반에 포함되어 있다는 점이 정말 훌륭하다고 생각합니다. 하나의 틀로서, 현대성을 유지하는 데 방해가 되는 장벽을 제거합니다. 그리고 운영 체제의 정교한 기능을 활용하십시오. 제가 생각하기에 우리가 살펴본 한 가지 방법은 다음과 같습니다. 꼭 해야 할 일에 시간을 투자하세요 앱이 플랫폼의 일부처럼 보이도록 만들기 위해서입니다. 우리는 이를 최대한 줄이고 싶습니다. 그렇게 하면 앱을 진정으로 독창적으로 만드는 요소에 모든 시간을 쏟을 수 있습니다. 그건 그걸 보여주는 아주 좋은 방법이라고 생각해요. 네, 물론입니다. 시스템 구성 요소에 대해 좀 더 자세히 설명해 주시겠어요? 제 생각엔 위시리스트에는 아직 공개할 만한 흥미로운 요소들이 정말 많은 것 같아요. 오늘 마조는 디자인 프레젠테이션에서 샘플 앱에 대해 설명했습니다. 탭과 같은 핵심 시스템 구성 요소가 많이 있습니다. 아이콘에 SF Symbols 사용하여 매우 깔끔하게 유지한 탭 뷰입니다. 그리고 앱이 익숙한 표준 시스템 아키텍처를 활용하도록 합니다. 하지만 우리는 다양한 글꼴을 사용하여 타이포그래피를 활용합니다. 개성과 브랜딩을 표현하기 위해. 사람들이 그러한 상충 관계를 어떻게 헤쳐나가야 할지 조언해 주시겠습니까? 내장 컨트롤을 언제 사용해야 할까요, 아니면 좀 더 개성 있는 표현을 해야 할까요?

오, 그거 좋은데요.

소년. 그리고 고려해야 할 사항이 많습니다. 상황에 따라 다르기 때문입니다. 응. 정말 그래요. 제가 말하려던 건, 그건 정말 어디에 놓느냐에 대한 디자인 결정이라는 거예요. 앱의 어떤 부분이 차별화되기를 원하시나요? 익숙함을 느끼는 게 좋잖아요? 익숙함에는 분명 이점이 있다고 생각해요. 마치 앱을 처음 다운로드하는 사람과 같기 때문입니다. 그들이 그것을 친숙하게 느낄 수 있기를 바라는 거죠. 앱 사용 방법을 따로 배울 필요가 없습니다. 그리고 그런 소소한 경험들이 그들을 끌어들이는 역할을 하죠. 그렇죠? 그게 바로 눈에 띄는 점이에요. 정말 훌륭한 렌즈네요. 그 렌즈로 세상을 보는 건 마치... 러셀 러셀은 정말 많은 일을 했습니다. 그는 다양한 UI 프레젠테이션 컨트롤러와 시트, 그리고 SwiftUI 시트를 만들었습니다. 그리고 판재는 제가 그 용도로 가장 좋아하는 재료 중 하나입니다. 테일러의 지적처럼 사람들은 일이 어떻게 진행될지 그냥 알고 있는 것 같아요. 운영 체제의 핵심 구성 요소라서 정말 망설여집니다. 글로벌 지침을 제공하기 위해. 하지만 직접 시트를 만들려고 하지는 마세요. 그렇죠? 네, 있어요. 아니요, 그건 아니에요. 그건 믿을 만해요. 그리고 이는 단지 저만의 문제가 아닙니다. 너만을 위한 게 아니야. 알았지? 네 말을 믿겠어. 좋아. 최근 몇 가지 질문에는 공통된 주제가 있는 것 같습니다. 점진적 정보 공개는 사용자 관점에서 양쪽 모두에게 만족스러운 방식입니다. 더 많은 것을 사용할수록 좋습니다. 다른 앱들과 마찬가지로 사용자가 더 잘 활용할 수 있습니다. 앱 작동 방식을 이해하세요. 하지만 API에서도, 예를 들어 상위 수준의 시맨틱 컴포넌트를 사용하는 경우처럼, 그러면 둘 다 당신에게 더 친숙하게 느껴질 것입니다. 그리고 앱을 사용하는 모든 사람들은 더욱 잘 적응하게 됩니다. 하지만 개발자 인 당신이 이해하기에도 더 쉽습니다. 왜냐하면, 더 단순하고, 더 높은 차원의 개념입니다. 그리고 만약 당신이 점점 더 많은 건물을 짓는 일에 뛰어든다면 사용 사례에 맞게 해당 기능을 점점 더 맞춤 설정하게 되면, 모든 사람에게 상황이 더욱 복잡해지는데, 어쩌면 그게 당연한 걸지도 모르겠습니다. 하지만 우리는 연속성이 유지되도록 하고 싶습니다. 그래서 비슷한 방식을 더 추가하는 것입니다. 상위 레벨 구성 요소를 적절하게 사용자 정의하여 다음과 같은 문제가 발생하지 않도록 합니다. 완전히 드롭다운 메뉴를 사용하는 것이 매우 중요합니다. 그리고 저는 이것을 연결하고 있었던 것 같아요. 우리가 마지막으로 무슨 말을 하고 있었는지는 모르겠지만. 하지만 아니, 난 느꼈어, 느꼈다고. 그러니까, 문득 떠오른 생각 말이에요. 제 생각에 시스템 구성 요소를 활용해서 할 수 있는 일이 정말 많다는 점입니다. 시트에 대해 이야기하거나 iOS 26 의 멋진 기능 중 일부를 살펴보는 것처럼요. 배경이 종이의 높이에 따라 조금씩 변하는 것처럼요. 시트의 동작을 사용자 지정하는 데 사용할 수 있는 다양한 도구가 있습니다. 그리고 수정자들. 그래서 때때로 다음과 같은 결과가 나올 수 있습니다. 문서를 읽는 데는 약간의 시간이 걸립니다. 그리고 어떤 선택지가 있는지 알아보세요. 그런데 프레젠테이션을 '데텐트'로 설정할 수 있는데, '데텐트'가 맞나요, '데텐트'가 맞나요? 저는 항상 어려움을 겪어요. 그게 제 비밀이에요. 저는 항상 그 문제로 어려움을 겪어요. 이 API의 생성 과정. 단어. 데탕트. 좋아요, 속도를 늦출게요. 그건 멈춤쇠야. 아, 그렇구나. 보세요, 저는요. 마치 마이크로피펫 같았어요. 네, 그랬습니다. 예를 들면. 마이크로피펫. 하지만 아시다시피, API에 내장된 다양한 기능을 활용할 수 있습니다. 정말 정교한 행동을 얻기 위해 그리고 이러한 내장 탐색 도구를 사용자 정의할 수 있습니다. 이러한 내장 컨트롤을 사용하여 앱에 개성을 표현할 수 있습니다. 뷰 수정자, 글꼴 같은 것들 이 시스템 구성 요소로 할 수 있는 일이 정말 많아요. 하지만 여전히 한계가 존재하며, 여러분이 그 한계를 발견하고 저희에게 알려주시기를 바랍니다. 저희는 그러한 제한을 없애기 위해 여러분의 의견에 귀 기울이고 있습니다. 그리고 그것을 더욱 강력하게 만듭니다. 완전 동감이야. 진실. 제가 그녀의 작품, 특히 Liquid Glass 에서 가장 좋아하는 것 중 하나는, 제가 틀렸다면 정정해 주셔야 할지도 모르겠지만, 키가 커짐에 따라, 더욱 불투명해집니다. 하지만 그 판 자체는 유리입니다. 그리고 시트의 높이에 따라, 마치 포근하게 감싸 안기는 것처럼요. 크기에 따라 기기 베젤에 바로 통합되거나 떠 있는 형태로 나타날 수 있습니다. 그리고 그건 마치, 정말, 정말 그래요. 좋네요. 지난 몇 년 동안 스프레드시트에 많은 기능들을 추가해 왔습니다. 당신은 침대의 왕인가요? 이게 맞나요? 아니요. 음,

우리 중에는 해당 부품이 작동하도록 설계 도면을 작업하는 사람들이 많습니다. 응. 아니요, 아름다워요. 저는 이 시스템들이 얼마나 세심하게 만들어졌는지 보는 것이 정말 기쁩니다. iOS 통해 구성 요소들이 새롭게 재구상되었습니다. 26개의 운영 체제와 Liquid Glass 지원합니다. 그리고 제가 살펴보는 것도 재미있었어요. 캣은 앞서 언급했듯이 보는 것의 즐거움을 이야기했습니다. 마음에 드는 앱을 발견했는데... 그리고 "이거 멋있어 보이네"라고 말하는 연습을 하는 거죠. SwiftUI 이용해서 직접 만들어보려고 합니다. 그건 마치 빈 페이지 문제와 비슷해요. 당신도 레이아웃이나 데이터 흐름 관련 기술을 배우고 싶을지도 모릅니다. 어디서부터 시작해야 할지 잘 모르겠어요. 디자인이 필요한지 궁금하시겠죠? 아시다시피, 그게 바로 여러분이 해결해야 할 첫 번째 문제죠. 하지만 스스로 연습해 보는 것도 좋을 것 같습니다. 아무것도 없는 상태에서 스스로 무언가를 만들어내는 것은, 제 생각에는, 경험을 쌓고 학습 내용을 다지는 훌륭한 방법입니다. 응. 정말 그래요. 저도 며칠 전에 iOS 홈 화면에 있는 앱으로 그랬어요. 앱의 흔들림 애니메이션. 예를 들면, 언제. 당신은 무언가를 누르고 있습니다. 네. 그리고 그들은 편집 모드로 고정되고, 그런 식으로 작동하죠. 세 가지 동작을 모두 수행합니다. 누가 이걸 제일 잘하는지 보고 싶어요. 무작위적이에요. 제대로 맞추기가 정말 어려워요. 제 생각엔 러셀인 것 같아요. 네. 러셀. 단순히 반복적인 곡선이 아닙니다. 그래서 SwiftUI 에서 정사각형에 그걸 구현하는 건 꽤 재밌는 연습이에요. 힌트를 하나 드릴게요. 난 네가 갈 거라고 거의 확신해 고급 사용자 지정 애니메이션의 병합 속성이 필요합니다. 저는 바즈 애니메이션을 생각하고 있었어요. 오케이, 좋아요. 네. 애니메이션 더빙 영상에 나오는 내용이에요. 그게 정말 그래요. 단계별 접근 방식도 매우 타당한 방법일 수 있습니다. 봐. 문제를 해결하는 방법도 여러 가지가 있잖아. 저는 그게 정말 재밌을 것 같다고 생각해요. 때때로 저는 어떤 작업을 다시 해보려고 할 때가 있는데, 그럴 때면 한 가지 접근 방식부터 시작할 수도 있습니다. 그리고 그게 어느 정도 있는 것 같고, 저는 계속 나아가면서 배우고 있습니다. 그리고 이러한 점진적인 접근 방식들. 제 생각엔 그건 러셀이 주장했던 점진적 정보공개 방식과 관련된 문제인 것 같아요. 앞서 언급했듯이, 이는 API 설계 자체의 핵심 원칙과 같습니다. 하지만 그건 마치 스스로를 다음 단계로 밀어붙이는 것과 같아요. 뭔가를 시도해 보면, 오, 꽤 근접했네요. 다음에 배우고 실험해 볼 만한 것은 무엇인가요? 원하는 결과에 더욱 가깝게 만들거나 새로운 것을 더하기 위해, 그 안에 독특한 요소가 있나요? 네, 제 생각에는 SwiftUI 경험 수준에 관계없이, 이제 막 시작하는 사람이든 경험이 풍부한 사람이든 상관없이 그리고 그들의 이해를 더욱 공고히 하려고 노력하면서, 배울 것과 발견할 것은 언제나 더 많다. 새로운 API만으로도 그리고 그리고 더욱 흥미로운 방식으로 일을 처리하는 방법을 찾는 것입니다. 네. 정말 멋지네요. 그럼 두 분 모두에게, 그리고 여러분 모두에게 마지막 질문 하나만 드리겠습니다. 오늘 위시리스트와 여러 여행에 대해 많이 이야기했어요. 그리고 이번 여행에서 하고 싶은 것들. 다양한 활동과 여행이 많아요. 다음 휴가는 언제인가요?

저는 올해 스코틀랜드를 꼭 가보고 싶습니다. 저는 한 번도 가본 적이 없어요. 시골 풍경을 보고 싶어요. 운전도 해보고 싶어요. 도로 왼쪽에 있습니다. 그건 당신의 꿈이죠.

스코틀랜드 속어 몇 가지. 가능합니다. 할 수 있어요, 할 수 있다고요. 그게 무슨 뜻일까요? 제 생각엔 그건 뭐랄까, 그런 것 같아요. 네, 더 알아볼게요. 거기에 도착하면 직접 테스트해보고 제대로 작동하는지 확인해야 해요. 청중 중에 아시는 분 계신가요? 나를 찾아오세요. 믹서에서. 정말 멋지네요. 사실 저는 제 것을 잘 모르겠어요. 자, 여기 계신 모든 사수자리 분들께 인사드립니다! 어머, 제 생일이 연휴 기간 중에 있네요. 그래서 여동생이 이번 달 말에 깜짝 여행을 계획했어요. 그리고 우리가 어디로 가는지도 모르겠어요. 그냥 가다 보면 알게 되겠죠. 그건 모험이죠. 그리고 위시리스트에는 그냥 적어두면 돼요. 모든 활동에 물음표가 붙어 있는 것과 같습니다. 마치 난수 생성기 같을 수도 있어요. 앞으로 무슨 일이 일어날지 아무도 모른다. 그것이 미래일 수도 있습니다. 네, 네. 저는 휴가 때 편히 쉬는 걸 좋아하지 않는 사람 중 하나입니다. 아이러니하게 들리겠지만, 저도 그렇게 생각합니다. 당신은 활동적인 휴가객이시군요. 저는 활동적인 휴가를 즐기는 사람입니다. 그래서 우리는 다양한 하이킹을 즐기는 것을 좋아합니다. 그래서 저희가 곧 선보일 것들 중 하나는 바로 이것입니다. 이탈리아 돌로미티 산맥에서 며칠 동안 하이킹을 하기 위해서요. 그게 하나예요. 아직 계획은 없어요. 우리는 언제 그렇게 할 수 있을지 알아내고 싶습니다. 좋네요. 아주 좋을 것 같아요. 우리는 해외 출장이 두 번이나 있고, 러셀, 아주 큰 미스터리도 하나 있어. 어쩌면 당신은 쿠퍼티노나 다른 곳으로 여행을 가고 있을지도 몰라요. 어떻게 될지는 두고 보면 알겠죠. 네, 곧 다시 연락드리겠습니다. 네, 모두 정말 감사합니다. 여러분 모두 저와 함께 그들에게 큰 박수를 보내주시겠어요? 이게 바로 저였어요. 정말 많은 걸 배웠고, SwiftUI 에 대해 이야기하는 건 정말 재밌어요. 고마워요.

SwiftUI 에 대해 더 배우는 건 정말 재밌어요. 기술적인 세부 사항뿐만 아니라 프레임워크에 담긴 이야기까지 포함해서 말입니다.

오늘은 정말 정신없는 하루였어요. 우리는 시각적 레이어부터 시작하여 SwiftUI 의 기본 개념들을 다뤘습니다. 디자인, 레이아웃, 모션부터 데이터 흐름까지 모든 것을 포함합니다. 그리고 모든 단계에서 우리는 그 결정의 이론적 배경을 설명했습니다. 위시리스트와 같은 실제 앱에서는, 제임스 그레이엄은 SwiftUI AllTrails 출시를 어떻게 도왔는지 직접 경험담을 공유했습니다. 또한 이러한 모든 장에 걸쳐 기능을 더욱 효율적으로 유지 관리합니다. 한 가지 분명한 사실은 시간을 내어 투자하라는 것입니다. 그리고 SwiftUI 의 기초를 배우세요. 이 기능을 활용하면 프레임워크를 사용하여 훌륭한 앱을 만들 수 있습니다.

저와 제 동료들은 오늘 Slido에서 저희와 함께 배우는 데 시간을 내주셔서 정말 감사합니다. 저희는 200개가 넘는 질문에 답변했고, 대화를 이어가기 위해, Apple 개발자 포럼 에서 질문해 보세요. SwiftUI 등에 대한 질문.

위시리스트 앱 코드는 다운로드 가능합니다. 앞으로 몇 주 안에 출시될 예정입니다. 정말 재밌는 앱이에요. 다음 여행을 계획 중이시든 아니시든 또는 오늘 발표에서 다룬 연습 문제를 다시 풀어보는 것도 좋습니다.

저와 제 동료들은 특정 영상들을 언급했습니다. 프레젠테이션 중에 관련 자료를 제공하고, 오늘 오후에도 계속해서 자료를 제공할 예정입니다. 자료 링크가 포함된 이메일을 보내드리겠습니다. 계속 학습할 수 있도록 말이죠.

SwiftUI 에 대해 배우는 가장 좋은 방법 중 하나 WWDC 영상들을 통해 다른 기술들에 대해서도 알 수 있습니다.

수백 개의 동영상이 있습니다. 해당 영상들은 Apple 개발자 웹사이트나 개발자 앱에서 시청하실 수 있습니다. 오늘 발표에서 익숙한 얼굴들을 몇몇 보실 수도 있을 겁니다.

정말 정신없는 하루였어요. 하지만 가시기 전에 특별한 손님 한 분이 더 계십니다.

여러분은 그녀를 기조연설에서 본 적이 있을지도 모릅니다. 최근 출시한 Swift Student Challenge 도 포함됩니다. 그녀는 간단한 인사말을 전하고 쇼를 마무리하는 데 도움을 줄 것입니다. Apple 개발자 관계 담당 부사장인 수잔 프레스콧을 환영해 주시기 바랍니다.

여기요!

너무 신나요. 우선, 제 직업부터요. 여러분 모두 자신의 직업을 사랑하시길 바랍니다. 하지만 보시다시피 정말 재밌어요. 오늘 하루 종일 잘 되기를 바랍니다. 그리고 오늘 이 자리에 함께하지 못한 분들도 많이 계십니다. 열정이 넘쳐흐른다 그리고 개발자 커뮤니티에 대한 헌신 이 조직은 전 세계에 걸쳐 활동하고 있습니다. 그리고 오늘 하루가 당신이 그 감정을 진정으로 느낄 수 있었던 날 중 하나였기를 바랍니다. 여기 와주셔서 감사하다는 말씀을 드리고 싶습니다. 물론 이미 감사드린다는 건 확실히 말씀드리지만요. 많은 분들로부터 연락을 받았습니다. 모두에게 감사드리고 싶습니다. 무대에 참여한 사람들 중, AllTrails의 James를 포함하여 이 자리에 함께해 주신 모든 분들께 감사의 마음을 전합니다. 그리고 자신의 경험도 공유하고 있습니다. 그래서 제가 묻고 싶은 건, 오늘 여러분에게 좋은 하루였나요? 비공식 설문조사입니다. 어땠나요?

우리는 로버트 의사규칙처럼 해야 하나요? 이제 야유하고 싶어하는 분들께 나가달라고 부탁드려야겠네요. 아니면 그 부분은 그냥 건너뛸까요? 그 방의 에너지를 느낄 수 있어서 좋았어요. 관객들의 에너지가 느껴졌어요. 그리고 전 그게 정말 좋아요. 리아가 더 자세히 설명해 줄 텐데, 이후에 우리에게 기회가 있습니다. 오늘 이 자리에 직접 오신 분들께서는, 온라인으로 참여해주시는 모든 분들께 감사드립니다. 그리고 그건 아주 중요한 문제입니다. 안녕, 그리고 우리는 너를 사랑해. 주스는 직접 가져오셔야 할 거예요. 왜냐하면 여기서는 모두를 위한 믹서 파티가 열릴 예정이기 때문입니다. 네, 간단한 다과도 준비되어 있습니다. 하지만 제가 생각하기에 가장 흥미로운 부분은 여러분이 만나보신 분들이 바로 그들이라는 점입니다. 무대에 있는 분들과 Apple 엔지니어링 부서에서 일하는 많은 다른 분들 개발자 관계팀이 여러분과 소통하기 위해 여기 있습니다. 그리고 여러분 모두 서로 만날 기회도 갖게 될 것입니다. 왜냐하면 그 커뮤니티는 Apple 중심으로 한 허브 앤 스포크 구조가 아니기 때문입니다. 이건 모두 여러분 덕분이에요. 그리고 우리가 할 수 있는 한 그 일에 참여하는 것이죠. 자, 그럼 이제 마무리를 위해 리사, 리사, 리아에게 마이크를 넘기겠습니다. 고맙다는 말씀 드리고 싶고, 믹서 파티에서 뵙겠습니다. 감사합니다. 응.

모두 감사합니다. 오늘 쿠퍼티노와 온라인에서 함께해 주셔서 감사합니다. 여러분은 우리 개발자 커뮤니티의 심장이자 영혼입니다. 새로운 것을 배우고 다음에 무엇을 탐구해 볼지 아이디어를 얻으셨기를 바랍니다. 현장에 참석하시는 모든 분들께. 잠시 후 밖에서 다과를 나누며 만나요. Apple 엔지니어 및 디자이너와 소통할 수 있는 기회도 있습니다. 직접 만나 뵙든 온라인으로 만나 뵙든, 모든 분들께 인사드립니다. 곧 다시 뵙기를 바랍니다. 온라인이나 가까운 Apple 개발자 센터에서 도움을 받으실 수 있습니다. 감사합니다.