Ajans "Flutter ile hem iOS hem Android" dedi — bu seçim beni sonradan bağlar mı?

iOS güncellemelerinde nadiren de olsa render motoru veya işletim sistemi bileşenleri değiştiğinde küçük görsel kaymalar yaşanabiliyor. Ajansın teklifine yeni iOS ana sürümleri çıktığında en az 1 yıl boyunca uyumluluk güncellemesi desteği vereceklerine dair bir madde mutlaka ekletin.

Biz geçen yıl lojistik takip uygulamamızı Flutter ile yayına aldık. İki ayrı native ekip tutmak yerine tek ekiple 210.000 TL harcadık. Şu an 12.000 aktif kullanıcımız var, gelen şikayetlerin sadece 2 tanesi arayüz takılmasıyla ilgiliydi, o da eski cihazlardaydı.

Ajansların çoğu 'iki platform tek kod' diyerek maliyeti düşürdüğünü söylüyor ama iOS arayüz kılavuzlarına hiç bakmıyorlar. Uygulama açıldığında Android gibi hissettiren bi iOS uygulaması çıkarsa iPhone kullanıcılarınız hemen olumsuz yorum yazar.

Ajansın daha önce App Store üzerinde yayınladığı en az üç Flutter uygulamasını isteyin... Kendi iPhone'unuza indirip liste kaydırma hızına, klavye açılıp kapanma tepkilerine ve geçiş animasyonlarına bizzat bakın.

Sahadaki teknisyenleriniz çevrimdışı çalışmak zorunda kalacak mı? Cihaz hafızasında veri saklama ve senkronizasyon mantığını nsl kurgulayacaklarını sordunuz mu? yani asıl tıkanma noktası genelde arayüz değil yerel veritabanı senkronizasyonudur.

biz iki senedir kullanıyoruz hiç bir sıkıntı yaşamadık... native yazalım desen o bütçe en az ikiye katlanırdı, ilk aşamada hiç gerek yok.

ek: aşağıda sorulmuş, cevabı ikinci mesajda yazdım.

ileride nativee geçmek zorunda kalırsanız bu uygulamanın başarısız olduğu anlamına gelmez, tam aksine işlerin çok büyüdüğünü gösterir. ya o gün geldiğinde zaten yeni kodu finanse edecek gücünüz olur şidilik hız kazanmaya bakın.

Native geçişte arayüz kodunu çöpe atarsınız ama arka uç mimariniz aynen korunur; 280.000 TL bu risk için gayet makul bir deneme bütçesi.

Karşı taraftan konuşayım, ben tedarikçi tarafındayım. Bunun cevabı sektöre göre çok değişiyor, genel geçer bir kural yok.

Başka türlü yapan varsa onu da merak ederim.

sonuna kdr katiliyorum bir de yazili olmayan her madde ileride iki tarafin da farkli hatirladiigi bi madde

bu kdr, uzattııysam kusura bakmayın

Deneyeceğim.

Haklısınız, ben de aynı yoldan geçtim. Ödeme takvimi işin aşamalarına bağlanmalı, takvime değil.

Sözleşmede kod sahipliği yazmıyorsa, ayrılırken pazarlık gücünüz kalmıyor. Ben olsam bu yoldan giderdim.

burada bi tuzak var söylemeden geçmeyeyim. flutter ile ios geliştirme tarfında yapılan hata genelde geri dönülebilir ama pahalı.

Genel olarak doğru ama bir yeri eksik kalmış. İlk kez yapıyorsanız küçük başlayın, ölçek sonra gelir.

Ben olsam bu yoldan giderdim.

Katılıyorum, hatta altını çizmek isterim. Bunu tek başına yapmaya çalışmak en pahalı yol.

Tecrübeyle sabit.

bende tam tersi oldu o yüzden yazıyorum. ilk kez yapıyorsanız küçük başlayın ölçek sonra gelir.

en ucuz teklif genelde en az düşünülmüş tekliftir.

aynısını yaşadım ve işte sormaktan çekinmeyin, soormayan hep daha pahalıya ödüyor.

karar verirken en kötü senaryoyu da yazzın sadece iyisini deil. bu arada bu kadar uzattıysam kusura bakmayın.

Tam olarak böyle. Erişim bilgileri kurum adına açılmalı, kişisel hesaplarla değil.

Kapsam büyüyorsa ya süre ya bütçe büyümeli. Üçüncü seçenek yok. Ben olsam bu yoldan giderdim.