Xcode로 빌드를 하다보면 각종 라이브러리 관련 error로 빌드 실패하는 경우가 상당히 많이있습니다. 

이는 보통 골칫거리가 아닐텐데요. CocoaPods 를 이용하면 라이브러리들을 쉽게 설치하고 관리할 수 있습니다.

이번 시간에는 Xcode에 CocoaPods를 설치하고 CocoaPods로 필요한 라이브러리들을 다운받아보도록 하겠습니다.


먼저, CocoaPods를 설치 할 Xcode 프로젝트를 준비합니다. 

제가 준비한 프로젝트 이름은 "CocoaPodsExample" 입니다.



그 다음 터미널을 실행시켜서 준비한 프로젝트가 있는 경로로 이동합니다.

(위 에서 3번째 줄에 cd CocoaPodsExample 한 것처럼 해당 프로젝트 폴더 안까지 이동하라는 뜻)

이동했다면 다음 명령어를 입력해줍니다.


명령어 : sudo gem install cocoapods 


그 다음 Password를(본인 컴퓨터의 비밀번호) 입력하면 자동으로 다운로드 받습니다.



1 gem installed 라는 메시지와 함께 

cocoapods 다운로드가 완료된 모습을 볼 수 있습니다.



이제 다운로드 받은 cocoapods 를 설치할 차례입니다.

다음 명령어를 입력합니다.


명령어 : pod setup


잠시 후 Setup completed 라는 메시지와 함께 설치가 완료됩니다.



본격적으로 라이브러리를 다운로드하기 위해서는 "podfile" 이라는 설정파일이 필요합니다.

podfile을 생성하기 위해 다음 명령어를 입력합니다.


명령어 : touch podfile



프로젝트 위치로 가보면 podfile 이 생성된 것을 확인할 수 있습니다.



이제 설정파일에 다운로드할 라이브러리 정보를 작성하기 위해 podfile 을 열어줍니다.


명령어 : open -e podfile


물론 podfile 을 더블클릭하여 직접 열어줘도 무방합니다만

간혹 시스템 설정에 따라 직접 열기가 안되는 경우가 있는데 그런 경우 위 명령어를 입력해서 열어주세요.



저는 프로젝트에 Firebase, AdMob, GooglePlayGames 를 연동하려했기 때문에 

필요한 라이브러리를 위와 같이 작성해주었습니다.


만약 ABCDEFG 라는 라이브러리가 필요하다면

대신에 pod 'ABCDEFG' 라고 작성해주면 됩니다.



podfile에 라이브러리 작성을 끝냈다면

작성한 라이브러리를 정말로 다운받기 위해 다음 명령어를 실행해줍니다.


명령어 : pod install



관련 라이브러리들이 다운로드된 모습입니다.

그리고 프로젝트 위치에 ~.xcworkspace 라는 파일이 새로 생성됩니다!



* 여기서 주의할 점!!!


- 혹시 CocoaPods 설치 진행 중에 Xcode 프로젝트가 열려있었다면 완전히 닫아줍니다.

- 앞으로는 ~.xcodeproj 파일 대신에 새로 생성된 ~.xcworkspace 라는 파일로 프로젝트를 열어줍니다. 무조건!


그래야 CocoaPods 로 다운로드한 라이브러리들이 정상적으로 적용됩니다.




XCode 빌드 시


Use of '@import' when modules are disabled


위와 같은 에러가 발생할 때 해결 방법!





- [Build Settings] 으로 이동


- modules 검색


- Enable Modules (C and Objectivce-C) 옵션을 No 에서 Yes 로 변경



끝 입니다 ^^




Google Mobile Ads SDK (구글 애드몹) 를 사용하는 프로젝트를 XCode에서 빌드할 때


No visible @interface for 'GADUNativeCustomTemplateAd' declares the selector 'performClickOnAssetWithKey:customClickHandler:'


이런 에러가 발생한다면!?



GADUNativeCustomTemplateAd.h 파일로 이동합니다.


*nativeCustomTemplateAd 선언 부를 찾습니다.


@property(nonatomic, strong) GADUNativeCustomTemplateAd *nativeCustomTemplateAd;

위와 같이 되어있는 부분을


@property(nonatomic, strong) GADNativeCustomTemplateAd *nativeCustomTemplateAd;

이렇게 수정합니다. (GADU... -> GAD...)





다시 빌드하면 에러가 사라졌을 것입니다!



개발자를 힘들게 하는 애플의 IPv6 검수 통과하기

목차

IPv6에 대해서 최소한도로 알아보기
Apple에서 공지한 iOS 앱에 대한 검수 내용 살펴보기
개발자들이 주의해야 할 사항
IPv6 로 인한 App Reject 사례와 참고 자료

지난 WWDC15 이후에 Apple 개발자 페이지에 올라온 News인 Supporting IPv6 in iOS 9에서는 IPv6-only network service가 지원돼야 한다는 정책을 발표하고, 2016년도 초부터 해당 사항을 앱 리뷰 시에 적용한다고 했습니다. 뉴스를 보자마자 머리가 띵해져 왔지만, 사실 이때까지만 해도 잘 와 닿지 않았던 이유는 IPv6 Only Network를 일반인들에게 제공하는 국내 ISP는 존재하지 않았기 때문에 Apple이 무엇을 원하는지, 그리고 도대체 어느 수준까지 앱 리뷰할 때 Reject 기준이 될지 머릿속에서 혼란이 왔습니다.

물론 Apple답게 테스트 방법에 대한 가이드라인이 있었기 때문에 해당 문서를 보고 제가 담당하고 있는 SDK에 대한 테스트를 진행해봤지만, 역시나 IPv6 Only network에서는 통신이 이루어지지 않았습니다.

처음에는 사내 네트워크 환경부터 SDK의 소스 코드 등을 살펴 보았지만, 크게 문제가 있어 보이지는 않았습니다. 하지만 컴퓨터는 거짓말을 하지 않는지라 SDK 내에서 사용하고 있는 Open Source 라이브러리를 살펴보니, IPv6를 지원할 수 없는 상태였습니다. 따라서 해당 문제를 해결하고 나니 정상적으로 IPv6 환경에서의 테스트가 성공하게 되었습니다.

이제부터의 글은 제가 IPv6에 대한 이슈를 처리하기 위하여 알아본 기본적인 내용에 대해서 적어보도록 하겠습니다.

IPv6에 대해서 최소한도로 알아보기

주소의 길이가 128bit로써 급격하게 늘어나는 인터넷 연결 기기와 이에 따른 IPv4 주소의 고갈에 대응하여 제안되었습니다. IPv6는 기존 Ipv4와의 호환성을 최대한 유지할 수 있는 방향으로 설계되어, 대부분의 기존 프로토콜의 수정 없이 IPv6 상에서 동작할 수 있습니다.

주소 표현 방법

주소의 표현은 128bit의 주소공간으로써 16bit(2octet)를 16진수로 표현하여 8자리로 구성합니다.

2001:0db8:85a3:0000:0000:8a2e:0370:7334

위의 Address Literal은 아래와 같이 표현할 수 있습니다.
0000 은 0으로 축약할 수 있으며, 아래와 같이 생략할 수도 있습니다.

2001:0db8:85a3:8a2e:0370:7334

IPv6의 특성

IPv6의 특성에 대해서 간략하게 알아보겠습니다.

  • IP 주소의 확장: IPv4의 기존 32 비트 주소공간에서 벗어나, IPv6는 128 비트 주소공간을 제공합니다.
  • 호스트 주소 자동 설정: IPv6 호스트는 IPv6 네트워크에 접속하는 순간 자동적으로 네트워크 주소를 부여 받습니다. 이는 네트워크 관리자로부터 IP 주소를 부여 받아 수동으로 설정해야 했던 IPv4에 비해 중요한 사항입니다.
  • 패킷 크기 확장: IPv4에서 패킷 크기는 64킬로바이트로 제한되어 있었습니다. IPv6의 점보그램 옵션을 사용하면 특정 호스트 사이에는 임의로 큰 크기의 패킷을 주고받을 수 있도록 제한이 없어지게 됩니다. 따라서 대역폭이 넓은 네트워크를 더 효율적으로 사용할 수 있습니다.
  • 효율적인 라우팅: IP 패킷의 처리를 신속하게 할 수 있도록 고정크기의 단순한 헤더를 사용하는 동시에, 확장헤더를 통해 네트워크 기능에 대한 확장 및 옵션기능의 확장이 용이한 구조로 정의 했습니다.
  • 플로 레이블링(Flow Labeling): 플로 레이블(flow label) 개념을 도입, 특정 트래픽은 별도의 특별한 처리(실시간 통신 등)를 통해 높은 품질의 서비스를 제공할 수 있도록 합니다.
  • 인증 및 보안 기능: 패킷 출처 인증과 데이터 무결성 및 비밀 보장 기능을 IP 프로토콜 체계에 반영 하였습니다. IPv6 확장헤더를 통해 적용할 수 있습니다.
  • 이동성: IPv6 호스트는 네트워크의 물리적 위치에 제한 받지 않고 같은 주소를 유지하면서도 자유롭게 이동할 수 있습니다. 이와 같은 모바일 IPv6는 RFC 3775와 RFC 3776에 기술되어 있습니다. (IPv4에도 모바일 IP가 정의되어 있지만 아직 많이 사용되지 않습는다.)

참조 : https://ko.wikipedia.org/wiki/IPv6

Apple에서 공지한 iOS 앱에 대한 검수 내용 살펴보기

iPhone 앱에 대한 검수

1.png
많은 개발자들이 야근을 하게한 원흉인 Apple의 공지: https://developer.apple.com/news/?id=05042016a

내용은 아주 간단하게도 IPv6 Only 네트워크에서도 App이 정상적으로 동작을 해야 한다는 것입니다. 이는 IPv4에 기반한 API의 작동은 되지 않는다는 것을 의미합니다. 일반적으로 네트워크 통신 시, NSURLSession과 CFNetwork 같은 High Level API의 경우는 이미 IPv6에 대한 지원에 문제가 없으나, Low-Level socket APIs를 직접 사용할 경우에는 구조체와 함수 등 IPv4 전용 함수를 사용하고 있는지에 대해서 확인이 필요합니다.

또한 앱에서 네트워크 통신 시, 하드 코딩 된 IPv4 주소를 사용하거나, 또는 서버에서 전달해주는 주소가 IPv4 주소를 사용하여 서버에 접근할 때도 앱에 대한 수정이 필요합니다.

따라서 아래에 기술한 방법과 같이 테스트 환경을 구축하여, 정상적으로 네트워크 통신이 가능해야 합니다.

IPv6 테스트 방법

일반적으로는 IPv6 Only 네트워크 환경을 갖추고 테스트를 할 수가 없을 것이기 때문에 Apple에서는 IPv6 테스트를 위하여 NAT64/DNS64 환경을 구성할 수 있도록 가이드를 마련해주었습니다.

테스트 환경

2.png
[https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW16] 에서 발췌

테스트 환경을 구축하기 위해서는 아래와 같은 장비가 필요합니다.

  1. 유, 무선 지원하는 MacOS가 설치된 장비
  2. iPhone, MacOS 장비

MacOS장비의 경우 DNS64, NAT64 역할을 하여 연결된 iOS Device에 IPv6주소를 할당하고, 외부 네트워크(IPv4)와의 통신을 할 수 있도록 해줍니다. (NAT64는 IPv6와 IPv4 호스트들 간에 통신을 할 수 있도록 하는 기술이며, DNS64는 DNS 서버에 AAAA 레코드를 요청했을 때, A 레코드만 존재한다면 A 레코드로부터 AAAA 레코드로 합성(변환)을 해주어서 요청한 서버의 IP주소를 획득할 수 있도록 합니다.)

iPhone은 인터넷 공유(NAT64)를 활성화 시킨 iMac(위의 1항목을 충족한다면 다른 장비도 가능)의 장비에 접속하며, iMac은 유선랜으로 기존 인터넷 환경에 접속하면 됩니다.

따라서 iPhone은 NAT64 환경에서 제공하는 IPv6 주소를 할당 받게 됩니다. 자세한 사항은 아래의 링크를 참고하시면 됩니다.

[https://developer.apple.com/library/mac/documentation/NetworkingInternetWeb/Conceptual/NetworkingOverview/UnderstandingandPreparingfortheIPv6Transition/UnderstandingandPreparingfortheIPv6Transition.html#//apple_ref/doc/uid/TP40010220-CH213-SW16]

만일 위와 같은 방법으로 테스트 시에 네트워크 통신이 제대로 되지 않는다거나, 오동작하는 경우가 발생한다면, 아래의 케이스에 대한 확인이 필요합니다.

  1. IP literal을 직접 hard-coding하여 프로그램에서 사용하고 있는지? 또는 IP Address를 설정파일이나 서버로부터 획득하여 socket연결을 시도하는지?
  2. Network Preflight(통신 전, Wi-Fi, Cellular 등의 연결 테스트)를 ZeroAddress (0.0.0.0)으로 Reachability Test를 하는지?
  3. Low-Level Networking API들을 사용하는지 (소스코드 및 외부 라이브러리)
  4. IP Address를 저장하기 위하여 uint32_tin_addrsockaddr_in과 같은 변수 타입(32bit 이하의 크기)을 사용하는지?

다음 항목에서는 위의 내용에 대해서 좀더 자세히 살펴보도록 하겠습니다.

개발자들이 주의해야 할 사항

IP literal을 프로그램 상에 Hard-Coding한 경우

일반적으로는 IP literal을 직접 사용하는 경우는 없겠지만, 일부 시스템의 경우, 최초 서버에 접근한 후, 해당 서버에서 IP를 할당 받아 다시 할당 받은 IP로 접속하게 하는 시스템들이 있을 수 있습니다. 또는 설정파일에서 IP를 가져와서 사용하는 경우도 있을 수 있습니다. 이럴 경우에는 IPv6 only 네트워크 상에서는 통신이 정상적으로 이루어지지 않으며, Apple 검수 시 Reject 사유가 됩니다. 따라서 반드시 DNS를 이용하여 IP를 획득할 수 있도록 해야 합니다.

Network Preflight를 할 경우

iPhone이나 iPad등 Mobile Device에서는 네트워크 통신이 항상 연결되어 있다고 보장을 할 수 없기 때문에, 통신 전에 Wi-Fi나 Cellular 연결 상태를 확인한 뒤, 통신을 하도록 구현을 많이 하는데요. 이 때, 기존에는 Zero-Address (0.0.0.0)로 Reachability Test를 많이 사용했습니다.

하지만 IPv6 Only 네트워크의 경우에도 Zero-Address로 Reachability Test를 할 경우 정상적으로 연결 상태를 확인할 수 없습니다.
따라서 아래와 같이 변경이 필요합니다.

일반적으로 IPv4 네트워크 환경에는 아래의 API에 Zero-Address를 할당하여 연결테스트를 했습니다.

SCNetworkReachabilityCreateWithAddress()

IPv4및 IPv6 네트워크 환경을 동시에 지원하기 위해서는 아래의 API를 통하여 실제 DNS에 존재하는 Host명을 기입하여 연결테스트를 하도록 해야 합니다.

reachability = SCNetworkReachabilityCreateWithName(kCFAllocatorDefault, @"www.google.com" UTF8String]);

SCNetworkReachabilityCreateWithName() 함수를 통하여 연결테스트를 할 때 실제 해당 Domain을 가지고 있는 서버로의 연결상의 부하는 발생하지 않으며, 네트워크 연결 상태만 확인합니다.

Low-Level Networking API들을 사용하는 경우

iOS Foundation Framework에서 지원하는 High-Level API들만을 사용하여 통신을 한다면 별도의 처리는 필요가 없지만, 일반적으로는 Websocket등의 통신을 위하여 외부 라이브러리를 사용하거나, 통신성능을 높이기 위하여 Open Source 네트워크 라이브러리를 사용하는 경우가 있습니다. 이럴 때는 Open Source 상에서 아래와 같은 함수들 만을 사용하고 있는지 확인해야 합니다.

아래와 같은 IPv4 전용 API들이 있다면 확인하여 제거(또는 변경)이 필요합니다.

  • inet_addr()
  • inet_aton()
  • inet_lnaof()
  • inet_makeaddr()
  • inet_netof()
  • inet_network()
  • inet_ntoa()
  • inet_ntoa_r()
  • bindresvport()
  • getipv4sourcefilter()
  • setipv4sourcefilter()

IPv4 타입을 사용하는 부분이 있다면 IPv6 타입도 똑같이 지원을 해야 합니다.

IPv4IPv6
AF_INETAF_INET6
PF_INETPF_INET6
struct in_addrstruct in_addr6
struct sockaddr_instruct sockaddr_in6
kDNSServiceProtocol_IPv4kDNSServiceProtocol_IPv6

IPv6 로 인한 App Reject 사례와 참고 자료

App Reject 사례

일부 앱에서 6월 1일 이후에 검수를 올린 App에서 별다른 변경사항 없이 Reject를 당하는 경우가 발생하였으며, Review Reject 사유에서는 IPv6 only network에서 정상적으로 게임이 실행되지 않는다는 이유를 듣게 되었습니다.

게임과 게임 서버의 통신상에서는 이미 IPv6를 지원하는 API를 사용하도록 조치하고 앱에서 사용하는 모든 서버의 주소를 Domain을 등록하도록 변경하여 문제 없이 검수를 통과할 수 있을 것으로 생각했지만, 위에 말씀 드린 것과 같이 정상적으로 검수를 통과하지 못했습니다. 확인 결과로는 서버로부터 IPv4 주소를 받아서 클라이언트가 그 주소 기반으로 접속을 시도하는 중에 이슈가 문제가 발생하였으며, 해당 주소가 IPv4 literal로 구성되어 있어서, IPv6 only network 환경에서는 정상적으로 Connection을 맺을 수 없는 상황이었던 것입니다.

최근에는 앱을 개발할 때 Open Source나 외부솔루션을 많이 사용하고 있는 추세이기 때문에, 앱에서 사용하고 있는 외부 솔루션에 대해서 IPv6에 대해서 지원이 되는지 명확히 확인해야 할 필요성이 있습니다.

참고 자료





출처 : http://meetup.toast.com/posts/91


유니티 프로젝트를 XCode로 빌드하고 app을 Run 했을 때


Terminating app due to uncaught exception 'NSUnknownKeyException' 


와 같은 에러와 함께 app이 멈추는 현상이 발생한다면,


XCode에서 UnityViewControllerBase를 검색.




UnityViewControllerBaseiOS.mm 에서


NSAssert(UnityShouldAutorotate(), @"UnityDefaultViewController should be used only if unity is set to autorotate");


이 부분을 주석처리하세요.



그 이후엔 문제없이 잘 돌아갔습니다.




유니티 프로젝트를 XCode로 빌드 시


엄청난 로그와 함께


ld: library not found for -lPods-Unity-iPhone

clang: error: linker command failed with exit code 1 (use -v to see invocation)


이런 에러가 발생한다면,


Unity-iPhone과

Pods의




Build Settings -> Architectures 의 모든 항목들이 일치하는지 확인해보시기 바랍니다.



저 같은 경우에는 Pods의 Architectures -> Architectures 항목이 서로 다르게 설정되어있었는데

일치시키고 다시 시도하니 빌드 성공했습니다.


매우 간단한 문제였는데 너무 오래 헤맸네요.



XCode에서 iOS App을 Archive 후 Upload to App Store 할 때,


(ERROR ITMS-90023: "Missing required icon file. The bundle does not contain an app icon for iPad of exactly '167x167' pixels, in .png format .")


이와 같은 에러로 인해 업로드 실패하는 경우가 생긴다면


해결 방법!




저기 iPad Pro App iOS 9 83.5pt 부분이 비어있을텐데

167x167 짜리 App Icon을 하나 만드셔서 저 부분에 드래그 & 드랍 해주시면 됩니다!



최근에 Apple에서 출시한 iPad Pro 때문에 생긴 문제같네요.





XCode로 디바이스에 Build & Run 시에


process launch failed: failed to get the task for process 915


와 같은 에러가 발생한다면


Project -> Build Settings -> Code Signing -> Code Signing Identify -> Release 항목을


Developer 용으로 변경하면 해결됩니다.



출처 : http://dev.tapjoy.com/ko/faq/unexpected-cfbundleexecutable-key-ios-submission-error/



"Unexpected CFBundleExecutable Key" iOS submission error

"Unexpected CFBundleExecutable Key" 혹은 "Unexpected CFBundleSupportedPlatforms value"

저희는 최근 애플 앱스토어에 앱을 제출함에 있어서 다음과 같은(혹은 유사한) 에러 메시지와 함께 앱이 리젝트 되는 경우가 있다는 리포트를 받았습니다.:

Screen Shot 2015-09-15 at 5.09.44 PM

이것을 대응하기 위해서는 다음을 따라 수정해주세요.:

다음과 같이 수동으로 Info.plist가 여러분의 TapjoyResources.bundle을 포함하게 해주세요.:


Set the following key:

CFBundleSupportedPlatforms = iPhoneOS

And REMOVE the following key entirely:

Executable file

만일 여러분이 Adobe AIR를 사용하고 계신다면, ANE 파일을 언팩하셔서, 위의 나온대로 수정하시고, 다시 ANE 파일을 패킹해 주세요. 이 작업을 위해서는 다음의 안내를 따라주세요.:

  1. unzip TapjoyExtension.ane -d temp
  2. Modify TapjoyResources.bundle found at temp/META-INF/ANE/iPhone-ARM/Tapjoy.embeddedframework/Resources/ as explained above.
  3. cd temp/META-INF/ANE/
  4. mv iPhone-ARM/platform.xml ios_platform.xml
  5. mv Android-ARM/platform.xml android_platform.xml
  6. <air_sdk_home>/bin/adt -package -target ane ../../../TapjoyExtension.ane extension.xml -swc ../../../TapjoyExtension.swc -platform iPhone-ARM -C iPhone-ARM -platformoptions ios_platform.xml . -platform Android-ARM -C Android-ARM -platformoptions android_platform.xml . -platform default -C default library.swf



이 내용은 XCode로 iOS App을 앱 스토어에 업로드 시 발생하는 

아래 error에 대한 해결 방법이기도 합니다.


(ERROR ITMS-90086)




-------------------------------------------------------------------------------------------------------------



출처 : http://www.econovation.co.kr/ecnvb/ios-%EA%B0%9C%EB%B0%9C%ED%8C%81-32bit%EB%A1%9C-%EA%B0%9C%EB%B0%9C%EB%90%9C-%EC%95%B1%EC%9D%84-64bit%EB%A1%9C-%EB%B3%80%ED%99%98-%EB%B0%A9%EB%B2%95/



애플이 아이폰5S 부터 A7 64비트 CPU를 탑재하면서 소프트웨어 개발자도 대응에 고심해야 하는 상황이 되었습니다. 또한 2015년부터는 32비트와 64비트 모두 지원하도록 앱을 개발해야 앱 심사를 받겠다고 합니다.

애플은 64비트 프로세서를 지원함에 따라 더 고성능의 앱을 더 빠르게 구동할 수 있다고 강조합니다. 애플은 개발도구인 X코드를 통해 32비트 앱을 64비트 앱으로 쉽게 변환할 수 있다고 주장합니다. 과거처럼 유니버셜 바이너리를 지원한다고 한 것입니다.

하지만, 앱을 아이폰5와 아이폰5S 모두에서 구동하게 하려면, 동일한 앱이 두 개의 코드를 갖는 걸 감수해야 합니다. 하드웨어야 OS 차원에서 알아서 판단해 32비트냐 64비트냐를 결정해 주겠지만 기본적으로 앱의 전반적인 용량은 커지게 되는 것입니다.

문제는 여기서 그치지 않습니다. 그 동안 애플의 가이드라인에서 벗어나 개발해왔던 앱 개발자라면 기존 앱을 64비트로 변환하는데 상당한 모험심을 가져야 할 것으로 보입니다. 64비트 앱을 원활히 개발하려면 애플에서 제시한 가이드라인을 엄격히 지켜야 하기 때문입니다.

여하튼 2015년부터 앱 개발 및 수정을 하여 앱 심사를 요청하려면 반드시 32비트와 64비트를 지원 하도록 개발이 되어야 하는 필수 요건이 되었습니다.


64비트 아키텍쳐 지원

iOS 개발팁-32bit로 개발된 앱을 64bit로 변환 방법_01

 

애플이 공식적으로 개발자를 위한 새 문서를 올렸는데, 아이폰5s의 64-bit 앱으로 변환하는 과정을 기술한 것입니다.

- https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/ConvertingYourAppto64-Bit/ConvertingYourAppto64-Bit.html#//apple_ref/doc/uid/TP40013501-CH3-SW1

자 그럼 64비트 변환방법에 대하여 알아보도록 하겠습니다.


64 비트 바이너리 변환 방법

1. Xcode 5.0.1 이상 설치합니다. (최신버젼 Xcode 6.1 설치 권장)
2. 개발 프로젝트를 오픈 합니다.

iOS 개발팁-32bit로 개발된 앱을 64bit로 변환 방법_02

3. 프로젝트 Build Settings -> Architectures 설정
- Architectures Standard architectures (armv7, arm64)
- Vaild Architectures arm64 armv7 armv7s

iOS 개발팁-32bit로 개발된 앱을 64bit로 변환 방법_03

4. 프로젝트 설정에서 iOS Deployment Target 을 iOS 5.1 이상으로 설정합니다.
- iOS 5.1 이하로 설정할 경우 64비트 빌드가 되지 않습니다.

iOS 개발팁-32bit로 개발된 앱을 64bit로 변환 방법_04
5. 프로젝트를 빌드를 합니다.
- 빌드시 컴파일러는 에러와 경고를 발생할 것입니다. 소스코드의 에러와 경고 항목을 Xcode 도움말 가이드를 참조하여 직접 수정해야 합니다.
- 애플이 제공하는 가이드 라인을 참조해서 소스 코드를 수정합니다.
https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/ConvertingYourAppto64-Bit/ConvertingYourAppto64-Bit.html#//apple_ref/doc/uid/TP40013501-CH3-SW1

iOS 개발팁-32bit로 개발된 앱을 64bit로 변환 방법_05

6. 소스코드 수정이 완료되면 64비트 하드웨어(아이폰5S 이상) 단말에서 테스트를 합니다.
7. 앱 Archive 를 생성하여 앱 심사을 위헤 애플에 제출합니다.



+ Recent posts