ฉันเปิดความโปรดปราน: "กำลังมองหาคำตอบจากแหล่งข้อมูลที่น่าเชื่อถือและ / หรือเป็นทางการ" แต่ไม่ได้รับตั้งแต่นั้นมา
แม้ว่าคำตอบของ @jackslash จะถูกต้อง แต่ก็บอกเล่าเรื่องราวเพียงบางส่วนเท่านั้นดังนั้นฉันจึงต้องการเขียนของตัวเองในแบบที่ฉันอยากเห็นในตอนที่ฉันถามคำถามนี้
ความเป็นจริงของคำตอบนี้คือกรกฎาคม 2015 เป็นไปได้มากว่าสิ่งต่างๆจะเปลี่ยนไป
ก่อนอื่นเรามายืนยันว่าการดำเนินการที่จำเป็นสำหรับการเซ็นโค้ดของเฟรมเวิร์กที่ถูกต้องควรแบ่งออกเป็นขั้นตอนที่นักพัฒนาของเฟรมเวิร์กต้องดำเนินการและขั้นตอนที่ Consumer ของเฟรมเวิร์กต้องดำเนิน
TLDR;
สำหรับเฟรมเวิร์ก OSX: นักพัฒนามีอิสระที่จะเผยแพร่เฟรมเวิร์ก OSX โดยไม่ต้องเซ็นโค้ดเนื่องจากผู้บริโภคจะกำหนดโค้ดใหม่
สำหรับกรอบงาน iOS: นักพัฒนามีอิสระที่จะแจกจ่ายกรอบงาน iOS โดยไม่ต้องลงรหัสเนื่องจากผู้บริโภคจะกำหนดรหัสใหม่ แต่นักพัฒนาถูกบังคับให้ Xcode กำหนดรหัสกรอบงานของตนเมื่อสร้างขึ้นสำหรับอุปกรณ์ iOS
เพราะเรดาร์: "iOS ของกรอบที่มีชิ้นจำลองไม่สามารถส่งไปที่ App Store"ผู้บริโภคของกรอบ iOS ของคุณถูกบังคับให้ทำงานสคริปต์พิเศษเช่น "copy_frameworks" หรือ "strip_frameworks" ซึ่งใช้lipo -remove
ในการถอดชิ้นจำลองจากกรอบ iOS และอีกครั้ง -codesigns stripped framework เพราะ ณ จุดนี้การกำหนดรหัสประจำตัวไม่ว่าจะเป็นอะไรก็ตาม (หรือไม่ใช่) จะถูกลบออกเป็นผลข้างเคียงของการlipo -remove
จัดการ
คำตอบอีกต่อไปนี้
คำตอบนี้ไม่ใช่ "ภาพวาดจากแหล่งข้อมูลที่น่าเชื่อถือและ / หรือเป็นทางการ" แต่เป็นไปตามข้อสังเกตเชิงประจักษ์หลายประการ
การสังเกตเชิงประจักษ์ # 1: ผู้บริโภคไม่สนใจเพราะพวกเขาจะกำหนดกรอบการออกแบบโค้ดใหม่ที่ได้รับจากนักพัฒนา
แจกแจงกรอบไบนารีที่รู้จักกันดีโครงการมาเปิดบน Github ไม่ได้ codesigned คำสั่งcodesign -d -vvvv
ให้: "วัตถุรหัสไม่ได้ลงนามเลย" ในกรอบงานไบนารี iOS และ OSX ทั้งหมดที่ฉันเคยสำรวจ ตัวอย่างบางส่วน: ReactiveCocoaและ เสื้อคลุม , อาณาจักร , PromiseKit
จากการสังเกตนี้เป็นที่ชัดเจนว่าผู้เขียนของกรอบงานเหล่านี้ตั้งใจให้เป็นรหัสที่ลงนามโดย Consumer ในนามของพวกเขากล่าวคือผู้บริโภคต้องใช้แฟล็ก "Code Sign on Copy" ในขั้นตอนการสร้าง "Embed frameworks" ที่ Xcode จัดเตรียมไว้หรือใช้เชลล์ที่กำหนดเอง สคริปต์ที่ทำสิ่งเดียวกันด้วยตนเอง: รหัสกรอบงานในนามของผู้บริโภค
ฉันไม่พบตัวอย่างใด ๆ ที่ตรงกันข้าม: เฟรมเวิร์กโอเพนซอร์สที่จะแจกจ่ายด้วยรหัสการออกแบบเอกลักษณ์ในส่วนที่เหลือของคำตอบฉันถือว่าแนวทางที่นำมาใช้อย่างกว้างขวางนี้เป็นแนวทางที่ถูกต้อง: ไม่จำเป็นต้องให้นักพัฒนากรอบงาน แจกจ่ายเฟรมเวิร์กของตนให้กับนักพัฒนารายอื่นโดยมีการกำหนดรหัสประจำตัวอยู่ในนั้นเนื่องจากผู้บริโภคจะทำการเขียนโค้ดใหม่
การสังเกตเชิงประจักษ์ # 2 ซึ่งใช้กับ iOS เท่านั้นและเป็นข้อกังวลของนักพัฒนา
ในขณะที่ผู้บริโภคไม่สนใจไม่ว่าจะเป็นกรอบการทำงานที่ได้รับจากนักพัฒนา codesigned หรือไม่ผู้พัฒนายังคงต้อง Codesign กรอบ iOS ของพวกเขาเป็นส่วนหนึ่งของการสร้างกระบวนการของมันเมื่อพวกเขาสร้างมันสำหรับอุปกรณ์ iOSเพราะมิฉะนั้น Xcode CodeSign error: code signing is required for product type 'Framework' in SDK 'iOS 8.1'
ไม่ได้สร้าง: หากต้องการอ้างอิงJustin Spahr-Summers :
เฟรมเวิร์ก OS X ไม่จำเป็นต้องได้รับการลงนามในการสร้าง ... น่าเสียดายที่ Xcode ต้องการให้เฟรมเวิร์ก iOS ต้องลงนามในเวลาสร้าง
คำตอบนี้ค่อนข้างดีสำหรับคำถามของฉัน # 2: ข้อมูลประจำตัว "นักพัฒนา iPhone" นั้นเพียงพอที่จะย่อ Xcode เพื่อที่จะสร้างกรอบงาน iOS สำหรับอุปกรณ์ ความคิดเห็นเกี่ยวกับ Carthage # 339 นี้พูดในสิ่งเดียวกัน
การสังเกตเชิงประจักษ์ # 3: เครื่องมือ lipo
พฤติกรรมเฉพาะของเครื่องมือ lipo: เมื่อนำไปใช้กับเฟรมเวิร์กไบนารีมันจะลบรหัสประจำตัวใด ๆ ซ้ำ ๆ ออกจากมันlipo -create/-remove codesigned framework ... -> not codesigned framework
เสมอ:
นี่อาจเป็นคำตอบว่าทำไมตัวอย่างทั้งหมดในข้อสังเกต # 1 จึงไม่ได้รับการออกแบบรหัสเลย: รหัสประจำตัวของพวกเขาจะหายไปหลังจากใช้ lipo แต่เนื่องจากตามข้อสังเกต # 1 ผู้บริโภคไม่สนใจว่ามันก็ดี
ข้อสังเกตนี้เกี่ยวข้องอย่างยิ่งกับข้อสังเกตถัดไป # 4 เกี่ยวกับ AppStore
การสังเกตเชิงประจักษ์ # 4: ไม่สามารถส่งกรอบงาน iOS ที่มีชิ้นส่วนจำลองไปยัง App Store ได้
นี้จะกล่าวถึงกันอย่างแพร่หลายใน: Realm # 1163และคาร์เธจ # 188และเรดาร์เปิด: rdar: // 19209161
นี่เป็นข้อกังวลของผู้บริโภคทั้งหมด: สำหรับเฟรมเวิร์กสากลของ iOS ที่ Consumer รวมไว้ในแอปพลิเคชันของพวกเขาเมื่อมีการสร้างแอปพลิเคชันพวกเขาจะต้องเรียกใช้สคริปต์พิเศษ (ขั้นตอนการรันสคริปต์ที่กำหนดเอง) ซึ่งจะลบชิ้นส่วนจำลองออกจากไบนารีของเฟรมเวิร์กนั้นเพื่อให้แอปผ่านการตรวจสอบความถูกต้องของ AppStore
ตัวอย่างที่ดีสำหรับกรอบไบนารีผมพบว่าในดินแดน: strip-frameworks.sh
ใช้lipo
เพื่อลบส่วนของสถาปัตยกรรมทั้งหมดนอกเหนือ${VALID_ARCHS}
จากนั้นออกแบบรหัสใหม่ด้วยอัตลักษณ์ของผู้บริโภค - นี่คือสิ่งที่ข้อสังเกต # 3 เริ่มต้นขึ้น: เฟรมเวิร์กจะถูกกำหนดรหัสใหม่เนื่องจากการปรับแต่งไลโป
Carthage มีสคริปต์CopyFrameworks.swiftซึ่งทำสิ่งเดียวกันกับเฟรมเวิร์กทั้งหมดที่รวมอยู่ใน Consumer: มันจะตัดส่วนของตัวจำลองออกและกรอบการออกแบบโค้ดใหม่ในนามของ Consumer
นอกจากนี้ยังมีบทความดี: ตัดเส้นสถาปัตยกรรมที่ไม่พึงประสงค์จากห้องสมุดแบบไดนามิกใน Xcode
ตอนนี้ภาพรวมของขั้นตอนที่จำเป็นในการสร้างทั้ง iOS และ OSX จากทั้งมุมมองของนักพัฒนาและผู้บริโภค สิ่งแรกที่ง่ายกว่า:
OSX
ผู้พัฒนา:
- สร้างกรอบ OSX
- มอบให้กับผู้บริโภค
นักพัฒนาไม่จำเป็นต้องมีกิจกรรมการเขียนโค้ด
ผู้บริโภค:
- รับ OSX framework จาก Developer
- คัดลอกกรอบงานไปยังไดเร็กทอรี Frameworks / และกำหนดรหัสโดยอัตโนมัติในนามของผู้บริโภคซึ่งเป็นส่วนหนึ่งของกระบวนการ "Code Sign on Copy"
iOS
ผู้พัฒนา:
- สร้างกรอบงาน iOS สำหรับอุปกรณ์ Xcode จำเป็นต้องมีการออกแบบรหัสข้อมูลประจำตัว "นักพัฒนา iPhone" ก็เพียงพอแล้ว
- สร้างกรอบงาน iOS สำหรับโปรแกรมจำลอง
- ใช้ lipo ที่สร้างกรอบงาน iOS สากลจากสองก่อนหน้า ณ จุดนี้รหัสประจำตัวการเซ็นชื่อของ 1 ขั้นตอนจะหายไป: ไบนารีเฟรมเวิร์กสากล "ไม่ได้ลงนามเลย" แต่ก็เป็นเรื่องปกติเนื่องจาก "ผู้บริโภคไม่สนใจ"
- มอบให้กับผู้บริโภค
ผู้บริโภค:
- รับกรอบงาน iOS จากนักพัฒนา
- คัดลอกเฟรมเวิร์กไปยังไดเร็กทอรี Frameworks / (ขั้นตอนนี้อาจซ้ำซ้อนขึ้นอยู่กับว่าสคริปต์ในขั้นตอนที่ 3 คืออะไร)
- ใช้สคริปต์พิเศษเป็นส่วนหนึ่งของกระบวนการสร้าง: สคริปต์นี้จะตัดตัวจำลองออกจากเฟรมเวิร์ก iOS จากนั้นออกแบบโค้ดใหม่ในนามผู้บริโภคของพวกเขา