앱스토어 계정 이전시 애플 로그인 마이그레이션

애플 로그인을 사용중인 앱을 다른 앱스토어 계정으로 이전하는 경우 해당 앱 내에서 애플 로그인 사용자를 구분하는데 사용되는 ID값(Team scoped identifier)이 변경된다. 이 값 뿐만 아니라 기존 애플 로그인 사용자가 이메일 가리기(private email) 기능을 활성화 했다면, 이로 인해 생성된 이메일 주소 또한 바뀌기 때문에 앱 이전(app transfer, 앱 트랜스퍼) 전/후로 별도의 마이그레이션을 꼭 수행해야한다. 이를 제대로 잘 처리하지않으면 기존 가입되어있던 사용자가 로그인을 시도해도 기존 사용자 정보로 로그인되는것이 아니고 신규 사용자 처럼 간주될 수 있기 때문에 주의해서 처리가 필요하다. ...

2023년 9월 13일 · 5분 · 910단어

모바일 디바이스간 P2P 연결 및 데이터 전송 방법

iOS/Android 모바일 디바이스들 사이에서 P2P 형태로 데이터 전송을 하는 방법에 대해 리서치 할 일이 있어서 알아본 내용을 간단히 공유합니다. 네트웍 타입별 Android/iOS P2P 연결 가능성 체크 Bluetooth 애플 MFi인증 디바이스만 iPhone/iPod과 Bluetooth 연결 가능 MFi는 apple에서 accessary 제조업체들이 만든 하드웨어를 인증하는 제도 (안드로이드는 인증되지 않음) Bluetooth Low Energy BLE는 애플 MFi인증 제약이 존재하지 않아서 안드로이드/iOS간 연결 가능 BLE는 말그대로 저전력으로 설계된 spec이기때문에 전송 속도가 매우 느림 iOS는 모두 지원하지만 안드로이드 디바이스별로 지원 스펙이 다름 (제대로 지원안하는 경우도 있음) BLE의 최대 전송속도 Apple guide line을 따르는 BLE 디바이스라면 디바이스에따라 이론적인 최대 전송속도 8~32kbps 정도가 한계 packet interval, MTU size 파라메터에 맞춰 application이 전송하는 데이터를 완벽하게 fit 시켰을때 나올 수 있는 이론적인 수치. 실제로는 더 느릴것 같음 https://devzone.nordicsemi.com/question/3440/how-do-i-calculate-throughput-for-a-ble-link/ WiFi 동일 네트워크 라우터에 접속한 디바이스들사이에서 P2P 연결 가능 multicast를 지원하는 라우터인경우 mDNS(ex: Apple Bonjour)를 이용하여 자동으로 동일 네트웍상의 디바이스를 찾아 주는 것이 가능 개인적으로 사용하는 office/home wifi가 아닌 WiFi hotspot 같은 공용 라우터의 경우 P2P 연결이 안될 가능성이 높음. 뮤직 서버에서 P2P연결 시작만 중계하는 NAT 뒤에 연결된 디바이스들도 연결이 가능하긴 함 UDP 홀펀칭 등의 방식을 사용하면 어느정도 커버가능하긴하지만 100% 연결 보장은 힘듦 참고자료 Android/iOS Local Radio Interop 3rd party frameworks Google Nearby Bluetooth, BLE, WiFi 등의 연결방식을 상황에따라 적절히 조합해서 근처에 있는 device를 찾아서 연결해주는 framework 아래 두가지 API set이 있는데 상황/용도에따라 다르게 사용 Message API iOS/Android small payload only through google server (devices do have to be connected to the Internet). 음원전송은 불가능 Connection API Android ONLY P2P connection: message, file, stream transfer support 음원전송에 적합 http://p2pkit.io 유료 framework $0.01/ MAU Android/iOS 둘다 서포트 하지만 GoogleNearBy 와 동일하게 대역폭한계로 음원전송에는 부적합해보임 20 messages per second and cannot exceed the size of 100KB

2018년 12월 15일 · 2분 · 270단어

Playground에서 Cocoapod 라이브러리 사용하기

엑스코드 플레이그라운드(Xcode Playground)에서 간단하게 코드를 테스트 해보고 싶은데 해당 코드가 특정 cocoapod 라이브러리에 의존성이 있는 경우 cocoapods-playgrounds 명령어 도구를 사용하면 편리하다. 설치 및 사용 방법 설치 sudo gem install cocoapods-playgrounds 플레이그라운드 프로젝트 생성 cocoapods playgrounds podName 위 명령어를 실행하면 위 라이브러리가 연결된 워크스페이스가 자동으로 생성되고, 해당 워크스페이스 안에 우리가 사용할 수 있는 playground 파일까지 포함되어있으니 여기서 마음껏 테스트 해보면 된다. 여러 라이브러리 동시 참조 여러개 라이브러리에 의존성을 가지는 플레이그라운드 프로젝트를 만들고 싶을 경우, 라이브러리 이름을 컴마로 구분하여 붙여 써 둔다. ...

2018년 11월 24일 · 1분 · 156단어

Swift struct vs. class 차이점 비교 분석

Swift에는 struct와 class타입이 공존하고있기 때문에 아래의 차이점을 잘 숙지하고 상황에 맞게 사용하는것이 매우 중요하다. struct call by value (할당 또는 파라메터 전달시 value copy가 일어남) stack memory 영역에 할당 (속도가 빠름) scope based lifetime: 컴파일타임에 compiler가 언제 메모리를 할당/해제할지 정확히 알고있음 data locality: CPU 캐시 히트율이 높음 상속 불가능 (protocol은 사용 가능) NSData로 serialize 불가능 Codable 프로토콜을 이용하여 손쉬운 JSON <-> struct 변환 가능 (Swift 4 이상) 항상 새로운 변수로 copy가 일어나기때문에 multi-thread 환경에서 공유변수로 인해 문제를 일으킬 확률이 적음 1 class call by reference (할당 또는 파라메터 전달시 객체를 가리키고있는 메모리 주소값만 복사됨) heap memory 영역에 할당 (속도가 느림) 런타임에 직접 alloc하며 reference counting을 통해 dealloc이 필요 memory fragmentation 등의 overhead가 존재 상속 가능 NSData serialize 가능 Codable 사용 불가능 런타임에 타입 캐스팅을 통해서 클래스 인스턴스에 따라 여러 동작이 가능 deinitializer 존재 참고: class안에 struct 변수를 property로 정의하는것 가능하며, 반대로 struct의 property중 하나로 class 인스턴스 변수를 갖고있는 것도 가능하다. 이 경우 해당 struct 변수의 copy가 일어날때 class 인스턴스의 주소값만 복사된다. ...

2018년 1월 30일 · 3분 · 549단어

Swift Closure vs. Objective-C Block 차이점 비교 분석

Obj-C의 블락(block)이나 Swift 클로저(closure)는 컨셉은 거의 동일하나 closure 내부에서 현재 scope에 존재하는 값 타입(value type) 변수들을 캡쳐(capture)해서 사용할 때 기본동작이 반대로 되어있기 때문에 사용법에 주의를 기울여야 한다. 반면 클래스 인스턴스와 같은 참조 타입(reference type) 변수들은 항상 reference copy가 일어나기 때문에 두 언어를 사용할때 차이점에 크게 신경쓰지않아도 된다. (대신 retain cycle이 생기지 않도록 조심해야 한다.) 다음 예제들을 통해서 차이점을 좀 더 자세히 알아보자. Capture in Swift closure Swift의 경우 일반적으로 value type 변수를 다른 변수에 할당하거나, 함수 파라메터로 전달 할 때 copy동작이 기본이다. 하지만 closure에서 변수를 capture를 할 때는 명시적인 capture list를 작성하지 않으면 value type 변수(struct 변수 포함) 임에도 불구하고 reference capture가 일어난다. 확인을 위해서 다음 예제를 살펴보자. ...

2018년 1월 30일 · 2분 · 305단어

Swift 익스텐션, Obj-C 카테고리 메서드명 Prefix하기

Obj-C category의 위험성 Obj-C에서 동일한 메서드 이름을 가진 카테고리(category) A, B가 동시에 존재하더라도, 컴파일 타임에 오류가 발생하지 않고 정상적으로 빌드되어 실행이 가능하다. 하지만 런타임에서 A와 B중 어떤 녀석이 먼저 호출될지 알 수 없기때문에 (규칙이 없으며 랜덤하게 호출됨) 매우 위험한 상황이 발생한다. 이를 방지하기 위해서 Obj-C에서 카테고리 메서드에는 프로젝트에서 사용하는 고유의 prefix를 붙여줘서 이름이 완전히 겹칠 확률을 최대한 줄여주는 방식을 꼭 사용해야 한다. 그렇지 않으면 외부 라이브러리를 사용할때 해당 라이브러리에 동일한 category명이 존재해서 랜덤하게 호출되는 상황이 발생 할 수 있다. 이는 매우 원인 파악도 힘든 에러가 될 것이기에 꼭 피해야 한다. ...

2017년 9월 23일 · 2분 · 381단어

유니버셜링크 vs. 커스텀URL스킴 비교 분석

iOS의 경우 기본적으로 Sandbox환경이라 다른 앱들간에 정보를 주고받는것이 간단하지 않다. 이때 정보를 주고받을 수 있는 대표적인 방법이 custom URL scheme이다. 앱의 고유한 scheme을 정의하고 이 scheme으로 시작하는 URL안에 정보를 담아서 URL을 열게되면 해당 scheme이 갖는 다른 앱을 실행하면서 정보전달을 할 수 있다. 하지만 이 방법에는 치명적인 단점이 있는데, 애플 앱스토어에서 해당 앱이 정의한 scheme의 uniqueness를 보장해주지 않기때문에 다른 앱들이 자신이 정의한 scheme을 사용하고 있을 수 있다는 점이다. 자신의 앱을 MyApp이라고 하고 이 앱이 myapp:// 이라는 custom URL scheme을 사용한다고 가정하자. (MyApp안의 info.plist 내에 존재하는 “URL types – URL Schemes” 항목에 myapp 이 정의하면 됨) 방금 정의한 custom schememyapp은 unique가 보장되지 않기 때문에 앱스토어에 올라온 YourApp 이라는 엉뚱한 앱이 동일하게 앱 내부에 custom scheme으로 myapp을 정의하는 일이 발생할 수 있다. 만약 MyApp과 YourApp이 동시에 설치되어 있는 device에서 myapp://으로 시작하는 URL을 open하게 되면 두 앱 중에서 누가 열릴지 알 수 없게 되어버린다. 설치 순서에 영향을 받는 것도 아니라서 특정한 규칙이 없으며, 상황에따라 두 앱중 하나가 열리게 되는 랜덤한 현상이 발생한다. ...

2017년 8월 21일 · 3분 · 427단어

iOS 인앱 정기결제(IAP Auto-renewable Subscription) 튜토리얼

iOS 앱에서 상품을 등록하고 판매하는 과정은 꽤나 복잡하다. 그 중에서도 정기구독 자동결제(Auto-Renewable Subscription) 상품을 판매하는 경우 신경써야 할 부분이 매우 많다. 2016년 WWDC에서 애플은 Auto-Renewable Subscription을 모든 카테고리의 앱에 적용가능하도록 허용하기로 했고(기존에는 잡지, 음악 등 특정 컨텐츠에 대해서만 허용되었었음), 해당 타입의 결제를 통해 발생한 매출의 경우 다음 조건을 만족할 경우 앱 판매 수수료를 30% ->15%로 인하 하는 내용에 대해서 발표했다. 수수료 인하 조건 해당유저가 1년이상 결제를 유지한 경우 1년 이후 결제분의 수수료를 15%로 인하 (2016년 6월 13일 이후 부터 적용) 사용자가 중간에 정기 결제를 취소했더라도 60일 이내에 다시 정기결제를 시작한경우 해당 유저의 결제 기간은 계속 누적된다. (60일을 넘을 경우 리셋) 이번 발표 전 기존 결제 기간도 카운트 된다. (Prior days of paid service are counted.) 즉, 이미 1년간 결제해온 사용자가 6월 13일 이후에 결제할 경우 수수료는 15%로 줄어든다. Auto-Renewable Subscription에 대해 자세히 설명하기 전에 먼저 앱스토어의 다른 상품 타입들에 대해서도 간략히 정리해보도록 하자. ...

2016년 6월 26일 · 12분 · 2410단어

UIImage의 scale을 올바르게 처리하기

UIImage의 size 는 픽셀(px)단위가 아닌 포인트(point) 단위로 처리가된다. 따라서 사이즈 정보에 추가적으로 스케일(scale) 정보를 같이 같고있다. UIImage를 bundle에서 [UIImage imageNamed:]를 이용하여 불러올때는 이미지에 붙어있는 @2x 또는 @3x 포스트픽스를 통해서 해당이미지의 스케일이 정상적으로 설정되어 특별히 신경쓸 필요가 없다. 마찬가지로 서버에 이미지 데이터를 요청해서 받아올 경우에도 AFNetworking의 AFImageResponseSerializer을 사용하면 UIImage를 만들어줄 때 스케일 관련 정보 또한 내부적으로 처리를 해주니 신경을 쓸 필요가 없다. 하지만 NSData로부터 UIImage 를 생성할때나 파일명에 포스트 픽스가 없는 다운로드된 파일로 부터 UIImage를 생성할 때는 이러한 스케일 처리를 따로 해줘야 된다. ...

2015년 7월 6일 · 2분 · 241단어

Cocoapod version update for Mac OS Yosemite

 Mac OS X Yosemite 로 업그레이드를 하게되면 cocoaPod이 잘 작동하지 않을것이다. 이때 다음 인스트럭션을 따라 해결해 나가면 된다. 코코아팟 최신버전으로 업데이트 (현재 최신은 0.34.4 입니다) sudo gem uninstall cocoapods sudo gem uninstall xcodeproj sudo gem install xcodeproj sudo gem install cocoapods 2. Podfile의 첫줄에 다음 코드 추가 source 'https://github.com/CocoaPods/Specs.git' 이부분은 옵셔널하긴한데, 추가하지 않으면 deprecated warning이 뜨기때문에 추가해주는것이 좋다. 3. 빌드시 Podfile.lock 혹은 Manifest.lock 관련 에러가 날 경우 처리방법 ...

2014년 10월 27일 · 1분 · 97단어