호댕의 iOS 개발

iOS에서 앱을 배포하기 위해선 Code Signing이 필수적이다. 이를 통해 어떤 사람이 해당 앱에 서명을 했는지 식별하고, 서명이 된 이후에는 앱에 변경 사항이 없다는 것을 보증해준다. (서명은 앱 빌드 & 아카이빙 시 됩니다) https://help.apple.com/xcode/mac/current/#/dev3a05256b8 https://help.apple.com/xcode/mac/current/#/dev3a05256b8 To see this page, you must enable JavaScript. Pour afficher cette page, vous devez activer JavaScript. Zur Anzeige dieser Seite müssen Sie JavaScript aktiv..

갑자기 이런 메일을 받았다면...? 24년 3월 13일 이후로 배포 시 프로덕트에 Privacy Manifests가 누락되어 있다면 애플에서 메일을 보내게 된다. Hello, We noticed one or more issues with a recent submission for App Store review for the following app: {앱 이름} Version {현재 배포 버전} Build {등록해놓은 빌드 버전} Although submission for App Store review was successful, you may want to correct the following issues in your next submission for App Store review. Once yo..

최근 회사에서 테스트 코드를 지속적으로 추가해주고 있고, 멋쟁이 사자처럼에서도 테스트 코드 관련해서 발표를 진행해서 테스트 코드에 대해 한 번 정리해보고자 한다. 일단 테스트 코드는 채용공고를 보더라도 심심치 않게 보이기도 하고 막연히 테스트를 짜면 좋다는 생각을 가지고 있지만, 못짜는 경우도 많다. 테스트가 필요한 이유 그럼에도 테스트는 왜 필요할까? 물론 앱 규모가 작다면 매번 직접 시뮬레이터나 실기기에서 실행을 해보면서 원하는 동작이 정상적으로 작동하는지 테스트할 수도 있을 것이다. 오히려 이렇게 하는게 더 빠를 수도 있다. 하지만 이렇게 하면 한계는 존재한다. 버그나 예상하지 못한 사이드 이펙트가 발생했더라도, 어디서 발생했는지 바로 알 수 없음 앱이 커지고 리팩토링이 지속적으로 발생할 경우 직접..

이미 회고를 적기엔 늦은 날짜이지만 더 늦어지면 아예 안 적을 것 같아서 이제와서 23년 회고를 작성한다. 23년은 큰 변동은 없었던 한 해였고, 정말 시간이 어떻게 간 줄 모르게 빠르게 지나간 한 해였다. 그래도 다시 돌이켜보면 많은 것들을 한 한해인 것 같다. 작년 계획 평가 일단 작년 회고 에서 아래 목록을 계획으로 세웠었는데 [회고] 2022년을 돌아보고 앞으로를 계획해보자 (비전공자의 iOS 개발자를 위한 고군분투) 2022년은 정말 새로운 것들이 많았던 해였다. 진짜 2022년은 한마디로 모든 것이 새로운 한 해 이다. 기존 전공인 부동산학과와도 전혀 무관한 일을 하고 있고, 이전에 했던 인턴인 HR 직무와도 거 ho8487.tistory.com SwiftUI 공부하기 & 프로젝트 시도하기 🟡..

앱 개발을 하다보면 웹뷰로 구현이 되어 있는 부분을 종종 마주하게 된다. 특히 커머스 앱처럼 콘텐츠의 업데이트가 빠르게 되는 경우 앱의 업데이트 없이도 콘텐츠를 변경할 수 있기 때문에 웹뷰는 유용하게 사용된다. 하지만 이전에는 특정 URL을 웹뷰로 띄워보는 정도의 간단한 사용만 해보았고, 회사에서도 이미 커스텀되어 있는 웹뷰 관련 객체를 단순히 이용만 하여 웹뷰에 대한 구체적인 사용방법 등은 알지 못했다. 그러다 이번에 웹뷰 관련 작업을 하면서 웹뷰에 대해 좀 더 공부를 해보게 되었고 이를 정리하게 됐다. 일단 웹뷰를 사용하고 있다면 현재는 WKWebView 혹은 SFSafariViewController를 사용할 것이다. 이전에 사용하던 UIWebView는 iOS 12.0 이후로는 Deprecated 됐..

왜 DiffableDataSource를 알아보게 되었을까? 기존에는 TableView나 CollectionView를 사용할 때 IndexPath를 통해 Cell을 가져오고 이에 해당하는 데이터를 Cell에 주입시켜주는 식으로 사용을 하게 된다. 하지만 이렇게 사용하게 되면 비동기로 동작을 할 때 데이터를 업데이트하는 시점이 꼬이는 문제를 마주하게 된다. 이렇게 되면 강제종료가 발생하게 되고, 이로 인해 사용자 경험이 저하된다는 문제가 있다. 이런 문제는 사용하면서 항상 발생하는 문제가 아니라 간혹 데이터가 CollectionView / TableView가 업데이트되는 도중에 변경이 되면서 데이터의 수와 그려야 할 셀의 수가 차이가 나면서 발생하기 때문에 정확히 어떤 상황에서 발생하는 것인지 디버깅이 쉽지..

SwiftUI를 사용하다보면 꼭 보게 되는 것이 존재한다. import SwiftUI struct ContentView: View { var body: some View { Text("Hello World") } } View 프로토콜을 채택하게 되면 반드시 var body를 선언해야 하고 이는 연산 프로퍼티이며 some View 타입이다. 흠... 그런데 View면 View지 여기서 some View를 사용한다. 이유가 뭘까? 일단 some View로 선언한 타입 내에선 다양한 뷰를 나열하게 되면 뷰가 잘 그려진다. import SwiftUI struct ContentView: View { var body: some View { ZStack { Color(.black) Text("Hello World")..

앱에서 예상하지 못했던 비정상 강제 종료되는 상황을 트래킹하기 위해 Firebase의 Crashlytics를 많이 사용하게 된다. 사용자들에게 앱을 사용하다가 갑자기 앱이 종료되게 된다면 앱에 대한 신뢰도가 매우 떨어질 수 있기 때문에 이를 지속적으로 트래킹하고 문제의 원인이 된 부분을 해결해줘야 한다. Crashlytics는 Xcode의 dSYM 파일의 디버깅 정보를 이용해 어떤 코드에서 문제가 생겼는지에 대해 알려주게 된다. 구체적으로 보자면, dSYM 파일에는 앱의 바이너리 코드에서 사용하는 함수 / 변수 이름과 이에 대한 주소 정보가 포함한 Symbol Table이 존재하게 된다. 이를 매핑하여 어떤 함수에서 문제가 발생했는지 식별 가능 소스 코드에서 라인 번호와 바이너리 코드의 주소 간의 매핑 ..