블록체인하는 만두아빠

Flutter로 앱 개발을 완료하고 Apple App Store에 배포하는 상황에서 생기는 오류 해결 방법을 소개해드리려 합니다. ITMS-90078: Missing Push Notification Entitlement는 Xcode를 통해 Archive - Validate - Distribute를 거치고 나서 해당 사항 누락의 경우 등록된 메일을 통해 확인할 수 있는 오류입니다. 앱 리뷰 심사 거절(Reject)을 당하지 않도록 미리미리 준비해야할 것입니다.

해당 오류는 Push Notification을 Capability에 추가해주어야하는 오류입니다. Xcode를 통해 간단하게 추가해줌으로써 해결이 가능합니다.

Xcode를 통해 프로젝트를 열고 Targets - Runner - Signing & Capabilities 로 가서 Capability를 추가해주도록 합니다.

Push Notifications를 찾아서 더블 클릭을 통해 추가해주도록 합시다.

Signing의 아래쪽에 Push Notifications가 정상적으로 추가되었다면 다시 빌드해주도록 합니다.

Flutter로 앱을 개발할 때, 실제로는 앱 내에서 Push 알림을 사용하지 않더라도 사용된 패키지에 따라 Push Notifications가 설정이 되어야하는 경우가 있습니다. Push Notifications 없이 App Review를 시작했다가 Reject되면 시간 낭비가 크게 되니 반드시 Email을 통해 전송되는 오류들은 확실하게 잡아두고 진행하는 것이 좋다고 볼 수 있습니다.

Flutter로 앱을 제작하다가 AVD, iOS Simulator 등으로 디버깅할 때 뜨는 Debug 라벨 제거 방법입니다.

아래와 같이 Appbar를 사용하지 않는 앱을 개발할 때 특히 Debug 라벨이 더 거슬리기도 하는데, 제거 방법은 매우 간단합니다.

stl 혹은 stf Widget에서 return되는 MaterialApp 안에 다음의 명령어 한 줄이면 됩니다.

  @override
  Widget build(BuildContext context) {
    return MaterialApp(
        debugShowCheckedModeBanner: false,
        ...
        )
   }

debug 라벨을 제거하면 다음과 같이 깔끔한 디버깅 환경에서 테스트를 해볼 수 있습니다.

debug 라벨을 제거하지 않더라도 실제 Release 때는 라벨이 자동으로 제거가 되니 너무 걱정하지 않으셔도 됩니다.

일반적으로 main.dart 안에서만 모든 Widget을 구성한 경우가 아니라면 라벨을 제거하고 싶은 MaterialApp 마다 Debug 라벨 제거를 직접 해주셔야 합니다.

Flutter에서 앱을 작성하고, 구글 플레이스토어에 심사를 제출하기 전에 필요한 내용들을 정리.

(추후에 스크린샷을 추가하여 수정할 예정)

1. 앱 서명하기

Mac 기준 keystore 만드는 명령어.

keytool -genkey -v -keystore ~/key.jks -keyalg RSA -keysize 2048 -validity 10000 -alias key

여기서 생성된 파일은 공개 저장소에 올리지 말 것.

2. app/build.gradle 에서

• version Code 설정
• applicationID 작성
• signingConfigs 만들고 buildTypes를 debug에서 release로 변경
• keystoreProperties 작성
• 2021.12월 기준 TargetSdkVersion은 30 이상으로 작성되어야함

3. android 폴더에서

• key.properties 작성

터미널에서 flutter build appbundle 입력하여 aab파일 생성 → build/app/outputs/bundle/release에 app-release.aab 파일 있음

4. 개인정보처리방침 만들기

개인적으로 제작할 경우 관련 사이트(개인정보보호 포털)를 사용하고 이미 있는 경우 링크를 등록

5. 추가 필요한 내용

• 앱 액세스 권한
• 광고
• 컨텐츠 등급
• 타겟층
• 뉴스 앱
• 코로나19 접촉자 추적 앱 및 검사 결과 공유 앱
• 데이터 보안
• 웹 카테고리 선택 및 세부정보 제공
• 스토어 등록정보 설정
  • 앱 이름, 80자 설명, 4000자 자세한 설명.
  • 그래픽
    • 앱 아이콘(512x512)
    • 그래픽 이미지(1024x500)
    • 스크린샷 16:9 비율 320px~3840px, 2~8장
    • 7인치 태블릿 스크린샷(16:9 320x3840)
    • 10인치 태블릿 스크린샷(16:9 320x3840)

만두 이야기

풍성한 털(모량)과 짧은 머즐의 훌륭한 유전자를 갖고 태어났으나

아기 시절 큰 수술로 인해 전체 미용을 하게되어 그 많은 털들을 잃은 만두

그의 미모를 담은 스튜디오 촬영샷

아기사자 만두

얌전하게 앉아 아련한 눈빛을 쏘는 만두

사진찍는 동안 거의 가만있질 않았던 체력 풀충전 만두..

스튜디오 컷이 마음에 듭니다!

만두 이야기

겨울이 되어, 날씨도 춥고 쌀쌀한 요즘

간만에 사진을 보고 떠올려보는 가을

뒷산으로 산책 간 만두

뒷산의 나무 냄새도 맡아보고

아직 푸르른 잔디를 밟으며 헥헥 소리를 내는 만두

가을이어도 덥긴 더웠던 모양

"나도 같이 앉아서 쉴래"

"너무 덥다 진짜"

사진에서도 들리는 듯한 헥헥 소리

벤치에 앉아 잘 쉬는 만두

"강아지 친구는 언제나 환영이야"

집으로 가는 길, 아직 지지 않은 꽃이 가득한 화단 앞에서 자꾸 뒤돌아보며 산책의 끝을 아쉬워하는 만두

React 프로젝트 빌드 시 Expected linebreaks to be 'LF' but found 'CRLF' 에러가 발생할 경우 처리 방법 2가지!

Windows와 Mac 환경에서 번갈아가며 작업하는 등의 경우 간헐적으로 발생하는 에러로 Windows의 경우 캐리지 리턴(CR) 이후에 줄바꿈(LF)을 사용하여 CRLF가 되는 반면, Linux의 경우 단순 줄 바꿈(LF)의 형태를 사용하기에 나타나는 문제입니다.

1. 소스 코드 내에 직접 규칙을 작성하는 방법

   - Windows PC의 경우

/* eslint linebreak-style: ["error", "windows"] */

   - Unix의 경우

/*eslint linebreak-style: ["error", "unix"]*/

2. .eslintrc.js 파일에 규칙 직접 추가하는 방법

...

rules: 
	{
      'linebreak-style': 0,
    }
    
...

위의 방법 중 어느 것을 선택하든 쉽게 오류를 처리할 수 있습니다. 다만 컴포넌트의 갯수가 많은 경우 일일이 소스코드 내에 규칙을 작성해주는 것보다, 2번의 방법이 훨씬 편리할 것입니다.

열심히 만든 어플리케이션을 Apple App Store에 배포하기전 내부 테스트를 진행할 수 있도록 돕는 TestFlight를 사용해봅시다. Google Play Store에서는 자체적인 링크를 통해서 내부 테스팅을 진행할 수 있게 하는데, App Store에서는 TestFlight라는 별도의 앱을 통해서 코드를 받고, 코드 교환을 통해서 내부 테스트용 앱을 설치해볼 수 있도록 하고 있습니다.

우선 테스트할 앱을 빌드하고나서 developer.apple.com을 통해 App Store Connect로 들어갑니다.

사용자 및 액세스에 접속해서 내부 테스팅을 할 유저를 추가해줍니다. 참여할 내부 테스터의 Apple ID를 입력해주세요.

테스팅할 앱을 선택하고 TestFlight로 갑니다.

TestFlight에서 내부 테스팅에 + 를 눌러 테스팅 그룹을 먼저 추가해줍니다.

내부 그룹을 생성하셨으면 이제 테스터를 등록해줄 수 있습니다.

초대가 진행이되면 노란색으로, 초대가 정상적으로 되어 설치가 되면 설치되었다는 진행 상태가 표시됩니다. 테스터로 등록되어 초대받은 분에게는 해당 apple 계정에 등록된 메일주소로 다음과 같은 메일이 발송됩니다.

Accept invitation을 통해 Apple Developer 사이트로 넘어가서 로그인을 해줍니다. 등록이 정상적으로 진행이 되면 새로운 메일이 하나 더 메일주소로 오게됩니다.

해당 어플리케이션을 TestFlight에서 설치할 수 있는 코드를 담은 메일입니다. 이제 View in TestFlight를 통해 코드를 받고, TestFlight 앱에서 내부 테스팅을 진행할 수 있습니다!

열심히 작업한 모바일 어플리케이션을 구글 플레이스토어에 배포하기 전, 내부 테스트를 진행할 수 있습니다. 내부 테스트를 통해 실제 배포 이전에 버그나 최적화 등을 테스트해볼 수 있습니다. 우선 내부 테스트를 업로드하기 전에 테스트 환경을 설정해보도록 합시다.

테스트를 진행하고자하는 테스터는 우선 구글 플레이 모바일 앱으로 접속합니다. 프로필을 클릭하고 설정으로 들어갑니다.

가장 아래쪽에 정보를 클릭합니다.

Play 스토어 버전을 연속으로 계속 클릭해주세요. 개발자 모드가 열립니다.

완료되면 일반 탭에 가셔서 내부 앱 공유를 열어주실 수 있습니다. 

이제 내부 테스트 링크를 통해 어플리케이션을 미리 설치해서 내부 테스트를 진행할 수 있습니다.

Flutter로 Android 앱 개발을 위한 디버깅 중 [INSTALL_FAILED_INSUFFICIENT_STORAGE] 에러를 발견하셨을 경우에 대한 해결 방법입니다.

기본적으로 처음 생성한 Android Emulator에는 800MB의 용량을 가지고 있습니다. 이 용량을 초과하는 App을 빌드하면 위와 같은 오류가 뜹니다. 여유공간을 넉넉하게 설정해주도록 합시다.

안드로이드 스튜디오로 가서

우측 상단에 있는 AVD Manager를 클릭합니다.

설정할 에뮬레이터를 확인하고 Edit을 통해 설정을 수정해줄 것입니다.

Show Advanced Settings를 클릭해서 고급 설정을 열어줍니다.

아래에 보시면 Internal Storage가 기본의 경우 800MB로 설정이 되어있을 것입니다. 이제 여유공간을 충분히 잡아주고 다시 빌드를 하면 됩니다.

우리는 iOS 앱을 개발하면서 앱을 실제 아이폰에서 테스트를 할 때, 일반적으로 케이블을 통한 연결 사용을 하게 됩니다. 실제로 케이블을 활용한 연결이 가장 간편하며 VScode에서 Flutter나 React-Native로 개발을 할 때 바로바로 연결이 가능하기 때문에 편리하기도 합니다. 하지만 케이블 연결이 끊어지면 디버깅중인 앱 또한 바로 종료되고, 케이블의 길이는 주로 짧은 편이므로 이러한 물리적인 불편한 점도 역시 존재합니다.

iMac 혹은 MacBook과 iPhone이 같은 무선랜 환경에 있다면 무선 디버깅을 통해 보다 쉽고 간편하게 디버깅이 가능합니다.

우선 케이블로 아이폰을 연결한 뒤 Xcode를 열고 Windows에서 Devices and Simulators를 선택합니다. 여기서 뜨는 창에서

connect via network를 선택해줍니다.

기존에 연결된 아이폰 옆에 지구본 모양과 같은 아이콘이 떠있는 것을 확인할 수 있습니다. 이제 기기 연결을 해제하고 Xcode를 다시 켜서 확인해주면 됩니다.

이제 별도의 케이블 연결없이도 무선으로 디버깅이 가능한 상태가 되었습니다!