[iOS-factor] V. 원격보다 로컬 선호하기
가능하다면 iOS 앱을 백엔드 없이도 잘 작동하는 똑똑한 앱으로 만드세요.
2018.06.03
by Felix Krause, translated by pilgwon
목차
- 시작하며
- I. 디펜던시(Dependencies)
- II. 설정(Config)
- III. 개발/라이브 동일시하기(Dev/prod parity)
- IV. 배포(Deployment)
- V. 원격보다 로컬 선호하기(Prefer local over remote)
- VI. 이전 버전과 호환되는 API(Backwards compatible APIs)
- VII. 앱 버전 정하기(App versioning)
- VIII. 데이터의 지속성(Persistence of data)
최근 몇 년 동안, 몇몇 개발자 팀은 개발 작업을 적게 해서 유저의 경험을 원격 백엔드에 로직을 옮겨왔고 iOS 앱은 서버의 결과를 보여주는 얇은 클라이언트로 만들어왔습니다. 이 접근 방식은 완벽하지 않은 인터넷 환경의 상황(지하철, 엘레베이터 혹은 느린 WiFi에서)에 있는 사용자에게 절망을 선사할 수 있습니다.
앱은 비즈니스 로직과 계산을 최대한 많이 가져와야 합니다. 여기엔 아주 다양한 이유가 있습니다.
- 프라이버시: 원격 서버에 데이터를 보내는 것을 피할 수 있습니다.
- 속도: 데이터를 서버에 보내고 리스폰스를 기다리는 것은 시간을 필요로 하고 실패할 경우도 있습니다. (예. 왔다갔다하는 WiFi)
- 데이터 사용량: 사용자들에겐 매달 사용할 수 있는 데이터의 양이 정해져 있습니다.
- 스케일링: 만약 앱이 바이럴에 의해 커진다면, 백엔드 서비스를 확장해야 할 수도 있습니다.
많은 iOS 앱은 어떠한 업무를 위해서 백엔드의 도움을 필요로 합니다. 예를 들면, 인증(authentication), 더 복잡한 계산 혹은 컨텐츠 저장등이 있습니다.
엔드 유저의 경험을 극대화하고 그들의 프라이버시를 보호하기위해 최소한의 백엔드 업무의 숫자를 제한하세요.
인터넷 연결이 반드시 필요하지 않은 앱의 모든 부분은 인터넷 연결 없이 작동해야 합니다.
- 여러분의 앱 시작 화면(처음부터 존재하지 말았어야 하는 화면)은 처음 웹 리스폰스를 기다리지 맗아야 합니다. 이는 왔다갔다 하는 와이파이 환경에선 사용자에게 나쁜 UX를 선사합니다.
- 만약 앱이 모든 것에 인터넷 연결(예. 소셜 네트워킹 혹은 라이드 쉐어링 앱)이 필요하더라도, 인터넷 연결 없이 역사적인 데이터(예. 최근 운전, 최근 다이렉트 메세지 목록)라도 읽기 전용으로 볼 수 있게 해야합니다.
- 인터넷 연결이 필요한 어떤 기능이 있다면 서버에 접근할 수 없을 때 확실한 에러 메세지를 띄워줘야 합니다.
- 와이파이 핫스팟이 호텔이나 공항처럼 로그인이나 확인이 필요하다면, HTTPs 리퀘스트는 1분 넘게 타임아웃이 걸릴 것입니다. Apple이 이 이슈를 시스템 단계에서 해결할 때까지, 우리가 개발자로서 이러한 상황을 적절하게 다뤄줘야 할 것입니다.
- 사용자가 앱을 처음 켰을 때 인터넷이 연결된 상태라고 가정하지 마세요. 사용자가 앱을 설치한 후에 바로 앱을 열지는 않으며, 이동 중에도 연결을 할 수도 있습니다. 최신 리소스로 앱을 즉시 사용할 수 있도록 앱을 만들어야 합니다. 이는 배포 요소에 설명된 주간 릴리즈 기차와 함께 직접적으로 작동됩니다.
전체 소스 코드는 GitHub에서 확인하실 수 있습니다.
이 프로젝트는 Felix Krause에 의해 시작되었습니다.
이 프로젝트는 Apple과 아무 관계가 없습니다.