[Petmory] 앱 출시 후기

처음으로 만들어본 앱이 9월 30일에 앱스토어에 출시됐다.

https://apps.apple.com/app/펫모리-petmory/id6443397065

 

심사가 엄청 빨리 진행되어 5시간정도만에 바로 확인할 수 있었다. 

 

 

앱 정보

 

일단 내가 출시한 앱은 다이어리 앱인데, 그 중에서도 반려동물과의 하루를 기록하는 컨셉의 앱이다.

 

앱의 기능은 다음과 같다.

 

• 반려동물과의 하루를 사진과 함께 기록
• 작성 내용을 월별, 연도별 다이어리 형태로 확인
• 작성했던 기록들을 한 번에 모아보기
  • 등록된 반려동물별로 필터링을 통해 기록 나눠보기
• 기록 검색
• 반려동물과의 일정을 캘린더에 저장

 

 

프로젝트 진행

 

 

어떤 앱을 만들지 고민하던 기간에 뒤에서 잠을 자고 있던 두부를 보고 반려동물과의 하루를 기록하는 다이어리 앱을 만들어보기로 했다.

 

처음에는 정말 완벽하고 깔끔하게 계획을 짰다고 생각하여, 9월 25일 정도면 출시를 하겠다고 생각했었다.

 

하지만 두 번째 이터레이션부터 내가 진짜 멍청하고 생각없이 계획을 짰구나라는 생각이 들었었다.

 

결국 처음에 계획했던 것과는 완전히 다른 스케줄로 진행되었고, 그 마저도 중간에 오류 해결에 시간을 많이 쏟다보니 지켜지지 않았다...

 

그래도 꾸역꾸역 개발을 진행했고 얼추 기획했던 기능들이 구현됐을때, 아쉬운 부분도 많았지만 그런 부분들은 추후에 업데이트로 진행해보기로 하였고 그대로 심사를 제출했다.

 

프로젝트를 진행할 때 가장 크게 느꼈던 것은 진짜진짜 디자이너분과 기획자분이 대단하다는 것을 느꼈다..

 

특히 계획이 틀어진 가장 큰 이유가 디자인 때문이었다.

 

며칠을 생각하고 아 괜찮겠다싶어 구현해놓은 결과물을 보면 정말 구려서 다시 수정하는 과정을 반복하다보니 이도저도 아니게 됐던 것 같다.

 

중간 발표때, 다른 분들의 앱을 보는데 정말 와 소리가 나올 정도로 깔끔해서 놀란 기억이 있다.

 

그 이후에 UI에 더욱 욕심이 생겨 시간을 계속해서 투자해봤지만, 내 창작 센스의 한계를 느끼고 아쉬운대로 마무리 지었다.

 

 

 

디자인도 디자인이지만 개발을 하며 만난 이슈들이 정말 많았다. 

 

그 중 몇가지는 해결하는데에만 몇시간 며칠을 쏟았던 기억이 있다.

 

겪었던 이슈들 중 큼직한 것들만 가볍게 정리해보겠다.

 

 

이슈

 

Realm 모델

 

사실 처음에는 얼추 생각했던 것들이 있었기때문에 테이블을 구성하는게 그렇게 오래걸리지 않았다.

 

근데 개발을 진행하면서 점점 잘못 설계되었다는 것을 느끼고 하나씩 수정했었다.

 

다시 한 번 내가 했던 기획들이 정말 형편이 없다는 것을 느낄 수 있는 계기였다.

 

계획없이 짠 결과물을 보면 충분히 더 적은 컬럼으로 구성할 수 있을 것 같은 생각이 들었다.

 

근데 렘을 수정하게되면 앱을 지웠다가 깔아야돼서 마이그레이션을 진행해야한다.

 

이 부분은 더 알아봐야 할 것 같다.

 

 

 

IQKeyboard 이슈

 

원래는 IQKeyboard 라이브러리를 사용하지 않으려고 했다.

 

사용해봤을때 짜잘한 이슈들을 많이 겪었기때문에 직접 구현해보자라는 생각으로 구현을 해봤지만, 깔끔하지도 않고 시간도 시간이었기때문에 결국 사용하게 되었다..

 

아무튼 IQKeyboard를 사용한 이유는 텍스트뷰에서 키보드에 커서가 가려지지 않게 하기 위해서였다.

 

나는 작성화면에서 텍스트뷰에 쓰는 만큼 전체 뷰가 늘어나길 원했다.

 

그래서 스크롤뷰를 이용하고 텍스트뷰의 스크롤을 막았더니 원하는대로 텍스트가 길게 입력되면 텍스트뷰가 늘어나서 전체 뷰가 늘어나게 됐다.

 

하지만 커서가 보이지 않는 것이 문제였다.

 

이를 해결하기 위해, 텍스트뷰 내에서 커서의 위치를 구하고 y값이 일정 위치를 넘어가게되면 superView origin의 y값을 변화시켜주었다.

 

텍스트뷰가 늘어나면서 origin 값이 변하는 것을 확인하였지만 원하는 느낌이 아니었다.

 

그래서 IQKeyboard를 사용하기로 결정했는데, 텍스트뷰의 스크롤이 막혀있으니 IQKeyboard도 적용되지않았다..

 

이 문제로 며칠을 고민하다가 결국 해결하지 못하고 텍스트뷰에 직접 입력하는 것이 아닌, 새로운 뷰를 띄워서 데이터 전달을 통해 텍스트뷰에 텍스트가 채워지도록 구현했다.

 

다른 사람들에게도 물어가며 사용자 입장에서 많이 불편한지 확인해가며 최선의 방법을 찾은거라서 아쉬웠지만 어쩔 수 없이 진행하였다.

 

이 앱에 대해서는 괜찮을 것 같지만, 이 이슈에 대해서는 라이브러리를 쓰지 않고 해결하는 방법을 더 공부해봐야 할 것 같다.

 

 

 

 

구조 변경

 

 

처음에 구현했던 모습은 오늘 작성한 글이 있는 경우에만 메인 화면에 다이어리를 보여주었다.

 

12시가 지나게 되면 다음 날이 되기 때문에 다이어리 모습이 바로 사라지게 돼서 당황했다는 피드백과 다이어리를 눌렀을 때, 생각했던 구조와 다르다는 피드백을 받았었다.

 

또한, 다이어리를 보여주는 것은 괜찮은 생각인데 현재의 상태로는 굳이 있는 이유를 모르겠다는 피드백을 받았었다.

 

피드백을 듣고 내가 느끼기에도 "오늘"이라는 키워드가 중요한가 싶었고, 다이어리를 더 이용해보는 것이 훨씬 낫겠다는 생각이 들었다.

 

그래서 기존에 UIView로만 보여주던 다이어리를 컬렉션뷰를 이용해 일년치의 다이어리를 보는 방향으로 바꾸게 되었다.

 

그러다보니 데이터를 가져오는 메서드들에도 변화가 필요했었다.

 

새로운 fetch메서드를 생성하고, 기존의 필터링 메서드들을 수정하다보니 생각보다 큰 작업이 됐었던 것 같다.

 

그래도 방향성이 딱 정해져있었기 때문에 시간은 하루이틀 정도밖에 걸리지 않았던 것 같다.

 

구현하고나니 내 생각에도 다이어리를 더 활용하는 느낌이 들어 좋았고, 심심했던 분위기도 그나마 채워졌던 것 같다.

 

피드백을 해주시지 않았다면 지금보다도 더 모자란 상태로 출시했을 것이기 때문에 다행이라고 생각이 든다...

 

 

 

 

이미지가 없는 경우

 

 

기본 이미지를 만들지 말지 고민을 정말 많이 했다.

 

있는 게 내 입장에서도 더 편했기 때문에 원래는 만들려고 했었다.

 

하지만 그 동안 디자인과 UI로 고민했던 것을 생각하니 분명 시간적으로 여유롭지 못할 걸 알았기 때문에 없는 경우엔 그냥 비워주기로 결정했다.

 

그러다보니 작성 기록을 보는 화면에서 이미지가 없는 경우에 공간이 비어있게 되었다.

 

처음에는 레이아웃 제약을 바꿔주려고 했었다.

 

역시나 원하는대로 구현되지 않았기에 고민하던 중, 스택뷰를 이용하면 hidden 시켰을 때 공간을 채워준다는 것이 기억났다.

 

그래서 이미지뷰를 스택뷰로 감싸고 hidden시켜주니 원하는 대로 빈 공간을 채워서 레이아웃이 잡히는 모습을 볼 수 있었다.

 

 

 

 

이미지 컬렉션뷰 리로드

 

 

작성 화면에서 이미지를 없애면 스택뷰가 쪼그라들어서 공간이 채워지게끔 구현했다.

 

하지만 이 상태에서 이미지를 추가하면 어떤 경우에는 이미지뷰의 공간만 생기고 리로드가 되지 않았다.

 

알아본 바로는, 이미지의 용량보다도 컬렉션뷰의 hidden과 연관이 있었다.

 

그래서 히든이 풀린 뒤에 리로드를 해주도록 했는데도 해결이 되지 않아서 조금 더 늦은 시점에 리로드를 시켜주었다.

 

되는 경우와 안되는 경우가 있는데 차이를 모르겠어서 더 알아봐야 할 것 같다..

 

 

 

 

datePicker를 ActionSheet에 넣기

 

 

 

일정 화면에서 leftBarbutton을 누르면 datePicker가 나오도록 구현하고 싶었다.

 

그래서 데이트피커를 만들어서 actionsheet에 바로 넣어줬더니 왼쪽 위 부터 채워져서 중앙으로 오지 않는 문제가 있었다.

 

frame값을 주고 해봐도 해결되지 않았다.

 

그래서 알아낸 방법이 actionSheet의 뷰 안에 새로운 뷰컨트롤러를 만들어서 넣고 그 안에 데이트 피커를 넣으니 사이즈가 알맞게 들어갔다.

 

 

 

백업 및 복구

 

 

 

기존에는 realm파일 자체를 압축하여 복구하는 방법밖에 구현하지 못했다.

 

이 방법은 복구를 했을 경우에 앱을 다시 시작해야지만 복구가 되기 때문에 사용자 입장에서 살짝은 불편할 수도 있을 것 같았다.

 

또한, 앱을 강제로 종료시켜야 할지, alert로 앱을 종료해달라고 띄워야할지 고민하던 중에 json형태로 복구를 진행한 팀원분이 계셔서 나도 한 번 해보기로 했다.

 

간단히 정리해보자면,

 

우선, realm 모델에서 Codable프로토콜을 채택하여 인코딩, 디코딩이 가능하게 만들어야 한다.

 

모델들을 각각 인코딩하여 json파일로 만든 뒤에 압축하고, 불러올 때는 기존의 데이터를 지우고 압축파일을 풀어 디코딩 해주었다.

 

근데 지금 구현된 백업복구 로직에서는 문제점이 많다..

 

1. 복구 중 사용자가 백그라운드로 가거나 다른 행동을 하는 경우

2. 사용자가 잘못된 백업 파일로 복구하는 경우엔 데이터가 지워지게됨..

    지금은 백업 파일의 이름으로만 판단하기 때문에 완성도가 낮음..

 

이 외에도 분명 있기때문에 생각하면서 로직을 업데이트 해야 할 것 같다.

 

 

 

 

메모리 릭

 

 

아무 생각없이 개발을 하던 중, 팀원분께서 메모리 릭이 발생한다는 말을 듣고 나도 확인해봤더니 역시나 발생하고 있었다...

 

디테일 화면을 들어갔다가 나오면 deinit이 되지 않아 계속해서 메모리가 늘어나고 있었다.

 

정말 메서드 하나씩 전부 주석처리를 하면서 deinit이 되는 시점을 확인했더니 클로저를 사용한 부분 때문에 메모리릭이 발생하는 것을 알게 되었다.

 

그래서 기존에 강한 참조를 하는 부분에 weak self를 이용해서 해결해주었다.

 

아직까지 이런 부분의 이해가 많이 모자란 것 같아서 공부를 더 해야할 것 같다.

 

 

 

 

업데이트

 

 

내 생각에 제대로 기획된 상태로 진행되지 않아서 완성도가 낮은 앱인 것 같다.

 

그래서 고쳐야 할 부분도 많고 추가해야 할 것들도 많다.

 

• UI
• 백업, 복구 로직
• 반려동물이 한 마리인 경우엔 작성 화면에서 디폴트로 선택된 상태로
• 복구 후에 알림이 제대로 오는지 확인
• 다이어리 UI
  • 현재 월별로 보여주고 있기때문에 마이그레이션을 통해 렘을 수정해야할듯
•  

이 외에도 사용자들이 생기고(생길진 모르지만) 니즈가 생긴다면 반영해야 할 것 이다.

 

 

 

후기

 

 

처음으로 앱을 출시해보니 내가 정말 신경써야 했던 부분들을 많이 무시했다는 것을 알게되었다.

 

또한, 계획한대로 진행되는 일은 정말 드물거라는 생각이 들기때문에 잘 생각해서 계획을 짜야될 것 같다는 생각이 들었다.

 

마지막으로, 디자이너분들과 기획자분들은 정말 존경스럽다는 생각이 가장 강하게 남아있다..