Xcode

Jalur yang Mengirim Build ke App Store Di Bagian 1 kita membuat build target MAS, dan di Bagian 2 kita membuat file konfigurasi dan percabangan kode yang memisahkan dua saluran. Target FocusTimer MAS kini dalam bentuk yang dapat dimasukkan ke App Store. Dalam bagian terakhir ini, kita akan menyiapkan jalur untuk mengunggah build tersebut ke App Store Connect, dan membahas cara memverifikasi dua saluran agar tetap tidak rusak ke depannya, menyelesaikan seri. ...

Membuat Target Benar-Benar “Khusus MAS” Di Bagian 1, kita mendaftarkan Bundle ID khusus MAS dan menduplikasi build target FocusTimer MAS. Tetapi target tersebut masih hanya salinan dari target distribusi langsung. Build MAS harus berbeda dari build distribusi langsung dalam tiga hal. Entitlement — hanya set minimum yang sesuai untuk App Store Info.plist — hilangkan kunci Sparkle, tambahkan metadata App Store Kode — percabangan agar tetap bisa dikompilasi meskipun tanpa Sparkle Dalam artikel ini, kita akan memisahkan ketiganya. ...

Saluran Distribusi Lain — Mac App Store Seri sebelumnya membahas konfigurasi satu kali untuk mendistribusikan aplikasi macOS secara langsung dengan Developer ID. Setelah sertifikat, notarisasi, pembaruan otomatis Sparkle, dan feed pembaruan yang dihosting sudah tersedia, Anda dapat membiarkan pengguna mengunduh file .dmg secara langsung tanpa melalui App Store. Seri ini membahas konfigurasi satu kali untuk menempatkan aplikasi yang sama di Mac App Store (MAS) juga. Dua metode distribusi ini bukan pilihan yang saling eksklusif. Anda dapat menjalankan satu aplikasi melalui saluran distribusi langsung dan saluran App Store secara bersamaan. App Store memiliki Apple yang menangani pembayaran, pengembalian dana, dan visibilitas pencarian atas nama Anda, serta membawa kepercayaan pengguna yang lebih tinggi, sehingga menjalankannya bersamaan dengan distribusi langsung adalah pilihan yang umum. ...

Bagian Terakhir — Di Mana Meletakkan Pembaruan Di Bagian 1 kita menyiapkan sertifikat Developer ID dan notarisasi, dan di Bagian 2 kita menyiapkan kunci penandatanganan Sparkle. Itu berarti kita sekarang memiliki cara untuk menandatangani aplikasi, melakukan notarisasi, dan memverifikasi keaslian pembaruan. Namun lokasi yang ditunjuk oleh SUFeedURL (https://updates.example.com/appcast.xml), yang kita tulis ke Info.plist aplikasi di Bagian 2, masih belum berisi apa pun. Dalam bagian terakhir ini, kita akan menghosting feed pembaruan yang akan mengisi tempat tersebut dan menyelesaikan pengaturan build, melengkapi seluruh konfigurasi satu kali. ...

Pembaruan Otomatis, dan Mengapa Anda Membutuhkan Satu Lapisan Penandatanganan Lagi Di Bagian 1, kita menyelesaikan pengaturan sertifikat Developer ID dan notarisasi. Dengan itu, Anda siap untuk mengirimkan aplikasi kepada pengguna untuk pertama kalinya. Namun aplikasi tidak selesai setelah satu rilis — Anda harus terus merilis versi baru yang memperbaiki bug dan menambahkan fitur. Untuk aplikasi Mac App Store, App Store menangani pembaruan untuk Anda. Aplikasi yang didistribusikan langsung tidak mendapatkan itu, jadi Anda harus membangun fitur pembaruan otomatis ke dalam aplikasi sendiri. Di macOS, standar de facto untuk peran ini adalah framework open-source Sparkle. Dengan Sparkle terpasang, aplikasi secara berkala memeriksa “feed pembaruan (appcast),” dan jika ada versi baru, aplikasi memberi tahu pengguna, mengunduhnya, dan menginstalnya. ...