Pelokalan aplikasi di iOS
Bagian 1. Apa yang kita miliki?
Panduan Sumber Daya String Lokal
Pendahuluan
Beberapa tahun yang lalu, saya terjun ke dunia magis pengembangan iOS, yang dengan segala esensinya menjanjikan masa depan yang bahagia di bidang IT. Namun, dengan menggali lebih dalam fitur platform dan lingkungan pengembangan, saya menghadapi banyak kesulitan dan ketidaknyamanan dalam menyelesaikan tugas yang tampaknya sangat sepele: “konservatisme inovatif” Apple terkadang membuat pengembang sangat canggih untuk memuaskan pelanggan “INGIN” yang tak terkendali.
Salah satu masalah ini adalah masalah melokalisasi sumber daya string aplikasi. Saya ingin mencurahkan beberapa publikasi pertama saya di hamparan Habr untuk masalah ini.
Awalnya, saya berharap bisa memasukkan pikiran saya dalam satu artikel, tetapi jumlah informasi yang ingin saya sampaikan cukup besar. Pada artikel ini saya akan mencoba mengungkap esensi dari mekanisme standar untuk bekerja dengan sumber daya lokal dengan penekanan pada beberapa aspek yang diabaikan oleh sebagian besar panduan dan tutorial. Materi ini terutama ditujukan untuk pengembang pemula (atau mereka yang belum mengalami tugas seperti itu). Untuk pengembang berpengalaman, informasi ini mungkin tidak terlalu berharga. Tetapi tentang ketidaknyamanan dan kerugian yang dapat ditemui dalam praktek, saya akan memberitahu di masa depan ...
Di luar kotak. Bagaimana penyimpanan sumber daya string diatur dalam aplikasi iOS
Untuk memulainya, kami mencatat bahwa keberadaan mekanisme lokalisasi di platform sudah merupakan nilai tambah yang besar, karena menyimpan programmer dari pengembangan tambahan dan menetapkan format tunggal untuk bekerja dengan data. Dan seringkali, mekanisme dasar sudah cukup untuk implementasi proyek yang relatif kecil.
Jadi, peluang apa yang diberikan Xcode kepada kami "di luar kotak"? Pertama, mari kita lihat standar untuk menyimpan sumber daya string dalam suatu proyek.
Dalam proyek dengan konten statis, data string dapat disimpan secara langsung di antarmuka ( .storyboard dan .xib , yang pada gilirannya adalah file XML yang dibuat menggunakan alat bantu Builder Interface ) atau dalam kode. Pendekatan pertama memungkinkan kami untuk menyederhanakan dan mempercepat proses menandai layar dan tampilan individual pengembang dapat mengamati sebagian besar perubahan tanpa membangun aplikasi. Namun, dalam hal ini tidak sulit untuk mengalami redundansi data (jika teks yang sama digunakan oleh beberapa elemen, tampilan). Pendekatan kedua hanya menghilangkan masalah redundansi data, tetapi mengarah pada kebutuhan untuk mengisi layar secara manual (dengan menetapkan IBOutlet tambahan dan menetapkan nilai teks yang sesuai), yang pada gilirannya mengarah pada redundansi kode (tentu saja, kecuali untuk kasus-kasus di mana teks harus dipasang langsung oleh kode aplikasi).
Selain itu, Apple menyediakan ekstensi file standar .strings . Standar ini mengatur format untuk menyimpan data string dalam bentuk array asosiatif ( "-" ):
"key" = "value";
Kuncinya adalah case-sensitive, memungkinkan penggunaan spasi, garis bawah, tanda baca dan karakter khusus.
Penting untuk dicatat bahwa meskipun ada sintaks langsung, file Strings adalah sumber kesalahan rutin selama kompilasi, perakitan, atau operasi aplikasi. Ada beberapa alasan untuk ini.
Pertama, kesalahan sintaksis. Titik koma yang hilang, tanda sama dengan, tanda kutip tambahan atau tidak terhindarkan pasti akan menyebabkan kesalahan kompiler. Selain itu, Xcode akan menunjuk ke file dengan kesalahan, tetapi tidak akan menyoroti garis di mana ada sesuatu yang salah. Menemukan kesalahan ketik seperti itu bisa memakan waktu cukup lama, terutama jika file tersebut berisi sejumlah besar data.
Kedua, duplikasi kunci. Aplikasi, tentu saja, tidak akan macet karena itu, tetapi data yang salah dapat ditampilkan kepada pengguna. Masalahnya adalah bahwa ketika mengakses baris demi kunci, nilai yang sesuai dengan kemunculan terakhir kunci dalam file ditarik ke atas.
Akibatnya, desain yang sederhana membutuhkan programmer untuk sangat teliti dan penuh perhatian saat mengisi file dengan data.
Berpengetahuan luas pengembang dapat segera berseru: "Tapi bagaimana dengan JSON dan PLIST? Apa yang tidak mereka sukai?" Yah, pertama-tama, JSON dan PLIST (pada kenyataannya, XML biasa) adalah standar universal yang memungkinkan penyimpanan string dan numerik, logis ( BOOL ), data biner, waktu dan tanggal, serta koleksi - indeks - terindeks ( Array ) dan asosiatif ( Dictionary ) array. Dengan demikian, sintaks dari standar-standar ini lebih jenuh, dan karenanya lebih mudah untuk digigit. Kedua, kecepatan pemrosesan file tersebut sedikit lebih rendah daripada file Strings, lagi-lagi karena sintaksis yang lebih kompleks. Ini belum lagi fakta bahwa untuk bekerja dengan mereka, Anda perlu melakukan sejumlah manipulasi dalam kode.
Terlokalisasi, terlokalisasi, tetapi tidak terlokalisasi. Lokalisasi Antarmuka Pengguna
Jadi, dengan standar yang sudah ditentukan, sekarang mari kita cari tahu cara menggunakannya.
Mari kita mulai. Pertama, buat Aplikasi Tampilan Tunggal sederhana dan tambahkan beberapa komponen teks ke Main.storyboard pada ViewController .
Konten dalam hal ini disimpan langsung di antarmuka. Untuk melokalkannya, Anda harus melakukan yang berikut:
1) Buka pengaturan proyek
2) Lalu - dari Target ke Proyek
3) Buka tab Info
Di bagian Pelokalan , kami segera melihat bahwa kami sudah memiliki entri "Bahasa Inggris - Bahasa Pembangunan" . Ini berarti bahwa bahasa Inggris ditetapkan sebagai bahasa pengembangan (atau standar).
Mari tambahkan bahasa lain sekarang. Untuk melakukan ini, klik " + " dan pilih bahasa yang diinginkan (misalnya, saya memilih bahasa Rusia). Caring Xcode segera menawarkan kepada kami untuk memilih file mana yang akan dilokalisasi untuk bahasa yang ditambahkan.
Klik Selesai , lihat apa yang terjadi. Di navigator proyek, tombol untuk menampilkan sarang muncul di dekat file yang dipilih. Dengan mengkliknya, kita melihat bahwa file yang dipilih sebelumnya berisi file lokalisasi yang dibuat.
Misalnya, Main.storyboard (Base) adalah file markup antarmuka default dalam bahasa pengembangan basis, dan ketika membentuk lokalisasi untuk itu, Main.strings (Russian) terkait Main.strings (Russian) dibuat berpasangan - file string untuk lokalisasi Rusia. Membuka itu, Anda dapat melihat yang berikut:
/* Class = "UILabel"; text = "Label"; ObjectID = "tQe-tG-eeo"; */ "tQe-tG-eeo.text" = "Label"; /* Class = "UITextField"; placeholder = "TextField"; ObjectID = "cpp-y2-Z0N"; */ "cpp-y2-Z0N.placeholder" = "TextField"; /* Class = "UIButton"; normalTitle = "Button"; ObjectID = "EKl-Rz-Dc2"; */ "EKl-Rz-Dc2.normalTitle" = "Button";
Di sini, secara umum, semuanya sederhana, tetapi demi kejelasan, kami akan mempertimbangkan lebih detail, memperhatikan komentar yang dihasilkan oleh Xcode yang peduli:
/* Class = "UILabel"; text = "Label"; ObjectID = "tQe-tG-eeo"; */ "tQe-tG-eeo.text" = "Label";
Ini adalah turunan dari kelas UILabel dengan nilai "Label" untuk parameter text . ObjectID - pengidentifikasi objek dalam file markup - ini adalah baris unik yang ditetapkan untuk komponen apa pun pada saat ditempatkan di Storyboard/Xib . Dari ObjectID dan nama parameter objek (dalam hal ini, text ) kunci dibuat, dan catatan itu sendiri dapat secara resmi diartikan sebagai berikut:
Atur parameter teks dari objek tQe-tG-eeo ke Label.
Dalam catatan ini, hanya " nilai " yang dapat berubah. Ganti " Label " dengan " Label ". Kami akan melakukan hal yang sama dengan benda lain.
/* Class = "UILabel"; text = "Label"; ObjectID = "tQe-tG-eeo"; */ "tQe-tG-eeo.text" = ""; /* Class = "UITextField"; placeholder = "TextField"; ObjectID = "cpp-y2-Z0N"; */ "cpp-y2-Z0N.placeholder" = " "; /* Class = "UIButton"; normalTitle = "Button"; ObjectID = "EKl-Rz-Dc2"; */ "EKl-Rz-Dc2.normalTitle" = "";
Kami meluncurkan aplikasi kami.
Tapi apa yang kita lihat? Aplikasi ini menggunakan lokalisasi dasar. Bagaimana cara memeriksa apakah kami melakukan transfer dengan benar?
Di sini ada baiknya melakukan penyimpangan kecil dan menggali sedikit ke arah fitur platform iOS dan struktur aplikasi.
Untuk memulai, pertimbangkan untuk mengubah struktur proyek dalam proses penambahan lokalisasi. Ini adalah bagaimana direktori proyek terlihat sebelum menambahkan lokalisasi Rusia:
Dan setelah itu:
Seperti yang bisa kita lihat, Xcode membuat direktori baru ru.lproj , di mana ia menempatkan string lokal yang dibuat.
Dan di mana struktur proyek Xcode untuk aplikasi iOS yang sudah selesai? Dan terlepas dari kenyataan bahwa ini membantu untuk lebih memahami fitur-fitur platform, serta prinsip-prinsip distribusi dan penyimpanan sumber daya secara langsung dalam aplikasi jadi. Intinya adalah bahwa ketika merakit proyek Xcode, selain menghasilkan file yang dapat dieksekusi, lingkungan mentransfer sumber daya (file tata letak antarmuka Storyboard / Xib , gambar, file garis, dll.) Ke aplikasi yang sudah selesai, menjaga hierarki yang ditentukan pada tahap pengembangan.
Untuk bekerja dengan hierarki ini, Apple menyediakan kelas Bundle(NSBundle) ( terjemahan gratis ):
Apple menggunakan Bundle untuk menyediakan akses ke aplikasi, kerangka kerja, plugin, dan banyak jenis konten lainnya. Bundel mengatur sumber daya ke dalam subdirektori yang didefinisikan dengan jelas, dan struktur bundel bervariasi berdasarkan platform dan jenis. Menggunakan bundle , Anda dapat mengakses sumber daya suatu paket tanpa mengetahui strukturnya. Bundle adalah antarmuka tunggal untuk mencari elemen, dengan mempertimbangkan struktur paket, kebutuhan pengguna, pelokalan yang tersedia, dan faktor relevan lainnya.
Cari dan temukan sumber daya
Sebelum Anda mulai bekerja dengan sumber daya, Anda harus menentukan bundle . Kelas Bundle memiliki banyak konstruktor, tetapi utama paling sering digunakan. Bundle.main menyediakan jalur ke direktori yang berisi kode yang dapat dieksekusi saat ini. Dengan cara ini, Bundle.main menyediakan akses ke sumber daya yang digunakan oleh aplikasi saat ini.
Pertimbangkan struktur Bundle.main menggunakan kelas Bundle.main :
Berdasarkan uraian di atas, kita dapat menyimpulkan: ketika aplikasi dimuat, Bundle.main -nya terbentuk, lokalisasi perangkat saat ini (bahasa sistem), lokalisasi aplikasi dan sumber daya lokal dianalisis. Kemudian aplikasi memilih dari semua lokalisasi yang tersedia yang sesuai dengan bahasa sistem saat ini dan menarik sumber daya lokal yang sesuai. Jika tidak ada kecocokan, sumber daya dari direktori default digunakan (dalam kasus kami, pelokalan bahasa Inggris, karena bahasa Inggris didefinisikan sebagai bahasa pengembangan, dan kebutuhan untuk pelokalan sumber daya tambahan dapat diabaikan). Jika Anda mengubah bahasa perangkat ke Rusia dan memulai ulang aplikasi, maka antarmuka sudah sesuai dengan lokalisasi Rusia.
Tetapi sebelum Anda menutup topik pelokalan antarmuka pengguna melalui Interface Builder , perlu dicatat cara lain yang patut diperhatikan. Saat membuat file pelokalan (dengan menambahkan bahasa baru ke proyek atau di inspektur file lokal), mudah untuk melihat bahwa Xcode menyediakan kemampuan untuk memilih jenis file yang akan dibuat:
Alih-alih file baris, Anda dapat dengan mudah membuat Storyboard/Xib lokal yang akan menyimpan semua markup file dasar. Nilai tambah yang besar dari pendekatan ini adalah pengembang dapat segera melihat bagaimana konten akan ditampilkan dalam bahasa tertentu dan segera memperbaiki tata letak layar, terutama jika jumlah teks berbeda, atau arah teks yang lain digunakan (misalnya, dalam bahasa Arab, bahasa Ibrani) dan sebagainya. . Tetapi pada saat yang sama, membuat file Storyboard / Xib tambahan secara signifikan meningkatkan ukuran aplikasi itu sendiri (semua sama, file string memakan banyak ruang lebih sedikit).
Oleh karena itu, ketika memilih satu atau beberapa metode pelokalan antarmuka lainnya, ada baiknya mempertimbangkan pendekatan mana yang lebih tepat dan praktis dalam situasi tertentu.
Lakukan Sendiri. Bekerja dengan sumber string yang terlokalisasi dalam kode
Semoga dengan konten statis, semuanya lebih atau kurang jelas. Tetapi bagaimana dengan teks yang diatur langsung dalam kode?
Pengembang sistem operasi iOS menangani ini.
Untuk bekerja dengan sumber daya teks lokal, kerangka kerja Yayasan menyediakan keluarga NSLocalizedStrings metode di Swift
NSLocalizedString(_ key: String, comment: String) NSLocalizedString(_ key: String, tableName: String?, bundle: Bundle, value: String, comment: String)
dan makro di Objective-C
NSLocalizedString(key, comment) NSLocalizedStringFromTable(key, tbl, comment) NSLocalizedStringFromTableInBundle(key, tbl, bundle, comment) NSLocalizedStringWithDefaultValue(key, tbl, bundle, val, comment)
Mari kita mulai dengan yang jelas. Parameter key adalah kunci string dalam file Strings; val (nilai default) - nilai default yang digunakan jika kunci yang ditentukan tidak ada dalam file; comment - (kurang jelas) deskripsi singkat dari string terlokalisasi (pada kenyataannya, itu tidak membawa fungsionalitas yang berguna dan dimaksudkan untuk menjelaskan tujuan penggunaan string tertentu).
Adapun parameter tableName ( tbl ) dan bunble , maka mereka harus dipertimbangkan secara lebih rinci.
tableName ( tbl ) adalah nama file String (sejujurnya, saya tidak tahu mengapa Apple menyebutnya tabel), yang berisi baris yang kita butuhkan dengan kunci yang ditentukan; ketika ditransfer, ekstensi .string tidak ditentukan. Kemampuan untuk menavigasi antar tabel memungkinkan Anda untuk tidak menyimpan sumber daya string dalam satu file, tetapi untuk mendistribusikannya atas kebijakan Anda sendiri. Ini memungkinkan Anda untuk menyingkirkan kemacetan file, menyederhanakan pengeditan, dan meminimalkan kemungkinan kesalahan.
Parameter bundle memperluas navigasi sumber daya lebih jauh. Seperti yang disebutkan sebelumnya, bundel adalah mekanisme untuk mengakses sumber daya aplikasi, yaitu, kita dapat menentukan sumber sumber daya secara independen.
Sedikit lagi. Kami akan pergi langsung ke Yayasan dan mempertimbangkan deklarasi metode (makro) untuk gambaran yang lebih jelas, karena sebagian besar tutorial mengabaikan hal ini. Kerangka kerja Swift tidak terlalu informatif:
/// Returns a localized string, using the main bundle if one is not specified. public func NSLocalizedString(_ key: String, tableName: String? = default, bundle: Bundle = default, value: String = default, comment: String) -> String
"Bundel utama mengembalikan string yang dilokalkan" - semua yang kita miliki. Objective-C agak berbeda.
#define NSLocalizedString(key, comment) \ [NSBundle.mainBundle localizedStringForKey:(key) value:@"" table:nil] #define NSLocalizedStringFromTable(key, tbl, comment) \ [NSBundle.mainBundle localizedStringForKey:(key) value:@"" table:(tbl)] #define NSLocalizedStringFromTableInBundle(key, tbl, bundle, comment) \ [bundle localizedStringForKey:(key) value:@"" table:(tbl)] #define NSLocalizedStringWithDefaultValue(key, tbl, bundle, val, comment) \ [bundle localizedStringForKey:(key) value:(val) table:(tbl)]
Di sini Anda sudah dapat melihat dengan jelas bahwa tidak lain dari bundle (dalam dua kasus utama mainBundle ) bekerja dengan file sumber daya string - sama seperti dalam kasus pelokalan antarmuka. Tentu saja, saya dapat langsung mengatakan ini, mengingat kelas Bundle ( NSBundle ) pada paragraf sebelumnya, tetapi pada saat itu informasi ini tidak memiliki nilai praktis tertentu. Tetapi dalam konteks bekerja dengan baris dalam kode, ini tidak bisa dikatakan. Bahkan, fungsi global yang disediakan oleh Yayasan hanyalah pembungkus metode bundel standar, tugas utamanya adalah membuat kode lebih ringkas dan aman. Tidak ada yang melarang untuk menginisialisasi bundle secara manual dan secara langsung mengakses sumber daya atas namanya, tetapi dengan cara ini muncul (walaupun sangat, sangat kecil) kemungkinan pembentukan tautan sirkuler dan kebocoran memori.
Contoh di bawah ini akan menjelaskan cara bekerja dengan fungsi global dan makro.
Mari kita lihat bagaimana semuanya bekerja.
Pertama, buat file String yang akan berisi sumber daya string kami. Sebut saja Localizable.strings * dan tambahkan ke dalamnya.
"testKey" = "testValue";
( File string dilokalkan dengan cara yang persis sama dengan Storyboard / Xib , jadi saya tidak akan menjelaskan proses ini. Kami akan mengganti " testValue " dalam file pelokalan Rusia dengan " test value *".)
Penting! Di iOS, file dengan nama ini adalah file sumber daya string default, mis. jika Anda tidak menentukan nama tabel tableName ( tbl ), aplikasi akan secara otomatis mengetuk Localizable.strings .
Tambahkan kode berikut ke proyek kami
//Swift print("String for 'testKey': " + NSLocalizedString("testKey", comment: ""))
dan jalankan proyek. Setelah mengeksekusi kode, sebuah baris akan muncul di konsol
String for 'testKey': testValue
Semuanya bekerja dengan baik!
Demikian pula dengan contoh lokalisasi antarmuka, ubah lokalisasi dan jalankan aplikasi. Hasil dari eksekusi kode adalah
String for 'testKey':
Sekarang mari kita coba untuk mendapatkan nilai dengan kunci, yang tidak ada di file Localizable.strings :
//Swift print("String for 'unknownKey': " + NSLocalizedString("unknownKey", comment: ""))
Hasil dari eksekusi kode tersebut adalah
String for 'unknownKey': unknownKey
Karena tidak ada kunci dalam file, metode mengembalikan kunci itu sendiri sebagai hasilnya. Jika hasil seperti itu tidak dapat diterima, maka lebih baik menggunakan metode ini
//Swift print("String for 'testKey': " + NSLocalizedString("unknownKey", tableName: nil, bundle: Bundle.main, value: "noValue", comment: ""))
di mana ada parameter value ( nilai default ). Tetapi dalam kasus ini, Anda harus menentukan sumber sumber daya - bundle .
String lokal mendukung mekanisme interpolasi, mirip dengan string iOS standar. Untuk melakukan ini, tambahkan catatan ke file string menggunakan string literal ( %@ , %li , %f , dll.), Misalnya:
"stringWithArgs" = "String with %@: %li, %f";
Untuk menampilkan garis seperti itu, Anda harus menambahkan kode formulir
//Swift print(String(format: NSLocalizedString("stringWithArgs", comment: ""), "some", 123, 123.098 ))
Tetapi ketika menggunakan desain seperti itu Anda harus sangat berhati-hati! Faktanya adalah bahwa iOS secara ketat memonitor jumlah, urutan argumen, korespondensi jenisnya dengan literal yang ditentukan. Jadi, misalnya, jika Anda mengganti string sebagai argumen kedua alih-alih nilai integer
//Swift print(String(format: NSLocalizedString("stringWithArgs", comment: ""), "some", "123", 123.098 ))
maka aplikasi akan menggantikan kode integer dari string "123" di tempat ketidakcocokan
"String with some: 4307341664, 123.089000"
Jika Anda melewatkannya, kami dapat
"String with some: 0, 123.089000"
Tetapi jika Anda melewatkan objek yang sesuai dengan %@ dalam daftar argumen
//Swift print(String(format: NSLocalizedString("stringWithArgs", comment: ""), "123", 123.098 ))
maka aplikasi hanya akan crash pada saat eksekusi kode.
Dorong aku, sayang! Pelokalan pemberitahuan
Tugas penting lainnya dalam bekerja dengan sumber daya string terlokalisasi, yang ingin saya bicarakan secara singkat, adalah tugas melokalisasi notifikasi. Intinya adalah bahwa sebagian besar tutorial (baik pada Push Notifications dan Localizable Strings ) sering mengabaikan masalah ini, dan tugas-tugas semacam itu tidak begitu jarang. Oleh karena itu, ketika dihadapkan dengan ini untuk pertama kalinya, pengembang mungkin memiliki pertanyaan yang masuk akal: apakah ini pada prinsipnya mungkin? Saya tidak akan mempertimbangkan mekanisme operasi Apple Push Notification Service sini, terutama sejak mulai dengan iOS 10.0, pemberitahuan Push dan lokal diimplementasikan melalui kerangka kerja yang sama - UserNotifications .
Anda harus menghadapi masalah serupa ketika mengembangkan aplikasi server-klien multibahasa. Ketika tugas seperti itu pertama kali menghadang saya, hal pertama yang muncul di benak saya adalah membuang masalah lokalisasi pesan di sisi server. Idenya sangat sederhana: aplikasi mengirimkan lokalisasi saat ini ke backend saat startup, dan server memilih pesan yang sesuai saat mengirim push . Tetapi masalahnya segera matang: jika pelokalan perangkat berubah, dan aplikasi tidak dimulai ulang (tidak memperbarui data dalam database), maka server mengirim teks yang sesuai dengan pelokalan "terdaftar" terakhir. Dan jika aplikasi diinstal pada beberapa perangkat dengan bahasa sistem yang berbeda sekaligus, maka seluruh implementasinya akan bekerja seperti neraka. Karena solusi seperti itu segera bagi saya tampak sebagai penopang paling liar, saya segera mulai mencari solusi yang memadai (lucu, tetapi di banyak forum "pengembang" menyarankan untuk melokalisasi pushies tepat di backend ).
Keputusan yang tepat sangat sederhana, meskipun tidak sepenuhnya jelas. Alih-alih JSON standar yang dikirim oleh server di APNS
"aps" : { "alert" : { "body" : "some message"; }; };
perlu mengirim formulir JSON
"aps" : { "alert" : { "loc-key" : "message localized key"; }; };
di mana loc-key digunakan untuk meneruskan kunci string yang dilokalkan dari file Localizable.strings . Dengan demikian, pesan push ditampilkan sesuai dengan lokalisasi perangkat saat ini.
Mekanisme interpolasi string lokal dalam pemberitahuan push bekerja dengan cara yang sama:
"aps" : { "alert" : { "loc-key" : "message localized key"; "loc-args" : [ "First argument", "Second argument" ]; }; };
Kunci loc-args melewati array argumen yang harus disematkan dalam teks notifikasi yang dilokalkan.
Untuk meringkas ...
Jadi, apa yang kita miliki pada akhirnya:
- standar untuk menyimpan data string dalam file
.string khusus dengan sintaksis sederhana dan dapat diakses; - kemampuan untuk melokalkan antarmuka tanpa manipulasi tambahan dalam kode;
- akses cepat ke sumber daya lokal dari kode;
- pembuatan otomatis file pelokalan dan penataan sumber daya direktori proyek (aplikasi) menggunakan alat Xcode;
- kemampuan untuk melokalkan teks pemberitahuan.
, Xcode , .
.