Balto 개발을 통한 iOS SDK 개발 지식

12739 단어 XcodeSwiftSDKiOS
어제는 @inoinojp대 선생님 자칭 JavaScript 중급자가 모르는 10가지 사양!

입문


안녕하세요, 저는 Hiroki Terashima, Goodpatch 개발Balto의 iOS/iOS SDK/서버단입니다.
iOS 엔지니어입니다.
Balto아직 베타판이지만 곧 정식으로 발매되니 잘 부탁드립니다!m(_ _)m
2016년은 이 Balto 개발에 심혈을 기울인 한 해였는데...
첫 번째 SDK 개발과 비교적 새로운 Elixir 언어로 서버를 개발하는 것은 새로운 사물에 대한 도전으로 가득 차 있다.
그런 Balto SDK 개발에서 얻은 별로 사용되지 않는다는 견해를 공유하고 싶습니다.

iOS SDK 개발 고려 사항

xxxxx.framework 자주 보는 녀석이네.
기본 사항은 여기서 생략한다.

코코아팟이랑 카티지는 안 될 것 같아요.


갑자기 힘들어.
iOS Developer는 라이브러리 관리 도구라는 것을 잘 알고 있습니다.
이것은 왜 사용할 수 없습니까? 라이브러리의 클래스는 공공 클래스일 수도 있고 전역 함수도 존재할 수 있기 때문입니다.
자체 제작한 SDK를 삽입한 응용 프로그램은 SDK의 라이브러리에 넣으면 사용할 수 있다.엑스코드의 변환 후보에 들어가지 않은 Alamofire의 방법이 나왔다???으로 여겨질 것이다..
그래서 사용하려면 수동으로 넣고 퍼블릭반을 다 끄고... 이런 말도 안 되는 일이 기다리고 있어요.
만약 그것을 하려고 한다면, 나는 내가 실시하는 것도 괜찮고, 공부도 할 수 있다고 생각한다.

SDK 옆에 화면이 있을 때 주의하십시오.


뒷면에 아무거나 하는 스타일의 SDK라면 크게 신경 쓸 필요는 없지만 SDK 측면에 화면을 만들어 표시한다면 UI 설치에 주의하세요.
물론 당연하지만, 편입된 측의 응용 프로그램에 UINavigationBar가 있다면.appearance 등을 설정하면 끌려갑니다.
그래서 SDK의 설치는 디자인을 정확하게 설정해도 우스운 디자인으로 편입된다!이렇게 될 수도 있어.
반대로도 마찬가지다.
SDK에서 appearance를 설정하면... 말할 것도 없어요.
또한 코드에서 UIIMage를 생성할 때도 주의해야 한다.
평상시
let hogeImageView.image = UIImage(named: "hoge")
깔끔하게 쓰고 싶은데 SDK 한쪽에서 SDK의 Asset에서 그림을 끌어올리려면 bundle를 지정해야 합니다.
let hogeImageView.image = UIImage(named: "hoge", in: Bundle(for: type(of: self)), compatibleWith: nil)
이런 느낌인데.
그림뿐만 아니라 Plist와 Storyboard 등 자원을 읽을 때 주의해야 한다.

Bitcode 지원


비트코드에 대한 설명은 생략했지만 이것이 바로 곡자입니다.
유명한 말이지만 만들어진 SDK를 넣는 쪽에서 "Rebuild from bitcode"를 선택해 Archive를 하면xxx does not contain bitcode. 오류가 발생했습니다.
SDK의 BuildSettingsEnable BitcodeYES...
"Rebuild from bitcode"의 선택을 취소하면 Archive를 할 수 있지만, SDK를 제공하는 측으로서 어느 쪽에도 대응하지 않으면 사용하기 불편한 SDK가 됩니다.
해결 방법으로 BuildSettingsBITCODE_GENERATION_MODEbitcode를 추가합니다.반대로 필요 없을 때 넣는다marker.BITCODE_GENERATION_MODE 기본적으로 존재하지 않습니다. Add User-Defined Setting 직접 추가하십시오.

별말씀을요, Xcode7.x(사소한 숫자를 잊어버렸다) 이걸 넣으면 문법 하이라이트가 전혀 작용하지 않아 힘들어요...

불필요한 아키텍처 제거


Xcode7까지는 Store에 SDK를 넣는 앱을 신청할 때만 필요한 것 같지만 Xcode8이 되면 보통 Archive에 있을 때도 이 작업이 필요하다(자신의 환경에서는 7에서 8로 올라갈 때 나온다).
이것은 Archive 때Failed to verify bitcode in xxx. error: Cannot extract bundle from ...의 오류입니다.
SDK를 만들 때도 아날로그에 대응하는 경우가 많기 때문에 일반적인 프레임워크를 만드는 것이 보편적이라고 생각하지만 삽입식 프레임워크에 아날로그 프레임워크i386x86_64가 포함되면 오류가 발생할 수 있습니다.
아카이브할 때 BuildPhaseScript 등을 통해 i386x86_64의 아키텍처를 제거할 수 있습니다.
이 방법의 스크립트는 매우 많은데, 그 중에서 자신이 사용한 것이다.
APP_PATH="${TARGET_BUILD_DIR}/${WRAPPER_NAME}"

# ここの *.framework は必要なものだけに絞る場合は指定して下さい。
find "$APP_PATH" -name '*.framework' -type d | while read -r FRAMEWORK
do
    FRAMEWORK_EXECUTABLE_NAME=$(defaults read "$FRAMEWORK/Info.plist" CFBundleExecutable)
    FRAMEWORK_EXECUTABLE_PATH="$FRAMEWORK/$FRAMEWORK_EXECUTABLE_NAME"

    EXTRACTED_ARCHS=()

    for ARCH in $ARCHS
    do
        lipo -extract "$ARCH" "$FRAMEWORK_EXECUTABLE_PATH" -o "$FRAMEWORK_EXECUTABLE_PATH-$ARCH"
        EXTRACTED_ARCHS+=("$FRAMEWORK_EXECUTABLE_PATH-$ARCH")
    done

    lipo -o "$FRAMEWORK_EXECUTABLE_PATH-merged" -create "${EXTRACTED_ARCHS[@]}"
    rm "${EXTRACTED_ARCHS[@]}"

    rm "$FRAMEWORK_EXECUTABLE_PATH"
    mv "$FRAMEWORK_EXECUTABLE_PATH-merged" "$FRAMEWORK_EXECUTABLE_PATH"
done
lipo 명령은 여러 구조를 지원하는 일반적인 파일을 생성하는 데 사용되는 명령입니다.
RunScript로 하면 BuildPhase 순서도 주의하십시오.Embedded Frameworks 이상 쓴 경우에도 오류가 발생합니다.Embedded Frameworks 기본적이기 때문에 그보다 낮지 않을 수도 있지만 자신은 이에 반해...
Bitcode를 지원하는 동시에 iOS의 SDK 개발은 편입된 쪽에서 Archive/Store에 업로드할 수 있습니다.
거기 미리 확인하는 게 상책일 수도 있어.

CocoaPods 또는 Carthage를 통해 배포


지금 이것에 대응하지 않으면 어렵게 만든 것을 사용하기 어려울 수도 있습니다(베타판 발토는 대응하지 않았습니다... 안 맞습니다...)
일반적인 개원 라이브러리 등이었으면 좋겠지만 원본 코드를 공개하기 싫은 SDK 등 .framework 형식의 물건을 나눠줄 때 평소와 조금 다르기 때문에 소개해 드리겠습니다.

Carthage의 경우


이것은 매우 간단하다.
carthage build --no-skip-current
carthage archive xxx
이렇게 하면 xxx.framework.zip 이 파일을 생성할 수 있으니 GitHub 저장소의 Release에 파일을 올려주세요.

코코카팟 때.


당연히 Podspec을 써야지.
Pod::Spec.new do |s|
  s.name         = "xxxxx"
  s.version      = "3.0.0"
  s.summary      = ""
  s.description  = <<-DESC
                   僕の考えた最強の SDK
                   DESC

  s.homepage     = "https://github.com/xxxxx/xxxxx"
  s.license      = { :type => "Apache 2.0", :file => "LICENSE" }
  s.author       = { "Hiroki Terashima" => "[email protected]" }
  s.platform     = :ios, "9.0"
  s.requires_arc = true

  # ここは何処かに上げたファイルのURLでも良い
  # s.source = { :http => "https://github.com/xxxxx/xxxxx/releases/download/#{s.version}/Cocoapods.zip" }
  s.source = { :git => "https://github.com/xxxxx/xxxxx.git", :tag => "#{s.version}" }

  s.preserve_paths      = 'xxxxx.framework'
  s.source_files        = 'xxxxx.framework/Headers/xxxxx-Swift.h'
  s.public_header_files = 'xxxxx.framework/Headers/xxxxx-Swift.h'
  s.vendored_frameworks = 'xxxxx.framework'
end
생성된 xxxxx.framework 에 Header 파일의 경로 등을 기재하면 다른 것과 느낌이 다르다.
이런 느낌으로 쓰면...
pod trunk push
사용자 정의 모양새를 정의합니다.

총결산


다른 것도 많아요.
요약하면 iOS의 SDK 개발은 편입된 쪽이 Archive/Store에 업로드하기 전이다.마지막 마지막ω’)"아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아아
내일은 헤드폰의 로고 (내 생각에) @kubosho_ 씨의 Prott의 dark theme 이야기!기대해주세요!

좋은 웹페이지 즐겨찾기