Android vs. iOS

21년 기준, 안드로이드와 iOS는 약 3:1 비율로 세계 모바일 시장을 점유하고 있다. 두 OS 모두 출시한지 10년이 넘어 긴 히스토리와 많은 기능을 갖고 있으며, 두 운영체제 간 차이점 때문에 한 사람이 모두를 하기가 쉽지 않다. 그래서, 양쪽 모두를 지원하는 앱을 만들 때 보통 React 등의 하이브리드 언어나 웹 앱을 선호된다.

하지만, 현재 운 좋게도(?) 내가 두 운영체제를 동시에 경험하고 있다. 좋은 기회이니, 다른 점들을 발견할 때마다 잊어버리기 전에 여기에 정리하려 한다.

(혹시 틀린 내용이나 업데이트 될 내용이 보인다면, 댓글로 남겨주세요. 감사한 마음으로 수정하겠습니다!)

테스트 앱 배포

  • Android : Firebase의 App distribution
  • iOS : Google Firebase의 App distribution 혹은 Apple의 Test Flight

Firebase는 앱 개발자에 필요한 다양한 기능을 제공한다. 그 중 하나가 테스터를 위한 테스터 앱 배포 기능, App distribution이다. Firebase는 구글에서 만들었지만, Android, iOS, Web 3가지 환경을 지원하며 App distribution도 마찬가지다. 여기서는 Android, iOS 배포만 비교해보자.

Firebase에서 Android는 테스터의 구글 계정(=이메일 주소)으로 초대장을 보내고, 테스터가 수락하면 바로 다운로드가 가능하다.

Firebase에서 iOS는 이메일 초대장에 테스터가 수락하는 과정의 일부로 테스터 단말(여기서는 iPhone)의 UUID를 수집한다. 그 후, 수집한 UUID가 포함된 profile로 앱을 새로 배포한 후에야 테스터가 다운로드 받을 수 있다.

iOS는 애플에서 제공하는 Test Flight를 이용해서 알파/베타 테스터에게 배포할 수도 있다. 서비스 제공 주체가 다르니 iOS 애플 계정을 따로 받아야하지만, 대신 App distribution과 달리 UUID 수집은 필요 없다.

Android와 iOS 테스트 앱 배포 방법을 정리해보자.

  • 모두 App distribution을 사용하면,
    • 장점 : Android와 iOS 테스팅 상황을 한 대시보드에서 볼 수 있다. 테스터 당 구글 계정 하나 씩만 수집한다.
    • 단점 : 테스터가 늘어날 때마다 앱을 다시 빌드해서 배포해야 한다.
  • Android는 App distribution, iOS는 Test flight를 쓰면,
    • 장점 : iOS도 애플 스토어에 올려야하는 점을 고려하면 테스트 배포부터 애플 개발자 도구를 쓰는 것이, 예상치 못한 문제 상황을 줄이고 동작도 매끄럽다.
    • 단점 : Android 테스터에겐 구글 계정을, iOS 테스터에겐 애플 계정을 수집해야 한다. 두 운영체제를 위한 테스트 앱 배포 상황을 종합적으로(= 한개의 대시보드에서) 볼 수 없다.

햅틱

  • Android : 리플 효과(Ripple effect)
  • iOS : 햅틱(haptic)

iOS는 다양한 인터페이스에 햅틱을 사용한다. 반면 안드로이드는 사용자의 동작이 잘 전달되었는지 특히 혼란스러운 버튼 같은 경우 물결처럼 퍼지는 리플 효과를 쓰고, 다른 경우는 거의 피드백이 없다. 다이얼로그나 노티피케이션은 사용자에게 표시되는 시각 정보로 충분하다고 보는 것 같다.

Android 초기엔 햅틱으로 인터페이스를 만드는 경우도 있었다. 하지만, 퀄리티와 균일함을 보장하지 않는 진동 때문에 화면 처리로 바뀐 것으로 생각된다. 그 이유는 안드로이드는 오픈 소스로 시작했으며, 단말 제조사 누구나 안드로이드를 가져가 입맛대로 단말을 만들어 팔 수 있다. 라이센스 비용이 발생되지 않는 구조 상 초반에 특히 저가 단말 중심으로 출시되어 진동의 퀄리티를 보장할 수 없었다. 현재 안드로이드는 전화나 문자, 메시지 알람 등을 제외하고는 진동을 쓰지 않는다. 일부 기능에서는 여전히 진동을 켤 수 있도록 하지만, 기본 값은 off이며 대부분의 사용자들도 쓰지 않는다.

iOS는 애플이 소프트웨어와 하드웨어 생산을 직렬화(하드웨어 생산은 외주를 쓰지만), 퀄리티를 항상 보장할 수 있고 진동의 섬세한 제어가 가능하다. Haptic Heaven과 같은 테스트 앱을 이용해 다양한 진동을 경험할 수 있다.

그래서 iOS는 전화나 문자 같은 기능 뿐 아니라 키입력, 팝업, 노티피케이션 까지 다양한 부분에 진동을 사용한다. 햅틱에 대한 설명은 이 글을 읽어보자.

모달

iOS에서 모달에 대해 검색하면, ‘사용자의 이목을 끌기 위한 화면 기법’이라고 설명한다. iOS가 지향하는 모달 사용법을 한 문장으로 정리한 문장 같다. 과거의 전통적인 모달은 사용자가 응답을 하기 전까지 다른 동작을 할 수 없게 만들었다. 그래서, 웹을 비롯해 안드로이드 등에서는 모달 사용을 최대한 자제해야한다고 말하기도 했다. 안드로이드는 에러 팝업과 같이 사용자에게 정확한 안내가 필요한 경우를 제외하고는 모달을 사용하지 않는다. 에러 팝업을 표시하는 경우라도, 팝업 외 영역을 터치할 수 있게 하여, cancel 버튼을 누른 것과 같은 동작을 한다. 쓰더라도 사용자에게 답답함을 느끼지 않도록 구현하는 것이다.

iOS도 전통적인 모달의 강제성은 거의 없다. 사용자의 ‘이목을 끌어야 하는’ 상황이라 판단될 때 모달 기능을 제공하여 사용자에게 표시한다. 에러 팝업 보다는 모달 형태로 동작하는 전체 화면이 뜨는 경우가 많다. 이 모달 화면 내 (보통) 우측에 취소 버튼을 두어 나갈 수 있게 한다. 하지만, (왼쪽의) 뒤로 가기 버튼을 제공하지 않고 취소버튼을 만들어 모달로 뜬 화면에서 했던 동작을 한꺼번에 취소하게 만든다. 안드로이드는 모든 페이지를 한단계 씩 들어가고 나갈 수 있는 것에 비해 큰 차이점을 갖는다.

버전 표기

version code는 업데이트 여부를 판단하는데 중요하다. 안드로이드와 Int, iOS 모두 Int 형으로 표기한다. 자바는 Int가 32bit, Swift는 64bit이므로 두 플랫폼에서 동일하게 사용하려면 자바 쪽에 맞춰 최대 2100000000까지만 쓰자.

version Name은 사용자에게 표시된다. 일반적인 VOC 접수 시 버전 정보와 재현 경로 정도만 알려지는게 일반적이다. 그러므로 version name 통해 소스코드를 특정할 수 있어야 좋다. 안드로이드는 version name 표기시 제약이 없어, 문자열도 입력할 수 있다. iOS는 숫자와 점(.)으로만 구성되어야 하며 점을 최대 2개 까지 사용하여 3파트로 구성된 버전 표기를 권장한다. 두 플랫폼에서 동일하게 사용하려면 <major>.<minor>.<patch> 형태로 써야 양쪽에서 사용할 수 있다.
예) 1.2.34

그 밖에

댓글 달기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다

이 사이트는 스팸을 줄이는 아키스밋을 사용합니다. 댓글이 어떻게 처리되는지 알아보십시오.