안녕하세요. 에이닷 iOS App을 개발하고 있는 김혜지입니다.현재 저희 팀은 SwiftUI로 에이닷 iOS app을 개발하고 있습니다.SwiftUI는 아직 그 역사가 짧다 보니 예상치 못한 문제들이나 어떻게 개발하는 것이 맞는지에 대한 고민이 잦은데요🥲이번 포스팅 역시 팀원분들과 이야기하다 나온 주제에서 영감을 얻었습니다.SwiftUI로 개발하다 보면 아래와 같이 에 helper property로 를 만드는 경우가 있습니다.와 에서 를 생성했을 때의 차이가 있다는 것을 알게되어 여러분께 한 번 말씀드려보고자 이 글을 쓰게 되었습니다.SwiftUI로 개발하고 계시거나 Swift Concurrency를 사용하시는 개발자 분들이라면 관심을 가지실 주제일 것 같습니다이 글은 SwiftUI와 Actor isolation을 포함한 Swift Concurrency를 이해하고 계시면 더욱 읽기 좋습니다.SwiftUI로 개발하면서 modifier 참 많이 사용하는데요. 혹시 이 modifier는 어느 쓰레드에서 실행이 되는지 아시나요?아래 코드의 주석 // 1과 // 2 모두 main thread 에서 실행되는 것이 보장될까요?새로 추가한 method는 로 annotate 되어 main thread에 대한 isolation이 보장된 곳에서만 호출이 가능합니다.를 키워드 없이 호출할 수 있는 가 main actor isolation, 즉 main thread에서 실행이 보장된 곳이겠죠.• None 1번 : main thread 에서의 실행이 보장됨• None 2번 : main thread 에서의 실행이 보장되지 않음사실 1번 의 main thread 실행은 당연한 것입니다. 이유는 다음과 같습니다.• None 의 파라미터는 로 annotate 되어 있음.하나씩 자세히 알아보겠습니다.의 정의는 다음과 같습니다.는 라고 명시적으로 annotate 되어있네요...2. 의 파라미터는 로 annotate 되어 있음modifier의 정의만으로는 파라미터에 대한 비밀을 알 수가 없군요... 그래서 SwiftUI module interface를 한 번 열어보았습니다.로 annotate 되어 있네요. annotation은 클로져들이 actor context를 inherit 하게 만들어줍니다.하지만 2번 도 때로는 main thread에서 도는 것이 보장될 수도 있습니다.위 코드를 빌드해보면 2번 task 에서도 async 키워드 없이도 test 메소드를 호출할 수 있는 것을 확인할 수 있습니다.이게 왜 되는지 결론부터 말하자면 global actor inference에 의해 를 갖고 있는 우리의 가 가 되었기 때문인데요...이 기묘한 상황을 이해하기 위해 Swift Evolution의 문서를 바탕으로 Global Actor Inference에 대해 간단하게 이야기 해보겠습니다.라고 합니다. 내가 global actor로 명시하지 않은 곳들에서도 global actor isolation이 추론(infer)될 수 있다고 하네요. 조금 더 읽어보겠습니다.actor-quali

저는 에이닷 서비스 내 활용되는 디자인 시스템을 개발 및 관리하고 있습니다.이번에 신규 디자인 시스템을 구축하면서 많은 기술적 고민들이 있었는데요.이런 고민들을 해결했던 저만의 방법들을 공유드리기 위해 포스팅을 진행하려고 합니다.첫번째 주제는 Swift Package Manager를 이용한 안정적인 라이브러리 배포 전략입니다.포스팅은 다음과 같은 순서로 진행될 예정입니다.• None 라이브러리 배포 전략이 필요한 이유라이브러리 전략이 필요한 이유UX 컨설팅으로 저명한 Neilsen Norman Group의 정의에 따르면,디자인 시스템이란 재사용 가능한 컴포넌트와 패턴을 활용하여 대규모 디자인을 관리하기 위한 표준 집합 을 의미합니다.다양한 팀에서 공통의 언어를 사용하여 시각적 일관성을 만들기 위해,저는 이라는 디자인 패키지를 활용하여 공통 스타일/컴포넌트 인터페이스를 배포하고 있습니다.에이닷이 업데이트되고 신규 기능이 추가되면서, 디자인 시스템 내부에서도 자연스럽게 변화가 생기게 되는데요.업데이트 된 디자인 시스템이 여러 프로젝트에서 안정적으로 적용되기 위해서는,시스템 관리자는 하위 호환성을 고려한 버전 관리 전략을 수립하고 이에 맞는 인터페이스를 제공해야 합니다.Semantic Versioning은 패키지의 버전 번호를 어떻게 정하고 올려야 하는지에 대한 규칙과 요구사항을 정리해놓은 버전 관리 방식입니다.시스템 규모가 커지고, 많은 패키지를 사용할수록 의존성이 중요해지게 되는데요. 이러한 규칙들을 통해 업데이트 된 API 변경 사항을 예상하고 적절하게 버전 관리를 할 수 있습니다.• None 메이저 버전 (1.x.x) : 기존 버전과 호환되지 않게 API가 변경됨.• None 마이너 버전 (x.1.x) : 기존 버전과 호환되면서 새로운 기능이 추가됨.Semantic Versioning 을 사용하여 버전 관리를 했을 경우, 개발팀과의 의사소통에는 문제가 없었습니다.하지만 디자인팀에서도 (Figma 가이드 배포 시) 버전 관리 규칙이 있었기 때문에, 개발 버전에 반영되었는지 확인 시에 어려움이 있었습니다.(Figma) 2.0.1 버전 반영사항은 (SDK 기준) 1.3.12 버전에 반영되었습니다.이러한 버전 차이는 앞으로도 더 벌어질 것이라고 판단했고, 개발/디자인 팀 사이의 커뮤니케이션 비용을 늘릴 것이라고 예상했습니다.그래서 커뮤니케이션 오류를 줄일 수 있도록 버전은 동일하게 사용하고,pre-release 라벨을 통하여 개발 반영사항을 전달하도록 관리하고 있습니다.이러한 전략을 통해 개발/개발, 개발/디자인 팀 모두와 원활하게 커뮤니케이션 할 수 있었습니다.Swift Package Manager의 의존성 관리 시에, 앞서 소개드린 Semantic Versioning를 활용하여 버전 관리를 할 수 있습니다.파일 내부에 dependencies 섹션에서 패키지의 버전을 관리할 수 있습니다. Swift 에서는 다양한 버전 범위 관리 방법을 제공하고 있습니다.• None from 키워드는 특정 버전 이상의 패키지 버전을 사용할 때 사용됩니다.•

스포카 iOS 플랫폼에서는 Clean Swift 아키텍처를 기반으로 키친보드와 키친보드 유통사 iOS 앱을 개발하고 있습니다.Clean Swift란, Uncle Bob의 클린 아키텍처를 iOS, MacOS 플랫폼에 맞게 적용한 형태의 아키텍처입니다.이 글에서는 스포카에서 Clean Swift 기반으로 iOS 앱을 개발하며 겪었던 어려움과 이를 어떻게 개선하였는지에 대한 내용을 다루어보겠습니다.왜 Clean Swift를 채택하는가?Clean Swift 아키텍처를 제품 개발에 꾸준히 사용한 이유는 아래와 같습니다.• 키친보드 iOS 앱의 아키텍처는 언제든지 바뀔 수 있다.• 스포카 모바일 챕터는 규모가 크지 않습니다. 그래서 추후 여러 사람과 공동으로 작업하게 되었을때 손쉽게 다른 아키텍처를 결합하거나, 현재의 아키텍처를 개선할 수 있어야한다고 보았습니다.• Clean Swift가 추구하는 프레임워크가 아닌 템플릿으로 만들어지는 아키텍처 구조는 특정 아키텍처에 강하게 결합되지 않도록 도와주었고 이는 개선에도 용이하였습니다.• 키친보드 iOS 앱은 로직의 복잡도가 높다.• 키친보드 서비스는 무거운 도메인들과 관리되어야하는 케이스가 다소 존재하는 편입니다. 저희는 이러한 로직의 복잡도가 UI의 복잡도보다 높다고 판단하였습니다.• 클린 아키텍처를 기반으로 한 Clean Swift는 iOS 플랫폼에 특화된 고수준과 저수준을 분리하는 방식을 제시합니다.• 이러한 고수준 비즈니스 논리의 분리가 키친보드 iOS 앱 코드의 복잡도를 낮출 수 있었습니다.그러나 Clean Swift를 적용하며 마주한 문제가 있었습니다.저희가 마주한 Clean Swift의 문제점은 발전하는 iOS 문제였습니다.iOS 플랫폼은 끊임없이 발전을 거듭했습니다. SwiftUI의 등장, 상태 관리의 중요성 대두, 새로운 비동기 처리 방식의 도입 등 Swift 언어와 패러다임은 다소 많은 변화를 거쳤습니다.iOS 플랫폼의 클린 아키텍처라는 말이 무색하게 2015년에 발표된 Clean Swift는 2024년의 iOS 플랫폼에는 맞지 않게 된 것이었습니다.이러한 Clean Swift의 문제점을 마주하여 새로운 기술 도입에 어려움을 겪었고, 새로운 아키텍처로의 변경을 생각하기도 했었습니다.그러나 앞서 언급드린 프레임워크가 아닌 템플릿, 고수준과 저수준 분리 등 Clean Swift에서 제시하는 방향성은 여전히 유효하여 깊은 고민이 되었습니다.Clean Swift를 만든 Raymond는 블로그에서 아래와 같은 말을 하였습니다.Raymond의 말처럼, 저희는 Swift 언어가 지속적으로 발전하는 만큼 더 나은 방법을 찾아 나아가야한다고 보았습니다. 그래서 Clean Swift를 변형하여 언어와 패러다임의 발전에 맞추는 여러 시도들을 해보았습니다.이 글에서는 저희가 설계한 완벽하진 않지만 더 나은 방법(better ways)의 Clean Swift를 소개해 드려 보고자 합니다.먼저 개선한 Clean Swift의 설계 목표로 기존의 장점들을 포함한 다음의 4가지를 선정하였습니다.• Single Re

안녕하세요. LINE Plus iOS Platform Dev 팀에서 iOS 개발을 하고 있는 김윤재입니다. 2021년에 Swift Concurrency가 등장했을 때 LINE Engineering 블로그에 Swift Concurrency를 소개하는 글(Swift Concurrency에 대해서)을 남겼습니다. 어느덧 글을 쓴 지 2년이 지났네요. 당시에는 주로 Swift Concurrency의 장점을 소개했는데요. 이번 글에서는 최근 팀에서 Swift Concurrency를 적용할 때 성능 관점에서 어떤 점을 주의해야 할지 스터디를 진행하며 알게 된 점을 공유하려고 합니다.Swift Concurrency의 두 가지 특징성능 관점에서 주의해야 할 점을 살펴보기 전에 Swift Concurrency 내부 작동 방식의 두 가지 특징인 TaskPriority와 Suspension points를 먼저 살펴보겠습니다.TaskPriority 작동 방식Swift Concurrency에는 GCD(Grand Central Dispatch)의 QoS(Quality of Service)와 같은 역할을 하는 TaskPriority가 있습니다. 아래는 Swift TaskPriority와 GCD QoS를 서로 상응하는 우선순위에 맞게 배치한 표입니다. 같은 행에 속하면 같은 우선순위입니다.QoS(GCD) TaskPriority(Swift Concurrency) Userinitiated High Default Medium Utility LowSwift Concurrency의 장점 중 하나로 소개된 것이 스레드를 코어 수만큼만 사용해서 콘텍스트 스위칭이 적다는 것이었습니다(참고: WWDC 2021: Swift Concurrency - Behind the Scenes). 그렇다면 스레드 숫자가 코어 수로 제한되는 상황에서 우선순위에 따른 스케줄링을 어떻게 진행하는지 아래와 같은 의문이 들었습니다.우선순위가 다양한 작업이 있을 때 OS는 어떤 방식으로 각 작업에 스레드를 할당할까?우선순위가 더 높은 작업이 많을 때 우선순위가 낮은 작업은 어떻게 실행을 보장받을까?이 의문을 해결하기 위해 우선순위가 높은 작업을 먼저 실행한 뒤 낮은 작업을 실행해 결과를 살펴보고, 다음에는 우선순위가 낮은 작업부터 실행해서 결과를 살펴봤습니다.우선순위가 높은 작업부터 추가했을 때 스레드 할당 방식먼저 TaskPriority가 High인 작업들을 추가한 뒤, 이어서 Low인 작업들을 추가하는 방식으로 테스트를 진행했습니다. 테스트는 코어가 6개인 iPhone 12 Pro 기기로 진행했습니다. 따라서 Swift Concurrency에서 스레드를 6개 사용할 것이라고 판단, High 작업을 6개 추가한 뒤 Low 작업을 6개 추가했습니다.Xcode Instruments에서 Swift Concurrency 프로파일링 템플릿을 이용해 진행한 프로파일링 결과 중 두 가지, 작업 상태(Task states)와 스레드(Threads) 결과를 살펴보겠습니다.먼저 작업 상태는 아래와 같이 나타났습니다. 상위