iOS10 기준 아이폰앱 개발시 고려해야할 점

0

iOS10이 출시됨에 따라 아이폰 앱 개발도 이슈가 되고 있어, 개발 견적에 대한 테크니컬한 이슈들이 있어 앱개발을 고려하고 있다면 꼭 검토해야할 부분들을 정리해 보았다.

1, iOS버전

iOS가 출시된지 9년이 지나갔다. 지금까지 매년 운영체제가 업그레이드되면서 최근에는 10버전까지 나오게 되었는데 개발자로서 운영체제 버전 기준을 어떻게 잡을지가 가장 중요하다고 본다. 앱스토어에 출시된 유명한 몇가지 앱들을 기준으로 타겟팅을 하고 있는 검토해 보았다.

  • iOS 7버전 이상: KakaoTalk, Line, SK T-Map
  • iOS 8버전 이상: Facebook, Twitter, Pokemon Go, Youtube, Instagram, Wunderlist

대부분의 앱들이 iOS 8이상으로 나오고 있고 최근 업그레이드가 된 개발도구 Xcode8에서는 iOS8이상이 필수가 되었다. 필자가 개발하고 있는 앱들도 현재 개발대상은 iOS8이상으로 진행중에 있고 Swift 3.0기반으로 개발되는 앱들은 iOS9 이상으로 고려되어 개발하고 있다.

2016년 9월 12일 기준으로 애플에서 밝힌 내용에 따르면 iOS버전별 점유율은 다음과 같다.

ios-version

iOS9 및 iOS8을 합친 점유율이 97%정도인데 지금 현재는 iOS8이상으로 개발하는 것이 좋다고 보지만  iOS10이 출시된 이후를 고려한다면 iOS8 점유율은 더 떨어질 것으로 예상되기 때문에 차후 출시되는 앱에 대해서는 iOS8의 점유율 상태를 보고 하위버전을 결정하면 될 것 같다.

언제 서비스가 시작되는가?

iOS 6버전부터는 매년 9월에 운영체제 업데이트가 진행되었다. 특히 9월에 서비스가 오픈하는 곳이라면 최신 운영체제를 지원하지 않는다고 생각할 수 있고 베타버전이 나오지도 않았다면 어떤 문제가 있을지 알수 없기 때문에 발주하는 업체에서 요청시 출시일자를 9월이후로 고려하게 한다.

어떤 기능을 이용하는가?

iOS10에서는 일부 기능이 아이폰7에서만 지원되는 것들이 있고(일본의 경우 Apple Pay기반으로 FeliCe를 지원함) iOS9이상에서만 사용되는 기능과 iOS10부터 ATS설정에서 NSAllowsArbitraryLoadsInWebContent라는 키가 추가되어 웹뷰에 표시되는 내용에 대해서 http통신을 허용하는 설정항목이 추가되었다. 그러나 이 기능은 iOS10에서만 지원하기 때문에 다른 운영체제 버전별로 어떤 기능을 제공할지에 대해 고려해야 한다.

필자는 새 개발 프로젝트를 맡게되면 반드시 iOS8 이상으로 개발을 진행하고 있지만, 앞으로 2~3개월후에 나올 앱이면서 Swift 3.0언어로 개발할 경우, 오픈소스 라이브러리와의 호환성을 위해 iOS9이상으로 개발을 진행하고 있다. 물론 고객사가 iOS7도 대응하길 바라면, 점유율 정보와 Xcode8부터는 iOS8이상을 지원하기 때문에  iOS8이상으로 개발을 진행해야한다고 설득하고 진행한다.

 

2. 기기

작년 아이폰6/6+가 출시된 이후 통일된 너비가 크게 변경되었다. 이전까지 위치정보를 절대값으로 개발하던 개발자들에겐 지옥같은 일이었다. 하지만 이번에 iOS10이 나오면서 iPhone4S이전모델은 업데이트를 지원하지 않게 됨에 따라 디자인 기준도 iPhone5이상을 고려해서 하게 되었다.

  • 디스플레이 1136x640px(326ppi)기준: iPhone5, iPhone5s, iPhone5c, iPhone SE
  • 디스플레이 1334x750px(326ppi)기준: iPhone6, iPhone6s, iPhone7
  • 디스플레이 1920x1080px(401ppi)기준: iPhone6+, iPhone6s+, iPhone7+

2016년 9월 16일 출시된 iPhone7/7+는 iOS10전용 기기라고 보면 된다. iPhone4s가 운영체제 업데이트에서 제외되었지만 결국은 기기 종류 및 운영체제 버전을 기준은 더 많아졌기 떄문에 개발을 위해 이를 기준으로 삼는 기기가 명확해야 한다. 모든 테스트하게 되면 일도 많아지기 때문에 어느정도만 테스트하려는 기기와 운영체제 죄소범위로 잡고 개발을 하는것을 추천한다.

물론 새로운 기기 대응은 필수이기 때문에 기존 기기를 어디까지 대응할 것인지가 명확해지면, 대응해두면 좋다라고 한다는 것은 사실 대응하지 않아도 문제가 되지 않는다라고 이해할수도 있어 어디까지 개발해야할지가 개발자에게는 항상 부담으로 남는다. 즉, 필요없는 기기는 개발범위를 결정할 때 제외를 과감하게 하는 것이 좋다.

 

3. UI 디자인

UI 디자인 자체는 처음부터 정해진 경우는 극히 드물다. 그래서 개발을 발주받아 진행시 체크해야할 부분은 다음과 같다.

누가 디자인하나?

  • 모든 것을 자체적으로 해결하는지, 별도의 디자인 외주업체와 같이 진행하는지등의 디자인 작업을 누가하는지에 따라 주의해야할 부분이 몇가지 있다.
  • 어떤 도구를 이용하는가?  Adobe Photoshop CC, Adobe Illustrator CC, Sketch 3.x등 어떤 도구를 이용해서 만드는지와 도구 통일성을 고려한다.
  • 각 화면별 요소를 누가 잘라서 주는가? 디자이너가 할것인지, 개발자가 할 것인지를 고려해야 하며, 기준은 작업효율성을 고려해서 결정하자.
  • 제공되는 확장자는 무엇인가? PNG, JPG등 무엇을 사용할지 결정해두자.

전체 레이아웃(디자인가이드)를 작성하자. 화면별 요소 뿐만 아니라 전체 레이아웃 또는 디자인가이드를 반드시 작성하자. 디자이너에게 가이드까지 맡긴다면 Sympli서비스를 이용하여 디자인파일을 올려 자동으로 디자인가이드를 개발자가 확인하는 서비스를 이용한다면 비용 및 시간 절약이 가능하다. 물론 이 서비스보다 먼저 시작한 곳은 Zeplin이 있지만, Zeplin보다 좋은 점은 Xcode, Android Studio플러그인이 제공되어 디자인을 정확하고 쉽게 반영할 수 있었다.

간단한 앱이라고 생각하고 그만큼 개발공정도 적게 들어간다고 생각하는 경우가 많지만, 디자인을 외주로 줄 경우, 이를 명확하게 이해시키는 과정에서 시간이 생각보다 많이 소요될 수도 있다. 그래서 프로젝트를 진행할 때 이런 경우도 고려해서 진행해야 한다. 프로젝트가 시작된 후에 급하게 결정하거나 허둥지둥되면 프로젝트가 망가질 수 있어, 우선 인식을 시키고 양쪽 모두가 만족할 수 있는 일하는 환경을 만들어야 한다.

어떤 사용자 인터페이스를 만들 것인가?

어떤 앱이라도 사용자의 어떤 요구라도 앱의 목적이 정해져 있기 때문에 그것 위에 요구사항에 대한 정보설계를 하게 된다. 물론 정보설계는 중요한 작업중 하나이지만, Apple이 공개한 iOS Human Interface Guideline을 이해하고 있어야 한다. 이를 이해한 후에 어떤 사용자인터페이스를 만들어갈것인지를 검토하는 것이 전반적인 디자인 효율성을 포함하여 달라진다. 또한, 아이폰과 안드로이드기반 스마트폰의 상세한 일부 UI가 달라지기 때문에 이를 고려해서 개발진행을 해야 한다.

 

4. 애니메이션

아이폰은 화면이 작기 때문에 애니메이션 효과를 통해 작업을 보조하는 경우가 많다. 화면이 작고 간단한 UI의 아이폰 앱에서 애니메이션 효과를 사용하면 UX만족도를 높일 수 있다. 애니메이션 및 전환등을 처음부터 정하는 경우는 극히 드물며 프로젝트를 진행하면서 앱 화면을 만들고 테스트해보면서 그 앱의 움직임을 보려고 한다. 적어도 사용자가 참고하고 있는 앱이 있기 때문에 어떤 앱이 어떤 움직임을 보이고 있는지 사전조사를 해두자.

오픈소스를 사용하고 있는가?

최근 추세는 오픈소스로 애니메이션 및 전환효과를 제공하고 있는 것들이 많아지고 있어, 오픈소스(OSS)를 사용하는 것을 고려하여 작업량을 크게 줄이는 방법도 있다. 아이폰 앱개발에서 이런 개발처리 속도는 크게 중요하기 때문에 효율적인 개발을 위해 오픈소스를 제외할 수 없다.

또한 애니메이션작업시 디자이너와 개발자와의 의사교환에서 가장 큰 것은 공수조정작업이 차이가 크다. 대화도 중요하지만, 아무래도 감각적인 부분의 비중이 더 크기때문에 디자이너에게 GIF애니메이션 또는 시뮬레이터로 애니메이션을 만들어달라고 하여 테스트해보면 효율적이다.

 

5.  로컬앱의 기능

아이폰 앱은 오프라인 상태에서도 사용할 수 있는 요구사항도 있을 수 있다. 이런 요구사항을 미리 검토하는 것도 중요하다.

오프라인 상태의 기능도 필요한가?

오프라인 상태의 기능을 구현한다면 앱의 근본적인 전제조건이 달라진다. 오프라인 상태의 기능구현이 필요한 경우 개발공정은 확실히 늘어난다. 개발공정 및 사용자에 대한 효과를 비교하고 그 비용을 사용하여 사용자에게 제공하려는 기능인지를 검토해두어야 한다.또한 로컬앱 기능이 필요한 상태는 다음과 같다.

  • 지하철등의 오프라인 상태가 자주 일어나는 곳에서 사용하는 앱
  • 산악지대등에서 사용하는 앱
  • 온라인/오프라인 상태 관계없는 앱

오프라인 상태의 데이터처리

오프라인 상태로 이용하는 것은 앱에서 데이터를 관리하게 된다. 이런 경우 다음을 고려하게 된다.

  • 앱에서 어떻게 데이터를 가질 것인가?
  • 암호화 방식은 어떤 것을 사용하는가?
  • 데이터 동기화는 어떻게 하나?
  • 데이터를 어떤 경우에 삭제하는가?

위와 같은 경우 UI와는 크게 상관이 없지만 아이패드의 경우는 다소 틀리기 때문에 경우의 수를 고려해야 한다.

 

6. 앱의 상태전이

백그라운드에서 실행되다가 되돌아가면 앱이 실행되는 것을 고려하지 않고 테스트시 문제가 될 수 있지만, 오류 테스트시 문제라는 것은 재작업하는 것밖에는 없다. 상태전이에 대해서도 검토해두어야 한다. iOS앱 상태전리르 제대로 파악해두고 알맞게 상태전이가 되도록 해야 한다.

iOS 앱 상태전이

  • Not running: 앱이 시작되지 않거나 실행되었지만, 시스템을 정지한 경우
  • Inactive: 앱이 포그라운드에서 실행되고 있거나 사용하지 않는 상태
  • Active: 앱이 포그라운드에서 실행되고 재부팅중인 상태
  • Background: 앱이 포그라운드에는 없지만 여전히 실행하고 있는 상태
  • Suspended: 메모리에는 유지되고 있지만 앱이 실행하지 않는 상태

high_level_flow_2x

어떤 상태전이가 있는가?

  • 홈화면에서 앱 시작할 경우
  • 다른 앱에서 앱을 시작할 경우
  • 푸시 알림에서 앱 시작할 경우
  • 온라인 상태에서 앱 시작할 경우
  • 오프라인 상태에서 앱 시작할 경우
  • 홈 화면으로 갈 경우
  • 다른 앱을 실행할 경우
  • 앱을 작업에서 종료할 경우
  • 로그인, 로그오프, 자동로그인 시
  • 앱의 버전 업그레이드 알림에서 시작할 경우

등 여러가지를 고려하다보면 끝이 없다. 예로 푸시알림에서 앱 시작시 앱을 실행하는 것만인지 알림된 메시지에 의해 시작화면을 변경할 것인지등을 고려할 것들이 많다. 이런 상태전이에서 앱 실행을 제대로 정하고 각 화면간 일관성을 유지하도록 해야한다.

 

7. 오류 처리

앱 오류는 서버에서 리턴되는 오류로 인한 오류처리를 해야한다. 이것을 어디까지 처리할 것인지에 따라 달라진다.

오류를 고려하여 시작하면 끝이 없지만, 필요한 것은 오류 처리를 알맞게 실행하는 앱을 사용하는 사용자에게 알맞은 메시지로 처리가 이루어지고 있는지가 중요하다. 오류 관련해서 개발 끝까지 가지 않으면 모르는 부분이 많기때문에 차후에 몰리게 되어 미리 예측을 해서 상정할 수 있는 오류등을 고려해서 오류핸들링을 어느정도의 공정이 필요한지를 체크해야 한다.

 

8. 개발 대상

개발 대상은 기능뿐만 아니라, 작업범위도 포함되어 있다. 예로 디자인은 어떻게하고 외부 시스템과의 연동은 어떻게 하며, 신청까지 작업 범위이고 운영은 어떻게 하는지가 포함되어 있다.

기능 내용

아이폰 앱 개발에서는 매년 운영체제 업데이트 또는 새로운 기기가 나온다. 또한 빨리 출시하는 것이 중요해지고 있고 완전한 요구사항이 확정되지 않은 상태에서 개발의뢰를 하는 경우가 많다. 그런 상황에서는 개발사의 견적은 크게 달라지는 경우가 많다. 아이폰 앱 개발팀이 있다면 개발하면서 요구사항이 변화가 발생하여 그에 따른 비용도 고려하는 것이 중요하다. 물론 요구사항이 변경되지 않도록 하기 위해 Proto.io와 같은 프로토타입 작성 도구를 사용하여 보여준다면 좀더 고객과의 간격을 줄일 수 있다.

자료 신청

자료 신청과 자료 준비작업이라는 것이 있는데 이를 개발사에서 할 것인지도 고려해야 한다. 라이선스 자체를 개발회사에서 얻을 것인지, 고객사가 얻을 것인지, 얻은 후 릴리즈신청은 누가할 것인지등에 대한 사전에 미리 기준을 잡도록 하자.

 

9. 개발 대상 이외의 작업들

개발 대상 이외의 작업은 다음과 같은 것들이 있다.

개발도구

작업을 관리하기 위한 Asana, 소스관리르 위한 Github, CI환경을 제공하기 위한 g, 프로토타입을 만들기 위한 Proto.io (또는 Prott), 디자인가이드 제공을 위한 Sympli (또는 Zeplin)등 다양한 외부 도구도 많아지고 있어 어떤 도구를 이용하여 개발하는지도 예상해야 한다. 무료 도구가 더 좋을지도 모르겠지만 스스로가 환경을 구축하고 유지보수를 위해 보다 효율적인 도구들이 많이 나와 있기 때문에 사용하는 것을 추천한다.

하드웨어

최근 블루투스 기반 액세서리나 IoT도 유행하여 그에 맞는 하드웨어와 같이 사용하는 앱도 늘어나고 있다. 이런 경우 하드웨어를 빌려서 개발을 할지, 아니면 개발시 구입해야 하는지에 대한 가격비용도 고려해야 한다.

인프라

필자는 보통 서버(백엔드) 개발을 할 경우 AWS를 이용하는 경우가 대부분이지만 최근에는 Google Firebase를 사용하여 개발기간을 단축하거나 서비 이용비용을 줄여 개발견적을 줄일 수 있다.

서버(백엔드) 개발

최근까지의 아이폰 앱들은 서버(백엔드)와 연동하지 않는 앱은 적다고 본다. 아이폰 앱은 어디까지나 뷰에서 주요 처리를 서버측에 전달하는 경우가 많기 때문에 서버개발에서 무엇을 할 것인지도 결정해야 한다. 또한 아이폰 앱은 푸시알림 요청도 한번에 처리해야 하기 때문에 성능을 어디까지 담보할 것인지에 대한 테스트 방법등을 미리 정해두어야 한다.

기타 경비

멀리 있는 고객과의 협력을 하는 경우, KTX 및 항공권, 차량 유류비등을 자주 이용할 수 있다. 빈도에 따라 달라지기 때문에 이런 부분도 확인해두어야 한다.

 

10. 결과물

개발이 완료되면 고객에게 납품해야할 완료보고서 및 관련 문서작업도 필요하다.

설계서

설계문서는 보통 어떤 설계서가 필요한지 설정해야 하고 그에 따른 어떤 프로그램을 사용하여 어떤 확장자로 제공할지를 명확하게 해두지 않으면 결과물을 만들기 위한 개발범위를 줄일 수 있고 사용자에게 제공되는 아이폰 앱에 더 집중할 수 있게 된다.

소스코드

소스코드를 제공할 경우, github로 제공할 수 있는가? 프로젝트파일은 DVD또는 USB메모리로 제공하는 방법등이 있다. 또한 원래 소스코드를 기본 제공하는지도 사전이 확인해야 한다.
이처럼 개발에 따른 완벽한 견적산출은 없다고 본다. 앞에서 이야기한 몇가지 중요포인트를 고려해서 추정하여 정확한 비용산출이 필요로 해진다. 개발이라는 것은 솔직히 단순하게 코딩만으로 이루어지는 것은 아니다. 요구사항을 정리하고 이를 바탕으로 설계서를 작성할 수 있게 된다면, 프로젝트 관리 공정도 필요하고 테스트를 어떻게 어디까지 할 것인지도 크게 달라진다. 고객도 개발자도 모두 만족할 수 있는 프로젝트가 진행되도록 이런 전제들이 제대로 인식을 맞춰야 한다.

 

Facebook Comments

No more articles