Rilis Safari adalah neraka bagi pengembang

Safari 16.4 diluncurkan minggu lalu, dan itu adalah mimpi buruk bagi kami. Kami sedang mengembangkan aplikasi berbasis browser untuk membuat game yang disebut Construct. Versi awal Safari 16.4 memecahkan pembukaan proyek, pratinjau proyek, dan semua konten yang diterbitkan dengan Konstruksi secara berbeda setiap saat. Saya ingin berbagi pengalaman saya sehingga pengguna, pengembang, regulator, dan Apple sendiri akan tahu apa yang harus kami lalui karena rilis Safari yang tampaknya rutin.

Pengembang sebagian besar browser menyediakan versi pra-rilis untuk pengujian awal. Misalnya, Chrome Canary dan Firefox Nightly diperbarui setiap hari, selain itu, ada rilis dev dan beta yang lebih jarang. Apple menyediakan Pratinjau Teknologi Safari (STP), tetapi hanya kompatibel dengan macOS, dan tidak diperbarui pada jadwal yang dipublikasikan secara publik. Tampaknya terjadi sekitar sekali setiap dua minggu. Browser pra-rilis biasanya cukup kasar dan mengandung masalah yang jelas yang cepat diperbaiki. Namun, ketika mereka mulai masuk ke versi beta, Anda perlu melihat lebih dekat. Jadi ketika Safari 16.16 beta 4 diumumkan pada 1 Februari (juga tanpa jadwal publik), kami mulai melihat lebih dekat dan menemukan banyak masalah.

Kegagalan pembukaan proyek

Proyek konstruksi disimpan dalam file zip; untuk membacanya, kami menggunakan pustaka zip.js populer, yang pada gilirannya menggunakan API Compression Streams (jika didukung). Safari 16.4 menambahkan dukungan untuk API Compression Streams, tetapi untuk beberapa alasan ternyata tidak kompatibel dengan zip.js, sehingga membuka proyek di Construct gagal. Secara potensial, ini berarti bahwa banyak kasus menggunakan zip.js di web juga rusak.

Saya sepatutnya menyerahkan masalah ini pada 17 Februari. Setelah membingungkan apakah masalah ini adalah duplikat dari yang lain (bukan), insinyur Apple mempelajari dan mengidentifikasi masalahnya, setelah itu mereka mengatakan bahwa itu akan diperbaiki pada 27 Februari. Pada akhirnya, bukan jawaban yang buruk, untuk kredit karyawan Apple.

Kemudian Safari Tech Preview 165 dirilis pada 8 Maret. Masih ada bug di dalamnya. Rilis Safari 16.4 tampak dekat, tetapi kami tidak tahu pasti karena garis waktunya tidak diketahui. Apa yang harus kita lakukan? Mereka membuat perubahan, tetapi masalahnya tetap ada? Atau apakah koreksi belum dilakukan? Tetapi mengapa mereka melakukan ini jika lebih dari seminggu telah berlalu sejak koreksi? Haruskah kita berasumsi bahwa Safari akan melepaskan utas kompresi yang rusak, dan merilis patch darurat untuk mengatasi masalah ini? Mereka tidak akan mengambil risiko merusak ritsleting.js untuk semua orang, bukan? Bahkan jika kami melakukannya, kami tidak tahu berapa banyak waktu yang tersisa. Haruskah kita tidak melakukan apa-apa dan berharap Safari 16.4 akan dirilis dengan perbaikan yang berfungsi? Tapi kemudian kita tidak akan tahu apakah bencana akan terjadi sampai versi browser diluncurkan. Ini dilema yang mengerikan.

Saya bertanya apakah perbaikan akan dirilis di Safari 16.4, tetapi insinyur memberi tahu saya tentang STP. Sayangnya, ini bukan jawaban untuk pertanyaan: tidak ada jaminan khusus bahwa apa yang ada di STP akan terbawa ke Safari 16.4.

Pada akhirnya, kami memutuskan untuk melihat apa yang akan datang dengan Safari 16.4. Perhatikan bahwa selama peristiwa yang dijelaskan dalam posting ini, kami tidak dapat membuka sebagian besar proyek di Construct. Juga perlu diingat bahwa satu-satunya cara untuk mengetahui apa yang sebenarnya akan dirilis dalam versi browser adalah dengan hanya menguji secara manual setiap rilis Safari, yaitu, kita harus menghabiskan waktu mencari tahu apa yang sudah diketahui Apple dengan pasti. Setelah beberapa minggu menunggu dengan menyakitkan, STP 166 dirilis pada 23 Maret, dan kemudian Safari 16.4 akhirnya diluncurkan pada 27 Maret. Hanya ada satu hari kerja di antara mereka. Apa yang bisa saya lakukan hari itu? Tidak ada: pada hari Jumat dan sisa minggu depan, saya berlibur. Saya tidak tahu kapan harus berlibur di waktu luang saya dari rilis Safari, karena tidak ada jadwal rilis publik. Oleh karena itu, saya pribadi dapat memeriksa apakah semuanya berfungsi hingga 3 April, seminggu penuh setelah rilis Safari 16.4 di seluruh dunia. Sampai saat ini, saya tidak dapat sepenuhnya yakin bahwa perangkat lunak kami akan berfungsi di Safari. Untungnya, itu berhasil. Ini juga bekerja di STP 166, meskipun informasi ini tidak terlalu berguna.

Semua kesulitan ini sebagian besar dapat dihindari jika Apple hanya menentukan untuk masalah versi yang diperbaiki, seperti yang dilakukan pengembang browser lainnya. Sedikit transparansi akan membuat perbedaan yang signifikan dalam perencanaan kami.

Pratinjau proyek rusak

Masalah berikutnya yang saya temukan adalah bahwa pratinjau desain di Construct hanya menunjukkan layar kosong. Ups! Ini juga masalah serius bagi kami. Saya mengirim masalah lagi. Insinyur Apple kembali membantu penelitian dan melakukan pekerjaan dengan baik. Saya akan menghilangkan detailnya karena sangat kompleks dan tidak terlalu relevan. Singkatnya, Service Worker penting untuk melihat pratinjau proyek di Construct, dan kami secara tidak sengaja mengeksploitasi bug Chrome yang menyebabkan Service Worker kami mogok di Safari 16.4. Artinya, dalam hal ini, Google sebenarnya yang harus disalahkan atas masalah tersebut (Google, tolong perbaiki), dan kami harus menyelesaikannya.

Dilema yang mengerikan muncul lagi, tetapi kali ini lebih buruk: tampaknya rilis Safari sudah dekat. Kali ini, kita pasti perlu menyelesaikan masalah. Berapa banyak waktu yang kita miliki? Ini pertanyaan penting. Kami memiliki jadwal rilis Construct kami sendiri dengan rilis beta untuk pengujian dan rilis stabil setiap beberapa bulan yang kami luncurkan untuk semua orang. Jika kami mengetahui tanggal rilis Safari, kami akan dapat membandingkan grafiknya. Jika Anda punya waktu, Anda dapat bersantai dan meluangkan waktu untuk menjelajah, dan perbaikan kami akan menjangkau pengguna sesuai dengan jadwal rilis biasa sebelum pembaruan Safari. Tetapi jika Safari dirilis keesokan harinya, ada keadaan darurat: Construct rusak dan kami harus memperbaikinya sebelum besok untuk menghindari ketidakpuasan pengguna! Inilah perbedaan antara bug rutin dan darurat.

Tentu saja, kami tidak tahu bahwa Safari tidak dijadwalkan untuk rilis pada hari berikutnya. Beberapa karyawan Apple mencoba memberi petunjuk kepada kami tentang jadwal yang jelas tidak dapat mereka ungkapkan, tetapi kami tidak bisa mendapatkan sesuatu yang lebih konkret daripada "segera." Oleh karena itu, kami terpaksa menganggap ini sebagai keadaan darurat dan bertindak sesuai dengan itu. Lebih buruk lagi, pengembangan Service Worker sangat kompleks, dan mereka memiliki berbagai kesulitan, membuat mereka lebih sulit untuk dikodekan. Jadi kami harus berhenti dari pekerjaan lain, melakukan kerja keras pada jadwal darurat, dan kemudian segera meluncurkannya ke semua pengguna, yang berisiko: bagaimana jika kami membuat kesalahan di suatu tempat dan merusak sesuatu yang lain?

Semua kekacauan ini bisa dihindari jika Apple hanya menerbitkan jadwal rilis, seperti yang dilakukan setiap pengembang browser. Sekali lagi, sejumlah kecil transparansi akan memungkinkan kita untuk menghindari banyak masalah. Untungnya, semuanya berjalan dengan baik dan kami tidak merusak apa pun, tetapi kami mengalami sakit kepala baru: Safari tampaknya menyimpan skrip Layanan lama secara berbeda dari browser lain. Saya tidak pernah tahu mengapa ini terjadi, tetapi itu menciptakan risiko kemunduran situasi yang serius.

Akhirnya, Safari 16.4 diluncurkan sekitar sebulan kemudian. Kita bisa bekerja dengan tenang. Tindakan darurat tidak perlu dan ternyata membuang-buang waktu.

Semua konten yang diterbitkan di Construct rusak

Di tengah-tengah semua ini, saya melewatkan masalah yang bahkan lebih serius. Ternyata di Safari 16.4, semua game web yang diterbitkan oleh Construct selama beberapa tahun terakhir rusak.

Masalahnya adalah bahwa Construct menggunakan OffscreenCanvas (jika tersedia) untuk menjalankan game di Web Worker untuk meningkatkan karakteristik kinerja. Safari 16.4 menambahkan dukungan untuk OffscreenCanvas, tetapi hanya konteks — masih belum ada dukungan untuk WebGL. Construct memerlukan WebGL untuk merender. Jadi dia melihat bahwa OffscreenCanvas didukung, membuat pekerja, membuat OffscreenCanvas, lalu mengambil WebGL untuk konteksnya, lalu macet dan pengguna melihat layar kosong. Faktanya, itu adalah masalah terbesar dari semuanya. Karena itu, seluruh volume konten web yang tersedia rusak. Kami merilis patch darurat kedua untuk diperbaiki (melalui semua kerumitan itu lagi), tetapi karena konten ini telah diterbitkan oleh pengguna kami di seluruh web selama beberapa tahun, hampir tidak mungkin untuk memperbaruinya. Ini mencakup ribuan game di situs-situs seperti itch.io, Newgrounds, Poki, dan kami sendiri; materi pelatihan yang digunakan oleh perusahaan; materi pendidikan yang digunakan oleh guru; kios interaktif di museum... dan sebagainya. Itu masih berpotensi bencana.

Kami terkejut. Kami mengenali OffscreenCanvas hanya dengan memeriksa untuk melihat apakah itu diatur (yaitu ). Saya tidak berharap browser dirilis dengan beberapa konteks, dan saya berasumsi bahwa itu akan sama dengan standar . Mengapa tidak? Dokumentasi MDN diam pada ketersediaan konteks yang tidak konsisten. Pada tahun 2018, Chrome merilis OffscreenCanvas dengan semua konteks. Pada tahun 2022, Firefox merilis OffscreenCanvas dengan semua konteks. Untuk pertama kalinya, browser telah merilis dukungan yang tidak konsisten untuk konteks.

Apple mengatakan bahwa ini jelas diizinkan oleh spesifikasi, dan bahwa fungsinya diakui secara tidak sengaja oleh pihak kami. Setelah membaca spesifikasi yang relevan, saya masih tidak bisa mengatakan, menjadi pengembang web dan bukan programmer browser, apakah jelas ini dapat diterima. Tapi katakanlah itu masalahnya, bagaimanapun juga, pengembang browser membutuhkan waktu lebih lama untuk mempelajari spesifikasinya daripada kebanyakan pengembang web.

Pertama, seperti yang saya pahami, tujuan spesifikasi adalah untuk menjaga kompatibilitas web: Prinsip Desain HTML mengatakan bahwa Anda perlu mempertahankan konten yang ada. Misalnya, ketika ternyata nama metode Array baru melanggar situs web, spesifikasi menamainya menjadi , sehingga tidak akan merusak apa pun. Ini menunjukkan bahwa spesifikasi mencerminkan realitas web, dan bukan alasan untuk melanggarnya. Oleh karena itu, solusi yang saya usulkan adalah memodifikasi spesifikasi untuk menunjukkan bahwa kanvas HTML dan OffscreenCanvas harus mendukung konteks yang sama. Ini menghindari masalah kompatibilitas web yang kami temui (dan mungkin yang dihadapi orang lain), dan dalam segala hal lain tampak lebih kohesif. Safari kemudian harus menunda implementasi OffscreenCanvas hingga dukungan WebGL tersedia, dan kemudian semua konten web yang relevan akan terus berfungsi.

Kedua, bahkan jika spesifikasi diakui benar dan penulis memutuskan untuk tidak mengubahnya, apakah Apple tidakApakah Anda peduli dengan kompatibilitas web? Mengapa tidak menunda rilis OffscreenCanvas, terlepas dari apa yang tertulis dalam spesifikasi? Ini akan menjadi solusi pragmatis untuk meningkatkan kompatibilitas web. Itu mungkin untuk menunda rilis dan menghabiskan waktu menambahkan dukungan WebGL. Saya yakin bahwa sebagian besar pengembang perangkat lunak berpengalaman telah melakukan hal serupa dalam karir mereka: pada tahap selanjutnya, masalah dengan fitur baru ditemukan, jadi Anda menonaktifkan fitur tersebut, menunda rilisnya ke rilis berikutnya sesuai jadwal dan menghabiskan waktu luang untuk implementasi yang benar. Safari merilis OffscreenCanvas empat tahun enam bulan setelah dukungan penuhnya dirilis di Chrome, tetapi masih merusak sebagian besar konten; mungkin akan lebih baik untuk merilisnya empat tahun sembilan bulan setelah Chrome dengan implementasi penuh yang menjaga kompatibilitas web? Mengapa memilih opsi tergesa-gesa yang merusak sesuatu? Saya melakukan yang terbaik untuk meyakinkan Apple untuk menunda rilis, tetapi saya hanya samar-samar diberitahu bahwa fitur tersebut mungkin akan dirilis tidak berubah.

Menurut pendapat saya, ini adalah contoh bagaimana Apple menggunakan formalitas untuk tidak mengubah jadwalnya. Kami menghadapi bencana, dan untuk menghindarinya, cukup bagi Apple untuk menunda rilis salah satu dari banyak fitur baru Safari 16.4. Pada akhirnya, pengembang menambahkan trik browser khusus yang mendeteksi mesin kami dan menonaktifkan OffscreenCanvas untuk itu. Ini benar-benar memungkinkan kami untuk menghindari bencana kompatibilitas. Namun, semua orang yang melakukan kesalahan yang sama kurang beruntung - peretasan browser khusus untuk mesin kami tidak akan menyelamatkan mereka."2d"nulltypeof OffscreenCanvas !== "undefined"<canvas>flattenflat

Catatan pribadi

Dalam situasi normal, saya tidak akan mengatakan ini, tetapi saya pikir penting untuk menekankan skala masalah. Bagi saya pribadi, ini adalah beberapa minggu yang sangat menegangkan. Terkadang saya muak dengan kecemasan, termasuk di luar pekerjaan. Ketidakpastian menjengkelkan: mungkin bencana akan terjadi, atau mungkin semuanya akan baik-baik saja. Saya tidak tahu apa yang akan terjadi, dan saya tidak tahu kapan kita akan tahu. Setiap hari selama beberapa minggu bisa menjadi hari biasa atau berubah menjadi bencana, dan tidak mungkin kita tahu apa yang akan terjadi, dan kita bahkan tidak tahu mana dari banyak potensi masalah yang akan menyebabkan bencana. Dan meskipun biasanya tidak seburuk itu, rilis Safari sebelumnya juga menyebabkan masalah serupa.

Kita hanya manusia, dan situasi seperti ini mempengaruhi kita. Saya harus mengatakan bahwa saya telah membangun perusahaan ini selama lebih dari satu dekade, dari bekerja pada laptop di rumah hingga bisnis yang sukses dengan 250 ribu pengguna aktif bulanan. Saya telah menghadapi bencana, kritik, pengguna yang tidak puas, server tiba-tiba mogok tak terduga pada hari libur, dan sebagainya. Ini bisa menantang, tetapi Anda menanganinya seperti seorang profesional. Namun, situasi rilis Safari telah menjadi salah satu situasi kerja terburuk dan paling menegangkan. Dan hal yang paling menjengkelkan adalah bahwa semua ini bisa dihindari: Apple bisa membuat perubahan yang sangat sederhana yang akan menyelamatkan kita dari sebagian besar stres, namun, secara konsisten gagal membuat perubahan seperti itu selama bertahun-tahun.

Saya ingin menekankan bahwa ini bukan kritik terhadap karyawan Apple tertentu. Tidak ada satu pun orang Apple yang menyebabkan stres ini - saya secara khusus mengatakan bahwa banyak dari mereka melakukan pekerjaan mereka dengan baik, dan Apple tidak kekurangan orang pintar dan pekerja keras. Masalahnya terletak pada kebijakan manajemen rilis Apple. Aspek-aspek seperti kurangnya transparansi menyebabkan banyak ketidakpastian, dan menurut saya kebijakan perusahaan ini bertanggung jawab atas tekanan yang saya dan mungkin pengembang web lainnya alami. Satu-satunya tujuan saya di sini adalah untuk menerangi kenyataan yang dihadapi pengembang ketika berhadapan dengan rilis Safari, dan untuk mencoba mempengaruhi perubahan dalam kebijakan Apple yang saya yakini berdampak pada hal itu.

Sejarah rilis Apple

Rilis Safari biasanya tidak seburuk itu, tetapi hal-hal seperti ini telah terjadi di masa lalu dan menyebabkan banyak stres dan kekacauan juga. Ini menunjukkan bahwa tidak ada yang berubah, dan bahkan situasinya semakin buruk. Berikut adalah deskripsi singkat tentang masalah sebelumnya yang kami alami dengan Safari.

• iOS 11.2.2 rusak WebAssembly. Itu merusak bagian Wikipedia, semua konten yang diterbitkan Construct, dan mungkin sesuatu yang lain. Sebagian besar masalah bisa dihindari dengan hanya menonaktifkan WebAssembly sehingga semuanya akan jatuh kembali ke fallback. Sebaliknya, perusahaan membiarkannya menyala, tetapi rusak hingga rilis iOS 11.3 beberapa bulan kemudian. Sementara itu, Apple belum memberikan dukungan yang signifikan. Kami hanya mendapat bantuan dari seorang insinyur Wikipedia yang membagikan solusi yang mereka temukan.
• Safari 11.1 merusak MessageChannels dengan cara yang merusak Construct, yang menyebabkan kami mendukung solusi selama bertahun-tahun.
• Safari 14 dirilis dengan metode replaceChildren() yang rusak yang menyebabkan gangguan pada Construct.
• Safari 14 memecahkan localStorage dan kemudian memecahkan IndexedDB
• Bahkan ketika masalah diperbaiki, itu masih dapat menyebabkan stres dan ketidakpastian. Masalah audio di Safari 15 menimbulkan risiko pemutaran audio rusak di semua konten Construct. Itu dihilangkan sebelum rilis penuh Safari 15, tetapi Apple tidak mengkonfirmasi ini sebelumnya. Saya harus memeriksa semuanya sendiri lagi.
• Bug dengan WebGL di Safari 15.0-15.4 menyebabkan layar kosong dirender untuk sepotong konten Construct. Masalahnya telah diperbaiki di Safari 15.5, tetapi kami tidak pernah diberitahu tentang hal itu, kami mengetahuinya dengan memeriksa secara manual setiap rilis Safari.
• Selama bertahun-tahun, kami telah memimpikan satu format file audio terbuka yang diputar di semua browser. WebM Opus hampir siap: didukung oleh semua browser, termasuk Safari di macOS, tetapi tidak hanya di Safari di iOS dan iPadOS. Ini adalah satu-satunya kendala untuk penggunaan format ini di semua browser, yang akan menghilangkan kesulitan signifikan dengan dukungan audio di web. Namun, tidak jelas apakah Apple sedang mengerjakan ini sama sekali; Saya membuat Issue sekitar setahun yang lalu, tetapi tidak ada yang dengan jelas menyatakan niat perusahaan.
• Safari 16 memiliki masalah yang merusak pemutaran audio di Construct dalam beberapa situasi. Tampaknya tidak ada tanggapan yang signifikan dari Apple untuk itu, terlepas dari kenyataan bahwa laporan itu dikirim sekitar enam bulan yang lalu. Kami terus mendukung solusi, yang juga menyebabkan kesulitan lain.
• Terkadang masalah menghilang ke dalam kehampaan. Masalah ini dikirim sekitar setahun yang lalu, tetapi tidak ada reaksi yang dapat dipahami dari Apple. Bandingkan ini dengan bagaimana Firefox bereaksi terhadap masalah serupa, yang dilaporkan sekitar waktu yang sama.

Tanpa ragu, ada kasus lain, daftarnya sama sekali tidak lengkap. Dalam banyak masalah yang terkait di atas, hal serupa terjadi: tidak dapat dipahaminya apa yang terjadi, pertanyaan yang belum terjawab tentang jadwal, penolakan Apple untuk mengungkapkan detail yang diperlukan untuk pengembang.

Kami hanya memiliki masalah serius dengan Apple dan Safari. Sangat jarang ada kesulitan serupa dengan beberapa pengembang browser lain, dan ketika mereka melakukannya, ada transparansi lengkap tentang apa yang akan dilakukan dengan mereka, sehingga kami dapat membuat rencana.

Bagaimana mengatasi masalah ini

Singkatnya, jawabannya adalah: "lakukan hal yang sama seperti pengembang browser lainnya." Tidak ada pengembang browser lain yang menciptakan masalah serius seperti itu, dan sebagian besar ini disebabkan oleh proses pengembangan mereka yang jauh lebih baik untuk pengembang web seperti kami. Mereka termasuk:

• Transparansi: Beri tahu developer rilis mana yang akan merilis perbaikan bug dan memublikasikan jadwal rilis. Ini saja akan menyingkirkan sejumlah besar ketidakpastian.
• Selalu perbarui Safari apa pun OS-nya: Safari adalah satu-satunya browser yang tersisa di industri yang terkait dengan OS-nya. Ini menempatkan penghalang tinggi untuk memperbarui Safari. Tampaknya bahkan pembaruan kecil namun kritis terpaksa menunggu pembaruan berikutnya dari seluruh sistem. Tentu saja, ini meningkatkan waktu untuk menyelesaikan masalah serius sekalipun: alih-alih berminggu-minggu atau berhari-hari, diperlukan berbulan-bulan. Jika tim pengembangan Safari mengendalikan dan mengelola siklus rilisnya sendiri dengan bijak, itu akan secara signifikan mengurangi dampak dari masalah tersebut.
• Opsi pengujian prarilis lainnya: Anda memerlukan Chrome Canary dan Firefox Nightly yang setara, diperbarui setiap hari dan apa pun OS-nya, dapat dengan cepat menyelesaikan masalah secara berulang dan mengonfirmasi perbaikannya. Baik versi ini dan STP juga harus tersedia di iOS dan iPadOS, karena saat ini satu-satunya cara untuk menguji pra-rilis Safari di iOS adalah pembaruan penuh ke sistem beta, yang lambat dan tidak nyaman.
• Komunikasi: Bug kadang-kadang terjadi, dan jika masalah disebabkan oleh kerusakan di Safari, Apple harus memberi tahu semua orang apa yang sedang terjadi, apa yang dilakukannya, kapan solusi diharapkan, dan apa yang dapat dilakukan pengembang untuk saat ini. Paling sering, jawabannya adalah diam, yang memberi perasaan bahwa perusahaan tidak peduli. Saya menduga bahwa karyawan Apple peduli untuk memecahkan masalah, tetapi dari luar sering terlihat buruk.

Menurut pengalaman saya, semua pengembang browser lain menangani ini dengan sangat baik. Hanya Apple yang tidak dapat mengatasi keempat poin ini. Merilis fitur baru untuk Safari adalah hal yang baik karena Apple tampaknya fokus pada Safari 16.4, tetapi tidak melakukan apa pun untuk mengimplementasikan item dalam daftar.

Kesimpulan

Pada akhirnya, semuanya berhasil. Tapi lihat upaya yang harus kami lakukan hanya untuk menjaga semuanya tetap berfungsi setelah rilis rutin Safari. Mungkin dengan rilis berikutnya kita harus melalui semuanya lagi, dan dengan yang berikutnya setelah itu juga, dan ada kemungkinan bahwa cepat atau lambat seseorang akan kehilangan sesuatu dan kita akan menghadapi bencana lagi ... Dan ketika saya memikirkannya, saya mulai merasa mual lagi.

Saya ingin menyukai Safari. Ini menggunakan teknologi yang sangat baik. Dalam rilis terbaru, banyak fitur keren telah dirilis, yang dalam kondisi normal saya akan senang. Jelas, perusahaan tidak kekurangan karyawan berbakat yang dapat dengan cepat memahami detail masalah teknis, dan saya ingin menjelaskan bahwa saya tidak memiliki masalah pribadi dengan siapa pun dari Apple. Yang menyedihkan adalah saya takut rilis Safari. Apple pasti bisa membuat mereka jauh lebih baik. Proses pelepasliarannya sangat rusak dan tetap demikian selama beberapa tahun. Dalam banyak kasus, kesulitan dapat dihilangkan hanya dengan sedikit intervensi dari Apple. Namun, perusahaan dengan keras kepala berpegang pada satu proses dan tidak pernah menunjukkan minat untuk mengubahnya. Dan pengembang seperti saya mengalami neraka pengembangan, memecahkan masalah yang muncul sebagai hasilnya: gangguan operasi normal yang tidak perlu, membuang-buang waktu mencari tahu apa yang sudah diketahui Apple tetapi tidak memberi tahu kami, merasa stres dan tidak yakin tentang bencana yang akan datang tanpa mengetahui kapan atau apa yang akan terjadi. Menurut pendapat saya, ini terlihat seperti kebijakan pengabaian pengembang.

Saya sangat ingin Apple berubah. Saya ingin Safari menjadi browser yang hebat. Saya ingin mengembangkan konten luar biasa yang berfungsi sempurna di Safari. Saya ingin memberikan persaingan yang kuat untuk browser demi meningkatkan web. Terus terang, saya ingin Apple berubah demi kesehatan mental saya juga. Jika Apple tidak berubah, maka satu-satunya hal yang tersisa bagi saya adalah membujuk orang untuk beralih ke Chrome atau Firefox dan meminta regulator untuk memaksa perusahaan mengubah sikapnya. Terlepas dari aktivitas hukum baru-baru ini, menurut saya rilis ini menunjukkan bahwa masalah dengan rilis Safari semakin buruk, tidak berkurang; Sementara itu, Apple tampaknya lebih tertarik untuk melawan persyaratan daripada menyelesaikan masalah ini. Akhirnya, kita akan berakhir di monokultur Chromium, yang akan berdampak buruk bagi web dan membawa masalah tersendiri. Tetapi jika itu terjadi, saya harus mengatakan bahwa pada titik ini saya tidak akan menyesal harus berurusan dengan rilis Safari.