Bir sürümü mağazaya yollamak, kodu yazmaktan daha tehlikeli olabilir. Çünkü hata artık senin ekranında değil, kullanıcının cebinde ortaya çıkar. Aşağıdaki liste, her sürümden önce istisnasız geçtiğim adımlar — ve her biri bir gece yarısı paniğiyle öğrenildi.
1. Yayın derlemesini kendi cihazında test et
Geliştirme derlemesiyle her şey çalışıyor olabilir; ama mağaza sürümü kodu küçültür ve sıkıştırır. O optimizasyon bazen kritik parçaları söküp atar — uygulama açılışta donar. Bu yüzden mağazaya yolladığım derlemenin birebir aynısını önce kendi telefonuma kurarım.
Bir kez, açılışta takılan bir sürüm yolladım. Sebep: optimizasyonun kaldırdığı bir bileşendi. Geliştirme derlemesinde asla görünmezdi.
2. Bildirimlerin gerçekten geldiğini gör
Bildirim planlanmış görünebilir ama ekrana hiç düşmeyebilir. Küçük bir yapılandırma eksiği, sistemin bildirimi sessizce çöpe atmasına yol açar — ne hata, ne uyarı. Gerçek cihazda, gerçek saatte bir bildirimin geldiğini görmeden "çalışıyor" demem.
3. Cihaz dilini değiştir
Bazı diller harfleri beklenmedik biçimde küçültür ve içerideki karşılaştırmalar sessizce kırılır. Uygulamayı hedef dilde en az bir kez baştan sona gezmek, bu tuzağı yakalar.
4. Test bayraklarını kapat
Geliştirirken limitleri gevşetir, kapıları açarım. Bunları kapatmayı unutmak, ücretli özelliği herkese bedava açmak demek. Artık her sürümden önce koddaki tüm "test" ve "devre dışı" bayraklarını tarayan tek bir komut çalıştırıyorum.
5. Ödeme akışını canlı test et
Satın alma altyapısı değiştiyse, statik testler yetmez — gerçek bir sandbox işlemi yapmadan "satın alma çalışıyor" diyemem. Gelirin bağlı olduğu tek yol burası; iki dakikalık test, günlerce süren şikâyeti önler.
6. Sürüm numarasını yükselt
Basit ama en sık unutulan adım. Mağaza aynı sürüm kodunu ikinci kez kabul etmez; yükseltmeyi atlarsan yükleme reddedilir.
Bu liste sıkıcı görünebilir. Ama tek kişilik bir stüdyoda güvenlik ağı sensin — ve bu altı adım, o ağın düğümleri.
Shipping a release can be more dangerous than writing the code. Because now the bug doesn't surface on your screen — it surfaces in the user's pocket. Below is the list I run before every release, without exception, each item learned through a midnight panic.
1. Test the release build on your own device
Everything may work in a debug build, but the store version shrinks and compresses the code. That optimization sometimes strips out critical pieces — and the app freezes on launch. So I install the exact build I'm about to ship onto my own phone first.
Once I shipped a version that hung on the splash screen. The cause: a component the optimizer removed. It never showed up in a debug build.
2. See notifications actually arrive
A notification can look scheduled yet never reach the screen. A tiny config gap makes the system silently drop it — no error, no warning. I don't say "it works" until I've watched one land on a real device at a real time.
3. Switch the device language
Some languages lowercase letters unexpectedly, and string comparisons quietly break. Walking through the app once end-to-end in the target language catches this trap.
4. Turn off test flags
While developing I loosen limits and open gates. Forgetting to close them means handing a paid feature to everyone for free. I now run a single command that scans the code for every "test" and "disable" flag before each release.
5. Test the purchase flow live
If the billing layer changed, static checks aren't enough — I can't claim "purchases work" without a real sandbox transaction. It's the one path revenue depends on; a two-minute test prevents days of complaints.
6. Bump the version number
Simple, but the most-forgotten step. The store won't accept the same version code twice; skip the bump and the upload is rejected.
This list may look tedious. But in a studio of one, you are the safety net — and these six steps are its knots.