- ในการพัฒนาแอป iOS ล่าสุดด้วย Swift 6 การใช้ เครื่องมือที่อิง LLM มีประโยชน์ค่อนข้างต่ำอย่างชัดเจน ทำให้เกิด ช่องว่างด้านประสิทธิภาพการทำงาน อย่างมากเมื่อเทียบกับฝั่ง Android (ที่ใช้ Kotlin, Compose และ Cursor)
- ทีม Android สามารถพัฒนาได้รวดเร็วพร้อมรองรับฟีเจอร์ใหม่บน OS รุ่นเก่าได้เป็นเวลานาน ขณะที่ทีม iOS ต้องเผชิญกับข้อจำกัดของไวยากรณ์และฟีเจอร์ใหม่ใน Swift 6 รวมถึงการรองรับจากเฟรมเวิร์กที่ยังไม่เพียงพอ จึงเกิด ประสิทธิภาพการทำงานที่ลดลง และ ภาระในการย้ายโค้ดเบส
- LLM ยังไม่เข้าใจโมเดล concurrency ใหม่และแพตเทิร์นที่ซับซ้อนของ Swift 6 ได้ดี จึงทำให้ ความสามารถของ LLM ในการทำโค้ดอัตโนมัติ/เร่งการพัฒนา ถูกจำกัด
- แม้การนำ Swift 6 มาใช้จะถูกมองในแง่บวกโดยนักพัฒนาบางส่วน แต่ปัญหา การเข้ากันได้ที่ไม่ดี กับเครื่องมือ LLM ก็ถูกชี้ว่าเป็นประเด็นสำคัญ
- ความโดดเด่นของ การรองรับย้อนหลังและแนวทางที่เป็นมิตรต่อนักพัฒนา ในระบบนิเวศของ Google เช่น Android, Compose และ Cursor ยิ่งถูกเน้นมากขึ้น ขณะที่ความไม่พอใจต่อความเร็วในการอัปเดตเฟรมเวิร์กและ API ของฝั่ง Swift/Apple ยังคงต่อเนื่อง
ประสิทธิภาพการพัฒนาในยุคของ Swift 6 และ LLM
ความรู้สึกต่อประสิทธิภาพการพัฒนา iOS vs Android
- ผู้เขียนกำลังพัฒนาแอปใหม่ด้วย Swift 6 ในทีม iOS ขนาดเล็ก และกำลัง พัฒนาไปพร้อมกัน กับทีม Android ขนาดเล็ก
- ทีม Android ใช้ Kotlin, Compose, Cursor จึงสามารถพัฒนาได้ รวดเร็วและรองรับฟีเจอร์ล่าสุด พร้อมรองรับได้กว้างถึง Android 10 ที่ออกในปี 2019
- ทีม iOS รองรับได้เพียง iOS 16 (2022) ขึ้นไป และจากการใช้ Swift 6 รุ่นล่าสุด ก็ต้องเจอกับข้อจำกัดหลายอย่างของฟีเจอร์อย่าง Observable, generic parameter packs เป็นต้น
ความไม่ลงรอยระหว่าง Swift 6 กับ LLM
- การเปลี่ยนแปลงครั้งใหญ่ของไวยากรณ์และเฟรมเวิร์ก ใน Swift 6 เกิดขึ้นในช่วงเวลาเดียวกับที่ LLM (โมเดลภาษาขนาดใหญ่) เข้ามามีบทบาท ทำให้ LLM ยังจัดการกับระบบ concurrency ใหม่ของ Swift 6 ได้ไม่ดี
- เครื่องมือ LLM ที่ใช้สร้างหรือแนะนำโค้ดอัตโนมัติ (เช่น ChatGPT, Claude, Cursor เป็นต้น) ยังเรียนรู้ข้อมูลและแพตเทิร์นที่เกี่ยวกับ Swift 6 ได้ไม่เพียงพอ จึงมี ข้อจำกัดในการสร้างโค้ดที่แม่นยำ
- นักพัฒนาต้องคอยอธิบายบริบท เพิ่มกฎ หรือช่วยเติมเต็มในส่วนที่ LLM ยังไม่เข้าใจด้วยตนเอง → ทำให้ ประสิทธิภาพการทำงานลดลง และเกิดงานซ้ำ ๆ
ความเห็นและประสบการณ์จากชุมชน
- นักพัฒนา iOS บางส่วนแสดง ความอิจฉา ต่อ ความเข้ากันได้ย้อนหลังของ API บน Android, ความสมบูรณ์ของ Compose UI และเครื่องมืออย่าง Cursor
- แม้จะมีความเห็นว่าการนำ Swift 6 มาใช้อาจเป็นการตัดสินใจที่ผิดพลาด แต่ในอีกด้านหนึ่งก็มีการยอมรับถึงความจำเป็นในการเรียนรู้แพตเทิร์นใหม่ ๆ พร้อมกับประเมินเชิงบวกว่า ความสามารถในการแสดงออกของโค้ดและคุณภาพของโค้ด ดีขึ้น
- เนื่องจากเฟรมเวิร์กหลักของ Apple ยังไม่ได้อัปเดตให้สอดคล้องกับ ระบบ concurrency ของ Swift 6 อย่างเหมาะสม จึงมีการแชร์ประสบการณ์เรื่อง ความซับซ้อนของโค้ด และ ประสิทธิภาพการทำงานที่ลดลง จากการต้องใช้ปะปนกับ GCD
- บางทีมเลื่อนการนำ Swift 6 มาใช้ไปก่อน และกำลังให้ความสำคัญกับการแก้ปัญหาความเข้ากันได้กับโค้ดเบสเดิมเป็นอันดับแรก
ความแตกต่างระหว่างระบบนิเวศ Android และ Apple
- Android เสริมประสิทธิภาพการทำงานของนักพัฒนาด้วย นโยบายรองรับย้อนหลัง (Backport) ของ API ใหม่ และกำลังเอาชนะข้อเสียสะสมมายาวนาน เช่น การแตกกระจายของระบบและบั๊กเฉพาะอุปกรณ์
- ตรงกันข้าม Apple มีภาระที่ทำให้นักพัฒนาต้องลงมือสร้างฟังก์ชันคล้ายกันซ้ำ ๆ เองอยู่เรื่อย ๆ จาก API แบบ private/มีข้อจำกัด และนโยบายอัปเดตที่ล่าช้า
- ด้วยการนำ เครื่องมือ AI และระบบอัตโนมัติ อย่าง Compose และ Cursor มาใช้ ประสิทธิภาพการพัฒนาฝั่ง Android จึงดีขึ้นอย่างรวดเร็วยิ่งกว่าเดิม
- นักพัฒนา iOS และ Swift มีกรณีเพิ่มขึ้นที่รู้สึกกังวลต่อ การเปลี่ยนแปลงของเทรนด์การพัฒนา และ ตำแหน่งทางอาชีพ ในช่วงที่ยังใช้ LLM ได้ยาก
บทสรุปและนัยต่อการทำงานจริง
- แม้ Swift 6 เองจะได้รับการประเมินสูงในด้านนวัตกรรมและความสามารถในการแสดงออกของโค้ด แต่ด้วย ข้อจำกัดของเครื่องมือเขียนโค้ดด้วย LLM/AI ในช่วงนี้ จึงยังเลี่ยงไม่ได้ที่จะต้อง ทำงานด้วยมือและอธิบายซ้ำ ๆ
- สำหรับโปรเจกต์ที่ต้องการการพัฒนาอย่างรวดเร็วและใช้ฟีเจอร์ล่าสุด ชุด Android + Compose + Cursor มีประสิทธิภาพเหนือกว่าอย่างชัดเจน
- หาก Apple ยังไม่เร่งอัปเดตระบบนิเวศของเฟรมเวิร์กและเครื่องมือ หน้างานที่นำ Swift 6 มาใช้ก็จะยังต้องยอมรับ ประสิทธิภาพการทำงานที่ลดลงและข้อจำกัดในการใช้ LLM
3 ความคิดเห็น
โดยรวมแล้วเป็นคำพูดที่ถูกต้อง แต่ในฐานะคนที่เคยลองรันโมเดลโลคัลบนอุปกรณ์ Apple Silicon ด้วย MLX อยู่พักหนึ่ง ผมก็เห็นด้วยแบบ 100% ได้ยากครับ
อ้างอิงไว้ว่าเวลาพัฒนาโมเดลก็มีภาระที่ต้องพอร์ตไปใช้กับ
mlxด้วย และถึงจะเปิดใช้mpsแล้ว จากความรู้สึกก็แค่คำนวณได้เร็วกว่า CPU เล็กน้อย เลยยังใช้งานไม่ค่อยสะดวกอยู่ครับอา.. เจ็บนะ โดนเต็ม ๆ เลย...