모바일 앱 · 반응형 웹

저희가 사유를 확인하고 고쳐서 다시 제출합니다. 견적에 포함된 범위입니다. 반려는 드문 일이 아니라 출시 과정의 일부라고 보는 편이 맞고, 제출 전에 반려 사유가 될 만한 것을 미리 점검합니다. 다만 심사 기간 자체는 저희가 줄일 수 없습니다.

기능에 따라 갈립니다. 로그인, 기기 간 데이터 공유, 푸시 알림, 결제가 있으면 서버가 필요합니다. 기기 안에서만 도는 앱이라면 서버도 계정도 없이 만들 수 있습니다. 저희가 만든 영업킷과 견적킷이 그런 구조입니다. 서버가 필요 없으면 운영비도 들지 않으니, 정말 필요한지 먼저 따져 봅니다.

앱은 스토어 심사를 다시 거치므로 웹처럼 즉시 반영되지 않습니다. 그래서 자주 바뀔 내용은 처음부터 서버에서 내려받도록 설계해 두면 심사 없이 고칠 수 있습니다. 어디까지 그렇게 할지는 무엇이 얼마나 자주 바뀌는지 보고 함께 정합니다.

비용을 가르는 것은 플랫폼 수가 아니라 만들 화면과 기능의 양입니다. 하나의 코드로 만들기 때문에 웹을 빼도 크게 줄지 않고, 반대로 나중에 웹이 필요해질 때 새로 만들지 않아도 됩니다. 화면 수가 적으면 그만큼 줄어듭니다.

필요합니다. 두 스토어 모두 처리방침 주소를 요구합니다. 그리고 수집하지 않는 것과 데이터가 제3자에게 닿지 않는 것은 다릅니다. 지도 타일을 받아 오는 앱은 수집이 0이어도 그 서버에 접속 기록이 남습니다. 스토어 신고 내용과 문서가 어긋나면 그것 자체가 반려 사유가 되므로, 기기 밖으로 나가는 통신을 기준으로 적습니다.