iOS 13 대응 후기
StoreKit 사용하시는 분들 꼭 확인!
TL;DR
iOS 13 대응 아래 3개
Dark Mode 대응
> 라이트 모드 강제: info.plist에서 .light 모드 강제
Modal Presentation 변경 대응
> 기존 presentationStyle 유지: presentationStyle = .fullScreen으로 강제
StoreKit 델리게이트 메소드에서 크래시
> 델리게이트 메소드에서 UI업데이트는 MainThread안에서 하도록 수정
직군별 필요한 질문들
PM
Dark Mode 적용했을때 비지니스 임팩트가 어떻게 생길수 있나? (텍스트가 많은, 슬랙, 노션은 거의 바로 대응함)
인앱 결제 쪽에 이슈가 없나?
Designer
Dark Mode 대응 시, UIComponent 및 색 정리 어떻게 가져가야 하나?
Presentation Style 변경을 통해서 UX 개선 여지 확인
iOS Engineer
Dark Mode: 이거 언제 다 적용하나, 디자이너랑 잘 얘기해보기
Presentation Style, 새로 나온 거 쓰고 싶지만, 디자이너랑 PM 한테 허락 맡고 쓰기
StoreKit 크래시 나는 부분 확인 및 수정
그 외에도 iOS13 올라가면서 컴파일러가 더 빡빡하게 크래시 발생하는 부분 확인하기
iOS 13 릴리즈
iPhone11 Pro 시리즈가 9/20일 출시되기 하루 전날,
9/19에 iOS13가 정식 릴리즈가 되었다.
많은 논란 가운데 현재 iPhone 11 Pro는 높은 판매고를 올리고 있다고 한다. [기사]
이럴수록 iOS 13 대응은 더욱더 중요해진다.
iOS 개발자는 새로운 릴리즈가 출시될 때마다 행복함을 느낀다.
다음은 그 행복들...
신규 iOS SDK로 앱 빌드해서 마주하는 다양한 행복들(신규 iOS 대응 문제들)
min SDK를 올릴 기회
신규 iOS 나온 새로운 기능들 써보기(아니, 정확히는 맛보기?... 당장 프로덕트에는 추가하기 어렵기 때문에?)
이전에 iPhoneX 처음 나올 때도, iOS11에서 노치스크린 대응해야 하는 큰 이벤트가 있었다.
회사 안팎으로 노치스크린 대응 안된 앱 서비스를 가지고 많이들 질타와 응원?을 해주셨었다.
이번 iPhone11 Pro출시와 함께 릴리즈 된 iOS13에서도, iOS11 만큼 준비해야 될 것들이 많아 보이긴 했다.
다음은 잘 알려진 대응할 녀석 2개이다
다크모드 대응
기본 모달 프레젠테이션 변경됨
이제, 가벼운 마음으로 Xcode11 GM을 다운받고,, 차근히 iOS13 대응을 시작하였다.
iOS 13 대응하기
가볍게 시작했지만, 생각보다 가볍지 않았기에 대응하면서의 소소한 배움을 공유하고자 한다.
다크 모드 처리
기본 모달 방식의 변화
StoreKit 관련 크래시
iOS 13 SDK로 처음 올릴 때 발견된 이슈들
iOS 13 올리자마자 확인되는 대표적 UI 이슈들을 아래에 공유한다.
먼저, iOS 13으로 하고, 다크모드를 켜고 앱을 올려보았다.
앞선 말한 크게 2개가 대응이 필요해 보였다.
다크모드
시스템 기본색 사용시 마음대로 흰/검 간에 반전이 자동으로 적용되서 생기는 이슈
모달 프레젠테이션 변경 이슈
기본 모달과 달리 변경된 모달에서는 pull to dismiss 가 가능함
다크 모드
다크 모드의 경우, 이미 WWDC 2019 부터 소개가 되어 많이 알려진 녀석이라 확인해봐야 한다.
Human Interface Guideline(이하 HIG) 에도 새롭게 "Dark Mode" 가 소개가 되었다.
일단, 다크 모드를 쓰는 이유가 컨텐츠에 더 집중시키기 위함이라고 쓰여있다. [HIG 읽어보기]
요즘 많은 앱들이 최대한 무채색을 사용해서 컨텐츠에 집중시키고 있다라는 아티클을 읽었는데, 다크모드도 컨텐츠에 집중시키는 방법의 일환으로써 iOS에서 제공해주는 것으로 보인다.
의도가 어찌됬든, 실제 프로덕션 레벨에서는 다크 및 라이트 두개의 모드에서 다 테스트해보라고 HIG에서 권장하고 있다.
또한 색의 대비?(Contrast)가 적당한지 꼭 확인해보라고 한다. 왜냐하면, 어두운 배경에, 타이틀의 경우에도 어두운 회색이면 잘 안보일테니 말이다.
HIG에서 애플의 의도를 읽어봤으면, 이제 실제 문제를 확인하기 위해서 다크모드에서 앱을 올려보도록 한다.
이미 앞에서 이슈들을 사진으로 살펴 보았다.
이제 문제는 파악했으니, 어떻게 해결할까 고민을 해야한다.
회사의 사정마다 다르겠지만, 다크모드를 바로 대응하는 곳이 있는가 하면, 추후로 미루는 회사도 있는 것 같다. 대부분은 기존의 앱모습 그대로를 유지하는게 목표가 아닐까 한다? (특히, 스타트업?)
그럼에도, 거의 바로 대응한 앱들은 슬랙, 노션, 인스타 정도가 있었다. (내 폰에서 9/20일에 확인 )
이제 다크모드 대응법 2개에 대해서 간략히 짚고 넘어가고자 한다.
1. 기존룩 그대로 유직(라고 쓰고 다크모드 대응 안하고, 라이트모드로 고정시키기라고 읽기)
2. 진짜 다크모등 대응하기
기본적으로 iOS 13대응 하면서, 기존룩을 그대록 유지하는 1번방법을 선택했다.
다크모드 대응1 (a.k.a 기존 그대로 유지시키기)
다크모드 대응2 (a.k.a 진짜 다크모드 대응하기)
다크모드 대응 고수님께서는 아래에, 다크모드 대응 비법을 전수 받고자 합니다. 아래 댓글에 남겨주시면 맥주를 대접합니다.
모달 방식 변화
다크모드 만큼 큰 변화중 하나가, 기본 모달 프레젠테이션 방법의 변경이다.
iOS 13에 들어와서 새로운 presentation style이 추가되었고, 새로운 인터랙션까지 포함하고 있다.
새로운 프레젠테이션 스타일은 사용자가 현재 어느 컨텍스트에서 현재 페이지가 있는지 더 알기 쉽게 표현되고, 페이지를 닫으려고 하는 상황에서, 기존에 여러번 "닫기", "뒤로 가기" 버튼을 누르는 것 대신 pull-to-dismiss 할수 있는 제스쳐를 제공하고 있다.
새로운 프레젠테이션 스타일
새로운 프레젠테이션 스타일 자체는 더 좋은 UX를 고려함이기는 하나, 현재 프로덕트 적용에 있어서 어려움이 있을수 있다.
어려움이 있을수 있는 이유는 크게 2가지의 변경 때문이다.
첫번째, 새로운 모달 방법에서 보여지는 카드가 기존과 사이즈가 다르다
두번째, "pull to dismiss" 인터랙션이 추가됨
사이즈 변경에 따른 어려움
새로운 모달 방법에서 카드 모양으로 보여줌에 따라,
노치 디바이스에서도 보기에 더 유려하고, 검은색 배경으로 모달 컨텍스트도 더 잘 전달할수 있다는 애플의 의도를 알수는 있었다.
그러나, 본질적으로 카드로 인한 사이즈 변경, 정확히는 높이가 줄어들기 때문에 UIComponent가 안보일수도 있고, 그로 인해 UIComponent의 재배치도 고려해봐야하는 이슈가 생긴다.
새로운 Pull To Dismiss 제스쳐
이제 모달뷰를 pull to dismiss 할 수 있게 기본적으로 제공해주고 있다.
기존에도 다양한 서비스에서도 이것을 제공해주기 위해, iOS 개발자들이 고민 많이 해서 개발도 했었다.(특히, ViewController 관한 애니메이션 공부를 많이 했어야 했음)
개발자들의 이런 노고를 이해해준것에 대해서는 고맙지만, 기본적인 UX가 바뀜에 따라 문제가 생기는 경우가 있다.
기존 모달 방식에서는 Close 혹은 Back, Save 버튼을 통해서 뷰 디스미스를 했었다. 이때는 뷰의 디스미스를 버튼을 통해서 타이밍을 잡고, 디스미스 전에 해주어야 할일(파라미터 저장, 패스 등)을 해주었었다. 그런데 새로운 제스쳐 추가에 따라, 디스미스하는 타이밍을 잡아야 하는 길이 하나 더 생겨서 이부분을 처리해주어야 한다. 예를 들어, 기존에는 Save, Cancel등을 통해서 명확히 사용자의 의도를 파악 할수 있었는데, Pull to Dismiss 를 한다고 할때, 사용자가 Save를 원하는지, Cancel을 원하는지 정확히 판단하기 어려워졌다. 따라서, 기존 UX에 대해서 재고해야하는 이슈도 있기 때문에, 바로 적용하기 어려울수 있다.
대응
이번 iOS 13대응에 대해서는 기존 방식을 최대한 유지하자는 차원에서, iOS 12처럼 일단 기본적으로 .fullscreen 방식을 모달을 적용하기로 했다.
앱내에 모달이 몇십개 정도로 많지 않기 때문에, 프레젠팅시 modalPresentationStyle = .fullscreen 로 변경해서 대응해주었다.
구현은 아래와 같이 한다.
StoreKit 크래시
iOS13 대응하면서, 나름 크리티컬 했던 부분이 StoreKit 관련 크래시 대응이었다.
프로덕트에 앱내 구매가 있는 경우(디지털 제품), StoreKit을 이용이 필수이다.
기본적으로 StoreKit으로 아래의 3가지는 꼭 구현해줘야 한다
인앱 상품 요청
인앱 상품 결제
인앱 상품 복원
애플의 많은 framework을 사용하다보면 발견할수 있는 것이, 델리게이트 패턴을 많이 사용하는 것을 확인할 수 있다.
StoreKit에서도 어김없이 델리게이트 패턴을 사용하여, 상품 요청, 상품 결제, 상품 복원을 구현하도록 되어 있다.
구체적인 예로, 인앱 상품 요청의 경우는 아래의 흐름을 따른다
SKProductsRequest 객체 생성
SKProductsRequest 객체 델리게이트 지정
SKProductsRequest 객체의 start() 메소드 호출 (인앱 상품 요청)
성공 및 실패시 델리게이트 메소드 호출
코드로 구현하면 대충 애래와 비슷하게 구현됨.
특히, 델리게이트 메소드 호출시, 결과에 맞는 UI 업데이트 코드를 수행하도록 구현하였다.
문제는 iOS13 SDK로 빌드한 경우, 델리게이트 메소드에서 UI코드를 수행하는 경우 크래시가 났었다.
결론적으로, 델리게이트 메소드에서 호출되는 closure 코드에 DispatchQueue.main.async { }
를 명시적으로 달아줏어서 크래시는 해결함
좀더 원인을 자세히 파악하기 위해 몇가지 가설이 생각났었다.
첫번째 가설
> iOS13 SDK에서는 MainThreadChecker가 더이상 워닝따위 주지 않고 빡빡하게 크래시를 낸다
그래서, 네트워크(URLSession) 및 백그라운드(DispatchQueue.global(qos: .background)) 에서 UI 업데이트 코드 수행해봄.
결과적으로는 MainThreadChecker가 워닝 잘주고 있음.
두번째 가설
> iOS13 SDK에서는 StoreKit에서 delegate 메소드 호출시, UI 코드 업데이트시 명확하게 Main스레드에서 수행안할 경우 크래시남
개인적으로 수행해본 실험에서 두번째 가설이 맞는 것으로 확인. 상품 요청, 상품 결제, 상품 복원 관련 델리게이트 메소드에서 UI 코드 업데이트시 크래시가 남을 확인함.
StoreKit 크래시 관련해서 단편적인 몇몇 시나리오만 확인해서 일반화 하기 어렵지만, StoreKit 관련 델리게이트 메소드에서는 UI 업데이트 코드 수행시, MainThreadChecker로 warning 주는 대신 크래시를 주는것으로 확인
추가적으로, SKStoreProductViewController 은 iOS13 SDK 이후로, subclassing 지원 하지 않음 [공식 다큐먼트]
Important !
If you compile with the iOS 13 SDK, attempting to instantiate a subclass of SKStorProductViewController results in a runtime exception.
- Apple
StoreKit 뿐만 아니라, Complier 자체가 빡빡해져서, 이제 워닝으로 안봐주는 문제들이 있는 것으로 보임.
실제로, AVFoundation관련해서도 가끔씩 발생하던 크래시가 iOS13 올라가자마자 급증했었고, 리팩터링을 통해서 좀더 깔끔하게 짜니까 말끔하게 사라짐. 애플 덕분에 기술부채 강제로 처리하게됨.
회사 내부 뿐만 아니라, 외부에서도 애플덕분에 강제 기술부채 해결하고 있는중임.
StoreKit 이슈로 twitter의 mopub-ios-sdk에도 이슈가 올라와서 수정되었음.
Google의 admob-ios-sdk도 이슈가 있어서, 원성이 자자함 아직 수정 진행중인것으로 확인됨.
결론
다크 모드 대응
일단, 라이트 모드 강제 하고
비지니스 임팩트가 있으면, 대응 하자
대응 할때, 디자이너와 협업이 중요할듯
프레젠테이션 스타일 변경 대응
일단, 기존 방식(fullscreen)으로 대응
새로운 automatic 방식은 UX 디자이너와 상의해서 개선해보기
StoreKit 크래시 대응
델리게이트 메소드 호출시, UI Code는 명시적으로 MainThread에서 수행
기타
iOS 13 SDK 에서 전반적으로 워닝으로 너그럽게 넘겨주던 녀석들을 이제는 빡빡하게 잡고, 수틀리면 크래시 내고 있음
크래시가 나는 케이스들 이참에 리팩터링해서 기술 부채 없애자
p.s.
추가 생각 및 의견은 언제든지 환영합니다.
코드 스니핏 못 넣는 것은 너무 힘듭니다. (브런치 팀 화이팅)
Hiring !!
현재 딜라이트룸에서는 Business Driven Developing에 관심있는 개발자들을 찾고 있습니다.
jason@delightroom.com 으로 핑주시면 감사하겠습니다.
꼭 채용 말고도, Business Driven Design, Developing에 관심 많으신 분들은 핑주시면, 커피 한잔하면서 재미난 얘기할 준비는 항상 되어있습니다 :)
채용 직군
- product designer (병특, 전문연구요원 포함)
- iOS engineer (병특, 전문연구요원 포함)
- android engineer (병특, 전문연구요원 포함)
- backend engineer (병특, 전문연구요원 포함)
딜라이트룸이 궁금하시면 아래글 참고
https://medium.com/delightroom/알라미-그게-뭐하는-앱인데-c36d4f7985e
