XCode’da Build Numarası Otomatik Olarak Nasıl Artırılır?

Yazılım geliştirirken karşılaştığımız kod dışında kalan birçok zorluk vardır. Bunlardan bir tanesi test. Beta dağıtımı hangi sağlayıcı üzerinden olacak? CI-CD süreçleri nasıl olacak? Kod nerede saklanacak? Teknik bilgi takım içerisinde nasıl dağıtılacak? Versiyonlama nedir? Build Numarası nedir? Uygulama yayınladıkça 1.0 dan 2.0 a çekilen Apple Store’un artırmamızı istediği sayıdan ibaret midir? Ve daha bir sürü soru aklımıza gelmektedir.

Yazılım geliştirmede karşılaştığımız sorunlardan bir tanesi de versiyonlamadır. Günlük hayatımızda kendisiyle sıkça karşılaşırız. Kullandığımız yazılımsal ürünlerin menüsünde, profil sayfasında, ayarlar sayfasında, sağında, solunda… v1.4.3 veya x.y.z gibi numaralandırmalar illaki gözümüze çarpmıştır. Bunlar versiyonlamanın ta kendisidir. Peki neye göre ve nasıl yapılır bu versiyonlama? Neye göre ve nasıl yapıldığı, firmanın sektördeki pozisyonuna, yaptığı işlere veya geliştiricinin keyfine göre tamamen farklılık gösterebilecek bir durumdur. Dünya genelinde sabit bir versiyonlama tekniği olmamakla birlikte, kullanılan teknikler birbirleriyle oldukça benzerdir. En yaygın kullanılanı da semantik versiyonlamadır. Biz de Peakup Labs mobil geliştiricileri ekibi olarak bu versiyonlama tipini kullanmaktayız. Semantik versiyonlamanın detaylarını buradan öğrenebilirsiniz. Versiyonlama konusunda bir çok Türkçe kaynak da vardır bu arada.

Build Numarası Nedir?

Çok temel bir şekilde anlatacağım. Bir yazılım ürününü geliştirirken genel olarak tüm ürünü bir anda ortaya koymuyoruz. Başlıyoruz bir şeyler yapıp kullanıcıya/tester a/yöneticiye… yolluyoruz. Yolladığımız kişi bakıyor ve şunları ekleyebilir miyiz, bunları değiştirebilir miyiz, şurada hata var… şeklinde geribildirim veriyor. Yapıyoruz tekrar gönderiyoruz. Peki gönderdiğimiz kişi bu 2 ürünü nasıl ayırt edecek? İşte burada versiyonlama ve build numarası devreye giriyor. İlk ürünümüzün numarası 1.0 iken ikinci ürünümüzün numarası 1.1 olduğu zaman, ikinci ürünün daha sonra çıktığını kullanıcı kolayca ayırt edebiliyor. Bazen 2. ürün yerine 1.ürünü kullanan bir kullanıcı olduğu ve 1.1 de düzelttiğimiz bir hatadan bahsettiği zaman direkt olarak kendisine 1.1 sürümünü indir orada o hatayı çözdük diyebiliyoruz mesela.

Build numarası da versiyon numarası da ürünü kimliklemek için kullanılan numaralardır.

Bu numaraların tek görevleri tabiiki kullanıcının sürümleri ayırt edebilmesi değildir. Aynı zamanda AppleStore veya Google Play Store aynı sürüm numarasına sahip build ları güncelleme olarak görmediği için yayınlamamaktadır. Belirli bir şekilde Build numarasının ve versiyon numarasının artırılması gerekmektedir. Versiyon numarası elle artırılabilir. Çünkü güncellememizin büyüklüğünü sistem bilemez belirleyemez bunu bilen bizzat geliştirici olduğu için genel olarak kendisinin artırması daha uygun oluyor. Ancak Build numarasını sürekli elle artırmak gerekmez. Adı üstünde Build numarası. Her Build’da artırılır. Bunu sürekli elle artırmak gibi bir iş bence Geliştirici olmanın ruhuna aykırı. Yazdığımız sistemi, uygulamayı otomatiğe bağlamaya çalışırken build numarasını sürekli elle artırmak resmen çelişkidir 🙂

IOS Ortamında Versiyonlama Sistemi

Şimdi gelelim fasülyenin faydalarına. Bu yazıda build numarasını nasıl otomatiğe veya git commit sayısına bağlayabileceğimizi anlatacağım. iOS uygulamaları yukarıda da bahsettiğimiz gibi 2 ayrı tipte versiyon numarasına sahiptir.

  • Short bundle version string CFBundleShortVersionString (e.g. 1.12)
  • Build Number CFBundleVersion (e.g. 190)

Her “Short version” içinde birden fazla build barındırır. Build ların herbiri de “Bundle Version” a tekabül eder. Yani build numarası her build yapıldığında artırılırken Versiyon numarası birkaç build dan sonra artırılır. Alttaki ekran görüntüsünde gördüğünüz üzere 1.4 Versiyon numarasına sahip sürüm, 34 ve 35 numaralı 2 farklı build barındırıyor.

Versiyon ve build numaralarından gereğinden uzun bahsettiğimize göre artık sadede gelip Build numarasını otomatik olarak nasıl artırabileceğimize geçelim. Çok basit bir Shell script kullanarak bunu başarabiliriz

buildNumber=$(/usr/libexec/PlistBuddy -c "Print CFBundleVersion" "${PROJECT_DIR}/${INFOPLIST_FILE}")buildNumber=$(($buildNumber + 1))/usr/libexec/PlistBuddy -c "Set :CFBundleVersion $buildNumber" "${PROJECT_DIR}/${INFOPLIST_FILE}"

Yukarıdaki script plist dosyasındaki build numarasını alır, 1 yükseltir ve elde edilen yeni sayıyı XCode’un PlistBuddy özelliğini kullanarak plist dosyasına geri yazar.

  • ${PROJECT_DIR} :  Ana projenin tam yolu
  • ${INFOPLIST_FILE}:  Info.plist dosyasının tam yolu

XCode’da Build Numarasını Otomatik Olarak Artırmak

İyi güzel hoş da XCode’da bunu nasıl yapabiliriz? Öncelikle bu yazı XCode 11.4 versiyonunu kullanarak yazılmıştır. İlerleyen XCode sürümlerinde bir şeylerin yeri değişirse eğer yazı güncellenecektir. Eğer güncellenmemişse bize ulaşmanız yeterlidir anında güncellenir. Adım adım yazdıklarımızı uyguladığınız takdirde Build numarasını otomatik olarak artırabilirsiniz.

    1. Uygulama Target alanını, ardından Build Phases sekmesini seçiyoruz
    2. Yeni bir Script eklemek için yukarıdaki + butonuna basıyoruz
    3. Açılan pencereden New Run Script Phase‘i seçiyoruz
    4. Yeni Script ekranı açılınca, alttaki ekran görüntüsünde gördüğünüz bölüme yukarıda yazdığım script parçasını yazıyorsunuz. Bu arada bu scriptin adını da değiştirebiliyorsunuz. İsimlendirme ımmm severiz
    5. Projeyi Build ettiğiniz zaman Build numaranız otomatik olarak artırılacaktır.

Build numarasını bu şekilde artırmak her ne kadar güzel bir yaklaşım olsa da ben bir türlü sevemedim. 🙄

İçinizden “ya arkadaş bu kadar yazıyı boşa mı yazdın buraya kadar boşa mı okudum seni tatmin etmek için daha nasıl build numarası artıralım?” dediğinizi duyar gibi oluyorum. Bu yaklaşım Build numarasını artırmakta Best Practice değil. Peki nedir bu konudaki Best Practice?

Tabiiki Build numarasını Git commit sayısına bağlamaktır. 

Build Numarasını Git Commit Sayısına Nasıl Bağlayabilirim

Eğer build numarasını git commit sayısına eşitlerseniz, build numarası arşa çıkmış olmaz. Ayrıca Apple Store ve iş arkadaşlarımızın istediği gibi daima bir önceki sürümden fazla olacağı garantidir. Her build de bu numarayı artırmak, zaman içerisinde bu numaranın çok fazla artmasına neden olabilir. Peki bu numaranın çok fazla artmasının bir zararı var mıdır yoo. Tamamen keyfimden git commit sayısına bağlıyorum 🙂

https://gist.github.com/alparslandev/51ad5bc0192ad4d52ffcac02d5e3b541

Yukarıda paylaştığım gistte gerekli scripti yazdım. Sizin de gördüğünüz üzere Build numarasını Git commit sayısına bağlı olarak artırmak tabiiki mümkün. Gistteki scripti yukarıda anlattığım şekilde 4. adımda gösterdiğim boşluğa yazabilirsiniz.

iOS Development hakkındaki diğer yazılarımıza buradan
Android ve Kotlin üzerine olan yazılarımıza buradan erişebilirsiniz.

Ali iyi bir yazılım geliştiricidir. Kendini geliştirmeyi yeni şeyler öğrenmeyi çok sever. Build numarasını sadece Apple Store’a uygulama yayınlayacağı zaman öğrenenlerden değildir. Çok daha önceden versiyonlamanın ve build numarasının değerini öğrenmiştir zaten. Ali Apple Store’a güncelleme yollayamadığında “aa Build numarası 1.0 kalmış. 2.0 yapayım o zaman” diyenlerden değildir. Ali Build numarasını otomatiğe bağlar ve Versiyonlama numarasına da çok titiz bir şekilde dikkat eder.

Ali için sürüm notları da çok önemlidir. Ali hep güzel, anlaşılır, kullanıcının hoşuna gidecek sürüm notları yazar. Çok küçük bir uygulama yazıyor bile olsa versiyonlama sistemini düzgün kurar ve artırır. Sonuçta nasıl alışırsa öyle gider değil mi? Eğer Ali bir kere bile amaann salla gitsin derse bunun sonunun hayra alamet olmayacağını çok iyi bilir. Boş vermeye alışmanın eninde sonunda olmadık yerde çok büyük bir patlamaya ve prestij kaybına yol açabileceğini çok iyi bilir.

Ali gibi olun. Çalışın.

Kaynaklar

https://developer.apple.com/library/archive/technotes/tn2420/_index.htmlhttps://crunchybagel.com/auto-incrementing-build-numbers-in-xcode/https://www.mokacoding.com/blog/automatic-xcode-versioning-with-git/https://fuller.li/posts/versioning-with-xcode-and-git/

Jetpack Compose & SwiftUI

Herkese Merhaba. Peakup’ta Android Developer olarak çalışmaya başlayalı 6 ay oldu. Gidişat çok güzel. 5 ayda Google Play Store’a 5 adet sağlam Android uygulama yayınladık. Buradan uygulamalarımızın listesine erişebilirsiniz. En son yaptığımız İzin Yönetimi Android uygulamamız 12 Ekim 2019 tarihinde Google Play Store’a yüklendi ve kullanıma hazır hale geldi. Bu tarihten itibaren (yani 1 aydır) XCode ile iOS uygulamaları yazmaya başladım.

Android ve iOS ortamları cihaz olarak farklılar biliyorsunuz. Geliştirme ortamındaki fark cihaz farkından kat be kat fazla. Yeni bir dil, yeni bir IDE, yeni UI, yeni bir tasarım anlayışı, yeni kullanıcı alışkanlıkları, yeni … derken başlarda açıkçası sudan çıkmış balığa dönmüştüm. Swift ve Kotlin birbirine çok yakın diller olduğu için dil konusunda şanslıydım. Peki arayüz? Çok farklıydı. iOS’ta sürükle bırak kullanılıyordu kendimiz koda müdahale etmiyorduk ama Android’de de tam tersi sürükle bırak kullanmıyorduk. Derken SwiftUI’ın imdadıma yetiştiğini düşünmüştüm. Ama yanılıyordum. SwiftUI’a başlayalım mı başlamayalım mı derken Android de Jetpack Compose çıkarıp kafamı alt üst etmesin mi…

SwiftUI

SwiftUI

Google’da iOS öğreniyorum ne öğrenmem gerekir, iOS yedim zehirlendim, iOS kafası, iOS olmak istiyorum, iOS bize gelsin, iOS sistem gereksinimleri gibi araştırmalara başladım. Dolayısıyla çok uzun bir süre aramak zorunda kaldım 🙂 Haziran 2019 WWDC’de Apple’ın SwiftUI isimli yeni bir UI framework yayınladığını öğrendim. Bu Framework UI yazımını bayağı kolaylaştırıyor. Döküman ve internetteki çeşitli örnekleri incelediğinizde işleri kayda değer derecede hızlandırdığını ve çok pratik olduğunu göreceksiniz. Ayrıca öğrenmesi de çok kolay. Bu hevesle “Apple böyle taş gibi bir UI framework çıkardığına göre Storyboard sisteminin daha da yüzüne bakmaz” diye düşünerek hareket ettim ve ilk iOS projemi SwiftUI kullanarak açtım.

Projeyi yazmaya başladıktan sonra farkettim ki SwiftUI yeni çıktığı için dökümanlar ve örnekler çok azdı. Çıkalı 4 ay olmasına rağmen pek çok class deprecated olmuştu bile ve yerine stabil, çalışan bir kod da koymamışlardı. Buna dökümanlarda anlatılan bazı methodlar dahil. E tabiiki siz okuyana kadar çoktan düzelmiştir. Ancak o an ihtiyacım olan çok az bilgiyi bulabildim.

iOS 13

Mesela yazdığım uygulama için WKWebView bileşenini kullanmak zorundaydım. Bunun SwiftUI ile kullanımını merak ettim. Çok zor kaynak buldum. WKWebView içerisinde değişen linki almak istedim. Ancak başarıya hızlıca ulaşamadım. Hiçbir zaman kolay yolu tercih eden bir insan olmadım ancak alması gerekenden fazla vakit almasını da istemedim. Neyse deyip devam ettim. WKWebView ile olan işim uzun uğraşlar sonucunda çözülmüştü. Ancak SwiftUI da bir sayfadan başka bir sayfaya geçmekte bile zorlandım. Çünkü tüm View’ları NavigationView içerisine eklemeniz gerekiyor. Ve WKWebView ile oluşturduğum sayfayı onun içerisine almak pek mümkün görünmüyordu. Belki yeni başladığım için ben de becerememiş olabilirim. Bu yaşadığım çeşitli problemlere sadece bir örnekti.

SwiftUI Dezavantajları

  •  Bazı CustomView’ları SwiftUI kullanarak yapmaya başlayayım dedim ancak iOS 13 sınırı olduğunu öğrendim. SwiftUI ‘ı sadece iOS 13 güncellemesi yapmış iPhone’larda ve XCode 11 ve üzeri sürümlerde kullanabiliyorduk. Ayrıca kullandığınız mac, macOS Catalina işletim sistemine sahip olmak zorundaydı.
  • SwiftUI’ın henüz emekleme aşamasında olması geliştirilmeye devam ediliyor olması.
  • NavigationView içerisine eklenen WKWebView’dan url değişikliklerinin alınamaması.
  • SwiftUI yeni olduğu için bazı bugların olması ve stabil olmaması

gibi birçok sebepten ötürü aklım ve gönlüm SwiftUI’da kala kala şimdilik Storyboard’a dönmek zorunda kaldım. Bazı quora soruları ve bazı makaleler de bu görüşümü destekleyecek nitelikte. Acele etmeyin 1 sene hatta 2 sene bekleyin hemen geçmeyin diyen pek çok yazı ve görüşle karşılaştım. Storyboard sistemi ile yaptığım uygulama 2 hafta sürdü. SwiftUI’a verdiğim 1 haftada bunun çeyreği kadar ilerleyememiştim.

Ufak bir kod örneği vermek istiyorum.

SwiftUI Örnek

Bu yapı bildiğiniz DeclarativeUI yapısı. Kısa, net, anlaşılır ve açık yapısı ile gözlerimi kamaştırdı resmen. SwiftUI hakkında detaylı bilgi için sizi apple dökümanına davet ediyorum. Keşke Android’de de böyle rahat bir sistem olsa diyordum ki 2019 Ekim ayında yapılan Android Dev Summit‘te Android Jetpack Compose isimli bir UI Framework kullanıma açıldı.

 

Android Jetpack Compose

Android Jetpack Compose

Nedir Jetpack Compose? “React, Litho, Vue.js, Flutter gibi teknolojilerden esinlenilen Declarative UI Toolkit’tir” – Compose tanıtım videosu. İlk olarak 2019 Google I/O’da tanıtılan bu framework o zamanlar baya havada kalmıştı. Çünkü henüz yenebilen birşey değildi. Deneyemiyorduk ne olduğunu bile tahmin edememiştik çünkü sadece birkaç satır kod gösterilmişti. Böyle bişey yapıyoruz gelecek bu haberiniz olsun diye gösteriyoruz demişlerdi. 23 Ekim 2019’da yapılan Android Dev Summit’te ise resmen tanıttılar, gösterdiler. Android Studio 4.0 indirip Jetpack Compose’u deneyebileceğimizi söyleyerek iyice heyecanlandırdılar 🤓Henüz indirip deneme şansım olmadı. İlerleyen zamanda Android Jetpack Compose için ayrı ve özel bir yazı PEAKUP Blog’da belirecek hiç merak etmeyin.

Gördüğümüz kadarıyla Compose, işimizi çok hızlandıracak, UI yazımını çok kolaylaştıracak, daha okunabilir, daha hızlı anlaşılabilir, birkaç ay sonra döndüğümüzde şair burada ne demek istemiş diye daha az düşüneceğimiz kaliteli kod üretmemizi sağlayacak. XML dosyalarındaki kalabalık kodu güzel bir yolla azaltacak gibi. Heyecanla ilk fırsatta denemeyi ve ağzını yemeyi bekliyorum. E tabi içimden bi ses acele etme stabil değildir. Stabil olduğu zaman daha çok konuşulacak daha çookk rüyayı süsleyecek diyor. Compose için de bir kod örneği sunarak değerlendirmeye geçiyorum.

Android Jetpack Compose örneği

Ne güzelmiş öyle Text yazıp parantez açıp içine yazdığım textin hemencecik önizlemede TextView’a dönüşmesi. Altyapısını çok merak ediyorum bu hantal Android sisteminde bunu nasıl böyle yapabildiniz diye yakalarına yapışıp sormak istiyorum 🤗 Android Jetpack Compose hakkında detaylı bilgi alabilmeniz için döküman ve eğitim bağlantısını buraya ekliyorum. Yandaki telefon görüntüsü acaba preview mu yoksa emülatör mü diye de düşünüyorum bir yandan. Neyse olumlu düşünelim olumlu olsun. Preview o aynen. Hı hı preview tabi canım. Preview o emülatör değil o. İyi iyi baya iyi hızlı da aynı zamanda aynen.

Şaka bir yana şunu sorayım. Tanıdık geldi mi syntax yapısı? Gördüğünüz üzere Android’in getirdiği Jetpack Compose View Toolkit’i de SwiftUI gibi DeclarativeUI yapısına sahip. Sanırım yan yana kıyaslamasını gösterdiğimde daha da şaşıracaksınız:

SwiftUI & Android Jetpack Compose

 

Farkları

Evet benzerlik şaşırtıcı. Hatta ürkütücü derecede şaşırtıcı. Yeminle kopyala yapıştır yaparım 3 5 harf değiştiririm varya iki tarafın da arayüzünü bitirmiş olurum. Hem de responsive. Her cihaza uyumlu.

  1. Legacy kod ile olan bağları: SwiftUI, UIView ve UIViewRepresentable sınıfları ile oluşturulur ve UIViewController içerisinde, UIHostingController ile birlikte kullanılır. Jetpack Compose ise @Composable annotation ile oluşturulur ve @GenerateView annotation ile de XML içerisinde kullanılır.
  2. SwiftUI sınıfları Struct yapısına sahiptir. Struct’larda inheritance yok sadece protocol inherit edebilirler. Composable ise bildiğimiz normal bir fonksiyondur ve arayüzün sadece bir kısmını oluşturur. Tüm sayfadan sorumlu değildir. Ancak Kotlin’de fonksiyonlar sınıfa bağlı olmak zorunda da değildir. Dolayısıyla sadece Kotlin kullanarak hiç XML kullanmayarak View oluşturabiliriz diye düşünüyorum.
  3. SwiftUI’da body: View{ } kalıbı içerisine kod yazmak zorundayken Compose’da böyle bir zorunluluk yoktur, annotation bir fonksiyonu Compose fonksiyonu yapmak için yeterlidir.
  4. İki yapı da View’ları dikey veya yatay dizebiliriz. Dizilim sisteminde görünürde çok büyük fark olmasa da dizilim bileşenlerini  isimlendirmede farklar vardır. (Bi zahmet)
    Compose SwiftUI
    Row HStack
    Column VStack
    Stack ZStack
  5. SwiftUI “Bir kere yaz heryerde kullan” mantığından ziyade, “Bir kere öğren her yerde yaz” mantığına hitap ederken Compose tamamen tekrar kullanılabilir bir mantık sunuyor. Compose open source iken SwiftUI değil haliyle.
  6. Stil başlığında da birkaç fark olduğu görünüyor. Alttaki gistte gördüğünüz satırlar kendi içlerinde aynı işi yapıyor.

https://gist.github.com/alparslandev/d869f8a89443df184d4a9b5152a39496

Ortak Özellikleri

  1. Her iki teknoloji ile de özel view objeleri üretebilirsiniz. SwiftUI ile yapılan sınıflar da Compose ile yapılan sınıflar da başka sayfalarda CustomView olarak kullanılabilir.
  2. Bu Toolkitlerin en iyi yanı ise preview hizmetleri. SwiftuUI Canlı preview ile birlikte geliyor. Hatta etkileşime bile girebiliyorsunuz SwiftUI Preview ile. Burada bahsedildiği kadarıyla Android Studio da Live Preview özelliğine sahip. Şu çalıştır butonundan bizi bi kurtarın rica ediyorum. Button{ } yazdığım anda kendisi sağda preview açsın koysun butonu. Canlı canlı göreyim. SwiftUI’da kalbimi fetheden özelliklerden birisidir kendileri. Android Studio’da da performanslı ve tatlı olacağını umut ediyorum  (Gelecek gelecek Jetpack Compose yazısı gelecek ve geldiğinde buralara linklenecek…)
  3. SwiftUI’da macOS Catalina ve iOS 13 zorunluluğu olduğu için yakın zamanda SwiftUI’a geçen çok fazla uygulama göremeyebiliriz. Ve Compose tarafında da daha hızlı uygulanabilir olan daha şeffaf bazı sınırlar var elbet. Android Studio 4.0 ve uygulamanızın Api Level 21 üstü olması lazım. Android Studio zaten işletim sistemi bağımlılığı olmayan bir ide. Ancak zaten biz Peakup’ta Android projelerini zaten api level 21 üstüne açıyoruz artık.

Farklar benzerlikler uzayıp gider. Şimdilik burada bırakalım ileride Toolkitler geliştikçe buraları da güncelleriz.

Şimdi derin ve cevabını merak ettiğim bir soru var aklımda. İnşallah sizin aklınızda da uyanmıştır bu soru. Yazıyı buraya kadar okuduysanız uyanmalı bence 🙂  Neden 2 dev şirket birden ardı ardına DeclarativeUI yapısına sahip yeni UI Toolkit ve Framework yayınlar? Nedir ki bu DeclarativeUI biraz da ondan bahsedelim.

DeclerativeUI

Bir hesaplama mantığını, kontrol akışını açıklamaksızın ifade eden bir programlama paradigmasıdır. DeclarativeUI denince hemen hemen hepimizin aklına React ve Flutter geliyor. Hatta Google I/O’da kullanılan sunumun görselini hemen buraya iliştiriyorum. Google I/O Jetpack Compose DeclarativeUI

Klasik yöntem olan Imperative UI ile kıyaslarsak:

https://gist.github.com/alparslandev/3e62219a398f9daba916380bbc9ebe4b

Bu iki paradigma da UI yaratımı paradigması. Bunlar arasında heryerde geçen bir tabir var. DeclerativeUI da neyin neye benzediğini sadece açıklıyoruz. UI’da neye benzeyen bir obje istediğimizi söylüyoruz ve bir yere kadar onun stilini belirleyebiliyoruz. Mesela Buton istediğimizi yazıyoruz ancak tam pozisyonunu (x, y) cinsinden belirtmiyoruz. Yazılımcı tüm sürecin nasıl işleyeceğini tek tek yazmaz. Obje yaratımı ile frameworkler ilgilenir. UI yaratımı için her adımını bizim yönettiğimiz model ise paylaştığım Gistten de anlaşılacağı üzere ImperativeUI adını alır.

DeclarativeUI bize yazının başından beri bahsettiğim övdüğüm gibi çok daha kolay, çok daha kısa kod ile çok iş yapabileceğimiz bir model sunuyor. Kod daha okunabilir daha anlaşılabilir oluyor. Yapılacak şeye odaklanıyoruz. Nasıl yapılacağına değil. Vaktimiz de çok kısalıyor böylece. Peki buna Apple ve Google’ın altyapısı hazır mı. Android ve iOS platformları acaba bu tarz yeri yerinden oynatacak birer frameworke hazır mı bunu biraz düşünmek lazım. İşimizi hızlandırıp kolaylaştırdığı için bu modele yöneldiklerini düşünüyorum ancak bazı uyumsuzluklar stabilsizlikler ve bilimsizlikler işimizi uzatabilir de. Zaman içerisinde daha net yorum yapacağız elbet.

Gelecek

Okuduk anladık güzel hoş declarativeui swiftui compose tamam hadi dağılalım. Hemen değil 🙂 Beyin fırtınası olmadan olmaz. Bu işin geleceği ne olur? Android Studio’da UI tasarlayıp bunu iOS’a da uygulamak mümkün olabilir mi? Ya da tam tersi? UI kısmını tek bir kere geliştirip ufak değişikliklerle diğer ortama da uygulamak 🤔

Diyelim ki 3 sene sonra böyle birşey yapıldı. Cross-platform ama bir yandan da native UI geliştirebileceğimiz ortak bir toolkit bir framework yapıldı. Kolaylaştıkça işimiz hızlanıyor kabul. Ancak acaba işlerin fazla kolaylaşması kod yazıyor olma hissimi yok eder mi? Tarihte fazla kolaylaşan her şeyde olduğu gibi burada da değeri ve saygıyı düşürür mü? Neyse bunlar da başka bir yazının konusu 🙂

Not: Framework’ler henüz emekleme aşamasında. Gelişmeleri takip ediyor ona göre yazıyı güncelliyor veya yeni yazılar üretiyor olacağım.

Daha iyi bir yazılım için, gözünüz Kotlin ve Swift üzerinde olsun.
Yazılımla kalın, Esen kalın.

Kaynakça

http://nilhcem.com/swift-is-like-kotlin2019 Ekim Android Dev Summit Youtubehttps://flutter.dev/docs/get-started/flutter-for/declarativehttp://intelligiblebabble.com/compose-from-first-principles/https://quickbirdstudios.com/blog/swiftui-vs-android-jetpack-compose/https://medium.com/@ZoeWave/swiftui-jetpack-compose-db29036532dfhttps://codeburst.io/declarative-vs-imperative-programming-a8a7c93d9ad2https://medium.com/front-end-weekly/imperative-versus-declarative-code-whats-the-difference-adc7dd6c8380