안녕하세요! iOS 앱 개발자로 일하고 있는 Evan 입니다. 보통 iOS 앱을 개발한다 하면 Objective-C, Swift 이렇게 2개 언어가 생각이 나실텐데요, 이 둘이 구체적으로 서로 어떻게 다르고 Swift 에서는 무엇이 더 발전된 것인지 많은 분들께서 궁금해하셨을 것 같습니다. 이번 포스팅에서는 이 둘의 차이점에 대해서 알려드리고자 합니다.  Swift 의 탄생 배경iOS 앱은 원래 1984년에 출시된 Objective-C 언어로 개발이 되어왔었습니다. C 언어 기반에 특이한 스몰토크 형식의 객체지향 개념이 추가된 언어이죠. C 언어의 포인터, 객체지향, 스몰토크? 이렇게만 들어도 꽤나 어려워 보입니다. 오랜 세월동안 안정화되었지만 배우기가 어렵고 개발자가 직접 메모리 관리와 같은 성능 개선을 많이 해야만 했습니다. 이는 아이디어를 가진 많은 앱 개발자들의 앱 출시에 걸림돌이 될 수밖에 없었습니다. 이에 애플은 Objective-C 에서 어려운 C 를 걷어내고 최신 언어의 장점을 다수 반영한 새로운 언어를 만들기로 결심합니다. [ WWDC14 Swift 출시 발표 장면 ] 애플은 개발자들이 더 “쉽고 빠르게” 앱 개발을 하여 앱스토어를 보다 더 활성화시키고 싶어했습니다. 그래서 이름도 “빠르게” 라는 의미가 담긴 “Swift” 로 지었던 것입니다. 그럼 이제 무엇이 더 발전된 것인지 살펴보도록 하겠습니다.  주요 차이점[ 주요 차이점 표 ] 요약하자면, Swift 는 개발 입문자들도 개발이 가능하도록 설계된 상대적으로 “쉬운” 언어이며 기존의 C 언어와 Objective-C 와도 완벽히 호환됩니다. 간단한 예제 코드를 보여드리겠습니다. [ Objective-C 코드 ] [ Swift 코드 ] Objective-C 는 생소한 스몰토크 문법으로 대괄호 [] 와 : 콜론을 사용하여 nil (NULL) 값을 처리하고 있습니다.이에 반해 Swift 는 익순한 문법인 점 . 을 사용하고 있으며 Optional 개념으로 물음표 ? 를 통해 nil 값 처리를 단 한줄로 처리하고 있습니다.  Optional 이란?여기에서 Optional 이 도대체 뭐지 라고 굉장히 생소해하시는 분들 많으실 텐데요, 이것은 Swift 가 사전에 앱이 죽는 것을 방지하고 매우 “안전” 한 언어로 만들기 위하여 도입한 새로운 개념입니다.Optional 타입 객체는 nil 값이 있는 경우와 없는 경우로 나뉘며, nil 값이 존재할 가능성이 있는 모든 변수에 자동 설정되며 수동으로 선언할 수도 있습니다.기존 Objective-C 에서는 nil 값으로 인해 예외처리를 하지 않으면 앱이 실행 중에 죽는 경우가 많았는데요, Swift 에서는 앱이 실행되기 이전에 컴파일 타임에서 자동으로 설정된 Optional 객체의 nil 값 반환을 통해 오류를 사전에 감지하여 안전성을 보장합니다.  현대적인 Swift 의 특징[ Modern Swift ] 언어를 새로 만드는 과정에서 애플은 파이썬과 같은 현대 프로그래밍 언어의 특성을 다수 반영하였습니다. 클로저, 제네릭, 타입 추론,

안녕하세요! 카페앱개발파트에서 iOS 개발을 하고 있는 셀린(Celine.jin)입니다. 이번에 카페앱 iOS 프로젝트에 종속성 관리를 위한 Apple의 공식 도구인 Swift Package Manager을 도입하여, 이에 대한 경험을 공유하고자 합니다. 이번 글에서는 Swift Package Manager를 도입한 이유와 사용법, 내부 빌드 과정에 대해 알아보겠습니다. SWIFT PACKAGE MANAGER 소개 SWIFT PACKAGE MANAGER란? Swift Package Manager(SwiftPM)는 종속성 관리를 위한 Apple의 공식 도구입니다. Cocoapods이나 Carthage와 같은 3rd party tool이 아닌 1st party로서, Xcode11에 내재된 기능으로 추가가 되었습니다. 애플에서 Swift Package Manager를 만든 이유는 Swift 생태계의 성장을 위해서입니다. Swift는 cross-platform 언어이고, 해당 언어를 지원하는 플랫폼에서 일관된 방식으로 코드를 구성하고 실행할 수 있는 툴이 필요했습니다. 그리고 Swift로 작성된 라이브러리가 쉽게 배포되고 사용되면서 성장하는 Swift 언어의 미래를 위해 해당 도구가 만들어졌습니다. Swift Package Manager는 자체 빌드 시스템이 포함되어 있고, 소프트웨어의 구성과 테스트, 실행까지 포함하고 있습니다. 그리고 라이브러리를 배포하는 방법에 대한 새로운 표준을 정의하였습니다. SWIFT PACKAGE MANAGER 도입 배경 카페 iOS 프로젝트에 Swift Package Manager를 도입한 이유는 다음과 같습니다. 1. 모듈화: 이번 카페에 규모 있는 프로젝트가 진행 중이어서 빌드 속도 등 여러 가지 개발 개선을 위해 모듈화를 하기로 결정하였습니다. 2. Dependency 관리: 기존 카페 프로젝트에는 종속성 도구로 Cocoapods를 사용하고 있었습니다. 모듈화 구조를 고민할 때 Xcode의 framework로 내부 프로젝트를 만들고, Cocoapods를 사용하여 종속성 관리를 진행해 보았습니다. 그러나 이 구조는 내부 framework에 추가된 pod dependency를 다른 framework에서 사용할 때 그 dependency를 Podfile에 다른 framework 대상으로 수동으로 추가해야 한다는 단점이 있었습니다. SwiftPM은 내부 모듈에 사용되는 dependency를 자동으로 관리해 주고, dependency를 추가 또는 변경할 때마다 pod install이라는 부가 작업을 하지 않아도 됩니다. 3. 1st party: 공식 도구이므로 애플 주최하에 미래적으로 계속 발전이 될 종속성 도구입니다. 4. 새로운 기술 도입: 모듈화 구조를 처음 진행하는 것이었고 기술 제한이 따로 없었으므로 해당 기술을 도입해 보자는 의견을 제시하였습니다. SWIFT PACKAGE MANAGER 사용법 그럼 프로젝트에 Package를 추가하는 대표적인 방법과 Package를 생성하는 방법에 대해 알아보겠습니다. 프로

최근 몇 년 동안 LINE 앱의 iOS 소스 트리는 지속적으로 성장해 수백 개의 모듈로 늘어났습니다. iOS 버전의 소스 코드는 2019년 말 기준으로 140만 줄을 넘어섰으며, 이러한 증가세는 멈출 기미가 보이지 않습니다. 그 결과 LINE iOS 버전의 빌드 시간이 크게 증가했습니다. 또한 프로젝트의 규모가 커지면서 로컬 환경에서는 문제 없이 실행되는 빌드가 CI에서는 실행되지 않거나 혹은 그 반대의 경우가 발생하는 것과 같은 재현 불가능한 문제점도 늘어났습니다. 그래서 저희는 잠시 한 발자국 뒤로 물러나 빌드 성능을 개선하고 문제의 재현 가능성을 높일 수 있는 방법에 대해 고민해 보았습니다.  의존성 관리 개선 저희 팀에서는 2012년 말에 의존성 관리 도구인 CocoaPods를 도입했습니다. CocoaPods는 프로젝트를 클린 빌드할 때마다 모든 pod 라이브러리를 다시 빌드해야 하므로 많은 시간이 소요되는 단점이 있지만(대부분의 라이브러리가 Objective-C로 구현되었다면 큰 문제가 아닐 수 있습니다), Xcode와 잘 연동되고 외부 라이브러리의 소스 코드를 마치 내 소스 코드처럼 보고 디버깅할 수 있는 훌륭한 오픈 소스 소프트웨어입니다. 이후 저희 팀과 프로젝트가 확대되었고, Swift의 시대가 도래했습니다. 저희 팀은 버전 1.0 시절부터 Swift를 사용했는데요. 처음 3년 동안엔 Swift 의존성을 사용하지 않고 버틸 수 있었습니다만, 결국 한계에 도달해서 어쩔 수 없이 Swift 의존성 관리 도구인 Carthage를 도입해 CocoaPods와 함께 사용했습니다. CocoaPods와는 달리, Carthage에는 설정이 거의 없었습니다. Carthage는 프레임워크처럼 의존성을 사전에 빌드만 해 줄 뿐, 프로젝트에 통합시키는 것은 개발자의 몫이었기 때문입니다.  의존성 빌드는 크게 두 가지 방법으로 진행할 수 있습니다. Carthage를 통해 사전에 빌드된 아티팩트(artifact)를 GitHub에서 다운로드하거나 로컬에서 빌드하는 것입니다. GitHub에서 임의의 바이너리 파일을 다운로드하는 것은 보안상 지양하고 있고, 앱 성능도 고려하여 저희는 모든 의존성을 정적 프레임워크로 빌드하는 방법을 선택했습니다. 이에 따라 개발자들은 모든 의존성을 본인의 로컬 작업 환경에서 빌드하게 되었습니다. Carthage는 보이지 않는 곳에서 Xcode를 실행시켜 모든 의존성을 팻(fat) 바이너리로 빌드하는데요. 이때 지원하는 모든 아키텍처에 대해 이 과정을 반복합니다. 만약 현재까지 iOS 10을 지원하고 있다면, 4개의 아키텍처를 위해 각 의존성을 총 4번 빌드해야 합니다. 또한 Xcode의 아카이브 액션은 자체 설계에 따라 항상 완전한, 클린 빌드를 하도록 되어 있습니다. 이런 이유로 빌드 작업은 꽤 오랜 시간이 걸렸습니다. 몇 개의 의존성을 업데이트하느냐에 따라 달라졌는데 대략 15분에서 20분 정도 소요되었습니다. 만약 모든 사람이 위와 같이 동일한 코드를 각각 반복적으로 빌드해야 한다면 엄청난 자원이 낭비될 텐데요. 다

LINE SDK 개발팀의 Wei Wang입니다. 저희는 작년 LINE DEVELOPER DAY 2018에서 새로운 LINE SDK for iOS와 LINE SDK for Android를 오픈소스로 배포했습니다. 이 SDK는 LINE 로그인과 몇 가지 API를 앱에 통합하는 기능을 제공하는데요. 이를 통해 각 앱에 따라 매력적인 사용자 경험을 만들 수 있습니다. 저희는 배포를 마친 후 게임 개발자에 대한 지원도 필요하다는 점을 깨달았습니다. 게임은 App Store와 Google Play 전체 앱 중 50% 이상을 차지하며 압도적인 수익을 창출하고 있습니다. 그래서 저희는 또 하나의 중요한 플랫폼인 Unity용 LINE SDK를 개발하기로 결정했습니다. LINE SDK for Unity는 게임 개발자가 혁신적인 차기 게임 타이틀을 개발하면서 LINE SDK를 좀 더 쉽게 사용할 수 있도록 설계했습니다. 이번 글에서는 기존 SDK for Unity를 랩핑(wrapping)하기 위해 저희가 시도했던 방법을 소개하고, iOS와 Android에 LINE SDK를 통합하는 방법을 이야기하려 합니다. LINE SDK for iOS와 LINE SDK for Android처럼 LINE SDK for Unity도 오픈소스입니다. 코드는 GitHub에서 확인할 수 있고, Unity 게임에서 LINE SDK를 사용하는 방법은 셋업 가이드를 참조해 주시기 바랍니다. 개요 저희는 Unity SDK를 제공하면서 기존 iOS와 Android용 네이티브(native) SDK를 랩핑하여 사용자가 쓰기 편한 C# 인터페이스를 제공하기로 결정했습니다. SDK 전체를 다시 구현하지 않고 기존 기능을 랩핑하면 다음과 같은 이점이 있습니다. 유지관리 비용이 절감됩니다. 기존 네이티브 SDK 코드를 재사용하면 유지관리 비용을 줄일 수 있습니다. LINE SDK는 오픈소스로 공개되어 보급률이 높고 평판도 아주 좋습니다. 네이티브 SDK를 사용하면 프로젝트의 품질이 확보될 뿐만 아니라, 네이티브 SDK의 새로운 기능이나 수정사항이 Unity SDK에 동기화됩니다. 네이티브 기능을 활용할 수 있습니다. LINE SDK의 로그인 기능을 사용하려면 LINE 앱이 설치되지 않은 경우에 사용하는 웹 뷰(WebView) 로그인이나 다른 앱과의 데이터 전송 처리 등 시스템 플랫폼의 다양한 기능이 필요합니다. 네이티브 SDK를 사용하면 이러한 문제를 네이티브에서 적절하게 대처할 수 있습니다.익숙한 조작 방법을 제공합니다. 모델과 API 정의를 C# 레벨로 제공하기 때문에 Unity 사용자는 iOS 플랫폼과 Android 플랫폼 간 차이에 상관 없이 C# 규칙대로 LINE SDK를 사용할 수 있습니다. LINE SDK for Unity의 기본 구조는 다음과 같습니다. 구현 방법 LINE SDK for Unity 구현 방법에 대해 설명하겠습니다(전체 소스코드는 GitHub에 공개되어 있습니다). Unity용 네이티브 플러그인 Unity에서는 광범위한 네이티브 플러그인이 지원됩니다. 네이티브 LINE