En son kod yazmayı nasıl öğrendiğimi yazdığımda , açıkçası bu kadar çok ve güzel geri dönüşler almayı beklemiyordum. Bu dönüşler pek çok başlık altında toplanabilirler, ama en ağır basanı ‘ben bir mobil uygulama geliştirmek istiyorum, nasıl yaparım?’ tadında sorular oldu.
Hepsine teker teker benzer cevaplar yazmak yerine bir tane bütünlüklü cevap yazmayı tercih ettiğimden buradan yazmaya karar verdim. Baştan söyleyeyim, eğer bu yazı işinize yararsa başkalarının da işine yaraması için paylaşmanızı rica ediyorum.
Mobil uygulama geliştirmeniz için öğrenmeniz gereken programlama dillerini tek bir yazıyla öğretemem, lakin daha önce kullandığım ve işe yaradığını gördüğüm yöntemleri sizinle paylaşabilirim. Bunları mümkün olduğunca kısa başlıklar halinde topladım, başlayalım:
1- Gereklilikler
Her şeyden önce, İngilizce bilmeniz gerekiyor. Bilmiyorsanız işi gücü bırakın önce İngilizce öğrenin, kendinizi bir dünya kaynaktan yoksun bırakmayın derim.
Ardından, eğer iOS uygulamaları geliştirmek istiyorsanız maalesef bir Mac ihtiyacı var, başka türlü işiniz ciddi şekilde zor olur. Mac işini hallettikten sonra bir Apple Developer hesabı açmanız gerekiyor, uygulamanızı App Store’da yayınlayana kadarki süreci ücretsiz. Açtığınız bu hesap ardından XCode isimli IDE’yi (Integrated Development Environment) yani kod yazıp bu kodu çalışacak şekilde derlemek için kullanacağınız editöre ihtiyacınız olacak.
Android uygulaması geliştirmek için ise kullandığınız işletim sisteminin pek bir farkı yok. Android Studio sağolsun MacOS, Windows ve Linux için çalışan versiyonlara sahip. Android Studio Google tarafından JetBrains şirketi ile birlikte geliştirilmiş bir IDE. Kullanım kolaylığı açısından muhteşem iş çıkartmışlar, Android yazmaya geç başladığım için pişman olmamı sağladılar.
2- Planlama
Bu başlık açık ara en önemlisi. Kod yazmayı ne kadar iyi bilirseniz bilin, bu başlığı önemsemeden gidebileceğiniz nokta ciddi şekilde sınırlı olacaktır.
Planlamadan kastım geliştirmek istediğiniz uygulamanın en ince detaylarına kadar mümkün olabildiğince ayrıntılı bir dokümantasyonunu oluşturmanız. Bunu nasıl yapacağınızı Denklem isimli kitabımda anlattım, ücretsiz indirmek için linki burada .
Kısaca anlatmak gerekirse, uygulamanızın hangi ekranlardan oluştuğu, bu ekranların tam olarak ne yaptığı, birbirleri arasında geçişlerin nasıl olduğu, içeriklerinin nereden geldiği gibi pek çok detayı barındırması gerekiyor bu dokümantasyonun.
İster kendiniz yazın ister başkasına yazdırın, bu dokümanlar işin olmazsa olmazı. Tabii bunu yaparken hayallerinizdeki uygulamanın gerçekte yazılabilir olup olmadığını da incelemeniz gerekiyor.
Bunun en kolay yolu hedef platformunuzda istediğiniz özellikleri barındıran uygulamaları incelemeniz ve tam olarak hangi uygulamanın hangi özelliklerini içereceğini netleştirmeniz. Daha önce yapılmış olduğundan yapılabilir olduğu kesin olacak bu başlıkların.
Örneğin, bir Android uygulamasından cihazın doğrudan alarm sistemine ulaşabilecekken, bir iOS uygulamasından bunu yapamazsınız. Bunu bilmenizin yolu da yapmak istediğiniz alarm uygulamasının benzerlerinin nasıl çalıştığını incelemek olacaktır.
Buradan çıkartacağınız sonuçlar doğrultusunda, hayaller ve hayatlar arasındaki bağlantıyı çok daha net kurabilecek ve ona göre ilerleyebileceksiniz.
3- İş Akışı
Uygulamanızın özelliklerini tam olarak netleştirdikten sonra, sıra geldi nasıl çalışacağını belirlemeye. Bu kısım ilk başlarda sıkıcı olacak, ama sonrasında ne kadar işe yaradığını göreceksiniz.
İş akışından kastım, hangi ekranın hangisinde nereye tıklandıktan sonra geleceğini, neler içereceğini ve nasıl geri dönüleceğini içeren bir şema. Bu şemayı çıkartmak için kağıt ve kalemden başka bir araca ihtiyacınız yok, ama illa teknoloji kullanacağım derseniz Mac için OmniGraffle veya Windows/Linux için LucidChart kullanabilirsiniz.
Ben iPad Pro, Apple Pencil ve Evernote birleşiminin kendi açımdan en iyisi olduğuna karar verdim, denemek isteyenlere onu da tavsiye edebilirim.
Küçük kutucuklar çizip onlara ekran isimleri vererek işe başlayabilirsiniz. Bu tekniğin adı ‘thumbnailing’. Küçük kutular, kısa yazılar ve oklardan oluşuyor ve ciddi şekilde işinize yarayabilecek bir teknik.
Uygulamanızın bütün işleyişini çizerek tasarladıktan sonra kimi noktaları atladığınızı farkedeceksiniz. Bu işlemin asıl amacı da bu.
Örneğin, uygulamaya giriş ekranı tasarladığınızda, bir kayıt olma ekranına ve bir şifre yenileme ekranına da ihtiyacınız olduğunu farkedeceksiniz. ‘Ya işte kullanıcı login olacak’ demeye benzemiyor biliyorum, ama yapacak bir şey yok. Kod yazacaksak her adımı planlamamız gerekiyor.
İş akışı süreçlerini tanımladıktan sonra ihtiyacımız olan, uygulamanın tasarımı olacak.
4- Tasarım
Tasarımcı olmayabilirsiniz, hatta benim gibi düz çizgi bile çizemiyor olabilirsiniz. Lakin bu durum, bir uygulama tasarımı yapmanızın önünde engel teşkil etmiyor.
Sizin için uygulama tasarımları sunan pek çok yer var, örneğin benim en yoğun kullandığım ui8.net bu iş için ideal. Bu süreçte biraz para harcamanız gerekebilir, lakin buna değecektir.
Tasarımlarınızı düzenlemek için Photoshop, Gimp, Sketch App veya Adobe Experience Design kullanabilirsiniz.
Gimp haricindekiler ücretlidir, hazırlıklı olmanız gerekebilir.
Uygulamanızın tasarımını mümkün olduğunca gerçekçi bir şekilde yapmanız çok önemli. Gerçekçiden kastım, uygulamanızın tam olarak ne içerdiğinizi bildiğinizden, bütün içeriklerin planınıza uygun olduğundan emin olmanız. Aynı zamanda hedef platformunuzun veya platformlarınızın gerekliliklerini de içeriyor olması gerekiyor.
Örneğin bir iOS uygulaması için ekran tasarlarken ‘geri’ butonu eklemeniz gerekirken, bir Android uygulamasında buna ihtiyacınız yok.
Aynı zamanda görsel açıdan söz konusu platformun o anki tasarım yönelimlerine uygun olması da kullanım kolaylığı açısından ciddi bir artı olacaktır.
Yine bir örnek vermek gerekirse, iOS 6 ve düşük sistemler gerçekçi bir tasarım sistemi kullanırken, iOS 7 ve üstü sistemler minimal tasarım kullanır. Android için de yine Google’ın geliştirdiği ve Android Studio’ya da entegre ettiği ‘Material Design’ sistemine aşina olmanız gerekebilir.
Bütün ekranlarınız içerisindeki bütün ayrıntıları tasarladığınızı düşünelim. Sıra geldi bu tasarımları uygulanabilir hale getirmeye.
5- Uygulanabilir Tasarım
Mobil uygulama geliştirme sürecinin en sıkıcı ve en zorlayıcı kısmından herkese merhaba.
Şimdi yapmanız gereken, tasarımlarınızdaki herbir öğenin kendine özel PNG dosyalarını oluşturmak.
Platformlara özgü pek çok özellik söz konusu olduğundan bu işlem biraz karmaşık gelebilir. Mümkün olduğunca basit haliyle anlatayım:
Bir iOS uygulaması geliştiriyorsanız, kullanacağınız herbir resim öğesi için 3 farklı boyuta ihtiyacınız var. iPhone 6 boyutları en çok kullanılan tasarım boyutları olduğundan örnek olarak onu vermenin uygun olacağını düşündüm.
Örneğin tasarımlarınızı 750x1334 piksel boyutunda ekranlara göre yaptınız. Tasarımlarınız iPhone 4 ile birlikte gelen ‘Retina Display’ özelliğine uygun durumda. Yani normal resim boyutlarının 2 katı.
Bu durum, tasarımınızda 100x100 piksel boyutunda bir nesnenin, uygulamada kullanacağınız boyutunun 50x50 piksel olduğu anlamına geliyor. Ayrıca iPhone 6 Plus ile gelen 3 katı boyutunda yani 150x150 piksellik bir resme de ihtiyaç duyacaksınız.
Bu resimleri isimlendirirken yapacaklarınız çok önemli, zira XCode bunları otomatik olarak nerede kullanacağını bu sayede biliyor olacak.
En küçük resminizin ismi “buton.png” ise, 2 katı olan resminizin ismi “[email protected]” ve 3 katı olan resminizin ismi “[email protected]” şeklinde olmak durumunda. XCode bunları sürüklediğinizde tek bir resmin farklı boyutları olduğunu anlayacak, onu dert etmeyin.
Öte yandan bir Android uygulaması geliştiriyorsanız, işiniz biraz daha zor olacak. Çok fazla android cihazı olduğundan, herbir cihaz tipi için özel olarak klasörleme yapmanız gerekiyor. Bu yazı yazılırken en düşük boyut “ldpi” iken, en yüksek boyut “xxxhdpi” olduğundan örneği ona göre vereceğim.
Bu arada, Android uygulamasında resimleri ve diğer kaynakları isimlendirirken büyük harf kullanamazsınız. Yani iOS uygulamasında ‘[email protected]’ gibi bir resminiz olabilirken, Android uygulamasında bunun “btn_register.png” şeklinde olması gerekiyor. Alt tireyi kullanmak durumunda değilsiniz, ama “camelCase” dediğimiz olayın karşılığı olarak kullanıldığından öyle yapmanızı öneririm.
Herbir çözünürlük için ayrı klasörlere ihtiyacınız olacak. Yani normal dosya sisteminizde, “drawable-ldpi”, “drawable,mdpi”, “drawable-hdpi”, “drawable-xhdpi”, “drawable-xxhdpi” ve “drawable-xxxhdpi” isminde klasörleriniz olması, hepsindeki “btn_register.png"nizin aynı isimde ve ilgili boyutlarda olması gerekiyor. Yazdığım sırayla boyutların 0,75x, 1x, 1.5x, 2x, 3x ve 4x şeklinde olması gerekiyor. Evet, bence de karışık.
Gelgelelim, Adobe’nin en son uygulaması Experience Design, size tek bir dışa aktarma işlemiyle bütün resimleri ilgili klasörlere bölünmüş halde sunuyor. Aylık 88 lira verebilecek durumdaysanız, Adobe Creative Cloud üyeliği almanızı ve henüz beta sürümünde olan Experience Design kullanmanızı şiddetle tavsiye ederim.
Geri kalan programlarda malesef bu işlemi elle yapmak durumundasınız.
6- Tasarımın Uygulanması
Bütün resimlerinizi bir şekilde dışa aktarmayı becerdiğinizi varsayıyorum. Varsayıyorum, zira bir yerlerde eksiklik kaldığını anlayıp süreci baştan almanız gereken durumlar olacaktır, bana onca yıldan sonra hala oluyor.
Geldik resimlerin uygulama içine atılmasına. Bu işlem bir sürükle-bırak işlemi olduğundan kolay olacak, çok da abartmaya gerek yok. İsimlendirmeleri doğru yaptıysanız bu adımda korkmanız gereken bir şey yok.
Gelelim ekranların uygulama IDE’sinde tasarlanmasına. Kodu yazmaya başlamadan bu işleme başlıyoruz, bu sayede kodu nereye yazacağımızı daha iyi anlayabilir duruma gelmeyi hedefliyoruz.
iOS uygulamalarında kullanacağımız yerin adı ‘storyboard (eski ismiyle interface builder)’. Storyboard dosyamızı açıp ‘thumbnailing’ sürecinde çizdiğimiz kutucukları (genelde UIViewController) ve okları (Segue) XCode içine yerleştiriyoruz.
Ardından 1x boyutunda çalışıyormuş gibi resimlerimizi de ilgili yerlere yerleştiriyoruz. Bu işlem beklediğiniz kadar kolay olmayacak, zira üzülerek söylüyorum ki ‘autolayout’ denilen sistem koyduğunuz şeylerin koyduğunuz yerde durmasını engelleyecek.
Autolayout, iOS sistemlerine 5. versiyondan katılan ve farklı cihaz boyutlarında beklediğimiz görünümü almamızı sağlamayı amaçlayan bir sistem. Burada yazdığım konulara ait eğitsel materyalleri YouTube dahil pek çok alanda bulabilirsiniz, bu yüzden herbirinin ismini ve neye yaradığını söylemekle yetiniyorum. Yoksa bu yazı bitmez.
Storyboard içine yerleştirdiğimiz resimlerimizi ve diğer kontrol nesnelerini autolayout ile birlikte yerine oturttuktan sonra, herbirini ilgili ‘class’ lara IBOutlet ve bir işe yarayacaksa “IBAction” olarak bağlamamız gerekiyor. Buradaki “IB”, yukarda bahsettiğim “Interface Builder"ın kısaltması, ona çok takılmamak lazım.
Bu işlem de bir sürükle-bırak-isimlendir işlemi olduğundan, biraz uzun sürse de çok zor olmayacak.
Gelelim Android’e.
Android, bu bahsi geçen autolayout sistemine benzer düzenleme sistemlerini ilk versiyonundan bu yana kullanıyor, o yüzden biraz daha şanslısınız.
Gelgelelim, Android sistemlerinde storyboard benzeri bir yapı yok. Yani iOS içerisinde yıllar önce kullandığımız ve artık eskiyen bir yöntem olan tek tek ekran tasarlama yönteminin bir alternatifi Android’de mevcut değil.
Teker teker ekranlarımızı tasarlamak Android’de “layout” yapılarını bildikten sonra çok zor bir işlem değil. Ayrıca Android’de isimlendirme yapmak için ek bir sürükle-bırak işlemine ihtiyacınız yok, doğrudan eklediğiniz her şeyin isimlendirmesini kendi üstünde “id” alanı aracılığıyla yapabiliyorsunuz. Sonrasında koddan doğrudan bu id’ler aracılığıyla nesneleri çağırmanız mümkün oluyor.
Buraya kadarki iş yeni başlayanlar için bir çile olacaktır, bunun farkındayım ama tekrar edeyim, her yer bu alanda kaynaklarla dolu. İngilizce bilmiyorsanız ivedilikle öğrenmenizi önermem de bu yüzden.
7- Uygulama Mimarisi
Geldik olayın en karmaşık kısmına. Karmaşık olduğu doğrudur, ama düzgün yapılırsa kod yazma kısmı samanlıkta iğne aramaktan öteye geçip düzenli ve güzel bir işe dönüşecektir.
Uygulama mimarisi, adından da anlaşılacağı üzere uygulamanın aslında nasıl çalıştığını net olarak yazılı hale getirmek demek.
Bu adımı atlayıp doğrudan koda gömüldüğüm çok oldu, kesinlikle önermiyorum.
Herbir butonun, herbir resmin ve herbir nesnenin yapacağı bütün işlerin net olarak yazılı hale getirilmesi gerekiyor. Mimariden kastım basitçe bu.
Yani bir ‘giriş’ butonunuz varsa, bunun yapacağı giriş işleminin nasıl olacağı, ne zaman yapılacağı, kullanıcının ekranını kitleyip kitlemeyeceği, herhangi bir animasyon içerip içermediği gibi mümkün olduğunca çok bilgi içermeniz gerekiyor.
Anlatması kolay tabii. Yakın bir zamanda bir iOS Bootcamp daha yaparsak orada uygulamalı olarak göstermeyi de planlıyorum. Orada daha da net görebilirsiniz.
8- Arkaplan Sistemi
Tamam kullanıcı giriş yapacak, lakin nereye giriş yapacak?
Kullanıcılarınızın bilgilerini tuttuğunuz, istediğiniz fotoğrafı yüklediklerinde herkese görünmesini sağlayan, fotoğrafı beğendiklerinde o beğeni sayısını artıran bir sisteme ihtiyacınız var. Bunun adı arkaplan sistemi.
Bu kendi başına tamamen başka bir geliştirme süreci anlamına gelebilir. Ayrıca bir uzmanlık alanı ve tonla ayrıntıyı kendi içinde barındırabilir. Gelgelelim bunun farkında olan Google gibi büyük ve güzel şirketler, bizi bu yükten kurtaracak uygulamalar geliştiriyorlar.
Geçtiğimiz günlerde tamamen yenilenen Firebase, Google tarafından desteklenen ve artık tam anlamıyla bir arkaplan sisteminden her ne bekliyorsanız sunmayı amaçlayan bir yapı.
Üstelik canlı bir yapı olduğundan kullanıcı deneyiminiz de muhteşem bir hale geliyor. Kullanıcılarınıza sunduğunuz sistem normal koşullarda çok ciddi bir geliştirici kaynağı harcamanızı gerektirirken, Firebase gibi bir altyapı kullanarak bu sorundan tamamen kurtulmuş oluyorsunuz. Evet, çok büyük bir ihtimalle tamamen.
Firebase size canlı bir veritabanı sunarken, aynı zamanda farklı kaynaklardan (Facebook, Google, Email, Twitter, Github ve niceleri gibi) kullanıcı girişi yapmanızı da sağlıyor. Aynı zamanda yeni entegre ettikleri ve ücretsiz/sınırsız olarak sundukları Google Analytics ve bildirim sistemi de cabası.
Firebase dosyalarınızı da depoluyor, ihtiyacınız varsa size Petabyte’lık (çok yani çok) alan dahi sunabiliyor. Üstelik hız konusunda da sorun yaşamanız mümkün değil, zira sistemler Google sunucuları üzerinde.
Aynı zamanda iOS ve Android için çatır çatır çalışan kütüphaneler de sunuyor. (Android’de bir ufak sorunları var, onu da yakında çözerler)
İşin kısacası, oturup Firebase mi öğreneceksiniz? Evet.
9- Kodlama
Geldik işin en zevkli kısmına. Zevkli dediğime bakmayın, eğer yukarda anlattığım işlemleri layıkıyla yapmadıysanız bu süreç canınızı ciddi şekilde yakacaktır.
Hani o “how to build an Android App in 2 hours” diye dersler var ya sağda solda, ha onlar işte bu adımı anlatıyorlar. Oradaki eğitmenlerin ne yaptıklarını çok iyi biliyor gibi görünmeleri yukardaki adımlarla ilgili, onu unutmamak lazım.
iOS geliştirme yapmak istiyorsanız, Objective-C veya Swift bilmeniz gerekiyor. Önerim yeni başlıyorsanız Swift ile başlamanız, daha önce Objective-C yazdıysanız da Swift’e geçmeniz olacaktır. Zira ciddi bir hızla gelişiyor ve açık kaynak kodlu olması sayesinde yakında pek çok farklı alanda da kullanılabilir olacak.
Android geliştirme yapmak istiyorsanız da, Java öğrenmeniz gerekecek. Java çok eski bir dil, o yüzden Swift’e göre çok daha karmaşık gelebilir. Ama eski olması, her türlü olası duruma dair bir fikri olduğu anlamına da geliyor, ‘rock-solid’ dediğimiz şekilde çalışıyor ve hız açısından da gayet başarılı.
Ha “cross-platform” diye bir şey de var, tek bir kodla (Genelde JavaScript – Java değil) birden fazla platforma uygulama geliştirmenizi sağlıyor, lakin benim önerdiğim bir alan değil. En azından henüz.
Uygulamanızın kodlanması sürecinde eğer doğru bir mimari yaptıysanız önünüzde yazılması gereken kodların aşağı yukarı belli olması gerekiyor, bu yüzden o anda yazdığınız kodun ne işe yaraması gerektiğine dair de net bir fikriniz olacaktır.
Sonrası Google, sonrası Stackoverflow (o İngilizce buraya gelecek).
10- Test, Test ve Yine Test
O kadar kod yazdınız, uygulamayı çalıştırmayı da bir şekilde başardınız, her şey ilk başta güzel görünüyor. Giriş butonuna bastınız, giriş de yapıyor.
Lakin gözünüzden kaçan bir şey var: Giriş butonuna bastıktan sonra giriş yapılırken kullanıcının arayüzünü kitlemeyi unuttunuz. Bunun sonucunda kullanıcılara zilyon kere o butona basma şansı vermiş oldunuz. ‘Yok bunu yapmazlar’ demeyin, emin olun yaparlar.
İşte bu gibi durumları anlamanızı ve çözmenizi sağlayan şeyin adı test. Mümkün olduğunca çok kullanıcıya uygulamanızın sağını solunu patlatma görevini vermeniz ve onları yaparken izlemeniz gerekiyor. Ha profesyonel test mühendisiniz vardır, onu bilemem. Ama aksi durumda o sorunların nasıl oluştuğunu görmeniz ve anlamanız için orada olmanız şart.
Bir çok test kullanıcınıza uygulamanızı dağıtmanın iOS tarafındaki benim gördüğüm en iyi yolu Twitter destekli bir sistem olan Fabric (eski adıyla Crashlytics). Apple destekli bir de TestFlight sistemi var, lakin ben ona bir türlü ısınamadım, haliyle öneremiyorum.
Android tarafında yapmanız gereken daha basit. Derlenmiş uygulamanızı içeren APK dosyasını Google Drive gibi bir yere atmanız ve test edecek zat’ı muhteremlere o dosyanın linkini vermeniz yeterli.
Testler yapıldıkça yeni sorunlar çıkacaktır, bunlarla karşılaşmaktan korkmamanız önemli. Test sürecinde çıkacak sorunlar canlı sistemde çıkacak sorunlardan her zaman çok daha iyidir, en azından aranızda kalır, kimse sizi bu sorunlardan ötürü suçlamaz, kötü yorum yapmaz, yerden yere vurmaz (bu işi Türkiye’de yapıyorsanız, yerme kültürümüz sağolsun her türlü yaparlar tabii, o ayrı).
11- Hata Ayıklama
Test yapması için arkadaşlarınıza uygulamayı dağıttınız, bir yandan da kendiniz kullanıyor ve sağı solu deniyorsunuz. Herhangi bir kaynaktan bir sorunla karşılaştınız. Şimdi sıra o sorunu çözmeye geldi.
Herhangi bir kod yapısı içerisindeki bir sorunu çözmenin en mantıklı yolu, o sorunun temel kaynağını bulmaktır. Testleri yapan arkadaşınız size ayrıntılı olarak nerede ne yapınca sorunla karşılaştığını anlattıktan sonra, onu geliştirme sisteminizden aldığınız bir derleme üzerinde tekrar etmeniz gerekiyor.
Tekrar ettiğinizde, “debug” dediğimiz süreç başlıyor. İlgili soruna yol açan kod satırı veya satırlarını bulup, olması gerektiği şekilde düzenlemeniz gerekecek. Bu işlem sıkıntılı bir işlem olacaktır, lakin ne kadar sorunla karşılaşır ve çözüm bulursanız o kadar iyi kod yazar hale geleceksiniz, bu yüzden bunlarla yüzleşmek lazım.
Ayrıca her sorun kodlama hatasından kaynaklı olmayabilir, yukarda verdiğim giriş butonu örneği de bunlardan biri. Bunlar ‘görünmeyen sorunlar’ olarak tanımlanır ve bunları düzeltmek için ek özellikler eklemeniz gerekebilir.
Haliyle siz uygulamanızı test için açtıktan sonra yayınlama noktasına gelene kadar bir uygulama kodu daha yazdığınızı farkedebilirsiniz, bunda bir sorun yok.
12- Yayınlama
Test ve hata ayıklama süreçlerini geride bıraktıktan sonra, sıra en güzel ve bir o kadar da sıkıcı işleme geliyor: Uygulamayı ilgili pazarlarda yayınlama.
Eğer uygulamanız iOS ile geliştirilmiş ve App Store’da yayınlanacaksa, bu size senelik 99 dolar vermek durumunda olduğunuz bir Apple Developer hesabına malolacaktır, üzgünüm ki bunun başka bir yolu yok.
Ardından sizi uygulamanızın App Store’daki listelenme sayfasını düzenleyebileceğiniz ‘iTunesConnect’ diye bir yere alacaklar. Burada uygulamanızın açıklamasını, ekran görüntülerini, ikonunu, hitap edebileceği yaş sınırını ve bunun gibi pek çok bilgiyi girmeniz istenecek. Bunları teker teker gireceksiniz.
Android tarafında olay biraz daha az maliyetli. Yani en azından senelik bir ücret ödemek durumunda değilsiniz. Doğrudan uygulama yayınlama işine girişebiliyorsunuz. Yine bir ton bilgi girmeniz gerekiyor, onlara dair de YouTube üzerinde pek çok kaynak bulmanız mümkün.
Uygulamaları yükledikten sonra iOS için 1–2 günlük, Android için 1–2 saatlik bir süreç başlıyor. Apple bütün yüklenen uygulamaları teker teker inceliyor, Android bunu eğer şikayet gelirse veya ek bir sorun olursa yapıyor, yoksa yapmıyor.
Her iki pazarın da kendi gereklilik listeleri var, onları inceleyip uygulamanızın kurallara uygun olup olmadığına bakmanızı öneririm. Aksi durumda Apple acımadan reddediyor uygulamanızı. Sonra düzelt, tekrar yükle, birkaç gün kaybetmeniz mümkün oluyor.
Sonuç
Mümkün olduğunca kısa ve ek bir bilgi gerektirmeyecek şekilde mobil uygulama geliştirme süreçlerini anlatmaya çalıştım.
Buraya kadar gelebildiyseniz, öncelikli önerim; platformu ne olursa olsun basit bir mobil uygulama yapmaya başlamanızdır. Uygulama her şeyi içermek durumunda değil, olabilecek en basit özellikleri barındırsın, sizi yukarda anlattığım süreçlere ısıtsın yeterli.
Süreç içerisinde pek çok sorunla karşılaşacaksınız. Bu sorunları önce Google’da aratmanızı, ardından Stackoverflow’a iletmenizi öneriyorum.
Bu arada yukarıda bahsettiğim gibi girişimcilerle yazılımcıların ilişkisini konu alan bir kitabım var, linki burada .
Seviyorum sizi.