Pengembangan Aplikasi Mobile

Aplikasi mobile dibangun, dirilis, dan disiapkan agar tim Anda tetap bisa merilis setelah saya selesai.

Saya lulusan Apple Developer Academy dengan pengalaman merilis ke App Store, dan saat ini mengelola siklus hidup aplikasi di App Store maupun Google Play. Artinya bagian-bagian yang merepotkan — signing, provisioning, review store, rollout bertahap — adalah hal yang sudah berulang kali saya kerjakan, bukan hal yang akan kita coba pahami bersama nanti.

Yang Anda dapatkan

• Source code di repository Anda, dengan aplikasi terdaftar di bawah akun developer milik Anda. Bukan milik saya.
• Build untuk iOS dan Android, dari satu basis kode Flutter atau dibangun native bila itu pilihan yang lebih tepat.
• Pipeline rilis otomatis — commit, lalu sebuah build sampai ke tester tanpa ada yang perlu menyentuh laptop.
• TestFlight dan internal testing Play Console yang sudah dikonfigurasi, dengan tim Anda diundang di dalamnya.
• Signing dan sertifikat yang disiapkan dengan benar, terdokumentasi, dan dimiliki oleh Anda.
• Pengurusan submission ke store: struktur teks listing, screenshot pada semua ukuran yang diwajibkan, deklarasi privasi, serta proses bolak-balik dengan tim review.
• Aset ikon dan splash screen yang dihasilkan untuk setiap kerapatan yang dibutuhkan.
• Crash reporting dan analitik yang sudah terpasang.
• Runbook yang mencakup cara membuat rilis, melakukan rollback, dan merotasi credential.
• Sesi serah terima bersama developer Anda, serta dukungan 30 hari pasca-peluncuran untuk perbaikan cacat.

Yang bisa saya bangun

Poster ini menyebut iOS dan Android, dan itu ringkasan yang jujur. Berikut bagaimana masing-masingnya benar-benar dikerjakan.

Aplikasi iOS

Native dengan Swift dan SwiftUI ketika sebuah aplikasi perlu terasa benar-benar native, atau harus menjangkau API platform yang dibungkus kurang baik oleh solusi lintas platform — CloudKit, widget, App Clip, HealthKit.

Lintas platform dengan Flutter ketika kedalaman itu tidak dibutuhkan, dan itulah kondisi yang paling sering terjadi.

Lewat jalur mana pun, bagian yang khas Apple menjadi tanggung jawab saya: signing, provisioning profile, TestFlight, serta percakapan dengan tim review App Store.

Aplikasi Android

Dibangun dari basis kode Flutter yang sama dengan aplikasi iOS-nya. Untuk sebagian besar produk, itu memang pilihan paling masuk akal secara ekonomi — satu tim, satu rangkaian pengujian, perilaku yang konsisten, dan beban pemeliharaan kira-kira separuh dari dua build native.

Penyiapan Play Console, jalur internal testing, dan rollout bertahap sudah termasuk.

Satu hal yang perlu saya sampaikan terus terang: saya mengerjakan Android melalui Flutter, bukan Kotlin native. Flutter menutup sebagian besar kebutuhan, dan bila memang benar-benar tidak cukup, saya akan menyampaikannya alih-alih memaksakannya.

UI & UX

Implementasi antarmuka dari desain Anda, atau default yang wajar bila desainnya belum ada: struktur navigasi, empty state, state pemuatan dan error, serta dasar-dasar aksesibilitas yang biasanya terlewat.

Perlu diselaraskan harapannya — saya mengimplementasikan antarmuka. Saya bukan perancang brand maupun identitas visual. Jika Anda membutuhkan itu, hadirkan orangnya dan saya akan membangun mengikuti karyanya.

Pipeline Rilis

Sering menjadi bagian paling bernilai, dan hampir selalu tidak tercantum dalam penawaran.

Build otomatis di Xcode Cloud, GitLab CI, GitHub Actions, atau Bitbucket Pipelines. Signing otomatis, sehingga sertifikat kedaluwarsa berhenti menjadi peristiwa yang merusak satu sore. Distribusi langsung ke TestFlight atau internal testing Play.

Saya melakukan tepat hal ini untuk sebuah aplikasi iOS berbasis Flutter dengan menggantikan build server Mac Mini on-premise memakai Xcode Cloud, termasuk scripting khusus yang dibutuhkan pipeline berorientasi Swift sebelum ia mau membangun Flutter sama sekali.

Teknologi

Bagaimana prosesnya

1. Pelingkupan. Daftar layar, platform, integrasi, kebutuhan store, dan apa yang di luar cakupan, secara tertulis.

2. Akun dan pipeline. Akun developer Anda, signing, dan build otomatis — disiapkan sebelum pekerjaan fitur, sehingga “bisa kirim build ke klien?” tidak pernah menjadi pertanyaan.

3. Pembangunan. Bertahap, dan bisa dipasang tester begitu bagian tersebut selesai.

4. Rilis. Submission ke store, penanganan review, dan rollout bertahap.

5. Serah terima. Runbook, pendampingan, masa dukungan.

Perlu Anda ketahui

Apple dan Google keduanya memungut biaya akun developer, dan keduanya meninjau submission sesuai jadwal mereka sendiri. Apa pun yang berpotensi memicu penolakan akan saya tandai sebelum kita mengirimkannya, bukan sesudahnya.

Hubungi saya

Sedang membangun sesuatu yang baru, atau tersangkut dengan aplikasi yang tidak bisa dirilis? Kirim pesan via WhatsApp.