멋있게걷는방법

출시는 성공했지만 firebase 로그인이 되지 않을 때!많이들 sha키를 제대로 확인하라고 하지만, 만약 처음 앱을 올리는 게 아니라 이미 앱이 배포되어 있고 두 번째 시도일 때는 이유가 다릅니다. 안드로이드는 한 번 출시하면 두 번째부터는 추가해줘야하는 sha 키가 있는데 이걸 firebase에 추가해 줘야 로그인이 가능합니다. 1. 먼저 google play console에 가셔서2. 설정 -> 앱서명 으로 이동하면 앱 서명 키 인증서 섹션에 보시면 SHA-1 인증서 지문과 SHA-256 지문이 있을 거예요. 이걸 firebase -> 프로젝트 설정 -> 내 앱 -> android -> 디지털 지문 추가에추가해 주시고 google-services.json을 다시 다운로드한 후 프로젝트에 적용시키면 ..

가장 큰 차이는 참조 카운팅 시점. GC 런타임 중에 메모리 해제 시점을 결정함. - 이미 할당된 메모리에서 더 이상 사용하지 않는 메모리를 해제하는 기술. 런타임에 동작. 백그라운드에서 실행. 불확실한 간격으로 발생하기 때문에, 객체가 더 이상 사용되지 않는 정확한 순간에 무조건 해제되는 건 아님. 발생시점 각 영역에 할당된 크기의 메모리가 허용치를 넘을 때 수행됨. ⇒ 개발자가 컨트롤할 수 없다. 왜? ⇒ 강제로 GC를 수행시키면 GC를 실행하는 동안 해당 스레드를 제외하고 모든 스레드가 멈춰서 성능에 영향을 줄 수 있다. 성능 저하가 발생할 수 있음. 런타임에 계속해서 메모리를 감시하다가 해제하기 때문이다. 순환참조 발생 X 계속해서 메모리를 감시하기 때문에 인스턴스가 해제될 가능성이 더 높다. 장..

해당 문제는 Tuist를 이용해 SPM을 사용하면서, Firebase SDK Library를 추가하면서 생긴 에러입니다. 해결법 일단 가장 간단한 방법은 Targets -> Build Phases -> Link Binary With Libraries에JavaScriptCore.framework를 추가하면 해결됩니다. 일단 저의 경우는 Tuist를 쓰고 있기 추가했더라도 generate를 하게 되면JavaScriptCore.framework가 다시 사라져 근본적으로 해결할 순 없습니다. Tuist에 추가하기 현재 Library를 추가하려는 모듈에서, dependency에 추가해야 합니다. 아래와 같이 TargetDepency의 sdk를 사용해 추가하면 됩니다. 주의 type을 framework로 지정해 주..

기본적으로 super 키워드는 상위 뷰를 호출합니다. 예를 들어볼게요. class A: UITableViewCell { override func layoutSubviews() { super.layoutSubviews() } } 만약 제가 UITableViewCell을 상속하고 있는 A라는 클래스에 있는 layoutSubview override 함수에서 super를 통해 super.layoutSubviews()를 호출했다면 어떤 뷰가 실행될까요? super는 상위 뷰를 호출한다고 했죠? 현재 상속 중인 클래스는 UITableViewCell입니다. 그럼 호출되는 건 UITableView의 상위 뷰인 UIView의 layoutSubviews가 호출되겠죠! super 가 뭘 하는 녀석인 줄은 알고 있었지만 이렇..

Guideline 2.1 - Information Needed In addition to the demo account you provided, we still need a demo phone number and authentication code to verify the registration process in your app. 해당 리젝 사유는 한 마디로 '나 회원가입 테스트할 건데 테스트용 전화번호랑 인증코드 줘'라는 의미입니다. 따라서 서버에서 테스트용 전화번호와 해당 전화번호일 때 성공할 수 있는 인증번호를 임의로 설정해야 합니다. ex) 전화번호가 01011110000 일 때 인증번호가 0000 이면 성공. 와 같은 로직을 작성해야 한다. 서버에서 이러한 로직이 있다면, 앱 심사 정보 메모에..

저의 두 번째 프로젝트를 개발, 출시하며 들었던 생각과 고민들에 대해 적어보려고 합니다. 이 프로젝트는 원래는 한 달짜리 프로젝트였지만, TestFlight를 통해 팀원끼리 테스트도 하며 피드백을 통해 요구사항을 추가됐고, 디자인도 변경되면서 기간이 길어졌습니다. 팀원들은 '일단 배포하고 v2에서 고치자~'라는 말을 자주 했는데요. 사실 이 말이 어쩌면 맞을지도 모릅니다. 빠른 앱 출시를 시도한다면, 앱스토어 배포 과정에서도 reject 사유를 알 수 있고, 또 만약 reject 없이 바로 앱이 출시된다 하더라도 사용자들로부터 얻는 피드백을 통해 앱의 퀄리티를 높일 수도 있겠죠. (reject 사유를 알 수 있다는 건 큰 이점이란 걸 이번에 reject을 4번 당하면서 깨달았습니다. ㅎㅎ) 그러나 제 생..

프로젝트에 단순 데이터를 불러오는 게 아닌, page 단위로 불러오면 메모리 효율을 아낄 수 있는데요, 이게 바로 Pagination 입니다. 무한스크롤이라고도 하죠. Pagination 은 메모리 효율을 아낄 수 있다고 했는데, 그 이유는 뭘까요? 들어가기 전에, tableView의 delegate, datasource로 tableView를 구성했다면 대부분 dequeueReusableCell를 이용해 재사용 셀을 구성했을 겁니다. 만약 Rx를 쓴다면? .drive(postTableView.rx.items(cellIdentifier: PostCell.identifier, cellType: PostCell.self)) { (row, data, cell) in 이런 식으로 쉽게 구현할 수 있었을 것입니다...

기존에 Github Action으로 CI를 구축할 땐 아래처럼 yml을 작성했습니다. name: Swift on: push: branches: [ master ] pull_request: branches: [ master ] jobs: build: runs-on: macos-latest steps: - uses: actions/checkout@v3 with: xcode-version: latest - name: install tuist run: curl -Ls https://install.tuist.io | bash - name: project Generate run: | rm -rf .package.resolved tuist generate - name: Build run: | xcodebuild -p..