การเรียนรู้การเขียนโปรแกรม Swift: พร้อมสำหรับ Prime Time แล้วหรือยัง

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

นับตั้งแต่เปิดตัว นักพัฒนา iOS จำนวนมากประสบปัญหากับคำถามว่าควรเปลี่ยนจาก Objective-C เป็น Swift อย่างไร อย่างไร และเมื่อใด คำตอบสำหรับคำถามนั้นจะแตกต่างกันไปในแต่ละทีมและทุกโครงการ

มีบทความจำนวนหนึ่งที่คุณสามารถอ่านได้ซึ่งครอบคลุมข้อดีมากมายของ Swift ดังนั้น แทนที่จะทบทวนประเด็นเดิมๆ ในบทความนี้ เราจะเน้นที่ข้อกังวลบางประการที่คุณอาจต้องการพิจารณาก่อนเรียนรู้การพัฒนาแอพด้วย Swift

แต่ก่อนอื่น ให้หมุนนาฬิกากลับสักหน่อย…

Before Swift: คุณจะใช้ Objective-C และคุณจะชอบมัน...

ปีคือปี 2010 iPhone ยังอายุไม่ถึง 3 ปี และความสามารถในการเขียนแอพที่มาพร้อมเครื่องสำหรับ iPhone มีมาเพียงประมาณ 2 ปีเท่านั้น เมื่อวันที่ 8 เมษายนของปีนั้น Apple ได้ประกาศเวอร์ชันของ iPhone OS ระบบปฏิบัติการของ iPhone (ก่อนหน้านี้เปลี่ยนชื่อเป็น iOS) มีฟีเจอร์ใหม่ๆ ที่ยั่วเย้า เช่น การทำงานหลายอย่างพร้อมกัน การสลับแอปอย่างรวดเร็ว และบริการพื้นหลัง เป็นที่เข้าใจได้ว่านักพัฒนา iPhone ต่างกระตือรือร้นที่จะรับมือกับ SDK ใหม่และเริ่มเล่นกับคุณสมบัติใหม่ที่น่าตื่นเต้นเหล่านั้น

แต่ SDK ของ iPhone OS 4 มีกระสุนที่ไม่คาดคิด กระสุนนี้ไม่ได้อยู่ในซอฟต์แวร์ แต่อยู่ในข้อตกลงการใช้งาน ด้วย iPhone OS 4 SDK ส่วน 3.3.1 ของข้อตกลงของนักพัฒนาได้รับการอัปเดตเพื่อรวมภาษาที่เป็นปัญหาต่อไปนี้:

แอปพลิเคชันต้องเขียนด้วย Objective-C, C, C++ … และมีเพียงโค้ดที่เขียนด้วย C, C++ และ Objective-C เท่านั้นที่สามารถคอมไพล์และเชื่อมโยงโดยตรงกับ Documented API
– ส่วนที่ 3.3.1 ของข้อตกลงนักพัฒนา SDK ของ iPhone OS 4 SDK

จำเป็นต้องพูด ข้อจำกัดใหม่นี้ทำให้นักพัฒนาหลายคนประหลาดใจ เหตุผลอย่างเป็นทางการสำหรับการเปลี่ยนแปลงนี้ ซึ่งสตีฟ จ็อบส์เป็นผู้จัดหาเองคือเพื่อป้องกันการใช้เครื่องมือข้ามแพลตฟอร์ม เช่น Flash CS5 ที่เพิ่งประกาศเมื่อเร็วๆ นี้ จ็อบส์อ้างว่า "ชั้นกลางระหว่างแพลตฟอร์มและนักพัฒนาสร้างแอปที่ต่ำกว่ามาตรฐานในที่สุด" แต่ความจริงที่ว่าแนวทางของ Apple ในการต่อสู้กับ "เลเยอร์ระดับกลาง" เหล่านี้คือการจำกัดภาษาการเขียนโปรแกรมใดที่สามารถใช้เขียนแอป iPhone ได้เผยให้เห็นบางสิ่งเพิ่มเติมเกี่ยวกับความคิดของ Apple: Objective-C น่าจะดีพอสำหรับทุกคน

เราอาจให้อภัยได้หากเห็นด้วยกับการยืนยันนี้ เนื่องจาก Objective-C ได้รับรางวัล "ภาษาการเขียนโปรแกรมแห่งปี" ของ Tiobe Index สองปีติดต่อกัน แต่ความจริงก็คือความนิยมของ Objective-C นั้นเป็นหน้าที่ของระบบนิเวศของแอปที่กำลังเติบโต ไม่ใช่ในทางกลับกัน ย้อนกลับไปในปี 2010 หลายคนไม่พอใจกับ Objective-C อยู่แล้ว และด้วยเหตุนี้ ทางเลือกอื่นในการเขียนแอพของ iPhone ในภาษาโปรแกรมอื่น ๆ ก็ถูกครอบตัดไปหมดแล้ว

ในที่สุด ภายใต้แรงกดดันจากชุมชนนักพัฒนาโดยรวม Apple ยกเลิกการเปลี่ยนแปลงในส่วน 3.3.1 ของข้อตกลงนักพัฒนา SDK เพียงห้าเดือนต่อมา อย่างไรก็ตาม ข้อความนั้นชัดเจน: หากคุณต้องการเขียนแอพสำหรับ iPhone คุณน่าจะใช้ Objective-C

… หรืออาจจะไม่ ป้อนภาษา iOS ใหม่ Swift

กรอไปข้างหน้าอย่างรวดเร็ว 4 ปีจากเหตุการณ์นั้นจนถึงเดือนมิถุนายน 2014 เมื่อ Apple แนะนำให้นักพัฒนาใช้ภาษาใหม่คือ Swift หากข้อความของ 4 ปีก่อนคือ Apple พอใจกับ Objective-C อย่างสมบูรณ์แล้ว ข้อความที่ส่งโดยการแนะนำของ Swift ก็คือในที่สุด Apple ก็พร้อมที่จะยอมรับความจริง Objective-C อาจไม่ใช่ภาษาที่ดีที่สุดในการเขียนแอปบนอุปกรณ์เคลื่อนที่เสมอไป

มีคนพูดถึงว่า Swift เป็นภาษาที่ "ทันสมัย" มากกว่า Objective-C อย่างไร หากคุณสนใจที่จะเรียนรู้ภาษาการเขียนโปรแกรม Swift คุณอาจต้องการดูคำแนะนำในการย้ายจาก Objective-C เป็น Swift

สิ่งที่คุณควรสังเกตก็คือ มีความแตกต่างที่สำคัญสองประการระหว่างภาษา Objective-C และ Swift:

1. Swift ไม่ใช่ superset ที่เข้มงวดของภาษา C
2. Swift เป็นการพิมพ์แบบสแตติก ไม่ใช่ แบบไดนามิก

การไม่เป็น superset ที่เข้มงวดของ C หมายความว่า Swift สามารถใช้โครงสร้างไวยากรณ์ได้ฟรี ซึ่งทำให้สามารถใช้ตัวดำเนินการแบบกำหนดเองใน Swift ได้ ตัวอย่างเช่น

การพิมพ์แบบสแตติกหมายความว่า Swift สามารถใช้ประโยชน์จากความก้าวหน้าล่าสุดในระบบการพิมพ์ที่บุกเบิกโดยภาษาต่างๆ เช่น Haskell

แม้จะได้รับการพัฒนามาเป็นเวลา 4 ปีก่อนที่จะเผยแพร่สู่สาธารณะ แต่ Swift ยังคงเป็นภาษาโปรแกรมรุ่นใหม่ ดังนั้นจึงมีข้อควรระวังหลายประการ

ความเข้ากันได้กับ Objective-C

iOS แบ่งปันมรดกร่วมกันกับ OS X ซึ่งจะนำประวัติศาสตร์มาจากระบบปฏิบัติการ NeXTSTEP ที่เปิดตัวครั้งแรกในปี 1989 เดิม NeXTSTEP ถูกเขียนขึ้นเป็นส่วนใหญ่ใน Objective-C และไลบรารีหลักจำนวนมากใน OS X และ iOS ติดตามรากทั้งหมด ทางกลับไปสู่การใช้งานดั้งเดิมเหล่านี้ (โดยบังเอิญ นี่คือที่มาของคำนำหน้า “NS” ที่พบได้ทั่วไปในคลาสหลัก เช่น NSString ) ในขณะที่ Swift อาจมีอยู่ตามทฤษฎีหากไม่มีไลบรารีหลักเหล่านี้ ความจริงก็คือโปรแกรม Swift ใดๆ ที่คุณอาจเขียนได้ในอนาคตอันใกล้ จะต้องติดต่อกับ Objective-C

นักพัฒนาที่อยู่เบื้องหลัง Swift ได้ทำงานที่ยอดเยี่ยมในการโต้ตอบกับไลบรารี Objective-C ที่มีอยู่โดยไม่เจ็บปวดที่สุด ไม่ได้หมายความว่ากระบวนการนี้ปราศจากความเจ็บปวดอย่างสมบูรณ์ Apple ได้จัดทำคู่มือที่เป็นประโยชน์ซึ่งอธิบายวิธีเรียกรหัส Objective-C จาก Swift และในทางกลับกัน แต่ก็มีบางอิมพีแดนซ์ที่ไม่ตรงกันที่สำคัญที่ควรทราบ

บางทีความไม่ตรงกันที่ชัดเจนที่สุดอาจเกี่ยวข้องกับไฟล์ส่วนหัว Objective-C เนื่องจากเป็นราก C ยังคงต้องมีการประกาศฟังก์ชันก่อนที่จะถูกเรียก เมื่อเรียกใช้ไลบรารี การประกาศเหล่านี้จะอยู่ในไฟล์ส่วนหัวของไลบรารี อย่างไรก็ตาม Swift ไม่ได้ใช้ไฟล์ส่วนหัว ดังนั้น ถ้าคุณต้องการเรียกรหัส Swift จาก Objective-C คุณจะต้องสร้าง "ส่วนหัวของการเชื่อมโยง" ก่อน แม้ว่าแนวความคิดนี้อาจดูไม่ซับซ้อนนัก แต่ในทางปฏิบัติ อาจเป็นงานที่ทำได้ค่อนข้างมาก

ภาวะแทรกซ้อนอีกชุดหนึ่งในการเชื่อมต่อระหว่าง Swift และ Objective-C เกิดจากความแตกต่างโดยธรรมชาติในระบบประเภท สวิฟต์ซึ่งใช้ภาษาสมัยใหม่อื่น ๆ ได้เลิกใช้แนวคิดของ nil แทนที่จะเป็นประเภทเสริมของ Swift ตัวอย่างเช่น เมธอดที่เปิดไฟล์ได้ก็ต่อเมื่อมีไฟล์นั้นอยู่แล้วจะมีประเภทส่งคืน File? (แทนที่จะเป็นแค่ File ) ใน Swift ด้วยการติดตามสถานที่ทั้งหมดที่สามารถเลือกประเภทได้ คอมไพเลอร์ Swift สามารถทำให้ไม่สามารถพบกับ "Null Pointer Error" ที่น่ากลัวได้อย่างมีประสิทธิภาพ แน่นอน เว้นแต่คุณจะเรียก Objective-C เนื่องจาก Objective-C ไม่รับประกันว่าจะไม่ส่งคืน nil Swift จึงมีหมวดหมู่พิเศษที่เรียกว่า Implicitly Unpack Optionals ซึ่งใช้เมื่อเรียกใช้โค้ด Objective-C ประเภทเหล่านี้สามารถใช้เป็นตัวเลือกในภาษา Swift พร้อมกับค่าใช้จ่ายทั้งหมดที่จำเป็นสำหรับการตรวจสอบการมีอยู่ อีกทางหนึ่ง สามารถใช้ได้เหมือนกับประเภทที่ไม่ใช่ตัวเลือก แต่ ถ้า Objective-C คืนค่าเป็น nil คุณจะจบลงด้วยข้อผิดพลาดรันไทม์ ดังนั้นคุณจะสูญเสียการรับประกันความปลอดภัยเวลาคอมไพล์ของ Swift บางส่วน

สุดท้าย ความไม่ตรงกันเล็กน้อยที่ควรพิจารณาเมื่อเขียนโปรแกรมระหว่าง Swift และ Objective-C เกี่ยวข้องกับวิธีสร้างอ็อบเจ็กต์และคลาสใต้หน้าปกในสองภาษานี้ Objective-C เนื่องจากลักษณะไดนามิกของมัน ใช้ไดนามิกไดนามิกเพื่อเรียกเมธอดบนอ็อบเจ็กต์ (ผ่าน objc_msgSend ) Swift สามารถ ใช้ไดนามิกไดนามิกได้อย่างแน่นอน แต่เนื่องจากเป็นแบบสแตติก จึงมีตัวเลือกในการใช้ vtable เพื่อจัดเก็บพอยน์เตอร์ของฟังก์ชันสำหรับแต่ละวิธี กลไกทั้งสองข้อใดที่ Swift ใช้ขึ้นอยู่กับปัจจัยสองสามประการ Plane Old Swift Objects จะใช้กลไก vtable เว้นแต่คลาสหรือเมธอดภายในคลาสจะได้รับการใส่คำอธิบายประกอบโดยใช้แอตทริบิวต์ @objc Swift คลาส Swift ที่สืบทอดมาจากคลาส Objective-C จะใช้ไดนามิกไดนามิกสำหรับเมธอดที่สืบทอดมา แต่ไม่ใช่สำหรับเมธอดใหม่ใด ๆ ที่คลาสย่อยแนะนำ (แต่คุณสามารถบังคับให้ใช้ไดนามิกดิสเพลย์ด้วยแอตทริบิวต์ @objc ได้อีก) ไม่ว่าโค้ด Swift จะสามารถทำงานกับคลาส Swift ได้เสมอ แต่โค้ด Objective-C สามารถใช้อ็อบเจ็กต์และเมธอดของ Swift ที่มีคำอธิบายประกอบอย่างเหมาะสมเท่านั้น

เร็วกว่า Objective-C?

เมื่อ Apple เปิดตัว ข้อดีอย่างหนึ่งของ Swift ที่เน้นเป็นพิเศษคือความเร็ว สิ่งนี้สามารถเข้าใจได้เมื่อคุณพิจารณาว่าเหตุผลหนึ่งที่มักให้ไว้สำหรับความไม่เต็มใจของ Apple ที่จะเปลี่ยนจาก Objective-C ไปเป็นภาษาระดับที่สูงกว่าก็คือ Objective-C ซึ่งโดยพื้นฐานแล้วเป็นส่วนเสริมของ C นั้นสามารถสร้างโปรแกรมได้เร็วและมีประสิทธิภาพมากขึ้น มากกว่าบางอย่างเช่น Python หรือ Ruby ถึงกระนั้น Objective-C ก็ไม่ใช่เรือจรวดเมื่อพูดถึงประสิทธิภาพที่แท้จริง และส่วนใหญ่มาจากการพิมพ์แบบไดนามิก ดังนั้น ด้วย Swift ที่ใช้ระบบประเภทสแตติก อาจมีคนคาดหวังว่า Swift ควร จะเร็วหรือเร็วกว่า Objective-C เป็นอย่างน้อย

แน่นอน ดังคำกล่าวที่ว่า “การโกหกมีอยู่สามประเภท: การโกหก การโกหกที่สาปแช่ง และการเปรียบเทียบ” (หรืออะไรทำนองนั้น…) แน่นอนว่ามีหลายสาเหตุที่ทำให้ภาษา Swift ทำงานได้เร็วกว่า น่าเสียดาย ที่ดูเหมือนว่าวิธีที่ Swift ใช้เทคนิค ARC (การนับการอ้างอิงอัตโนมัติ) ของ Apple สำหรับการจัดการหน่วยความจำ บางครั้งส่งผลให้คอมไพเลอร์ของ Swift สร้างโปรแกรมช้าลง อย่างมาก โดยเฉพาะอย่างยิ่งกับการตั้งค่าการปรับให้เหมาะสมที่ต่ำกว่า (เช่น สิ่งที่คุณอาจใช้ในระหว่างการพัฒนา) ข่าวดีก็คือดูเหมือนว่าการปรับปรุง Swift จะจัดการกับปัญหานี้อย่างต่อเนื่อง ดังนั้นจึงมีแนวโน้มว่าในอนาคตอันใกล้นี้ Swift จะสร้างไฟล์เรียกทำงานอย่างน้อยก็เร็วหรือเร็วกว่า Objective-C

มีข้อแม้อีกประการสำหรับความเร็วของ Swift ประเด็นทั้งหมดของ Swift คือนักพัฒนา จะไม่ เขียนโค้ดเดียวกันกับที่พวกเขาเคยเขียนใน Objective-C สิ่งนี้หมายความว่าสำหรับประสิทธิภาพ? แน่นอนว่ามันหมายความว่าการเปรียบเทียบประสิทธิภาพระหว่าง Swift และ Objective-C นั้นเกี่ยวข้องกันมากกว่าการเปรียบเทียบแบบธรรมดาที่สามารถเปิดเผยได้ นอกจากนี้ยังหมายความว่าการเปรียบเทียบประสิทธิภาพรันไทม์แบบสัมบูรณ์ของไฟล์เรียกทำงานที่สร้างขึ้นจะบอกเล่าเรื่องราวเพียงครึ่งเดียว

ทุกคนต้องการโปรแกรมที่รวดเร็ว แต่บ่อยครั้งที่ความเร็วในการพัฒนาก็มีความสำคัญไม่แพ้กัน ภาษาที่แสดงออกมากขึ้น สามารถทำงานได้มากขึ้นในโค้ดที่น้อยลง จะเป็นประโยชน์อย่างมากในเรื่องนี้ ในทางกลับกัน เมื่อทำงานในภาษาคอมไพล์ที่วงจร edit-compile-run-debug ใช้เวลาส่วนใหญ่ของวันของโปรแกรมเมอร์ คอมไพเลอร์ที่ช้าอาจส่งผลเสียต่อประสิทธิภาพการทำงานได้จริงๆ แม้ว่าหลักฐานจะเป็นเรื่องเล็กน้อย แต่ดูเหมือนว่าคอมไพเลอร์ Swift นั้นช้าพอที่จะสร้างความรำคาญ โดยเฉพาะอย่างยิ่งเมื่อทำงานกับโค้ดที่ใช้ฝึกระบบประเภทขั้นสูงของ Swift กลุ่มหนึ่งพบว่าความเร็วในการรวบรวมมีปัญหาเพียงพอที่จะกระตุ้นให้เปลี่ยนกลับไปใช้ Objective-C

คอมไพเลอร์

การพูดของคอมไพเลอร์ Swift เป็นที่มาของข้อแม้ที่มากขึ้นเมื่อพิจารณาเปลี่ยนเป็นภาษา Swift ใหม่ นอกเหนือจากความเร็วในการคอมไพล์แล้ว เนื่องจาก Swift ได้มาจากกลุ่มนักพัฒนากลุ่มเล็กๆ ที่ทำงานกับ Apple และถูกปล่อยออกสู่สายตาคนจำนวนมาก คอมไพเลอร์ก็เริ่มแสดงรอยแตกภายใต้ความเครียด มีแม้กระทั่งพื้นที่เก็บข้อมูล GitHub ทั้งหมดที่ทุ่มเทให้กับการรวบรวมตัวอย่างโค้ดที่จะทำให้คอมไพเลอร์ Swift ขัดข้อง

นอกจากนี้ยังมีคำถามว่าคอมไพเลอร์ Swift จะเปลี่ยนไปอย่างไร อีกโครงการหนึ่งใน GitHub กำลังรวบรวมการเก็งกำไรและการวิเคราะห์จากชุมชนเกี่ยวกับการเปลี่ยนแปลงที่อาจจะเกิดขึ้นสำหรับ Swift ตัวอย่างเช่น ตัวดำเนินการแบบกำหนดเองสามารถทำให้เกิดความเครียดอย่างมากกับ parser ในขั้นต้น ตัวดำเนินการแบบกำหนดเองใน Swift ไม่สามารถใช้อักขระเครื่องหมายคำถาม (?) แม้ว่าสิ่งนี้จะได้รับการแก้ไขแล้วใน Swift รีลีสล่าสุด คำขอยังคงสตรีมจากชุมชนนักพัฒนา Swift ที่กำลังเติบโตเพื่อความยืดหยุ่นมากยิ่งขึ้นในสิ่งที่ถือได้ว่าเป็นโอเปอเรเตอร์แบบกำหนดเองที่ถูกต้อง

ทุกครั้งที่คุณได้ยินว่า parser สำหรับภาษามีการไหล คุณควรหยุดชั่วคราว parser ของภาษาคือหัวใจและจิตวิญญาณของภาษาโปรแกรม ก่อนที่ความหมายของภาษาใด ๆ ที่สามารถนำมาใช้เพื่อสื่อความหมายในโค้ดได้ ตัวแยกวิเคราะห์จะกำหนดว่าอะไรคือโค้ดที่ถูกต้องและไม่ถูกต้องในการเริ่มต้นด้วย จึงเป็นกำลังใจที่ดีที่ Apple ได้ให้คำมั่นว่าจะรับรองความเข้ากันได้ของรันไทม์สำหรับ Swift ในระดับหนึ่ง ไม่จำเป็นต้องรับประกันว่าโค้ด Swift จะทำงานโดยไม่ต้องคอมไพล์ใหม่สำหรับ Xcode และ/หรือ iOS รุ่นใหม่แต่ละรุ่น และไม่รับประกันว่าคุณไม่จำเป็นต้องเขียนโค้ด Swift บางส่วนใหม่เพื่อให้เข้ากันได้กับ Swift รุ่นต่อๆ ไป แต่ขอย้ำอีกครั้งว่า ความมุ่งมั่นของ Apple ในการทำให้กระบวนการนี้เป็นไปอย่างราบรื่นที่สุด อย่างน้อยก็เป็นการปลอบใจเล็กน้อย

ชุมชน

ภาษาโปรแกรมที่แย่ที่สุดบางภาษาที่เคยสร้างมา (ซึ่งจะยังคงไม่มีชื่อ) ได้รับการช่วยเหลือมานานหลังจากที่สามัญสำนึกบอกว่าพวกเขาควรถูกผลักไสให้ตกชั้นของเทคโนโลยีที่ล้มเหลวด้วยความแข็งแกร่งของชุมชนที่เกี่ยวข้องเพียงลำพัง ในเวลาเดียวกัน คอลเล็กชั่นภาษาโปรแกรมดีๆ ที่ล้มเหลวในการจัดการเพราะความต้องการของชุมชนนั้นมีมากมายเกินกว่าจะนับได้ ชุมชนที่เข้มแข็งสร้างบทช่วยสอน ตอบคำถามเกี่ยวกับ Stack Overflow พบปะพูดคุยทางออนไลน์หรือพบปะพูดคุยด้วยตนเองที่การประชุม แบ่งปันเรื่องราว เคล็ดลับ และกลเม็ดต่างๆ และเขียนและแบ่งปันห้องสมุดที่มีประโยชน์ซึ่งกันและกัน เมื่อเลือกภาษาที่จะใช้สำหรับโปรเจ็กต์ ชุมชนเป็นสิ่งที่ต้องพิจารณาอย่างแน่นอน

น่าเศร้าที่ชุมชน iOS/Objective-C ไม่มีชื่อเสียงในด้านความเป็นมิตรและการต้อนรับที่ดีที่สุด ที่ค่อยๆ เปลี่ยนแปลงไป และโอเพ่นซอร์สก็มีบทบาทสำคัญมากขึ้นในการพัฒนา Objective-C อย่างไรก็ตาม ในช่วงเริ่มต้นนี้ เป็นเรื่องยากที่จะบอกได้ว่าชุมชน Swift จะเป็นอย่างไรในอนาคต ส่วนใหญ่จะประกอบด้วยนักพัฒนาที่โดดเดี่ยวที่ทำงานเฉพาะกับ Apple API อย่างเป็นทางการและชุดรหัสส่วนตัวของพวกเขาเองหรือไม่ หรือจะเป็นชุมชนที่มีชีวิตชีวาของกลุ่มแบ่งปันเคล็ดลับ กลเม็ด และห้องสมุดที่มีประโยชน์?

อีกแง่มุมหนึ่งของบทบาทของชุมชนคือบทบาทของนักพัฒนาของ Swift เอง แนวโน้มโดยรวมในการเขียนโปรแกรมคือการเปลี่ยนจากภาษาและแพลตฟอร์มการเขียนโปรแกรมที่เป็นกรรมสิทธิ์ไปเป็นโซลูชันโอเพ่นซอร์ส การพัฒนาโอเพ่นซอร์ส โดยเฉพาะในระดับภาษาโปรแกรมและรันไทม์สามารถเป็นประโยชน์อย่างแท้จริง ในขณะที่นักพัฒนา Swift ได้กล่าวหลายครั้งว่าตั้งใจที่จะเปิดภาษา Swift และรันไทม์อย่างสมบูรณ์ แต่ก็ยังไม่เกิดขึ้นดังนั้นจึงควรระมัดระวัง

ที่กล่าวว่านักพัฒนาซอฟต์แวร์ที่อยู่เบื้องหลัง Swift คือนักพัฒนารายเดียวกันที่อยู่เบื้องหลังโครงการ LLVM ที่ดำเนินมายาวนาน LLVM ไม่ใช่การเปรียบเทียบที่สมบูรณ์แบบ เพราะมันเริ่มต้นชีวิตแบบเปิดโล่งเป็นโครงการจากมหาวิทยาลัยอิลลินอยส์ Urbana-Champaign แต่สำหรับเครดิตของพวกเขา นักพัฒนาหลักยังคงเปิดกว้างและมีส่วนร่วมกับชุมชน แม้หลังจากที่พวกเขาส่วนใหญ่เปลี่ยนไปทำงานให้กับ Apple แล้วก็ตาม มีเหตุผลอย่างยิ่งที่จะคาดหวังว่าภาษา Swift จะยังคงได้รับการพัฒนาต่อไป (ส่วนใหญ่) ในที่เปิดเผย แม้ว่าแพตช์และคำแนะนำคุณลักษณะจากชุมชนจะยังปรากฏให้เห็นในภาษานั้นหรือไม่ก็ตาม

ฉันควรเรียนรู้ Swift หรือไม่

แน่นอนว่าไม่มีคำตอบ "ขนาดเดียวที่เหมาะกับทุกคน" ในที่นี้ และเช่นเคย การเลือกเครื่องมือที่เหมาะสมสำหรับงานต้องอาศัยความรู้อย่างลึกซึ้งในรายละเอียดทั้งหมดของโครงการที่เป็นปัญหา แน่นอนว่า ณ เวลานี้ Objective-C ยังคงเป็นทางเลือกที่ "ปลอดภัย" สำหรับการพัฒนา iOS แต่ Swift นั้นคู่ควรแก่การพิจารณาอย่างแน่นอน

การเปลี่ยนแปลงที่สำคัญที่สุดที่ Swift นำมาสู่การพัฒนา iOS คือนักพัฒนาหลายคนจะถามคำถามตัวเองเป็นครั้งแรกว่า "ฉันควรใช้ภาษาอะไร" จากประวัติของ Apple, Objective-C และแพลตฟอร์ม iOS การเปลี่ยนแปลงเพียงอย่างเดียวนี้ค่อนข้างน่าตื่นเต้น โดยเฉพาะอย่างยิ่งเมื่อพิจารณาว่าตัวเลือกไม่ใช่ไบนารี ในขณะที่ Apple ได้ระบุความต้องการของพวกเขาอย่างชัดเจน ชุมชนนักพัฒนา iOS โดยรวมได้ทำงานอย่างหนักมาหลายปีแล้ว และได้ให้คำตอบที่เป็นไปได้มากขึ้นสำหรับคำถามนี้