3 คะแนน โดย GN⁺ 2026-01-05 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • เป็นเฟรมเวิร์กที่ช่วยให้ พัฒนาแอปเนทีฟ Android ได้ด้วย Swift เพียงภาษาเดียว โดยครอบคลุมตั้งแต่ UI, manifest ไปจนถึง lifecycle ในภาษาเดียว
  • มอบโครงสร้างสำหรับสร้าง Android UI แบบ declarative UI โดยไม่ต้องใช้ XML, Java หรือ Kotlin เลย
  • ทำงานเป็น เฟรมเวิร์ก Android เนทีฟแท้ ไม่ใช่ web wrapper หรือ transpiler
  • สามารถนิยาม UI ได้ผ่าน ไวยากรณ์เชิงประกาศที่คล้าย SwiftUI และซ่อนชั้น JNI ที่ซับซ้อนทั้งหมด
  • มอบประสบการณ์พัฒนาแบบบูรณาการที่สามารถ กำหนดทั้ง Android Manifest และการตั้งค่า Gradle ได้โดยตรงด้วยโค้ด Swift
  • เป็น ทางเลือกเนทีฟแบบใหม่ สำหรับนักพัฒนา Swift ที่ต้องการขยายไปสู่ Android และเป็น จุดเปลี่ยนที่เปิดความเป็นไปได้ใหม่ ให้กับการพัฒนาแบบครอสแพลตฟอร์มบนพื้นฐาน Swift

ภาพรวมของ Droid

  • Droid เป็นเฟรมเวิร์กที่ออกแบบมาเพื่อให้สามารถ พัฒนาแอปพลิเคชัน Android แบบเนทีฟ ได้โดยใช้ภาษา Swift เท่านั้น
  • ออกแบบมาให้จัดการ UI, การตั้งค่าแอป, lifecycle และ manifest ได้จาก ภาษาและ codebase เดียวกัน
  • ขจัดการพึ่งพา XML, Java และ Kotlin ที่เคยถูกมองว่าเป็นสิ่งจำเป็นในการพัฒนา Android
  • รองรับ องค์ประกอบเนทีฟของ Android เช่น AndroidX, Flexbox และ Material Design
  • มี ไวยากรณ์เชิงประกาศ ที่คล้าย SwiftUI เพื่อทำให้การนิยาม UI ง่ายขึ้น
  • ซ่อนชั้น JNI ทั้งหมด และเข้าถึงได้ผ่าน API ระดับสูง

เป้าหมายการออกแบบและจุดเด่น

  • ยึดแนวทาง Pure Swift โดยเขียนทั้ง UI, manifest และองค์ประกอบของแอปทั้งหมดด้วย Swift
  • ใช้ declarative UI โดยให้ความสำคัญกับ ความอ่านง่ายและการนำมาประกอบกันได้
  • คงรูปแบบการพัฒนา No XML ที่ไม่ใช้ XML เลย
  • ใช้ โมเดลการรันแบบ Native Android ไม่ใช่แนวทางบนเว็บหรือการแปลงโค้ด
  • มอบโครงสร้างแบบรวมศูนย์ที่กำหนด UI, manifest และ dependency ของ Gradle ได้ในที่เดียว

แนวทางการประกอบ UI แบบ declarative

  • ใช้ API ที่เป็นมิตรกับ Swift เพื่อประกอบ Android UI แบบ declarative
  • สามารถแสดง วิดเจ็ต Android ด้วยโค้ด Swift เช่น ConstraintLayout, VStack, TextView และ MaterialButton
  • กำหนดข้อจำกัดเลย์เอาต์, click event และการตั้งค่าสไตล์ได้โดยตรงในโค้ด

การเขียน Android Manifest ด้วย Swift

  • ประกาศ Android Manifest เองด้วยโค้ด Swift
  • จัดการไอคอนแอป, ธีม, activity และการตั้งค่า fragment ได้ในระดับโค้ด
  • รวมการจัดการ lifecycle event และตรรกะการตั้งค่าไว้ใน ไฟล์ Swift ไฟล์เดียว

เอกสารและสภาพแวดล้อมการพัฒนา

  • มีเอกสารอย่างเป็นทางการและ กำลังขยายเพิ่มเติมอย่างต่อเนื่อง
  • แม้ยังไม่ได้มีการจัดทำเอกสารสำหรับทุกความสามารถของ Android ทั้งหมด แต่คู่มือที่มีอยู่ถูกจัดเตรียมไว้อย่างเป็นระเบียบ
  • สามารถ เริ่มพัฒนาได้ทันที ผ่าน Swift Stream IDE

ขอบเขตการรองรับ

  • รองรับวิดเจ็ต Android แบบดั้งเดิม
  • รองรับไลบรารี AndroidX
  • รองรับคอมโพเนนต์ Material Design
  • รองรับเลย์เอาต์ Flexbox

สถานะของโปรเจกต์

  • โปรเจกต์นี้ กำลังอยู่ระหว่างการพัฒนาอย่างคึกคัก และพัฒนาอย่างรวดเร็ว
  • API ยังอยู่ระหว่างการปรับปรุงโดยเปิดทางให้ขยายต่อได้ แต่ยังคงรักษาวิสัยทัศน์หลักไว้
  • สนับสนุนให้ส่งฟีดแบ็กและเข้าร่วมมีส่วนร่วมอย่างเต็มที่

1 ความคิดเห็น

 
GN⁺ 2026-01-05
ความคิดเห็นจาก Hacker News
  • มีการเปิดตัว Swift Stream IDE v1.17.0 ตอนนี้สามารถพัฒนา แอป Android แบบเนทีฟเต็มรูปแบบด้วย Swift เพียงอย่างเดียว ได้แล้ว
    ไม่ต้องแตะ XML, Java หรือ Kotlin เลย โดยภายใน เฟรมเวิร์ก SwifDroid ที่ผู้สร้างพัฒนาขึ้นจะจัดการวงจรชีวิตของ Android, Activity, Fragment, วิดเจ็ต UI (เช่น Material, Flexbox) และจัดการ dependency ของ Gradle ให้อัตโนมัติ
    มันจะคอมไพล์โค้ด Swift แล้วสร้างโปรเจ็กต์ที่สามารถรันได้ทันทีใน Android Studio ทั้งเครื่องมือและเฟรมเวิร์กเผยแพร่ภายใต้ MIT open source license

    • น่าสนใจ ผมสงสัยเรื่อง จุดตัด ระหว่างประสบการณ์ Android ที่นักพัฒนา Swift ต้องมี กับประสบการณ์ Swift ที่นักพัฒนา Android/Kotlin ต้องมี
      เขาบอกว่าไม่ต้องแตะ XML, Java, Kotlin เลย แต่ก็ยังสงสัยว่านักพัฒนา Swift ที่ไม่มีประสบการณ์ Android เลยจะสร้างแอปได้สำเร็จหรือไม่
      อีกอย่างก็อยากรู้ว่า ณ ตอนนี้และในปีหน้า แอป Kotlin หรือ Flutter สักกี่เปอร์เซ็นต์กันแน่ที่สามารถเขียนด้วย Swift ได้
    • จุดแข็งอย่างหนึ่งของ Swift คือ การทำงานร่วมกับไลบรารี C/C++ ได้ดี ปกติจะมากับ dependency แบบ SwiftPM หรือ Bazel เลยสงสัยว่าจัดการ dependency ของ SwiftPM อย่างไร
    • อยากรู้ว่าใช้วิธีไหนในการ bind โค้ด Java/Kotlin เข้ากับ Swift
      พวกเราก็กำลังลองทำอะไรคล้ายกันอยู่ แต่ใช้ Rust แทน Swift
    • ยินดีด้วย ผมเองก็กำลังคิดจะรวมสภาพแวดล้อมการพัฒนาให้เป็น Swift เหมือนกัน งานนี้เจ๋งมาก
  • ความพยายามแบบนี้สุดท้ายก็ ต้องผ่าน JNI อยู่ดี จึงมีข้อจำกัดตรงที่ API 80% ถูกเปิดให้ใช้ผ่าน Java เท่านั้น
    โปรเจ็กต์แบบนี้น่าสนใจเสมอ แต่สุดท้ายก็มักชนกับปัญหา leaky abstraction
    ก็เหมือนกับบน iOS ที่ต้องรู้ Objective-C หรือบน Windows ที่ต้องรู้ .NET/COM นั่นแหละ

    • ทุกวันนี้แม้แต่ใน ecosystem ของ Apple ถ้าจะประสบความสำเร็จก็ต้อง ใช้ได้ทั้ง Swift และ Objective-C
      จากประสบการณ์ฝั่ง Unity การ marshal จาก C# ไป C ค่อนข้างลื่น แต่กับ Swift ต้องลงแรงมากกว่ามาก
      และความจริงก็คือต้องคอยรองรับแยกตามแต่ละเฟรมเวิร์กใหม่
  • การใช้ภาษากลางข้ามแพลตฟอร์มอย่าง Swift หรือ Kotlin ดูดีในภาพรวม แต่ผมคิดว่าในทางปฏิบัติมันไม่ได้มีประสิทธิภาพอย่างที่หวัง
    สุดท้ายก็ต้องดูแล โค้ดเบสสองชุด และมีทั้งความแตกต่างกับวิธีอ้อมเต็มไปหมด จนรู้สึกว่าสู้ปล่อยให้แต่ละฝั่งใช้ภาษาของตัวเองไปเลยดีกว่า
    นักพัฒนาส่วนใหญ่ก็สร้างอาชีพด้วยการเรียนรู้หลายภาษาอยู่แล้ว และการย้ายไปใช้ภาษาอื่นก็ไม่ได้ยากนัก นี่เป็นความเห็นส่วนตัวนะ แต่ตัวโปรเจ็กต์เองผมว่าทำได้ดีมาก

    • ถึงอย่างนั้น ความพยายามแบบนี้ก็ช่วยให้วิศวกรที่คุ้นเคยกับแพลตฟอร์มหนึ่งสามารถไปทำงานบนอีกแพลตฟอร์มได้
      เมื่อก่อนผมเคยพยายามเรียนทำแอป Android แบบเนทีฟด้วย Java อยู่หลายเดือน แต่ไม่สนุกเลยจนเลิกไป
      ผมชอบการพัฒนา แบบเนทีฟเต็มรูปแบบ และแม้จะใช้ cross-platform framework มาหลายสิบปี ก็ไม่เคยเห็นความสำเร็จใหญ่จริง ๆ
      การสลับภาษามักมี ต้นทุนด้านการสลับบริบท เสมอ เวลาเขียนสลับระหว่าง Swift กับ PHP ผมมักพลาดเรื่องไวยากรณ์บ่อยมาก
      ภาษาเรียนได้ไว แต่การชำนาญ SDK, standard library และ framework ใช้เวลา นานมาก
    • เฟรมเวิร์กพวกนี้ช่วยให้ทำฟีเจอร์ง่าย ๆ ได้เร็ว แต่พอจะใช้ ความสามารถเฉพาะของแพลตฟอร์ม กลับกลายเป็นอุปสรรค
      โดยเฉพาะตอนนี้ที่มีเครื่องมือ AI ช่วยให้งานง่าย ๆ เร็วขึ้นอยู่แล้ว ผลประหยัดเวลารวมจึงไม่ได้มากนัก
      ถ้าแอปเป็นเหมือนเว็บแอปแทบทั้งหมดก็อีกเรื่อง แต่ถ้าไม่ใช่ ผมไม่ค่อยแนะนำ
    • Kotlin กับ Swift คล้ายกันมาก และส่วนที่ต่างกันนั้นผมกลับคิดว่า ไม่ควรพยายาม abstract มันออกไป
      ในแง่ภาษา ผมมองว่า Swift ดีกว่า แต่ KMP อยู่มานานกว่าและเสถียรกว่า ดังนั้นถ้าใช้จริงก็คงเลือกฝั่งนั้น
    • การรู้หลายภาษาให้ อิสระ มากกว่า
      แต่ผมไม่อยากผูกตัวเองกับ ecosystem ของบริษัทใหญ่บริษัทหนึ่งมากขึ้นไปอีก
      อีกอย่างสำหรับผม Swift เป็นภาษา ที่ใช้งานไม่ค่อยสบาย อยู่แล้ว เลยไม่อยากเอาไปใช้บนแพลตฟอร์มอื่นด้วย
  • อยากรู้ว่าเทียบกับ Skip แล้วเป็นอย่างไร
    โปรเจ็กต์นี้ดูเหมือนจะไม่ได้ย้ายโค้ด iOS SwiftUI ไป Android แต่โฟกัสที่ การพัฒนา Swift สำหรับ Android โดยเฉพาะ
    อยากรู้ว่าสิ่งนี้จะนำไปสู่คุณภาพแอปที่ดีกว่าหรือไม่ และมีกรณีใช้งานจริงบ้างหรือยัง

  • แค่ไม่ต้องใช้ Android Studio หรือ IntelliJ ก็ถือว่า ดีขึ้นมาก แล้ว งานเจ๋งจริง

    • การหนี Android ไปใช้ Xcode ฟังดูเหมือน การเลือกไปจับกรดไฮโดรคลอริก
    • สงสัยว่าสามารถเลี่ยง Gradle ได้ด้วยไหม ข้าม ฝันร้ายเรื่องการจัดการ dependency ไปได้หรือเปล่า
  • หน้าต่างยินยอมคุกกี้ดูเหมือนจะ ไม่สอดคล้องกับข้อบังคับของยุโรป

  • ไม่เข้าใจว่าทำไมการพัฒนาบนมือถือถึง ยุ่งยากกว่า บนพีซีขนาดนี้
    ทำไมแม้แต่การทำ Hello World ด้วยแอสเซมบลีบนมือถือยังยากขนาดนี้

    • ทำได้นะ แต่ก็ ทรมานพอ ๆ กับ การทำ Hello World ด้วยแอสเซมบลีบนพีซี เลยไม่มีใครทำ
  • ผมหยุดทำ Android ไปพักใหญ่ ถ้าจะสรุปสถานการณ์ตอนนี้ก็คือ
    เมื่อก่อน iOS ใช้ Swift ส่วน Android ใช้ Java
    ตอนนี้ Java ถูกแทนที่ด้วย Kotlin และมี cross-platform framework อย่าง Flutter หรือ React Native เกิดขึ้นมา
    Swift on Android เป็น ชั้น abstraction อีกชั้นแบบนี้หรือเปล่า หรือว่ามันใกล้เคียงเนทีฟมากกว่า
    สุดท้ายแล้วสิ่งที่เร็วที่สุดก็คือ native code ไม่ใช่หรือ?

    • React Native ไม่ได้อิง WebView มันเป็นชั้นแปลแบบเนทีฟที่ แปลง JSX เป็นโค้ด UI ของ SwiftUI/Kotlin
      ส่วนตัวผมชอบ Flutter มากกว่า นักพัฒนา Android แบบเนทีฟหลายคนก็บอกว่า Flutter อาจเป็น อนาคตของการพัฒนา Android
      ดูการถกเถียงที่เกี่ยวข้องได้ใน เธรด Reddit นี้
  • โปรเจ็กต์นี้เป็นแนวทางที่ต่างจาก SwiftCrossUI หรือ Skip
    SwiftCrossUI กับ Skip คือการรัน SwiftUI เดิมบนหลายแพลตฟอร์ม
    แต่ SwifDroid คือการ เขียน UI สำหรับ Android โดยเฉพาะด้วย Swift
    เป้าหมายคือสร้างแอป Android เต็มรูปแบบด้วย Swift โดยใช้ View system และ API ของ Android โดยตรง โดยไม่ต้องใช้ Java/Kotlin/XML
    นั่นคือไม่ใช่แนว "เขียนครั้งเดียว รันได้ทุกที่" แต่เป็นการ สร้างประสบการณ์ Android แบบเนทีฟด้วย Swift

  • อยากรู้ว่าวิธีที่เป็น idiomatic ใน Swift สำหรับจัดการ HTTP request และ parse JSON คืออะไร