ในเดือนกันยายนปีที่แล้ว ได้เปิดตัวการอัปเดตครั้งใหญ่ของ Proton Mail สำหรับ iOS และ Android
ภายนอกนั้น แอปใหม่มอบดีไซน์ที่ทันสมัย ประสิทธิภาพที่ดีขึ้น และความสามารถออฟไลน์ แต่ยังมีอะไรมากกว่าที่ตาเห็น เบื้องหลังนั้น แอปเหล่านี้เป็นการเขียนระบบของ Proton Mail ขึ้นมาใหม่ทั้งหมดบนสแตกเทคโนโลยีแบบใหม่ ซึ่งเป็นโครงการที่มีชื่อเรียกภายในว่า Engineering Transformation คำว่า ใหม่ นั้นเป็นความตั้งใจ เพราะเท่าที่ทราบ นี่เป็นครั้งแรกที่เทคโนโลยีที่เลือกได้ถูกนำมาใช้ในบริบทของแอปพลิเคชั่นสำหรับการใช้งานจริงที่มีอยู่แล้ว
บทความนี้มีจุดประสงค์เพื่อเผยให้เห็นการเดินทางอันน่าทึ่งที่ทีมงานได้ผ่านมาในการสร้างสรรค์การปฏิวัตินี้ และเพื่อตอบคำถามบางส่วนที่ชุมชนได้ถามเข้ามาตลอดเส้นทาง สิ่งสำคัญที่สุดคือ เหตุผลเบื้องหลังคือความจำเป็นในการเปลี่ยนแปลงสถานะที่เป็นอยู่
จุดเริ่มต้นของทั้งหมด
ความตระหนักที่ว่าสิ่งต่างๆ จำเป็นต้องเปลี่ยนเกิดขึ้นในเย็นวันศุกร์ของเดือนตุลาคม 2023 ซึ่งปรากฏขึ้นมาด้วยความชัดเจนอย่างน่าแปลกใจ แต่ไม่ได้เกิดขึ้นอย่างไร้เหตุผล: มันเป็นผลลัพธ์ของการใช้เวลาหลายเดือนในการพยายามหาจุดร่วมของปัญหาที่ดูเหมือนจะไม่เกี่ยวข้องกันซึ่งส่งผลกระทบต่อประสบการณ์ของผู้ใช้กับผลิตภัณฑ์มือถือ Mail และปฏิทิน
หากกล่าวแบบไม่ซับซ้อนเกินไป สามารถสรุปจุดที่เป็นปัญหาได้เป็นสามด้าน:
คุณภาพ: Mail iOS และ Mail Android หากพิจารณาแยกกัน ยังทำได้ต่ำกว่าความคาดหวังในแง่ของคุณภาพและประสิทธิภาพการทำงาน
ช่องว่างของคุณสมบัติระหว่าง iOS และ Android: คุณสมบัติบางประการมีให้บริการบนแพลตฟอร์มเดียวเท่านั้น โดยไม่มีความชัดเจนว่าอีกแพลตฟอร์มหนึ่งจะตามทันเมื่อใด
ความเร็วในการพัฒนาทางวิศวกรรม: การอัปเดตที่สำคัญและคุณสมบัติที่รอคอยมานานไม่ได้รับการส่งมอบอย่างทันท่วงทีในทั้งสองแพลตฟอร์ม
ปัญหาบางประการขยายวงกว้างไปไกลกว่าบนมือถือ และการตอบปัญหาเหล่านั้นจำเป็นต้องเบี่ยงเบนจากโดเมนเทคโนโลยีไปสู่ขอบเขตปัญหาที่น่าสนใจของการขยายขนาดองค์กร และโดยเฉพาะอย่างยิ่งสตาร์ทอัพด้านเทคโนโลยีที่เติบโตอย่างรวดเร็ว แต่ความเปราะบางของระบบนิเวศบนมือถือมีรากฐานมาจากเทคโนโลยีและสถาปัตยกรรมอย่างมาก
การขยายขนาดวิศวกรรมบนมือถือ
การขยายขนาดวิศวกรรมบนมือถือมาพร้อมกับความท้าทายเฉพาะตัวซึ่งแตกต่างอย่างมีนัยสำคัญจากการขยายขนาดทีมแบ็กเอนด์และเว็บ ความแตกต่างเหล่านี้เกิดขึ้นจากการกระจัดกระจายของแพลตฟอร์มและความเป็นจริงในการดำเนินงานของระบบนิเวศบนมือถือ โดยทั่วไปทีมมือถือจำเป็นต้องรองรับหลายแพลตฟอร์มในระบบปฏิบัติการและอุปกรณ์ต่างๆ (โทรศัพท์ แท็บเล็ต และบางครั้งก็เป็นอุปกรณ์สวมใส่) iOS และ Android มาพร้อมกับภาษาโปรแกรม เฟรมเวิร์ก และเครื่องมือของตนเอง ซึ่งนำไปสู่การทำงานซ้ำซ้อนจำนวนมาก: มีหลายทีม โค้ดเบสซ้ำซ้อน และต้องแลกเปลี่ยนระหว่างงานเฉพาะแพลตฟอร์มกับงานที่เกี่ยวข้องกับผลิตภัณฑ์อยู่ตลอดเวลา การดูแลให้ผลิตภัณฑ์ที่นำเสนอซิงค์กันนั้นต้องอาศัยการประสานงานอย่างมหาศาล
สิ่งที่ท้าทายสำหรับทั้งอุตสาหกรรมนั้นรุนแรงเป็นพิเศษสำหรับ Proton แอปที่มีฟังก์ชันการทำงานหลากหลายอย่าง Mail และปฏิทินมีความซับซ้อนมากกว่าแอปพลิเคชั่นบนมือถือส่วนใหญ่ในตลาดโดยธรรมชาติ เมื่อเพิ่มชั้นของลอจิกไคลเอนต์เพิ่มเติมที่จำเป็นในการจัดการการเข้ารหัสลับจากต้นทางถึงปลายทางเข้าไปด้วย ก็จะทำให้ได้ไคลเอนต์ที่ “หนา” เป็นพิเศษ ในอดีต ทีม Android ยุ่งอยู่กับการเขียน Mail ขึ้นมาใหม่เพื่อให้มีมาตรฐานคุณภาพที่ดีขึ้น ซึ่งเป็นเงินลงทุนที่ใช้เวลากว่า 18 เดือน นอกจากนี้ iOS ก็มีความจำเป็นอย่างยิ่งที่จะต้องปรับโครงสร้างใหม่ และยังไม่รวมถึงปฏิทิน ค่าใช้จ่ายในการทำงานซ้ำซ้อนนี้ได้กัดกินทรัพยากรวิศวกรรมไปทั้งหมด และเห็นได้ชัดว่าการทำแบบเดิมต่อไปจะไม่ทำให้ประสบความสำเร็จ
สิ่งที่ดีที่สุดเกี่ยวกับการยอมรับว่ากำลังติดขัดคือ มันจะทำหน้าที่เป็นปัจจัยบีบคั้นให้คิดนอกกรอบของสถานะที่เป็นอยู่ในปัจจุบัน จะทำอย่างไรหากสามารถเริ่มต้นใหม่ได้ โดยเป็นอิสระจากภาระของการตัดสินใจและข้อผูกมัดที่นำมาสู่จุดนี้? เมื่อพิจารณาอย่างใกล้ชิดว่าบริษัทที่ประสบความสำเร็จจัดการกับปัญหานี้อย่างไรในทศวรรษที่ผ่านมา ก็จะพบว่าบริษัทเหล่านั้นดำเนินตามกลยุทธ์ที่เป็นไปได้เพียงหนึ่งในสองทางเท่านั้น:
- แก้ปัญหาด้วยเงิน โดยการสร้างทีมที่ใหญ่ขึ้นเรื่อยๆ เนื่องจากต้นทุนการดำเนินงานที่สูงนั้นได้รับการชดเชยด้วยการลงทุนที่ไม่มีที่สิ้นสุดและ/หรือผลตอบแทนที่งดงาม แต่นี่ไม่ใช่ทางเลือกสำหรับรูปแบบธุรกิจที่ไม่มี VC ของ Proton: ไม่สามารถแข่งขันกับการใช้จ่ายของคู่แข่งที่ใช้โฆษณาและมีผู้ลงทุนสนับสนุนได้
- ออกแบบแอปใหม่เพื่อขจัดความสูญเสีย ซึ่งหมายถึงการสร้างแอปโดยใช้โค้ดเบสที่แชร์ร่วมกัน (มากที่สุดเท่าที่จะเป็นไปได้)
เมื่อทางเลือกที่ 1 ไม่สามารถเป็นไปได้ เส้นทางข้างหน้าจึงถูกกำหนดไว้แล้ว
หนทางสู่เป้าหมาย: การเลือกสแตกเทคโนโลยีที่เหมาะสม
ขั้นตอนต่อไปคือการเลือกสแตกเทคโนโลยีที่สามารถทำงานนี้ได้จริง
ในช่วง 15 ปีที่ผ่านมา การพัฒนาบนมือถือแบบข้ามแพลตฟอร์มเต็มไปด้วยโซลูชันแบบ “ครอบจักรวาล” เช่น HTML5, Xamarin, React Native, Flutter, Kotlin Multiplatform และอื่นๆ อีกมากมาย แต่ละโซลูชันมาพร้อมกับคำสัญญาเดียวกัน นั่นคือการแทนที่การพัฒนาแบบเนทีฟโดยสิ้นเชิง ในทางปฏิบัติ โซลูชันส่วนใหญ่มักจะล้มเหลวโดยสิ้นเชิงหรือไม่ก็ประสบความสำเร็จเฉพาะในขอบเขตปัญหาที่จำกัดอย่างมาก ไม่มีสิ่งที่เป็นนามธรรมสากลใดที่จะทำให้ความแตกต่างของแพลตฟอร์มหมดไปได้ ใครก็ตามที่เคยส่งมอบและบำรุงรักษาแอปพลิเคชั่นบนมือถือขนาดใหญ่ย่อมรู้ดีในเรื่องนี้ หนทางข้างหน้าที่น่าเชื่อถือเพียงอย่างเดียวคือการทำงานย้อนกลับจากความต้องการที่เป็นรูปธรรม แทนที่จะก้าวไปข้างหน้าตามกระแสเครื่องมือ
เป้าหมายสุดท้ายนั้นถูกแปลงเป็นชุดข้อกำหนดที่ต่อรองไม่ได้ (1) ซึ่งโซลูชันใดๆ ที่เลือกจะต้องตอบสนอง และใช้ข้อกำหนดเหล่านั้นเป็นกรอบการทำงานในการประเมินตลอดกระบวนการ:
- ต้นทุนและระยะเวลา: สแตกนี้ต้องลดต้นทุนและเวลาที่จำเป็นในการส่งมอบ บำรุงรักษา และพัฒนา Proton Mail ทั้งบน iOS และ Android ได้อย่างเป็นรูปธรรม
- ประสบการณ์ของผู้ใช้: ต้องรักษาประสิทธิภาพและคุณภาพการตอบสนองที่ใกล้เคียงกับแบบเนทีฟ หากทำไม่ได้ตามนี้ก็ถือว่าไม่สามารถยอมรับได้ตั้งแต่เริ่มต้น
- การเตรียมพร้อมรับอนาคตในเชิงกลยุทธ์: โซลูชันนี้ต้องมีอายุการใช้งานที่ยาวนาน มีความตั้งใจที่จะหลีกเลี่ยงเฟรมเวิร์กของบุคคลที่สามซึ่งจะทำให้แผนงานต้องพึ่งพาการสนับสนุนอย่างต่อเนื่องของซัพพลายเออร์รายอื่น
ความตึงเครียดระหว่างข้อจำกัดสองประการแรกคือจอกศักดิ์สิทธิ์ของอุตสาหกรรมนี้: “โซลูชันข้ามแพลตฟอร์มที่มอบประสิทธิภาพและประสบการณ์ของผู้ใช้ในระดับเดียวกับแอปพลิเคชั่นแบบเนทีฟ”
มีความคลางแคลงใจตั้งแต่แรกว่า React Native หรือ Flutter — ซึ่งเป็นสองเฟรมเวิร์กข้ามแพลตฟอร์มที่ได้รับความนิยมอย่างมากในขณะนั้น — จะสามารถตอบสนองเกณฑ์นี้ได้ แต่ถึงอย่างนั้น ก็ได้ทำการตรวจสอบความคลางแคลงใจนั้นโดยการสร้างการพิสูจน์แนวคิดสำหรับมุมมองรายการข้อความของ Mail
React Native แสดงให้เห็นถึงข้อจำกัดอย่างรวดเร็ว การเลื่อนดูชุดข้อมูลขนาดใหญ่ทำให้เห็นต้นทุนของโมเดลการประมวลผลแบบอินเตอร์พรีตได้อย่างชัดเจนจนน่าตกใจ Flutter ทำงานได้ดีกว่า แต่ UI ยังคงดูไม่เป็นแบบเนทีฟอย่างเห็นได้ชัด โดยเฉพาะบน iOS ที่สำคัญกว่านั้นคือ Flutter เป็นเฟรมเวิร์กที่เป็นกรรมสิทธิ์ซึ่งควบคุมโดย Google ซึ่งมี ประวัติ(หน้าต่างใหม่) ในการละทิ้งเทคโนโลยีที่พัฒนาขึ้นเอง และเพิ่งเลิกจ้างทีมงาน Flutter ไปเป็นจำนวนมาก สำหรับผลิตภัณฑ์ที่มีการรับประกันความปลอดภัยและความน่าเชื่อถือในระยะยาว การพึ่งพาภายนอกในระดับนั้นเป็นสิ่งที่ไม่สามารถยอมรับได้
Kotlin Multiplatform เป็นตัวเลือกถัดไป ถือเป็นตัวเลือกที่น่าสนใจ โดยเฉพาะอย่างยิ่งสำหรับองค์กรที่มีความเชี่ยวชาญด้าน Android เป็นอย่างดี แต่ท้ายที่สุดแล้วยังไม่ตอบโจทย์การใช้งาน การไม่มีเลเยอร์ UI ที่แชร์ร่วมกัน คำถามเกี่ยวกับความสมบูรณ์ของระบบ และภาระการทำงานเพิ่มเติมที่เกิดจากโมเดลการประมวลผลนั้นมีน้ำหนักมากกว่าประโยชน์ที่จะได้รับ
ณ จุดนี้ ข้อสรุปนั้นชัดเจนและสอดคล้องกับสัญชาตญาณในตอนแรก นั่นคือ สถาปัตยกรรมเดียวที่ทำให้เข้าใกล้ผลลัพธ์ที่ต้องการได้อย่างสม่ำเสมอคือสแต็กแบบผสมผสานอย่างตั้งใจ UI แบบเนทีฟในแต่ละแพลตฟอร์ม – Jetpack Compose บน Android, SwiftUI บน iOS – โดยมีเลเยอร์บิสเนสโลจิกที่แชร์ร่วมกันซึ่งเขียนด้วยภาษาระดับต่ำที่มีประสิทธิภาพสูง วิธีการนี้มีประวัติการใช้งานที่พิสูจน์แล้ว เช่น Dropbox เคยใช้ C++ เพื่อแชร์บิสเนสโลจิกในแพลตฟอร์มมือถือต่างๆ ก่อนที่จะเลิกใช้ไปในปี 2019 เนื่องจากต้นทุนการดำเนินงานและความซับซ้อนของภาษา
ภายในสิ้นปี 2023 Rust ได้ก้าวขึ้นมาเป็นผู้สืบทอดในตระกูลภาษาการเขียนโปรแกรมระบบอย่างชัดเจน
Rust มีประสิทธิภาพในระดับเดียวกับ C++ แต่ไม่มีข้อบกพร่องเดิมๆ หลายประการ โดยให้การรับประกันความปลอดภัยของหน่วยความจำที่แข็งแกร่งโดยไม่ต้องมีระบบเก็บขยะ บังคับใช้ความปลอดภัยในการทำงานพร้อมกันของเธรดในขณะคอมไพล์ และได้รับการสนับสนุนจากระบบนิเวศโอเพนซอร์สขนาดใหญ่ที่มีความสามารถสูง ที่สำคัญไม่แพ้กันคือ Rust ทำงานร่วมกับภาษามือถือแบบเนทีฟได้อย่างราบรื่น เช่น Swift และ SwiftUI บน iOS, Kotlin และ Jetpack Compose บน Android ทำให้เป็นตัวเลือกที่ใช้งานได้จริงสำหรับการแชร์โลจิกหลักโดยไม่ทำให้เลเยอร์ UI ถูกโจมตี
นี่ไม่ใช่การตัดสินใจที่ไม่มีความเสี่ยง ในขณะนั้น มีตัวอย่างแอปพลิเคชั่นมือถือสำหรับผู้บริโภคขนาดใหญ่ที่สร้างขึ้นบนสถาปัตยกรรมที่เน้น Rust เป็นศูนย์กลางเพียงไม่กี่ราย และประสบการณ์การใช้งาน Rust ภายในทีมก็ยังมีจำกัด
แต่นวัตกรรมที่มีความหมายนั้นไม่ค่อยเกิดขึ้นในขอบเขตที่มีความเสี่ยงต่ำ ความท้าทายที่แท้จริงไม่ใช่ตัว Rust เอง แต่เป็นความเฉื่อยขององค์กร ซึ่งก็คือการเปลี่ยนจากแนวทางเดิมๆ ที่ได้รับการพิสูจน์แล้วไปสู่การทดลองอย่างตั้งใจ โดยได้รับคำแนะนำจากข้อจำกัดที่ชัดเจนและการตัดสินใจทางวิศวกรรม
Proton Mail ใหม่: ผลลัพธ์และสิ่งที่ได้เรียนรู้
ข้ามมาดูในปัจจุบันและมาดูกันว่าการตัดสินใจที่ท้าทายนี้ให้ผลลัพธ์อย่างไร
แผนภาพด้านล่างแสดงสถาปัตยกรรมของ Mail บนมือถือ แกนหลักของ Rust มีหน้าที่รับผิดชอบบิสเนสโลจิกทั้งหมดของแอปพลิเคชั่น มีการผลักดันการใช้ Rust ให้เกินกว่าการใช้งานทั่วไป (ระบบเครือข่าย พื้นที่จัดเก็บ การคำนวณอัลกอริทึม) ไปจนถึงการจัดการโลจิกการนำทางที่ซับซ้อน ตัวอย่างที่ชัดเจนคือโลจิกที่ควบคุมการเลื่อนดูรายการข้อความอย่างไม่มีสิ้นสุด แม้จะดูไม่ปกติ แต่สิ่งนี้ได้รับการพิสูจน์แล้วว่าเป็นกุญแจสำคัญในการบรรลุเป้าหมายเพื่อขยายการใช้รหัสซ้ำให้ใหญ่ที่สุด ส่งผลให้ปัจจุบันมีการแชร์ฐานรหัสเกือบ 80% ร่วมกันระหว่าง iOS และ Android
สิ่งนี้ช่วยให้การนำผลิตภัณฑ์ออกสู่ตลาดรวดเร็วขึ้นและมีคุณภาพสูงขึ้นหรือไม่ แม้ว่าจะยังเร็วเกินไปที่จะสรุปในขั้นสุดท้าย แต่สัญญาณเริ่มต้นก็เป็นไปในทิศทางที่ดีอย่างยิ่ง:
- ในช่วงสองเดือนหลังจากการเปิดตัว ทีมงานสามารถจัดการอัปเดตคุณสมบัติรายสัปดาห์ในทั้งสองแพลตฟอร์มได้สำเร็จ (รวมทั้งหมด 12 การเปิดตัวคุณสมบัติ)
- มีการปิดช่องว่างของคุณสมบัติระหว่างแพลตฟอร์มต่างๆ โดยนำคุณสมบัติที่รอคอยมานานมาสู่ Android เช่น การปิดเสียงเตือนชั่วคราว การตอบรับคำเชิญในปฏิทิน และการปัดเพื่อไปยังข้อความถัดไป
- แม้จะอยู่ในช่วงเริ่มต้น แต่ฐานรหัสใหม่นี้ได้รับการพิสูจน์แล้วว่ามีเสถียรภาพมากกว่ารุ่นก่อนๆ ในทั้งสองแพลตฟอร์ม โดยอัตราการขัดข้อง of iOS อยู่ที่ 0.05% (ลดลงจาก 0.12%) ในขณะที่ของ Android กลับสู่เกณฑ์มาตรฐานเดิม (0.19%) นี่คือการรับรองที่แข็งแกร่งถึงเสถียรภาพของรันไทม์ของ Rust
ฝ่ายสนับสนุนยังสามารถปรับขยายขนาดได้อย่างมีประสิทธิภาพมากขึ้นภายใต้แนวทางนี้ การระบุและแก้ไขสาเหตุหลักที่แชร์ร่วมกันเพียงจุดเดียวนั้นมักจะรวดเร็วกว่าการตามแก้ไขปัญหาที่ดูคล้ายกันซึ่งเกิดจากข้อบกพร่องทางโลจิกที่แตกต่างกันเล็กน้อยซึ่งกระจายอยู่ในฐานรหัสอิสระสองชุด ได้พบการยืนยันเชิงประจักษ์ของสมมติฐานที่เคยตั้งไว้ในขณะที่แก้ไขปัญหากลุ่มการซิงโครไนซ์หมวดหมู่ที่ส่งผลต่อโลจิกซึ่งสนับสนุนความสามารถแบบออฟไลน์ของแอป นั่นคือ หนึ่งสาเหตุหลัก หนึ่งวิธีแก้ไขปัญหา ดังที่แสดงในแผนภาพด้านบนโดยโมดูล Rebasing ที่มาพร้อมกับเวอร์ชัน 7.6.2
อีกด้านหนึ่งของเหรียญล่ะ?
- บั๊กและข้อบกพร่องที่เกิดขึ้นใหม่มีแนวโน้มที่จะส่งผลกระทบในวงกว้างและส่งผลกระทบต่อผู้ใช้ในทั้งสองแพลตฟอร์ม ไม่สามารถได้ทุกอย่างที่ต้องการ แต่สามารถลดความเสี่ยงลงได้อย่างแน่นอนโดยการเน้นที่การทดสอบจากต้นทางถึงปลายทางให้มากขึ้น
- เช่นเดียวกับการแบ่งส่วนโซลูชันสำหรับผู้ใช้ตามแนวขวางของเทคโนโลยี มีความเสี่ยงที่จะเกิดการเก็บข้อมูลความรู้แยกส่วนและสูญเสียการมุ่งเน้นทางวิศวกรรมในส่วนของประสบการณ์ผู้ใช้จากต้นทางถึงปลายทาง จำเป็นต้องตระหนักถึงสิ่งนี้และตั้งใจลดความเสี่ยงดังกล่าว มาตรการที่มีประสิทธิภาพมากที่สุด ได้แก่:
- ปรับแนวทางการทำงานของทีมย่อยเพื่อส่งมอบคุณสมบัติต่างๆ แทนที่จะเป็นเลเยอร์เทคโนโลยี
- ฝึกอบรมวิศวกรมือถือให้กลายเป็น “ฟูลสแต็ก” นั่นคือสามารถดีบั๊ก สนับสนุน และสร้างสรรค์งานวิศวกรรมได้ทั้งในส่วนของฐานรหัส Rust และแพลตฟอร์มเนทีฟ.
ขั้นตอนต่อไปสำหรับการเปลี่ยนแปลงทางวิศวกรรม
ตั้งแต่เริ่มแรกของโครงการนี้ เป็นที่ชัดเจนว่าการเดิมพันครั้งนี้ขยายวงกว้างไปไกลกว่า Proton Mail เพียงอย่างเดียว การนำสแต็กเทคโนโลยีนี้ไปใช้กับแอปพลิเคชั่นหลักของ Proton ได้สำเร็จนั้นตั้งใจให้เป็นขั้นตอนแรกของการเดินทางที่ยาวนานขึ้น ซึ่งท้ายที่สุดแล้วจะเห็นแนวทางนี้ถูกนำไปใช้กับระบบนิเวศบนมือถือที่เหลือทั้งหมด
สถานการณ์นั้นกำลังเกิดขึ้นในขณะนี้ ในขณะที่เขียนบทความนี้ SDK บัญชีและการชำระเงิน ตลอดจนแอปบนมือถือ Proton Calendar รุ่นถัดไป กำลังถูกเขียนขึ้นใหม่เพื่อให้สอดคล้องกับทิศทางทางเทคนิคใหม่นี้
สิ่งนี้ทำเครื่องหมายถึงจุดเริ่มต้นของคลื่นลูกที่สองของการเปลี่ยนผ่านทางวิศวกรรม—วิวัฒนาการที่ขยายพิมพ์เขียวทางเทคโนโลยีด้วยกรอบสถาปัตยกรรมที่ออกแบบมาเพื่อให้สามารถนำส่วนประกอบกลับมาใช้ใหม่ได้ง่ายขึ้น ไม่เพียงแต่ในทุกแพลตฟอร์มเท่านั้นแต่ยังรวมถึงในทุกผลิตภัณฑ์ด้วย แม้ว่าการเปลี่ยนผ่านนี้จะไม่เกิดขึ้นในชั่วข้ามคืน แต่ก็เป็นพื้นฐานสำคัญในการสร้างระบบนิเวศที่เน้นความเป็นส่วนตัวเป็นหลักและผสานรวมกันอย่างราบรื่นตามที่ลูกค้าคาดหวังให้ Proton เป็น
(1): Simon Lewis,“กลยุทธ์สำหรับการปรับใช้แอปพลิเคชั่นบนหลายแพลตฟอร์ม”, 2023.
