mirabo01 님의 블로그

앱을 처음 배포해보면빌드보다 더 긴장되는 단계가 있다.바로 스토어 심사다.코드도 문제없고빌드도 잘 됐는데갑자기 “리젝” 메일이 온다이 단계에서 당황하는 이유는개발 문제가 아니라 정책 문제이기 때문이다.이 글에서는React Native + Expo 앱을 기준으로실제로 자주 걸리는 스토어 심사 리젝 사례를입문자 관점에서 정리한다.이 글이 필요한 사람첫 앱 배포를 앞두고 있는 경우이미 한 번 이상 리젝을 당한 경우“뭐가 문제인지 모르겠다”는 상태인 경우스토어 심사는 무엇을 보는가먼저 이 관점부터 정리해야 한다.스토어 심사는“코드 품질”이 아니라사용자 보호와 정책 준수를 본다.그래서 다음 항목들이 핵심이다.개인정보 수집 여부앱 설명과 실제 기능 일치 여부계정/결제/권한 사용의 정당성테스트 가능 여부[이미지: 앱..

이미지 최적화까지 마쳤다면이제 개발 단계는 거의 끝이다.다음으로 반드시 거쳐야 할 단계가 있다.바로 빌드와 배포다.내 폰에서는 잘 되는데APK / IPA는 어떻게 만들지?스토어 등록은 또 뭐가 이렇게 많지?이 글에서는Expo를 사용하는 React Native 프로젝트 기준으로배포 전 전체 흐름을 한 번에 정리한다.이 글이 필요한 사람Expo로 만든 앱을 실제로 배포해보고 싶은 경우Android / iOS 빌드 흐름이 감이 안 오는 경우스토어 등록 전에 무엇을 준비해야 하는지 알고 싶은 경우React Native 배포 전체 흐름큰 흐름부터 보면 이렇다.앱 정보 설정빌드 환경 준비Android / iOS 빌드스토어 업로드심사 대응[이미지: React Native 앱 배포 전체 흐름]이 글에서는Expo + E..

FlatList 최적화까지 했는데도앱이 여전히 무겁게 느껴진다면다음으로 의심해야 할 건 거의 항상 이미지다.실무에서 체감 성능 문제를 추적해보면원인이 이런 경우가 많다.이미지 용량이 너무 큼스크롤할 때마다 이미지 다시 로드리스트에 이미지가 많은데 최적화 안 됨이 글에서는React Native에서 이미지를 다룰 때 꼭 알아야 할 최적화 포인트를실무 기준으로 정리한다.이 글이 필요한 사람이미지가 많은 화면에서 스크롤이 끊기는 경우FlatList는 최적화했는데 여전히 느린 경우이미지 캐싱 개념이 잘 안 잡히는 경우React Native에서 이미지가 느린 이유웹과 달리모바일 앱에서는 이미지가 더 민감하다.메모리 사용량 제한네트워크 환경 다양저사양 기기 존재특히 리스트 + 이미지 조합은최적화하지 않으면 바로 성능..

리스트 화면은React Native 앱에서 가장 흔하면서도가장 쉽게 느려지는 부분이다.처음엔 잘 동작하다가데이터가 조금만 늘어나면 이런 증상이 나온다.스크롤이 끊긴다이미지 로딩이 버벅인다입력할 때 리스트 전체가 다시 그려진다이 글에서는FlatList를 쓸 때 실무에서 꼭 챙기는 성능 포인트를옵션 중심으로 정리한다.이 글이 필요한 사람FlatList 스크롤이 부드럽지 않은 경우리스트 아이템이 많아질 예정인 경우성능 최적화를 어디서부터 해야 할지 모르는 경우FlatList가 기본적으로 빠른 이유FlatList는보이는 영역 위주로만 렌더링한다.화면에 안 보이는 아이템은 렌더링하지 않음스크롤 위치에 따라 동적으로 생성/제거그래서ScrollView보다 기본 성능은 훨씬 좋다.하지만설정을 안 하면 반쪽짜리 성능이 ..

상태 관리까지 정리했다면이제 앱은 “기능적으로는” 꽤 그럴듯해진다.그다음에 체감되는 문제가 하나 있다.화면 전환이 묘하게 버벅인다입력할 때 전체 화면이 다시 그려지는 느낌리스트가 많아지면 확 느려진다이건 대부분렌더링 구조를 제대로 이해하지 못한 상태에서컴포넌트가 불필요하게 다시 그려지기 때문이다.이 글에서는React Native에서 성능 최적화를 시작할 때가장 먼저 이해해야 할 포인트를 정리한다.이 글이 필요한 사람앱이 커질수록 점점 느려지는 느낌이 드는 경우useMemo, useCallback을 왜 쓰는지 감이 안 오는 경우“일단 다 감싸면 되지 않나?”라고 생각한 적 있는 경우React Native 성능의 핵심은 렌더링이다React Native 앱에서성능 이슈의 대부분은 이 한 문장으로 정리된다.“필..

useContext까지 정리했다면이제 이런 생각이 들기 시작한다.상태가 점점 많아진다Context가 여러 개로 늘어난다로직이 한곳에 모이지 않는다이 지점에서상태 관리 라이브러리를 고민하게 된다.문제는 항상 이거다.“도대체 뭘 써야 하지?”이 글에서는React Native 실무에서 자주 언급되는Redux, Zustand, Recoil을과하지 않게, 선택 기준 중심으로 정리한다.이 글이 필요한 사람useContext로 버티다 한계를 느낀 경우Redux가 무겁게 느껴지는 경우상태 관리 라이브러리 선택 기준이 없는 경우상태 관리 라이브러리를 쓰는 이유상태 관리 라이브러리는상태와 로직을 한곳에서 관리하기 위해 사용한다.상태 위치가 명확해진다화면과 로직이 분리된다디버깅이 쉬워진다하지만 그만큼구조와 규칙이 추가된다...

API 연동까지 했다면이제 이런 고민이 자연스럽게 생긴다.로그인 정보는 어디에 두지?여러 화면에서 같은 데이터를 써야 하는데?props를 계속 내려야 하나?이 시점이 바로상태 관리가 필요해지는 순간이다.이 글에서는상태 관리 라이브러리를 바로 쓰기 전에,React Native에서 useContext로 어디까지 가능한지를실무 기준으로 정리한다.이 글이 필요한 사람props drilling이 불편해지기 시작한 경우전역 상태가 왜 필요한지 감이 안 오는 경우Redux 같은 라이브러리가 부담스러운 경우상태(state)는 왜 문제가 될까지금까지는대부분 이런 구조였을 것이다.화면 안에서만 쓰는 state컴포넌트 하나에서 관리하지만 앱이 커지면상태가 여러 화면에 걸쳐 필요해진다.예를 들면,로그인 사용자 정보토큰다크모드..

네비게이션까지 만들었다면이제 앱의 형태는 거의 갖춰졌다.다음 단계는“실제 데이터”를 붙이는 것이다.서버에서 목록 가져오기상세 정보 요청로딩 처리에러 처리React Native에서 API 연동은웹과 크게 다르지 않지만,처음에는 몇 가지 포인트에서 헷갈린다.이 글에서는fetch와 axios를 기준으로 API 연동의 기본 흐름을입문자 + 실무 기준으로 정리한다.이 글이 필요한 사람서버 데이터를 화면에 띄우고 싶은 경우fetch와 axios 중 뭘 써야 할지 고민되는 경우API 호출 위치와 타이밍이 헷갈리는 경우React Native에서 API 연동 흐름전체 흐름을 먼저 보면 이렇다.화면 진입API 요청로딩 상태 표시데이터 성공/실패 처리화면 렌더링이 흐름은React Native든 웹이든 거의 동일하다.[이미지..

Stack Navigation으로화면 이동까지 구현했다면이제 앱 구조가 조금 보이기 시작한다.하지만 실제 앱을 떠올려보면대부분 이런 형태다.하단에 탭이 있고홈 / 검색 / 설정 같은 화면이 고정되어 있음화면을 왔다 갔다 해도 탭은 유지됨이 구조를 만드는 게**Tab Navigation(탭 네비게이션)**이다.이번 글에서는react-navigation 기반 하단 탭 구조를 처음부터입문자 기준으로 정리한다.이 글이 필요한 사람하단 탭이 있는 앱 구조를 만들고 싶은 경우Stack과 Tab을 어떻게 같이 써야 할지 헷갈리는 경우실제 앱 같은 구조로 확장하고 싶은 경우Tab Navigation이 필요한 이유Stack Navigation만 쓰면화면이 계속 쌓이는 구조가 된다.홈 → 상세 → 설정 → 다시 홈이런 흐..

입력과 버튼까지 다뤘다면이제 앱다운 앱을 만들기 위한 마지막 기본 퍼즐이 남는다.바로 화면 전환이다.로그인 화면 → 홈 화면목록 화면 → 상세 화면뒤로 가기 처리React Native에는화면 전환이 기본으로 제공되지 않는다.그래서 대부분의 앱에서react-navigation 라이브러리를 사용한다.이 글에서는react-navigation을 처음 쓰는 사람 기준으로개념부터 가장 기본적인 사용법까지 정리한다.이 글이 필요한 사람화면이 하나짜리 앱에서 다음 단계로 가고 싶은 경우페이지 이동 개념이 아직 헷갈리는 경우react-navigation이 왜 필요한지 궁금한 경우React Native에 네비게이션이 없는 이유웹에서는 이런 흐름이 익숙하다.URL 변경페이지 이동뒤로 가기하지만 React Native 앱은단..