ญี่ปุ่น: Apple ต้องยกเลิกการแบนเอนจินเบราว์เซอร์ภายในเดือนธันวาคม

 (open-web-advocacy.org)
10 คะแนน โดย GN⁺ 2025-08-07 | 7 ความคิดเห็น | แชร์ทาง WhatsApp
  • รัฐบาลญี่ปุ่นเพิ่งผ่าน กฎหมายสมาร์ตโฟน ที่ห้ามโดยตรงไม่ให้ Apple แบนเอนจินเบราว์เซอร์ของบุคคลที่สาม บน iOS
  • ที่ผ่านมา การ บังคับใช้เอนจิน WebKit ทำให้การแข่งขันของเบราว์เซอร์บน iOS ถูกปิดกั้นโดยพฤตินัย และลดความสามารถในการแข่งขันของเว็บแอป
  • แนวทางใหม่ระบุชัดว่า Apple จะไม่สามารถสร้าง อุปสรรคที่ไม่สมจริงในทางเทคนิคหรือเชิงพาณิชย์ ได้
  • นอกจากนี้ ยังต้องรับประกัน สิทธิ์การเข้าถึง OS API สำหรับเบราว์เซอร์ ให้เท่าเทียมกันในเชิงการใช้งาน และห้ามลดประสิทธิภาพแบบเลือกปฏิบัติ
  • การบังคับใช้กฎหมายญี่ปุ่นกำลังสร้างสภาพแวดล้อมด้านกฎระเบียบร่วมกับ EU และสหราชอาณาจักรเพื่อ ฟื้นฟูการแข่งขันของเบราว์เซอร์ และคาดว่า 2026 จะเป็นจุดเปลี่ยนสำคัญ

ญี่ปุ่นเรียกร้องให้ Apple ยกเลิกการแบนเอนจินเบราว์เซอร์

ญี่ปุ่นได้ผ่านกฎหมาย ‘กฎหมายส่งเสริมการแข่งขันซอฟต์แวร์สมาร์ตโฟน’ อย่างเป็นทางการเมื่อไม่นานมานี้ และเดินหน้ามาตรการที่ห้ามโดยตรงต่อนโยบายระยะยาวของ Apple ที่ห้ามใช้เอนจินเบราว์เซอร์ของบุคคลที่สามบน iOS

สถานะของการแบนเอนจินเบราว์เซอร์

  • เดิม Apple อนุญาตให้ใช้ได้เฉพาะ เอนจิน WebKit เท่านั้น ส่งผลให้ เอนจินเบราว์เซอร์หลักทั้งหมด เช่น Firefox, Chrome, Edge, Opera, Brave และ Vivaldi ถูกกันออกจาก iOS โดยพฤตินัย
  • เรื่องนี้ทำให้ การแข่งขันของเบราว์เซอร์ถูกปิดกั้น อย่างแท้จริง และทำให้เว็บแอปไม่สามารถใช้ API หรือประสิทธิภาพที่จำเป็นต่อการแข่งกับแอปเนทีฟได้อย่างเท่าเทียม

การออกกฎหมายและแนวทางของญี่ปุ่น

  • กฎหมายฉบับนี้ถูกวางแผนขึ้นจากรายงานของ สำนักงานใหญ่การแข่งขันตลาดดิจิทัล และยังสะท้อนคำแนะนำจาก Open Web Advocacy
  • ล่าสุดมีการเผยแพร่ แนวทางกฎหมายการแข่งขันซอฟต์แวร์บนมือถือ (MSCA) ซึ่งชี้แจงการตีความและแนวทางบังคับใช้กฎหมายอย่างชัดเจน
โฆษณา

การห้ามขัดขวางเอนจินเบราว์เซอร์ทางเลือก

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

ความเท่าเทียมเชิงการใช้งานของการเข้าถึง OS API

  • MSCA กำหนดให้ต้องรับประกัน การเข้าถึงที่เท่าเทียมกันในเชิงการใช้งาน สำหรับสิทธิ์การเข้าถึง OS API
  • แม้อนุญาตให้มีการจัดหา API ทางเลือกได้ แต่หากมี ประสิทธิภาพด้อยกว่าอย่างมีนัยสำคัญในทางปฏิบัติ ก็จะไม่ถือว่าเท่าเทียมกันในเชิงการใช้งาน
    • กล่าวคือ แม้วิธีทางเทคนิคจะแตกต่างกัน เบราว์เซอร์ของบุคคลที่สามก็ต้องได้รับ ประสิทธิภาพและการเข้าถึงในระดับเท่าเทียมกัน กับที่ Apple หรือผู้ให้บริการที่ถูกกำหนดได้รับ
โฆษณา

หน้าที่ต้องมีหน้าจอเลือกเบราว์เซอร์ (Choice Screen)

  • กฎหมายกำหนดให้เบราว์เซอร์ (รวมถึงซอฟต์แวร์อื่น ๆ) ต้องมี หน้าจอเลือก (Choice Screen)
  • เป็นแนวทางที่เข้มกว่าของ EU โดยต้องแสดงหน้าจอเลือกทันที หลังการเปิดใช้งานครั้งแรก
    • กล่าวคือ ระหว่างการตั้งค่าสมาร์ตโฟนครั้งแรก หรือเมื่อเปิดแอปนั้นเป็นครั้งแรก ต้องให้ผู้ใช้ เลือกซอฟต์แวร์ที่ต้องการ

แนวโน้มต่อจากนี้

  • กฎหมายการแข่งขันซอฟต์แวร์บนมือถือมีกำหนด มีผลบังคับใช้ในเดือนธันวาคม 2025
  • ญี่ปุ่นจะเข้าร่วมกับ EU และสหราชอาณาจักรในฐานะเขตอำนาจที่ Apple ต้องอนุญาตเอนจินเบราว์เซอร์ของบุคคลที่สาม
  • คาดว่าญี่ปุ่นจะอ้างอิงประสบการณ์การกำกับดูแลของยุโรปและสหราชอาณาจักรเพื่อเตรียมการบังคับใช้
  • ดังที่เห็นจากกรณีของ EU และสหราชอาณาจักร การบังคับใช้ในทางปฏิบัติ น่าจะเป็นกระบวนการระยะยาวและซับซ้อน

บทสรุปและนัยสำคัญ

  • ญี่ปุ่น EU และสหราชอาณาจักรต่างกำลังผลักดันการฟื้นฟูการแข่งขันของเบราว์เซอร์บน iOS อย่างแท้จริง ผ่านการบังคับให้ Apple รองรับเอนจินเบราว์เซอร์ของบุคคลที่สาม
  • ปี 2026 อาจเป็นจุดเปลี่ยนของ โครงสร้างตลาดเบราว์เซอร์
  • ความสำเร็จหรือความล้มเหลวในท้ายที่สุดขึ้นอยู่กับความตั้งใจบังคับใช้ของหน่วยงานกำกับดูแล และความพยายามปรับปรุงอย่างเป็นรูปธรรมของ Apple
  • บทบาทของรัฐบาลญี่ปุ่นและองค์กรที่เกี่ยวข้อง ซึ่งทุ่มเทมายาวนานเพื่อปรับปรุงสภาพแวดล้อมการแข่งขันของเบราว์เซอร์และเว็บแอป ได้รับการเน้นย้ำ

บทความที่เกี่ยวข้อง

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

 
galadbran 2025-08-09

อืม... สำหรับผม วิธีที่ฟังก์ชันการท่องเว็บทั้งหมดต้องผ่านไลบรารีพื้นฐานนั้นทำให้เมื่อระบบบล็อก URL ใด URL หนึ่ง ก็จะได้ความสอดคล้องที่ดีแบบไม่สามารถหลบเลี่ยงได้ในฟังก์ชันการท่องเว็บภายในของทุกแอป เลยรู้สึกเสียดายนิดหน่อยนะครับ
 
tensun 2025-08-08

คาดว่าเบราว์เซอร์ AI จะมาแรง
 
prunusnira 2025-08-07

จากมุมมองของนักพัฒนา ก็คงหมายความว่าจะมีสภาพแวดล้อมที่ต้องพิจารณาเพิ่มขึ้นอีกสินะ 555..
 
ndrgrd 2025-08-08

ตอนนี้ก็ควรพัฒนาตามมาตรฐานเว็บกันได้แล้ว ฟีเจอร์ที่ไม่มีอยู่ก็อย่าไปใช้อย่างแข็งขันนัก
 
aqqnucs 2025-08-07

ดูเหมือนจะมีหลายตัว แต่สุดท้ายก็เป็นแค่ Firefox กับเอนจิน Chromium ไม่ใช่เหรอ
 
kwj9211 2025-08-07

แค่ดูรายชื่อเอนจินที่ถูกพูดถึงในสถานะการแบนก็มึนแล้ว @_@
 
GN⁺ 2025-08-07
ความเห็นบน Hacker News

  • ทุกคนพูดถึง Chrome กัน แต่ฉันปิด Chrome บน Android แล้วใช้ Firefox อยู่ ถ้าใส่ uBlock Origin บน Firefox มือถือ ประสบการณ์ใช้งานเว็บก็แทบจะเหมือนเดสก์ท็อปเลย ไม่ใช่แค่บล็อกโฆษณา แต่ยังใช้กฎ RegEx อย่าง :has-text เพื่อบล็อกองค์ประกอบที่ฉันไม่สนใจได้ทันทีด้วย ตอนนี้ Chrome ทำแบบนั้นไม่ได้แล้วแม้แต่บนเดสก์ท็อป ฉันถึงขั้นกำลังคิดจะย้ายไปใช้ Android เป็นอุปกรณ์หลักเลยด้วยซ้ำ แต่ความสะดวกที่ตอบแชตจาก MacBook ได้ทันทีเพราะ iMessage มันมีค่ามาก เลยตัดใจได้ไม่ง่าย นอกเหนือจากนั้น Android ดีกว่าโดยรวมมาก เรื่องคีย์บอร์ด iOS หรือ Siri นี่ไม่ต้องพูดถึงเลย

    • คู่ FF + uBO นี่แหละคือแอปนักฆ่าที่ทำให้ฉันยังอยู่กับ Android ถ้า Apple ยอมให้ใช้สิ่งนี้ได้ ฉันคงย้ายไปนานแล้ว เคยลองคิดเรื่อง messages.google.com ไหม? ต้องใช้แอป Messages ของ Google (ไม่ใช่ Samsung Messages) แล้วจะใช้ SMS กับ RCS บนเดสก์ท็อปได้ ถือว่าแทน iMessage ได้ดีเลย

    • ส่วนขยาย consent-o-matic บน Firefox มือถือก็น่าใช้มาก มันกดผ่านแบนเนอร์คุกกี้ให้อัตโนมัติแทบทั้งหมด ทำให้ไม่ต้องมานั่งจัดการทีละอันบนมือถือ สะดวกขึ้นเยอะ

    • ฉันก็ใช้ https://messages.google.com เพื่อทำสภาพแวดล้อมแบบ iMessage บนเดสก์ท็อปที่อิง Android เหมือนกัน ไม่แน่ว่าอาจเหมาะกับการใช้งานของคุณก็ได้ แค่ฉันไม่ได้ใช้ iMessage เลยอาจไม่รู้ทั้งหมด

    • ถ้าไม่ต้องการ iMessage และใช้แค่ SMS ได้ KDE Connect ก็ทำเดสก์ท็อปเมสเสจจิงจาก Android ได้ยอดเยี่ยมมาก (ใช้ได้บน Linux, Windows, MacOS แม้ฟีเจอร์ในแต่ละแพลตฟอร์มจะต่างกันบ้าง แต่รองรับ SMS ทั้งหมด) https://kdeconnect.kde.org/

  • ดูเหมือนญี่ปุ่นจะได้บทเรียนจากกรณีที่ Apple แสดงการ "ปฏิบัติตามกฎแบบเล่นลิ้น" ใน EU ถ้าออกมาในรูปนี้จริง ก็หวังว่า Apple จะโดนค่าปรับแบบเจ็บจริงในญี่ปุ่นด้วย ฉันคิดว่าไม่ใช่ "if" แต่เป็น "when"

    • ฉันนึกภาพถึงขั้นสั่งห้ามขายและนำเข้าเลย แล้วก็สงสัยว่า Apple จะต้องปิด Apple Store นานแค่ไหนถึงจะยอมคุกเข่า

    • ฉันชอบ walled garden ที่ช่วยกันฉันไม่ให้พลาดทำอะไรผิดพลาดเอง ขอบคุณ Apple ที่ไม่ส่งพิกัดของฉันไปมั่ว ๆ หรือปล่อยให้ Monarch แปลก ๆ มาติดตามฉัน เลยกังวลเรื่องข้อมูลส่วนตัวรั่วไหลน้อยลง (+4500 upvotes) บน Reddit ฉันสงสัยมาตลอดว่าพาดหัวต่อต้าน Apple ได้ +3 หมื่นอัปโหวต แต่คอมเมนต์ฝั่งสนับสนุน Apple กลับมีน้อยกว่ามาก บางทีก็คิดว่าทีมการตลาดหรือฟาร์มโทรลล์อาจเข้ามาจัดการภาพลักษณ์

  • ถ้าความเคลื่อนไหวด้านกฎหมายทั่วโลกนี้นำไปสู่ระบบนิเวศแอปที่เปิดกว้างขึ้นบน iOS ก็น่ายินดีมาก BrowserEngineKit ก็เป็นแค่ตัวห่อบาง ๆ ของ XPC กับระบบส่วนขยายของ iOS เท่านั้นเอง ถ้า XPC เป็น API แบบเปิด และถ้า Apple อนุญาตให้ใช้ JIT ใน subprocess ที่แยก sandbox ได้โดยไม่ต้องขออนุญาต Apple การพัฒนาคงดีขึ้นมาก เช่น แอปแชตสามารถมี subprocess แยกสำหรับจัดการข้อมูลนำเข้าที่ไม่น่าเชื่อถือได้ (iMessage ก็ทำแบบนี้อยู่แล้ว) สามารถแยกคอมโพเนนต์ที่ไม่เสถียรของแอปออกไปเพื่อให้การใช้งานและการกู้คืนจากแครชดีขึ้น ตัวจำลองระบบเก่าก็จะเร็วขึ้นมาก และทำให้ใช้ WASM บน iOS ได้ด้วย เบราว์เซอร์เองก็คงใช้ XPC ได้โดยไม่ต้องมี API เฉพาะทาง ปัญหาคือ ถ้าทำแบบนี้ได้ มันก็จะง่ายขึ้นมากที่จะโหลดโค้ดในแอปให้รันด้วยความเร็วระดับเนทีฟหลังผ่านการตรวจ App Store ไปแล้ว และอย่างที่ทุกคนรู้กัน ถ้าโลกแบบนั้นมาถึง มันคงเป็นหายนะ

    • ถ้า "หายนะ" นั้นมาถึง ฉันอยากดูผู้คนแตกตื่นกันบนเว็บอย่าง MacRumors จัง ยากจะเชื่อแบบไร้เดียงสาว่า Apple จะไม่สนับสนุนเว็บที่ช่วยผลักดัน narrative บนอินเทอร์เน็ตเพื่อผลประโยชน์ทางเศรษฐกิจของตัวเอง เช่น ความเห็นเหลวไหลทำนองว่าเสรีภาพในการใช้โทรศัพท์อย่างอิสระจะคุกคามความปลอดภัยและความเป็นส่วนตัวของทุกคนนั้น ถูกพูดซ้ำแทบตลอดเวลา

    • แบบนี้จะโยนภาระการป้องกันมัลแวร์ระดับระบบไปให้แอป sandbox มากขึ้นมาก จริง ๆ ตอนนี้ sandbox ก็เป็นเพียงหนึ่งในหลายชั้นป้องกัน เช่น notarization, permission, การตรวจแอป ฉันก็เห็นด้วยว่าผู้ใช้ควรติดตั้งแอปที่ตัวเองต้องการได้ แต่ก็ต้องยอมรับด้วยว่าถ้าทำแบบนี้ iPhone ทั่วไปจะเสี่ยงติดมัลแวร์ได้ง่ายขึ้นแบบ Android พื้นหลังของนโยบาย Apple แบบนี้ไม่ได้มีแค่ความอยากผูกขาด แต่ยังมีประเด็นด้านความปลอดภัยจริงอยู่ด้วย (แม้แรงขับหลักน่าจะเป็นเรื่องกำไรมากกว่า)

    • ตัวเบราว์เซอร์เองก็เป็นเหมือน app store อย่างหนึ่งอยู่แล้ว เพราะในทางปฏิบัติพวกเราก็รันแอปจากตรงนั้นตลอดโดยไม่ผ่านการตรวจของ Apple ดังนั้นในบริบทนี้ฉันเลยไม่ค่อยเข้าใจว่าทำไม Apple กับแฟน ๆ ถึงย้ำเรื่องความปลอดภัยของ App Store กันหนักมาก

    • ถ้าอนุญาต JIT ได้ มันไม่ได้จบแค่เรื่องอีมูเลเตอร์เร็วขึ้น แต่ยังมีประสิทธิภาพดีขึ้นเพราะไม่ต้องหมุนวนกับอินเทอร์พรีเตอร์ และอาจช่วยเรื่องอายุแบตเตอรี่หรือปัญหาเครื่องร้อนเวลาเล่นเกมปี 2008 บนมือถือได้ด้วย

    • (ละความเห็นที่ไม่มีสาระ)

  • ถ้าตีความคำว่า "ความเป็นไปได้ในการบล็อก" แบบกว้าง ๆ เช่น การล็อกภูมิภาคให้ "เอนจินเบราว์เซอร์ทางเลือกเปิดตัวได้เฉพาะกับบัญชี Apple ญี่ปุ่น" ก็อาจถูกมองว่าเป็นการขัดขวางการมีอยู่จริงของเบราว์เซอร์ทางเลือกโดยสาระสำคัญ Mozilla เองถ้าออกมาในรูปนั้น กลุ่มเป้าหมายก็คงเล็กเกินกว่าจะคุ้มพอร์ต Firefox มาลง iOS แม้โอกาสจะไม่สูง แต่บางทีนี่อาจเป็นจุดเริ่มต้นเล็ก ๆ ของเสรีภาพในการเลือกเบราว์เซอร์ระดับโลกก็ได้

    • การล็อกภูมิภาคให้ใช้เอนจินเบราว์เซอร์ทางเลือกได้เฉพาะบางบัญชี เป็นหนึ่งในสิ่งที่ Apple กำลังทำอยู่ใน EU

    • เท่าที่ฉันรู้ Gecko (เอนจินของ Firefox) ถูกพอร์ตมายัง iOS แล้ว

    • เดิมส่วนแบ่งตลาดก็น้อยอยู่แล้ว จะคุ้มพอร์ตเพื่อเพิ่มผู้ใช้มาอีกแค่น้อยนิดจริงหรือ

    • Mozilla เป็นองค์กรที่คุ้นเคยกับส่วนแบ่งตลาดน้อยอยู่แล้ว สถานการณ์แบบนี้ก็คงไม่ได้ต่างกันมากนัก แถมอาจกลายเป็นโอกาสปล่อยเวอร์ชัน QA ผ่านผู้ใช้ก่อนที่ตลาดจะเปิดเต็มที่ด้วย

  • ต่อจาก EU และ UK ตอนนี้ญี่ปุ่นก็มาปิดฉากการแบนเอนจินเบราว์เซอร์ทางเลือกบน iOS แล้ว ทั้งสามแห่งล้วนเป็นตลาดใหญ่ เลยสงสัยว่านี่จะมากพอให้ Chrome หรือ Firefox มีแรงจูงใจลงทุนทำเวอร์ชัน iOS ที่ใช้เอนจินของตัวเองจริง ๆ หรือไม่ (คือเบราว์เซอร์ที่อิง Blink และ Gecko) ก่อนหน้านี้มีข่าวลือเยอะว่าการพัฒนาล่าช้าเพราะเหตุนี้

    • เห็นจากไซต์เดียวกันว่า Apple ยังขัดขวางสารพัดไม่ให้ผู้ผลิตเบราว์เซอร์รายใหญ่ปล่อยเอนจินของตัวเองอยู่ บล็อกที่เกี่ยวข้อง

    • สำหรับ UK ฉันเข้าใจว่ารัฐบาลบังคับใช้กฎหมายที่เกี่ยวข้องอย่าง Digital Markets Act ปี 2024 แบบไม่ค่อยจริงจัง

    • ตามวัฒนธรรมญี่ปุ่น คนทั่วไปคงไม่ได้ใส่ใจกับการเปลี่ยนแปลงแบบนี้มากนัก ดูจากการใช้งาน Linux ในญี่ปุ่นก็ได้ ผู้ใช้สายฮาร์ดคอร์กลุ่มเล็ก ๆ จะใช้อะไรของเขาต่อไปไม่ว่ายังไง แต่คนส่วนใหญ่ก็แค่ใช้สิ่งที่สะดวก ไม่ค่อยชอบไปแกะระบบหรือปรับแต่งตั้งค่า

    • ก็มีมุมมองว่าเป็นเพราะ Apple ทำให้นักพัฒนาเบราว์เซอร์ลำบากมากจนไม่มีใครข้ามกำแพงนั้นได้

    • ฉันก็สงสัยว่า Firefox อาจเปลี่ยนไปใช้ Blink แล้วร่วมมือกับ Google เพื่อทำเอนจินทางเลือกบน iOS น่าจะเป็นทางเลือกที่สมจริงและง่ายกว่าไหม

  • ฉันสงสัยว่าการเปลี่ยนแปลงนี้จะดีจริงหรือเปล่า มันจะยิ่งเพิ่มส่วนแบ่งของ Chromium ในตลาดหรือไม่

    • Safari ไม่ใช่เบราว์เซอร์ที่ดีในเชิงโครงสร้าง เพราะผลประโยชน์ของ Apple ทำให้จงใจทำเว็บแพลตฟอร์มให้อ่อนแอ ถ้าไม่มีเบราว์เซอร์คู่แข่งที่แท้จริง ก็ไม่สามารถบังคับให้ผู้ใช้ใช้มันได้ การทำเบราว์เซอร์ที่ดีจริงจนผู้ใช้เลือกเองต่างหากคือการแข่งขันในตลาดที่แท้จริง

    • ก็จริง สุดท้าย Safari คือปราการสุดท้ายที่คอยยับยั้งไม่ให้เว็บบน iOS กลายเป็น "All Chrome Everywhere"

    • รัฐบาลอาจแก้ปัญหาการผูกขาดตลาดได้ คดี DOJ สหรัฐ vs Google ในวิกิ

    • ใช่ นั่นแหละที่ทำให้เรื่องนี้ซับซ้อน ด้านหนึ่งเราต้องทำให้ Apple เปิด iOS มากขึ้นให้ได้ แต่อีกด้านหนึ่งมันก็ยิ่งทำให้การผูกขาดของ Chrome แข็งแรงขึ้น

    • ข้อดีคือเราจะได้ใช้ Firefox แบบสมบูรณ์บน iOS และนี่เป็นการเปลี่ยนแปลงในทางบวก อิทธิพลที่ไม่สมควรของ Apple ในการบั่นทอนมาตรฐานเว็บเพื่อผลประโยชน์ของตัวเอง (เช่น ขัดขวางการรองรับ SPIR-V ใน WebGPU) ก็จะลดลง

  • (Narrator) หนึ่งปีต่อมา ส่วนแบ่ง Chrome ในญี่ปุ่นพุ่งถึง 100% และทุกเว็บไซต์ก็ถูกออกแบบมาเพื่อเบราว์เซอร์นี้เพียงตัวเดียว

    • คุณประเมินพลังของค่าตั้งต้นต่ำไปมาก ผู้ใช้ส่วนใหญ่แทบไม่เคยเปลี่ยนค่าพื้นฐานของระบบเลย

  • ญี่ปุ่นมีความสัมพันธ์กับ Apple แบบเฉพาะตัว ตัวอย่างเช่น ฟีเจอร์ตั๋วที่อิง FeliCa (ระบบ NFC แบบญี่ปุ่น) ถูกฝังมาใน iPhone ทุกเครื่อง ทำให้ผู้ใช้ iOS ทั่วโลกใช้ชีวิตในญี่ปุ่นได้สะดวกขึ้นมาก ที่น่าทึ่งกว่านั้นคือการใช้งานตั๋วจริงไม่ต้องมีแอปใด ๆ เลย แค่มี Apple Pay ก็พอ กระแสแบบนี้กำลังบีบให้จุดแข็งของแอปเนทีฟแคบลงเรื่อย ๆ (แม้ตอนนี้แอปเนทีฟยังมีข้อดีเฉพาะอยู่บ้าง) แต่อีกด้านหนึ่งก็ยากจะโต้แย้งข้อกล่าวหาว่า Apple แค่ย้าย "บทบาทผู้เฝ้าประตู" ไปยังพื้นที่อื่นในที่สุด

    • การรองรับเครือข่าย FeliCa เกิดขึ้นหลัก ๆ เพราะเทคโนโลยีขนส่งและการจ่ายเงินผ่านมือถือในญี่ปุ่นเกิดก่อน iPhone Mobile Suica กับ Osaifu-Keitai มีอยู่แล้ว ดังนั้นถ้า Apple อยากรักษาความสามารถในการแข่งขันก็จำเป็นต้องเร่งตามให้ทัน เริ่มจาก iPhone SKU เฉพาะญี่ปุ่น แล้วค่อยขยายไปทั่วโลก แม้แต่ตอนนี้ตลาดการจ่ายเงินผ่านมือถือในญี่ปุ่นก็ยังไม่ได้ถูกผูกขาด ถ้า Apple เจอแรงกดดันจากการแข่งขัน ก็จะมีการเปลี่ยนแปลง เช่น การเพิ่ม Express Transit แบบ Suica และแอปจ่ายเงินด้วย QR code สัญชาติญี่ปุ่นอย่าง PayPay ก็แพร่หลายกว่าการจ่ายด้วยบัตรเครดิตอีก

    • ส่วนแบ่ง iOS ในญี่ปุ่นสูงกว่าสหรัฐ (59%), UK (47%) และยุโรป (34%) โดยอยู่ที่ 64% ที่มา statcounter

    • FeliCa เป็นเรื่องของสิทธิการใช้งานสิทธิบัตร ดูเหมือน Apple จะได้สัญญาที่เอื้อประโยชน์จากที่ไหนสักแห่ง Google Pixel ก็มีชิปใส่มาครบทุกเครื่อง แต่ถ้าไม่ใช่รุ่นญี่ปุ่น ฟังก์ชันนี้จะถูกปิดด้วยซอฟต์แวร์ (รูตแล้วปลดได้)

  • พอมีประเทศหนึ่งทำสำเร็จ ก็ยิ่งเห็นพลังของ "อำนาจที่ทำได้จริง" สิ่งที่เคยบอกว่าทำไม่ได้มา 20 ปี ประเทศอื่นก็เริ่มเปลี่ยนเป็น "เราก็ทำได้ และจะตามไม่ทันไม่ได้"

    • แต่นั่นก็อาจน่ากลัวเหมือนกัน เช่น หลัง UK เริ่มใช้การยืนยันอายุด้วยบัตรประชาชนจริง หลายประเทศก็ออกกฎหมายเกี่ยวกับบัตรประชาชนที่รัฐออกให้ตามกันเป็นดอกเห็ด

  • ต้องตั้งสมมติฐานว่า Google เตรียมตัวมาอย่างต่อเนื่องเพื่อปล่อย Chrome "ของจริง" บน iOS ได้ทันที พวกเขาคงพัฒนามานานแล้วเพื่อรอจังหวะที่กฎหมายเปลี่ยนใช่ไหม

    • Google กำลังย้าย Blink (เอนจิน Chrome สำหรับ iOS) และมีความคืบหน้าแบบค่อยเป็นค่อยไป มีการติดตามไว้ใน Chromium bug tracker ลิงก์ติดตาม น่าจะเป็นเพราะนโยบายล็อกภูมิภาคของ Apple (EU geofencing) และข้อจำกัดหลายอย่างของ BrowserEngineKit เลยยังไม่ได้ทุ่มทรัพยากรเต็มที่สำหรับการเปิดใช้งานจริง

    • กุมภาพันธ์ 2023: “Google เริ่มทำ Chrome บน iOS ให้ใช้เอนจิน Blink แทน Apple WebKit” บทความที่เกี่ยวข้อง

    • (Blink คือเอนจินเรนเดอร์เว็บของ Chrome) ในเอกสารทางการสำหรับการบิลด์ Chromium/Chrome บน iOS มีคำอธิบายว่า blink web platform ยังอยู่ในสถานะทดลองและควรใช้เพื่อการวิเคราะห์เท่านั้น พร้อมระบุว่า target ที่เกี่ยวข้องอย่าง content_shell และ chrome มีประโยชน์ เอกสารบิลด์ทางการ