วิธีแก้ไขลายเซ็นเฟรมเวิร์ก CocoaPods ในการตั้งค่า iOS SDK

คุณจะแก้ไขข้อผิดพลาดในการเซ็นชื่อเฟรมเวิร์ก CocoaPods เมื่อทำการรวม iOS SDK ได้อย่างไร? ทำการวิเคราะห์เป้าหมายชุดทรัพยากร (Resource Bundle) ที่ไม่สามารถทำงานได้และเป็นสาเหตุของข้อผิดพลาด Development Team จากนั้นให้ใช้การเขียนทับผ่าน post_install ของ CocoaPods แบบจำกัดเฉพาะเป้าหมาย แทนที่จะปิดใช้งานการเซ็นชื่อทั่วทั้งโปรเจกต์ในทุก ๆ บันเดิล

ในกำหนดค่า CocoaPods/Xcode ที่ได้รับผลกระทบ เป้าหมายชุดทรัพยากรที่สร้างขึ้นอาจสืบทอดการตั้งค่าการเซ็นชื่อที่ทำให้ Xcode ร้องหา Development Team การแก้ไขข้อผิดพลาดการคอมไพล์เหล่านี้ต้องอาศัยการกำหนดค่า Podfile post_install build hooks แบบกำหนดเอง เพื่อปิดใช้งานข้อกำหนดลายเซ็นสำหรับซับเป้าหมายชุดทรัพยากรที่ไม่สามารถรันได้ หรือดำเนินการตามระเบียบการฝัง XCFramework ด้วยตนเอง

ทำไมกฎการเซ็นโค้ดของ Xcode 15 และ 16 ถึงทำให้การสร้าง iOS SDK CocoaPods เกิดข้อผิดพลาด

เครื่องมือสร้างของ Xcode และการเซ็นชื่อชุดทรัพยากร (Resource Bundle)

เริ่มต้นตั้งแต่ Xcode 15 และต่อเนื่องมาถึง Xcode 16 การปรับเปลี่ยนระบบการสร้างของ Xcode ส่งผลให้วิธีการกระจายการตั้งค่าการเซ็นโค้ดไปยังซับเป้าหมายที่ถูกสร้างขึ้นเปลี่ยนแปลงไป ในการกำหนดค่า Xcode และ CocoaPods ที่ได้รับผลกระทบ เป้าหมายชุดทรัพยากรที่ไม่สามารถรันได้ซึ่งทำหน้าที่แพ็กเกจทรัพยากร เช่น PrivacyInfo.xcprivacy, แค็ตตาล็อกสินทรัพย์ (Asset Catalogs) หรือสตริงแปลภาษา อาจสืบทอดการตั้งค่าการเซ็นโค้ดที่กระตุ้นให้ Xcode ขอ Development Team

ปัญหานี้แสดงถึงความไม่สอดคล้องของการรวมระบบสร้างภายในกระบวนการสร้างเป้าหมายของ CocoaPods มากกว่าการเป็นนโยบายที่เข้มงวดของ Apple ที่กำหนดให้ชุดทรัพยากรแบบสแตนด์อโลนที่ไม่สามารถรันได้ทุกชุดต้องมีลายเซ็นโค้ดอิสระ

โครงสร้างของข้อผิดพลาดในการคอมไพล์: Signing for Target Requires a Development Team

เมื่อรวมการพึ่งพา (Dependencies) โดยใช้ CocoaPods ตัวจัดการการพึ่งพาจะสร้างโปรเจกต์ Pods.xcodeproj แยกต่างหาก ซึ่งประกอบด้วยเป้าหมายที่แยกส่วนสำหรับแต่ละพ็อดและชุดทรัพยากรที่เกี่ยวข้อง ในระหว่างการสร้างอาร์ไพฟ์ (Archive) หรือการคอมไพล์บนตัวจำลอง (Simulator) Xcode จะประเมินเป้าหมายที่มีชื่อคล้ายกับ libOpoInstallSDK-OPPrivacy หรือ Pods-YourApp-resource-bundle

การคอมไพล์ล้มเหลวพร้อมกับข้อผิดพลาดทั่วไปในการสร้าง:

Signing for "libOpoInstallSDK-OPPrivacy" requires a development team.
Select a development team in the Signing & Capabilities editor.

เนื่องจาก CocoaPods สร้างซับเป้าหมายเหล่านี้แบบไดนามิกเมื่อรันคำสั่ง pod install การตั้งค่า Development Team ด้วยตนเองภายใน Xcode GUI จึงเป็นเพียงชั่วคราว การรัน pod install ซ้ำหรือการคอมไพล์บนระบบ CI/CD ที่สะอาดจะเขียนทับไฟล์โปรเจกต์ ทำให้ข้อผิดพลาดในการสร้างเกิดขึ้นซ้ำอีก

วิธีที่ซับเป้าหมายของ CocoaPods สืบทอดคุณสมบัติที่ไม่ได้เซ็นชื่อสำหรับบันเดิล Privacy Manifest

พ็อดสเปซ (Podspecs) ของ CocoaPods บางตัวแพ็กเกจไพรเวซีเมนเฟสต์ผ่านซับเป้าหมายชุดทรัพยากรที่สร้างขึ้น (ตัวอย่างเช่น ผ่านการประกาศ resource_bundles) ในขณะที่ตัวอื่น ๆ จัดส่งเมนเฟสต์ภายในเฟรมเวิร์กที่มีการจำหน่าย (Vendored Frameworks) หรือการประกาศทรัพยากรโดยตรง

ในการกำหนดค่า CocoaPods ที่ได้รับผลกระทบ ซับเป้าหมายชุดทรัพยากรที่ถูกสร้างขึ้นอาจไม่มีค่า DEVELOPMENT_TEAM ที่ใช้งานได้ หรืออาจสืบทอดการตั้งค่าการเซ็นชื่อที่ทำให้ Xcode ขอร้อง ดังกล่าว ดังนั้น ในขณะที่เป้าหมายแอปพลิเคชันหลักสร้างขึ้นด้วยโปรไฟล์การเตรียมใช้งาน (Provisioning Profile) ที่ถูกต้อง ซับเป้าหมายชุดทรัพยากรที่ซ้อนอยู่ก็สามารถกระตุ้นการตรวจสอบล่วงหน้าเรื่องการเซ็นโค้ดของ Xcode ได้ การแก้ไขปัญหานี้ต้องอาศัยการแก้ไขเฉพาะจุดในระดับ Podfile หรือการเปลี่ยนไปใช้การฝังเฟรมเวิร์กด้วยตนเอง

วิธีกำหนดค่า Podfile Build Hooks เพื่อแก้ไขข้อผิดพลาดการเซ็นชื่อชุดทรัพยากรเฟรมเวิร์ก

ทำความเข้าใจเกี่ยวกับการทำงานของ Podfile post_install Execution Hook

CocoaPods มีไลฟ์ไซเคิลฮุกที่ใช้ภาษา Ruby ชื่อว่า post_install ภายใน Podfile ฮุกนี้จะทำงานทันทีหลังจาก CocoaPods สร้างไฟล์โปรเจกต์ Pods.xcodeproj เสร็จสิ้น แต่ก่อนที่จะบันทึกลงในดิสก์ การดักจับการสร้างโปรเจกต์ในขั้นตอนนี้ช่วยให้นักพัฒนาสามารถวนลูปผ่านเป้าหมายที่ถูกสร้างขึ้น ตรวจสอบประเภทผลิตภัณฑ์ และแก้ไขการตั้งค่าคอนฟิกูเรชันการสร้างก่อนที่ Xcode จะเริ่มคอมไพล์

การทำระบบอัตโนมัติเพื่อเขียนทับการตั้งค่าการสร้างแบบจำกัดขอบเขตสำหรับซับเป้าหมายชุดทรัพยากร

เพื่อแก้ไขข้อผิดพลาดในการเซ็นชื่อบันเดิลทั้งบนเครื่องพัฒนาท้องถิ่นและเครื่องมือสร้าง CI/CD ระยะไกล ฮุก post_install สามารถตรวจสอบชื่อเป้าหมายและประเภทผลิตภัณฑ์ได้ แทนที่จะปิดใช้งานการเซ็นโค้ดทั่วโลกในทุกชุดทรัพยากรของ CocoaPods ซึ่งอาจนำความเสี่ยงด้านความปลอดภัยมาสู่การพึ่งพาจากภายนอก นักพัฒนาควรกำหนดขอบเขตการเขียนทับให้เจาะจงเฉพาะเป้าหมายบันเดิลที่ได้รับผลกระทบเท่านั้น

เมื่อเป้าหมายตรงกับประเภทผลิตภัณฑ์ชุดทรัพยากรของ Apple (com.apple.product-type.bundle) และตรงกับชื่อเป้าหมายที่กำหนด สคริปต์จะล้างค่าการตั้งค่าการสร้าง CODE_SIGN_IDENTITY และตั้งค่า CODE_SIGNING_ALLOWED เป็น NO สำหรับเป้าหมายชุดทรัพยากรที่ไม่สามารถรันได้ที่ได้รับผลกระทบโดยเฉพาะ การปิดใช้งานการเซ็นโค้ดในระดับเป้าหมายถือเป็นการแก้ปัญหาระบบสร้างเฉพาะจุด เมื่อได้รับการตรวจสอบเทียบกับแอปที่เก็บถาวรขั้นสุดท้ายและขั้นตอนการส่งไปยัง App Store

สคริปต์ Ruby ด้านล่างแสดงวิธีการใช้งานการเขียนทับแบบจำกัดขอบเขตนี้ภายใน Podfile ของโปรเจกต์:

# Podfile - การเขียนทับการตั้งค่าการสร้างแบบจำกัดขอบเขตสำหรับการเซ็นชื่อชุดทรัพยากร
# วาง post_install hook นี้ไว้ที่ด้านล่างสุดของ Podfile ในโปรเจกต์ของคุณ

post_install do |installer|
  # กำหนดชื่อเป้าหมายบันเดิลเฉพาะที่ต้องได้รับการยกเว้นการเซ็นชื่อ
  affected_bundle_targets = [
    'libOpoInstallSDK-OPPrivacy'
  ]

  installer.pods_project.targets.each do |target|
    next unless target.respond_to?(:product_type)
    next unless target.product_type == 'com.apple.product-type.bundle'
    next unless affected_bundle_targets.include?(target.name)

    target.build_configurations.each do |config|
      # ล้าง Code Sign Identity และปิดใช้งานการเซ็นชื่อสำหรับชุดทรัพยากรที่กำหนด
      config.build_settings['CODE_SIGNING_ALLOWED'] = 'NO'
      config.build_settings['CODE_SIGN_IDENTITY'] = ''
    end
  end
end

การตรวจสอบความเข้ากันได้ของ CI/CD ข้ามเป้าหมายการสร้าง Xcode Archive และ Simulator

หลังจากเพิ่มบิวด์ฮุกแบบจำกัดขอบเขตลงใน Podfile แล้ว ให้รัน pod install เพื่อนำการกำหนดค่าที่อัปเดตไปใช้กับ Pods.xcodeproj การสร้างสำหรับตัวจำลองมักจะมีข้อกำหนดการเซ็นชื่อสำหรับการเผยแพร่น้อยกว่าการสร้างอาร์ไพฟ์สำหรับอุปกรณ์ แต่ทีมวิศวกรควรตรวจสอบการตั้งค่าเป้าหมายที่ได้รับผลกระทบแยกต่างหาก ทั้งในการรันบนตัวจำลองภายในเครื่อง, การรันการทดสอบอัตโนมัติบน CI/CD และการกำหนดค่าการสร้างรีลีแอตอาร์ไพฟ์ของ Xcode

คำสั่งตรวจสอบการวินิจฉัยสำหรับการยืนยันการเซ็นโค้ด

การตรวจสอบการตั้งค่าการสร้างเป้าหมายและข้อมูลประจำตัวการเซ็นโค้ด

เมื่อทำการวินิจฉัยความล้มเหลวในการเซ็นชื่อแบบเป็นระยะ ๆ บนเซิร์ฟเวอร์บิวด์ นักสามารถสอบถามการกำหนดค่าการสร้างของ Xcode ได้โดยตรงผ่านคำสั่งเทอร์มินัล วิธีนี้ช่วยให้ตรวจสอบได้ว่า post_install hook ของ Podfile สามารถล้างข้อกำหนดการเซ็นโค้ดสำหรับซับเป้าหมายที่ได้รับผลกระทบได้สำเร็จหรือไม่ โปรดทราบว่าการตั้งค่าการสร้างยังสามารถตรวจสอบได้โดยตรงบนเป้าหมายแต่ละรายการภายใน Pods.xcodeproj ใน Xcode เพื่อยืนยันค่าที่มีผลเฉพาะเป้าหมายนั้น ๆ

รันคำสั่งต่อไปนี้จากไดเรกทอรีรากของโปรเจกต์:

# ตรวจสอบการตั้งค่าการสร้างการเซ็นโค้ดสำหรับเวิร์กสเปซเป้าหมาย
xcodebuild \
  -workspace YourApp.xcworkspace \
  -scheme YourApp \
  -configuration Release \
  -showBuildSettings | grep -E "(CODE_SIGN|DEVELOPMENT_TEAM)"

การตรวจสอบชุดข้อมูลอาร์ไพฟ์ของ Xcode และความสมบูรณ์ของลายเซ็น

หลังจากการสร้างอาร์ไพฟ์ ให้ตรวจสอบแพ็กเกจแอปพลิเคชันที่คอมไพล์แล้ว เพื่อยืนยันว่าไพรเวซีเมนเฟสต์ถูกวางตำแหน่งไว้อย่างถูกต้อง และไบนารีของเฟรมเวิร์กยังคงความสมบูรณ์ของลายเซ็นไว้

รันคำสั่งเทอร์มินัลสำหรับการวินิจฉัยเหล่านี้บนไฟล์ IPA ที่แตกออกแล้ว (ภายใน Payload/YourApp.app) หรือภายในพาธ .xcarchive ของ Xcode (Products/Applications/YourApp.app):

# ตรวจสอบการมีอยู่ของไพรเวซีเมนเฟสต์ภายในแพ็กเกจ IPA ที่แตกออกแล้ว
find Payload/YourApp.app -name "PrivacyInfo.xcprivacy" -print

# สำหรับเฟรมเวิร์กที่ฝังแบบไดนามิก ให้ตรวจสอบความสมบูรณ์ของลายเซ็น codesign:
codesign -dv --verbose=4 Payload/YourApp.app/Frameworks/OpoInstallSDK.framework

# ดำเนินการตรวจสอบลายเซ็นเชิงลึกบนชุดแอปพลิเคชันที่คอมไพล์แล้วขั้นสุดท้าย
# หมายเหตุ: ใช้ --deep เฉพาะสำหรับการตรวจสอบเพื่อการตรวจสอบเท่านั้น อย่าใช้ --deep ในระหว่างการดำเนินการเซ็นโค้ด
codesign --verify --deep --strict --verbose=2 Payload/YourApp.app

การดำเนินการตามลำดับการตรวจสอบนี้เป็นการสร้างวงจรกำหนดการวินิจฉัยที่สมบูรณ์ (reproduce → inspect → patch → verify) เพื่อให้แน่ใจว่าบิวด์รีลีสผ่านการตรวจสอบของ App Store Connect

วิธีนำเข้า iOS SDK ผ่านตัวจัดการการพึ่งพา CocoaPods

การกำหนดค่า Podfile ของโปรเจกต์เป้าหมายด้วย pod ‘libOpoInstallSDK’

การรวม OpoInstall ซึ่งเป็นแพลตฟอร์มแอตทริบิวต์บนมือถือและการเชื่อมโยงแบบลึก ผ่านทาง CocoaPods ถือเป็นแนวทางจัดการการพึ่งพามาตรฐานสำหรับแอป iOS การแจกจ่าย CocoaPods ในปัจจุบันจัดการการเชื่อมโยงของ SDK และทรัพยากรที่แพ็กเกจตาม podspec ของตน รวม use_frameworks! เมื่อจำเป็นต้องใช้ตามการผสานรวม CocoaPods ปัจจุบันของ SDK หรือสถาปัตยกรรมของโปรเจกต์

ในการเพิ่มการพึ่งพา ให้เปิดไฟล์ราก Podfile และระบุการพึ่งพาเป้าหมาย:

target 'YourAppTarget' do
  use_frameworks!
  
  # นำเข้า OpoInstall iOS Attribution SDK
  pod 'libOpoInstallSDK'
end

การดำเนินการรับเข้าการพึ่งพาและการตรวจสอบความสมบูรณ์ของเวิร์กสเปซ

รันคำสั่งติดตั้งจากไดเรกทอรีรากของโปรเจกต์โดยใช้เทอร์มินัล:

pod install --repo-update

เมื่อดำเนินการเสร็จสิ้นเรียบร้อยแล้ว CocoaPods จะสร้างหรืออัปเดตไฟล์ .xcworkspace นักพัฒนาจะต้องปิดไฟล์ .xcodeproj มาตรฐานและเปิดไฟล์ .xcworkspace ใน Xcode ตรวจสอบโฟลเดอร์โปรเจกต์ Pods เพื่อยืนยันว่า libOpoInstallSDK และเป้าหมายบันเดิล OPPrivacy ที่เกี่ยวข้องปรากฏอยู่ภายใต้รายการเป้าหมายของ Pods

การเริ่มต้นเอ็นจิ้น SDK ในสถาปัตยกรรมโปรเจกต์ Swift

หลังจากลิงก์เฟรมเวิร์กแล้ว ให้เริ่มต้น SDK ภายในเดลิเกตวงจรชีวิตของแอปพลิเคชัน (Application Lifecycle Delegate) เริ่มต้น SDK ณ จุดวงจรชีวิตที่บันทึกไว้สำหรับรุ่น SDK นั้น ๆ ตัวอย่างสาธารณะปัจจุบันจะเริ่มต้นจาก application(_:didFinishLaunchingWithOptions:) เพื่อจับพารามิเตอร์ Universal Link ในช่วงเปิดใช้งานครั้งแรก (Cold-start) และเพย์โหลดการติดตั้งแบบไดนามิก ตรวจสอบชื่อโปรโตคอลเดลิเกตและประเภทโมเดลข้อมูล (เช่น OpoinstallData หรือ OpoInstallData) เทียบกับเวอร์ชัน SDK ของ OpoInstall ที่จัดส่งมาจริง ๆ

นักพัฒนาสามารถตรวจสอบ เอกสารประกอบ iOS attribution SDK ทั้งหมดสำหรับคำจำกัดความเมธอดเดลิเกตโดยละเอียดและลายเซ็นคอลแบ็กพารามิเตอร์แบบไดนามิก

ตัวอย่างการใช้งานด้านล่างแสดงวิธีปฏิบัติตาม OpoInstallDelegate และทริกเกอร์การเริ่มต้น SDK ข้ามโค้ดเบส Swift สมัยใหม่:

// AppDelegate.swift - การเริ่มต้น OpoInstall iOS SDK
// วางไว้ภายใน iOS Application Delegate ของคุณ

import UIKit
import libOpoInstallSDK

@main
class AppDelegate: UIResponder, UIApplicationDelegate, OpoInstallDelegate {

    var window: UIWindow?

    func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        
        // เริ่มต้น OpoInstall SDK ด้วยตัวฟังเดลิเกต
        OpoInstallSDK.initWith(self)
        
        return true
    }

    // เมธอดคอลแบ็ก: จัดการพารามิเตอร์ที่ดึงมาเมื่อเปิดแอปผ่าน deep link
    func getWakeUpParams(_ appData: OpoinstallData?) {
        if let customData = appData?.data {
            print("OpoInstall SDK: Custom Launch Parameters = \(customData)")
        }
        if let channelCode = appData?.channelCode {
            print("OpoInstall SDK: Channel ID = \(channelCode)")
        }
    }
}

เวิร์กฟลอกการนำเข้าเฟรมเวิร์กด้วยตนเองสำหรับเป้าหมายโปรเจกต์ iOS

เมื่อใดควรเลือกการนำเข้าด้วยตนเองแทน CocoaPods ในสภาพแวดล้อมการสร้างขององค์กร

แม้ว่า CocoaPods จะช่วยให้การจัดการแพ็กเกจง่ายขึ้น แต่สภาพแวดล้อมการพัฒนาขององค์กรบางแห่งบังคับใช้ข้อจำกัดด้านความปลอดภัยหรือสภาพแวดล้อมการสร้างที่เข้มงวด การรวมเฟรมเวิร์กด้วยตนเองจะได้รับความนิยมเมื่อ:

• การแยกที่เก็บ (Repository Isolation): ระบบการสร้างจำกัดการเชื่อมต่ออินเทอร์เน็ตขาออก ทำให้ไม่สามารถดึงข้อมูลการพึ่งพาด้วย pod install ในระหว่างการคอมไพล์ได้
• ความเร็วของไปป์ไลน์การสร้าง: การตัดขั้นตอนการวิเคราะห์และการรันสคริปต์ของ CocoaPods ช่วยลดเวลาในการคอมไพล์ CI/CD ลง
• การควบคุมไบนารีโดยตรง: นโยบายการปฏิบัติตามข้อกำหนดด้านความปลอดภัยกำหนดให้ต้องมีการวิเคราะห์ไบนารีแบบสแตติกบนอาร์ทิแฟกต์ .xcframework ที่แน่นอนก่อนที่จะนำมารวมในโปรเจกต์

การดาวน์โหลดและการฝังอาร์ทิแฟกต์ XCFramework

ในการนำเข้า SDK ด้วยตนเองโดยไม่ต้องใช้ตัวจัดการการพึ่งพา ให้ดาวน์โหลด แพ็กเกจเฟรมเวิร์ก iOS SDK ล่าสุด ทำการคลายซิปไฟล์อาร์ชิฟการจัดจำหน่ายเพื่อค้นหาไดเรกทอรี OpoInstallSDK.xcframework ที่คอมไพล์แล้ว

ในการระบุว่าชิ้นส่วน (Slice) ของ XCFramework เป็นแบบสแตติกหรือไดนามิกก่อนที่จะฝัง ให้รันคำสั่ง file ในเทอร์มินัล:

# สอบถามประเภทของชิ้นส่วนสถาปัตยกรรมไบนารี
file OpoInstallSDK.xcframework/ios-arm64/OpoInstallSDK.framework/OpoInstallSDK

ทำตามขั้นตอนเหล่านี้เพื่อรวมไบนารีเข้ากับ Xcode:

• ขั้นตอนที่ 1: เปิดโปรเจกต์แอปพลิเคชันหลักของคุณใน Xcode
• ขั้นตอนที่ 2: ลากไดเรกทอรี OpoInstallSDK.xcframework ไปยัง Xcode Project Navigator ใต้กลุ่มเฟรมเวิร์กเป้าหมายหลัก
• ขั้นตอนที่ 3: ในหน้าต่างโต้ตอบ ให้ทำเครื่องหมายที่ Copy items if needed และเลือกเป้าหมายแอปพลิเคชันหลักของคุณใต้ Add to targets

การกำหนดค่า Link Binary With Libraries และ Framework Search Paths

ไปที่การกำหนดค่าเป้าหมายของแอปพลิเคชันของคุณภายใน Xcode:

• Build Phases: ขยายส่วน Link Binary With Libraries ยืนยันว่ามี OpoInstallSDK.xcframework แสดงอยู่
• Build Settings: ค้นหา Framework Search Paths (FRAMEWORK_SEARCH_PATHS) ตรวจสอบให้แน่ใจว่ามีพาธไดเรกทอรีที่มีเฟรมเวิร์กที่เพิ่มเข้ามาด้วยตนเองอยู่
• System Dependencies: เพิ่มเฉพาะเฟรมเวิร์กของระบบ Apple ที่ระบุไว้ในรุ่น SDK ที่คุณกำลังรวมเข้าด้วยกัน (เช่น AdSupport.framework หรือ WebKit.framework) อย่าเพิ่มเฟรมเวิร์กเก่าที่ยังไม่ได้ตรวจสอบ

การตั้งค่านโยบายการฝังและการเซ็นชื่อสำหรับไบนารีแบบไดนามิกเทียบกับแบบสแตติก

เลือกเป้าหมายแอปพลิเคชันและไปที่แท็บ General ค้นหาส่วน Frameworks, Libraries, and Embedded Content:

• Dynamic Frameworks: ตั้งค่าตัวเลือกการฝังเป็น Embed & Sign เฟรมเวิร์กแบบไดนามิกจะต้องอยู่ในไดเรกทอรี Frameworks ของบันเดิลแอปขั้นสุดท้าย เพื่อให้ตัวเชื่อมโยงแบบไดนามิก (dyld) สามารถโหลดได้ในขณะรันไทม์ และ Xcode จะใช้ลายเซ็นโค้ดของทีมพัฒนาของคุณในระหว่างการทำอาร์ไพฟ์
• Static Frameworks without Resources: การลิงก์ไบนารีนั้นเพียงพอแล้ว และการฝังเฟรมเวิร์กมักจะไม่จำเป็น เนื่องจากโค้ดแบบสแตติกถูกคอมไพล์โดยตรงลงในไฟล์ปฏิบัติการแอปพลิเคชันหลัก
• Static Frameworks with Resources (รวมถึง Privacy Manifests): ปฏิบัติตามแนวทางการจัดจำหน่ายของผู้จำหน่าย SDK สำหรับเฟรมเวิร์กสแตติกของ Xcode 15+ ที่สร้างขึ้นเพื่อแพ็กเกจทรัพยากรที่ฝังอยู่ Apple ได้บันทึกเกี่ยวกับการเพิ่มเฟรมเวิร์กด้วย Embed & Sign โดย Xcode จะละเว้นไบนารีปฏิบัติการที่ลิงก์แบบสแตติกไปแล้ว แต่จะยังคงรักษากลุ่มบันเดิลเฟรมเวิร์กและทรัพยากรที่ฝังไว้ พร้อมทั้งเซ็นชื่อให้เรียบร้อย

การแก้ไขปัญหาข้อขัดแย้งของลายเซ็น PrivacyInfo.xcprivacy ใน CocoaPods

ข้อกำหนดของ Apple Privacy Manifest สำหรับการพึ่งพาเฟรมเวิร์กของบุคคลที่สาม

SDK ของบุคคลที่สามอาจจำเป็นต้องรวมไฟล์เมนเฟสต์ PrivacyInfo.xcprivacy ไว้ด้วย ขึ้นอยู่กับการใช้งาน API, แนวทางการรวบรวมข้อมูล, พฤติกรรมการติดตาม และการที่ SDK นั้นปรากฏอยู่บนรายการ SDK ที่เผยแพร่โดย Apple ซึ่งอยู่ภายใต้ข้อกำหนดเมนเฟสต์ที่ชัดเจนหรือไม่

การแจกจ่าย OpoInstall ในปัจจุบันประกอบด้วยเมนเฟสต์ PrivacyInfo.xcprivacy โดยนักพัฒนาควรตรวจสอบการประกาศของเมนเฟสต์ดังกล่าวเทียบกับเวอร์ชัน SDK เฉพาะที่จัดส่งมาและแนวทางการส่งของ Apple ในปัจจุบันก่อนทำการอาร์ไพฟ์

การแก้ไขข้อขัดแย้งของทรัพยากร Privacy Manifest ที่ซ้ำกัน

เมื่อสร้างแอปพลิเคชันที่มีการรวมการพึ่งพาของบุคคลที่สามหลายรายการ Xcode จะค้นหาไพรเวซีเมนเฟสต์ทั่วมือถือที่เก็บถาวรและบันเดิล SDK ที่เชื่อมโยง พร้อมทั้งรวบรวมการประกาศของพวกมันเข้าด้วยกันเมื่อสร้างรายงานความเป็นส่วนตัวของ Xcode (Xcode Privacy Report) เพื่อตรวจสอบการประกาศความเป็นส่วนตัวที่รวมอยู่

หากโปรเจกต์รวมไฟล์ไพรเวซีเมนเฟสต์ที่ซ้ำกันไว้โดยตรงภายในขั้นตอน Copy Bundle Resources ของเป้าหมายหลักอย่างไม่ถูกต้อง Xcode อาจส่งคำเตือนหรือข้อผิดพลาดในการสร้าง:

Multiple commands produce '.../PrivacyInfo.xcprivacy'

ในการแก้ไขข้อขัดแย้งนี้:

• ตำแหน่งเมนเฟสต์ของเฟรมเวิร์ก: สำหรับ iOS XCFramework ไฟล์ PrivacyInfo.xcprivacy จะต้องอยู่ในรูปแบบเฟรมเวิร์กเฉพาะแพลตฟอร์มที่เกี่ยวข้องแต่ละรายการ (ตัวอย่างเช่น OpoInstallSDK.xcframework/ios-arm64/OpoInstallSDK.framework/PrivacyInfo.xcprivacy) แทนที่จะวางไว้ที่ไดเรกทอรีรากของคอนเทนเนอร์ XCFramework
• ทรัพยากรของแอปหลัก: เก็บการประกาศความเป็นส่วนตัวของแอปพลิเคชันโฮสต์ไว้ในทรัพยากรของเป้าหมายหลัก ในขณะที่ปล่อยให้ตัวแปรเฟรมเวิร์ก SDK จัดการไฟล์เมนเฟสต์ของตนเองภายใน

การตรวจสอบการประกาศ API ตามเหตุผลที่จำเป็นภายใน PrivacyInfo.xcprivacy

ตรวจสอบเนื้อหาของไพรเวซีเมนเฟสต์เพื่อให้แน่ใจว่าหมวดหมู่ API ที่ประกาศทั้งหมดตรงกับข้อกำหนด API ตามเหตุผลที่จำเป็น (Required Reason API) อย่างเป็นทางการของ Apple เปิดไฟล์ PrivacyInfo.xcprivacy เป็น Property List หรือ XML ดิบใน Xcode การประกาศควรตรงกับการใช้งาน API ที่จำเป็นอย่างเคร่งครัด:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>NSPrivacyAccessedAPITypes</key>
    <array>
        <dict>
            <key>NSPrivacyAccessedAPIType</key>
            <string>NSPrivacyAccessedAPICategoryUserDefaults</string>
            <key>NSPrivacyAccessedAPITypeReasons</key>
            <array>
                <string>CA92.1</string>
            </array>
        </dict>
    </array>
</dict>
</plist>

รวมเฉพาะหมวดหมู่ API และรหัสเหตุผลที่ได้รับอนุมัติซึ่งสอดคล้องกับข้อกำหนดการใช้งานจริงของ SDK เท่านั้น

การตรวจสอบการส่ง IPA ไปยัง App Store Connect ครั้งสุดท้าย

ก่อนที่จะส่งการอัปเดตแอปพลิเคชันไปยัง App Store Connect ให้ตรวจสอบอาร์ชิฟ IPA ที่คอมไพล์แล้วในเครื่อง:

• ขั้นตอนที่ 1: ใน Xcode ให้เลือก Product > Archive
• ขั้นตอนที่ 2: เมื่ออาร์ชิฟเสร็จสมบูรณ์ ให้คลิก Validate App ภายในหน้าต่าง Organizer
• ขั้นตอนที่ 3: Xcode จะตรวจสอบลายเซ็นเฟรมเวิร์กที่ฝังอยู่, สิทธิ์การเตรียมใช้งาน (Provisioning Entitlements) และสคีมาไพรเวซีเมนเฟสต์เทียบกับเซิร์ฟเวอร์ตรวจสอบความถูกต้องของ Apple

การตรวจสอบความถูกต้องที่สำเร็จแสดงว่าอาร์ชิฟได้ผ่านขั้นตอนการตรวจสอบก่อนการส่งเรียบร้อยแล้ว และเป็นขั้นตอนการตรวจสอบการสร้างที่จำเป็นก่อนการส่งไปยัง TestFlight หรือระบบการผลิต

การวิเคราะห์เปรียบเทียบระหว่าง CocoaPods และการนำเข้าเฟรมเวิร์ก iOS ด้วยตนเอง

การแลกเปลี่ยนด้านการบำรุงรักษา, การแยกตัวของลายเซ็น และระบบการสร้างอัตโนมัติ

การเลือกระหว่าง CocoaPods กับการรวมเฟรมเวิร์กด้วยตนเองเกี่ยวข้องกับการประเมินเวิร์กโฟลว์ของทีม, ความสามารถของเซิร์ฟเวอร์บิวด์ และภาระการบำรุงรักษาการพึ่งพา แม้ว่า CocoaPods จะช่วยให้อัปเดตเวอร์ชันโดยอัตโนมัติ แต่การอัปเกรดเวอร์ชัน Xcode อาจต้องมีการอัปเดต Podfile post_install hooks ให้สอดคล้องกับนโยบายลายเซ็นที่เปลี่ยนแปลงไปของ Apple

ตารางด้านล่างให้การเปรียบเทียบทางเทคนิคโดยละเอียดของกลยุทธ์การนำเข้าทั้งสองแบบ:

การประเมินกลยุทธ์การจัดการการพึ่งพาทั่วมือถือขององค์กร

CocoaPods ยังคงเป็นตัวเลือกที่ใช้งานได้จริงสำหรับทีมที่ใช้การจัดการการพึ่งพาตาม Podfile อยู่แล้ว เนื่องจากมีการแก้ไขการพึ่งพาอัตโนมัติและการล็อกเวอร์ชันส่วนกลางผ่าน Podfile.lock การรวมสคริปต์เขียนทับลายเซ็น Ruby แบบจำกัดขอบเขตช่วยแก้ไขปัญหาการบล็อกการเซ็นชื่อในระดับเป้าหมายทั่วมือถือของทีมและสภาพแวดล้อมการสร้าง CI/CD

บทสรุปและกรอบการตัดสินใจ

การนำเข้า iOS SDK อย่างมีประสิทธิภาพจำเป็นต้องเลือกกลไกการพึ่งพาที่เหมาะสมสำหรับเครื่องมือโปรเจกต์ของคุณ ในขณะเดียวกันก็ต้องลดความเข้มงวดในการเซ็นโค้ดของ Xcode ด้วย การใช้ CocoaPods ร่วมกับ post_install hook แบบจำกัดขอบเขตสามารถแก้ไขความล้มเหลวในการเซ็นชื่อชุดทรัพยากรที่ได้รับผลกระทบได้ ในขณะที่การฝัง XCFramework ด้วยตนเองจะช่วยควบคุมอาร์ทิแฟกต์การสร้างได้โดยตรง

ในขณะที่ Apple ยังคงปรับปรุงกฎการตรวจสอบของ App Store Connect อย่างต่อเนื่อง การรักษาการพึ่งพาของไคลเอนต์ให้เป็นไปตามมาตรฐานไพรเวซีเมนเฟสต์จึงยังคงเป็นสิ่งสำคัญ การปรับใช้เวอร์ชัน SDK ที่อัปเดตและการรักษา Podfile hooks แบบอัตโนมัติช่วยให้ทีมวิศวกรลดการติดขัดในการสร้างซ้ำ ๆ และปรับปรุงความสอดคล้องในการรวมระบบ

นักพัฒนาที่พร้อมจะเริ่มต้นใช้งานคีย์โปรเจกต์ของตนสามารถลงทะเบียนบน คอนโซลนักพัฒนา OpoInstall หรือตรวจสอบ เอกสารอ้างอิงการใช้งาน mobile attribution ทั้งหมดสำหรับแนวทางเพิ่มเติมเกี่ยวกับแพลตฟอร์ม

เอกสารที่เกี่ยวข้อง

• แนวคิด: iOS SDK, Code Signing Identity, Resource Bundle Signing, Privacy Manifest Aggregation

• เทคโนโลยี: CocoaPods, Xcode Build Toolchain, XCFramework, Swift Package Manager

• มาตรฐาน: แนวทางการส่ง Apple App Store Connect, ข้อกำหนด Apple Privacy Manifest

• APIs: OpoInstall iOS SDK Delegate APIs, Apple UIPasteboard APIs, Universal Links Associated Domains APIs

• เอกสารทางการและข้อมูลอ้างอิง & References:

  • คำแนะนำของนักพัฒนา Apple เกี่ยวกับไฟล์ Privacy Manifest

  • เอกสารของ Apple เกี่ยวกับข้อกำหนด SDK ของบุคคลที่สาม

  • บันทึกทางเทคนิคของนักพัฒนา Apple เกี่ยวกับ Required Reason APIs

  • คำแนะนำของ Apple Xcode เกี่ยวกับการสร้าง Static Framework

  • ข้อมูลอ้างอิงไวยากรณ์ CocoaPods สำหรับ Podfile Hooks