Let'Swift 2018
사이드 프로젝트로 앱스토어 1위 공략하기 - 노수진 님
Hompage: http://soojin.ro
작고 재밌는 아이디어에서 시작하기
새 앱을 다운로드 하는 이유
– 쓰고 있던 앱이 관리되지 않을 때
– 더 (기능이 많은, 적은, 이쁜, 편리한) 앱을 발견했을 때
– 새 아이폰을 샀을 때
비즈니스 모델 정하기
– 본인의 앱의 특성에 맞게 모델을 정해야 함
– 무료도 아닐 수 있음
앱 심사하기
– 리젝은 이의 제기해도 별로 소용이 없었음
사용자 모으기
– 커뮤니티(카페, 클리앙 등)에 홍보
– 앱스토어 순위에 오르고 난 뒤에는 수동으로 광고를 하지 않아도 유입
– 이후 페이스북 유료 광고했지만 비용이 더 큰 구조였지만 앱스토어 순위 유지가 더 이익이었기 때문에 유지
– 리뷰해 준 블로거에는 프로모션 코드를 제공
유저들과 소통하기
– 페이스북 그룹 유지
– 전용 메일로 피드백 받기: SNS보다 더 많은 피드백
– MFMailComposeViewController: 메일 앱에 계정 연동이 되어 있어야 하는 한계
– MailCore2(라이브러리): 좀 더 자유로운 메일
– 업데이트 노트로 상세한 설명
유지 보수
– 심각한 버그가 있을 때는 긴급 리뷰(몇 시간만에 가능)를 사용했음
앱스토어 리뷰 관리하기
– 앱스토어의 별점이 미치는 영향은 생각보다 큼: 적절하게 별점을 남겨주라는 요청을 하자
– 리뷰가 너무 욕이면 리포트를 통해 해결: 검토 후 리뷰가 삭제됨
iOS ❤️ Ruby - 김은영 님
iOS 개발자에게 유용한 Ruby Gem을 소개
Ruby와 Gem
Ruby
– 객체 지향 프로그래밍 언어
– 일본에서 만들어져 모바일을 포함해서 여러 분야에서 활발하게 사용
Gem
– Bundler로 버전관리를 진행
– cocoapods를 사용하는 것과 비슷
Gem 소개
CI Tool: Commit 단위로 컴파일, 테스트, 디플로이를 실행시키는 툴. 예로는 Jenkins, Bitrise가 있다.
Tachikoma: 버전이 고정된 라이브러리 이외에는 계속적인 최신 버전의 업데이트가 필요
– Cocoapods나 Carthage에 의해 관리되는 라이브러리 자동 업데이트 및 PR까지 올려줌
– 커맨드 라인으로 수동으로 실행하거나 CI Tool에 통합되어 자동적으로 실행
Danger: 버전 PR 내 확인사항, Objc 코드, Storyboard 에러 체크
– 사람이 자주 실수하는 것들을 dangerFile에 등록해놓으면 자동으로 체크
– Storyboard 내에 어그러진 것을 확인해줌.
houston: 로컬 푸시를 날릴 수 있음
– USB로 아이폰을 연결해서 디바이스 토큰을 얻은 뒤 푸시 알림을 날릴 수 있음
– AppDelegate에서 device_token을 찾아 push를 날림
tenma: Mile stone 에 따른 dev, master 브런치 제작
– 릴리즈 준비의 자동화 툴: 릴리즈 브랜치를 자동으로 만들어 줌
Fastlane: 앱 스토어 업로드 및 배포
– 앱 스토어 등록 시에 귀찮은 일들을 맡길 수 있음
TDS(Toss Design System) v2 소개 - 이택규 님
Before TDS v2
– 단위단위마다 디자인을 했음
– 디자인을 하기 위해서 미리 재료를 만들었지만 통일된 사용자 경험을 전달해주지 못함
TDSv2 to code
View - View model
– View model에서는 피쳐 개발에 집중
– 프로토콜을 통해 구현하여 확장 가능
Cell as base view
– 모든 TDS 컴포턴트는 UICollectionViewCell의 서브클래스
– 이것을 조합해서 관리
List binding
– 최소한의 layout 프로토콜을 만들어 뷰 모델을 adapter에 바인딩하여 리스트 생성
– cell distribution, alignment
Event emitter protocol
– 컴포넌트에서 발생하는 모든 이벤트를 protocol-base로 처리
외부 Pod으로 관리
– 별도로 컴파일되므로 시간 절약
– 비즈니스 코드가 이곳에 적히는 것을 지양하게 됨
시행착오
- TDS를 사용하면 쉽고 빠르지만 개발자는 효율성을 잃었음
- 비즈니스에 따라 TDS 컴포넌트가 구분되는데 이것을 좀 더 일반화할 수 없을까?
RxRIBs, Multiplatform architecture with Rx - 김남현 님
시간이 걸리더라도 두 플랫폼이 같은 구조를 가지도록 하자.
Factors to consider
– No MVC(mvvm, mvp도 마찬가지)
- 넘어가서 다 못적었다…
RIBs(http://github.com/uber/RIBs)
– Router
– Interactor
– Builder
– Presenter
– View
이렇게 나눠 놓아 Massive View Controller 문제를 해결할 수 있다.
그러나, 진정한 RIB의 강점은 State 관리에 있다.
State tree -> RIB tree
– 앱의 상태를 트리의 형태로 표현한 것
– Viewless, Viewful로 구분
– attach, detach의 형태로 뷰 hierarchy를 표현
RIB tree의 가장 큰 장점은 비즈니스 로직에 따라 상태를 표현할 수 있다는 것
Scope
– Scope를 제한함으로써 불필요한 옵셔널을 줄일 수 있다.
– 정말 필요할 때만 사용하는 프로퍼티를 정의할 수 있다.
ReactorKit으로 RxSwift 시작하기 - 김태준 님
RxSwift, 왜 써요?
– 강력한 비동기 처리: 많은 오퍼레이터들이 제공됨.
– 간결해지는 코드
– 코드 가독성 향상
– 유행…?
RxSwift, 왜 어렵죠?
– 처음 보는 문법과 용어
– 예제마다 다른 코드 스타일
– 검색에서의 어려움
그래서 포기하고 있다가 채팅 프로젝트를 하게됨.
– 비동기 채팅 데이터를 실시간으로 UI에 반영해야 함.
– 순차적인 리퀘스트
ReactorKit
View에서 Action을 Reactor에 날리면 Reactor에서 Mutation을 통해 side-effect를 일으킨 뒤 이것을 다시 View에 반영한다!
– RxSwift에서 권장하는 방식으로 쉽게 작성을 유도
– RxSwift보다 좀 더 정형화된 스타일의 예제를 제공해 주어 공부하기 수월함
– 국내 커뮤니티가 활성화
– RxSwift를 잘 몰라도 쉽게 도입할 수 있음
ReSwift와 함께 Undirectional Architecture - 황재욱 님
ReSwift 톺아보기
– Redux + Swift
– Redux: Flux를 적용한 라이브러리
ReSwift?
중앙 데이터 관리자를 통해 단방향 데이터 흐름을 구현한 라이브러리
단점
– 스레드 세이프하지 않음.
– 전역으로 관리하기 때문에 Decopuling이 어렵다.
– Store가 많은 데이터를 가지고 있기 때문에 규모가 커졌을 때 무거워 짐.
Store
– 앱의 State를 저장하는 중앙 저장소
– 전역으로 선언된 단 하나의 객체여야 함.
Action
– 작업에 대한 정보를 지니는 객체.
Reducer
– Action에 따라 state에 변화를 일으키는 함수
– Side-effect를 일으키지 않는 순수 함수로 선언해야 함.
View: State 변화에 반응하여 view를 보여주는 역할이며 주로 Action을 Dispatch한다.
Unidirectional Architecture는?
아직까지 ReSwift로 정립된 확실한 구조가 없다. 계속해서 대안을 찾다가 찾은 구조가 VIP 아키텍쳐.
RxSwift Internal(Observer와 Event를 중심으로) - 오진성 님
이 세션은 어렵고 깊어서 이해하기가 어려웠다.
GraphQL over Rest API - 이봉원 님
기존의 API 인터페이스
– 소켓 프로그래밍: 할 것이 많고 다수의 사용자에게 보내기 힘듦.
– XML-RPC: XML로 인코딩하여 http로 주고 받기. 형식을 서로 알아야 하는 단점.
– SOAP: XML이 무거움.
– REST: HTTP의 개발 원리를 최대한 이용해서 설계. 그러나 비표준임.
Changed API Landscape
– 효율적인 데이터 로딩이 필요
– 다양한 프론트 플랫폼
GraphQL
– Graph(그래프로 데이터들이 연결되어 있음) + QL(API를 위한 쿼리 언어)
– 페이스북에 의해 만들어진 새 API Standard로 2015년 공식 발표.
– 기존의 API와는 달리 클라이언트가 필요한 필드를 직접 요청할 수 있음.(Declarative Data Fetching)
– Single Endpoint, Single Request
– Strong Type System
Blogging App with GraphQL
– REST API를 통해서는 필요한 정보를 받을 떄마다 요청.
– 그러나, GraphQL에서는 한 번의 쿼리문으로 필요한 데이터를 다 받아올 수 있음.
기존 API의 문제점
– Nested CompletionHandler
– Overfetching problem
– 기존의 REST API 하에서는 불필요한 정보들까지 다 받아와야 하는 문제가 존재
– Too many Endpoint
– Versioning
– Schemeless
– 개발 속도
– 서버에 수정해야 할 사항이 있을 경우 요청을 하고 반영되기까지 기다려야 하지만 그럴 필요가 없음.
Query
– CRUD의 Read
– get이 아닌 post
– 원하는 데이터를 트리의 형태로 변환해 클라이언트에 전달하는 방식이라 할 수 있음
Resource Limitation
– 기존의 요청 횟수로는 맞지 않음
– 대신 Node Limit, Rate Limit
Mutation
– CUD
Subscription
– 서버의 변경이 일어날 때 미리 등록한 내용(데이터)을 클라이언트에 알려주게 됨
– 계속 연결되어야 하기 때문에 Stream의 개념이 사용
SIMD & MPS in Swift - 양승헌 님
“Software is not a platform”: ‘HW를 잘 이해하고 그에 따라 SW를 만들어야 한다’ 라는 뜻.
애플의 Accelerate Framework: 고성능, 에너지 효율적인 작업을 해주는 프레임워크
그 중 simd: Single Instruction, Multiple Data
– 간소화된 벡터 프로그래밍
– 소규모 벡터와 행렬 연산 지원
– 플랫폼 별 타입과 명령어를 추상화 함.
이후에는 어렵고 졸아서 제대로 적지 못했다.