Multiple Firebase Configuration 설정하기

Requirements xcconfig 과 Xcode scheme 을 이용하여 하나의 Xcode 프로젝트로 각 서버환경에 따른 앱을 구성했다. (요건 별도의 포스팅을 통해 상세히 서술해보겠습니다.) 오류 로그 관리를 위해 Firebase Crashlytics 서비스를 이용하기로 결정하였고 Firebase 에서 제공하는 메뉴얼을 통해 SDK를 연동 중 GoogleService-Info.plist를 다운받았다. 서버 환경이 3종류다보니 3개의 파일을 받았다. Try First FirebaseOption 클래스를 보니 파일이름을 파라미터로 instance를 생성하는 인터페이스가 존재한다. 동일한 파일명의 파일 3개를 프로젝트에 포함시켜야 하니 구분을 용이하게 하기 위해 파일이름을 아래와 같이 변경하였다. GoogleService-Info-Dev.plist GoogleService-Info-Staging.plist GoogleService-Info-Production.plist 그리고 아래와 같이 코드를 작성하였다. 실행을 했더니 GoogleService-Info.plist 파일을 찾을 수 없다는 경고가 로그창에 나타난다. 😣😤😡 Firebase SDK 개발팀에 대한 불만은 이전부터 있었다. SDK가 업데이트 될 때마다 자잘한 버그들이 끊이지 않은 것 때문인데, 이 경우도 그렇다. 인터페이스는 만들어두고 왜 코드 내부에서는 이를 처리하도록 하지 않는 것인가! 반성 좀 하길.. 😡 구글링을 해서 찾아보니 이 문제 때문에 발행된 이슈들이 꽤 있었다. In new Firebase, how to use multiple config file in xcode? Use different GoogleService-Info.plist for…

ATS(App Transport Security) 예외 도메인을 적용했는데도 ATS 오류가 날 때 확인 방법

ATS? WWDC 2016에서 발표된 ATS (App Transport Security) 도입은 iOS9부터 적용되었습니다. SSL 통신을 해야하고 최소 TLSv1.2를 만족해야 하며, 인증서는 SHA256 이상의 해쉬 알고리즘으로 서명되어야 한다는 의미입니다. 하지만 이를 당장에 만족시키기에는 무리다보니 선택적으로 적용되었고 2016년 12월말까지는 필수 적용을 해야한다고 발표했습니다. (그 후 연기가 되었고 지금은 어떤지 모르겠습니다..) 하지만 ATS를 설정한 이후에는 규칙과 예외 도메인을 관리해야하니 귀찮긴합니다… 설정하는 디테일 한 방법은 이 글에서 설명을 하진 않겠습니다. 오류 발생 ATS를 잘 정의했는데 관련 도메인의 추가 등의 이슈로 어느 순간 만날 수 있는 오류 메시지가 있습니다. Connection failed: Error Domain=NSURLErrorDomain Code=-1022 “The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.” UserInfo={NSUnderlyingError=0x7fada0f31880 {Error Domain=kCFErrorDomainCFNetwork Code=-1022 “(null)”}, NSErrorFailingURLStringKey=MyServiceURL, NSErrorFailingURLKey=MyServiceURL, NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection.} The resource could not be loaded because the App Transport Security policy requires the use of a secure…

Universal Link (iOS9) 적용하기

Universal Link? iOS9에서는 Universal Link 라는 기능이 추가 되었습니다. 이 기능을 쉽게 설명하자면, 일반적인 링크를 유저가 선택 시 해당 웹페이지로 이동하는 것이 아닌 해당 웹페이지에서 제공하는 앱을 띄워주는 기능입니다. 기존에는 앱의 고유 scheme을 정의해서 띄우는 방식이었는데 여기서 조금 더 발전된 기능이죠. Medium이라는 앱을 주로 사용하시는 분들은 이미 이 기능을 보셨을 수도 있겠네요. 짧지만 데모 영상 보고 가실게요~ 영상 최초 화면은 iOS 기본 메모장으로 테스트를 위해서 형식을 달리한 제 홈페이지 주소를 저장해뒀습니다. 그 주소 중 하나를 선택하면 일반적으로는 safari가 열리며 홈페이지가 열리지만 제가 임의로 만든 앱으로 이동하는 것을 볼 수 있습니다. 이것이 Universal Link 입니다. 간단하죠? Universal Link 구현 방법 당연하겠지만 애플 문서에서 잘 설명하고 있습니다. 그 외에도 검색을 해보면 여러 글들이 보입니다. 웹서버에 apple-app-site-association 파일 업로드 앱과 연관된 웹 서버의 루트(ubuntu 서버에서는 기본적으로 /var/www/html)에 정의 된 apple-app-site-association 파일을 업로드 합니다.이 파일은 JSON 형태로 아래와 같은 형태를 가집니다. JSON 내용 중 appID는 애플 개발자 계정의 Account Info 내용 중 Team ID 값과 앱의 identifier입니다.…

UITextField의 Placeholder에 animation 효과를 적용한 것처럼 보이게 구현하기

음.. 제목 정하기가 참 힘드네요. UITextField는 보통 로그인과 회원가입 시 유저에게 문자열을 입력받기 위해서 많이 사용합니다. 로그인 페이지에 대해서 이런저런 고민이 있어 pinterest를 검색하던 와중에 아래의 UI 컨셉을 발견했습니다. 부연 설명을 하자면, UITextField에 특정값 입력을 유도하는 placeholder는 입력이 시작되면 사라지게 되어 있습니다. 이 때 위 화면과 같이 타이틀이 별도로 없는 UI구성일 때는 좀 애매한 경우가 생기기도 하는데 재치있게 풀었더군요. 그래서 구현을 해봤습니다! (사실 다 아시는 건데 기록은 남겨야겠기에..) 아래 영상은 위 컨셉과 유사하게 컴포넌트를 적용한 화면입니다. 똑같진 않지만 비슷한가요…? 원리는 UITextField를 상속받은 클래스에 UILabel을 임의로 하나 더 addSubview 합니다. 사실 가장 효율적인 방법은 placeholder를 보여주는 view를 조작하는 것인데 쉽게하기로 맘먹고 UILabel을 배치했습니다. 이 코드에서 가장 중요한 포인트는 changeStatus입니다. enum으로 정의된 status에 따라 UILabel의 animation이 수행되도록 했습니다. !! 아래 노출되는 코드들은 Swift 2.0 기준입니다. 그 다음은 UITextField delegate의 각 이벤트 메소드에 상황에 따른 status 변경을 합니다. 위 코드에서 정의한 changeStatus를 적절하게 호출합니다. 비교적 쉽게 concept 디자인의 UITextField를 완성했습니다. (팁이나 될려나 몰겠네요..)

Swift vs. Objective-C ?!

2014년 Apple은 WWDC 2014에서 Swift를 발표했고 빠르게 버전업을 거쳐 벌써 Swift 2.0이 나왔습니다. 발표 당일 현지에 있었던 전 환호의 소리를 들었지만 걱정이 많았습니다. 새로운 언어를 배워야 한다는 부담감도 있었고 반감도 있었죠. 그래서 주변 분들에게는 난 계속 Objective-C로 개발할거야 라고 장담했었죠. 하지만 그 장담은 불과 일년만에 깨지고 말았습니다. 올해 초 새로운 프로젝트에 투입이 되었는데 무슨 이유인지 몰라도 욕심이 생겨서 프로젝트를 Swift로 세팅했습니다. 당시는 Swift 1.1에서 1.2로 넘어가는 시점이었는데 미리 해본 개발자분들은 아직은 아니다라며 말리셨습니다만 무모한(?) 도전을 해보기로 했습니다. 결국 Swift 1.2를 이용해 프로젝트를 계속 진행하였고 최근 결과물이 Apple의 심사를 마치고 App Store에 등록이 되었습니다. 왜 중도에 Objective-C로 회귀하지 않고 Swift로 프로젝트를 지속했을까 궁금증이 생기시는 분도 계실테고 반대로 아직도 시기상조 아닌가라고 생각하시는 분들이 많으시리라 생각됩니다. 그래서 좀 늦었지만 Swift 프로젝트 경험기를 공유하고자 합니다. Swift로는 안되는 것이 많다. 아닙니다. 어떤 framework를 사용하느냐에 따라 버그 유무는 존재했었지만 안되는 것은 없었습니다. 1.1까지는 버그가 꽤 많았다고 합니다. 그래서 Objective-C 코드와 Swift 코드를 Bridge 해서 사용하느니 그냥 Objective-C로 하겠다는 분도 계셨었습니다. 이 부분은 1.2에서…