Derin linkler ve QR kodları: güvenilirlik, güvenlik ve UX

Hangi sorunu çözüyoruz: kullanıcıları doğru ekrana ulaştırmak

Asıl amaç “uygulamayı açmak” değildir. Asıl amaç “kullanıcının şu anda ihtiyaç duyduğu tam ekranda uygulamayı açmak”tır. Bu, şifre sıfırlama ekranı, belirli bir sipariş, ön doldurulmuş bir form veya bir kontrol listesindeki doğru adım olabilir.

Bu, zaman ve sabır sınırlı olduğunda daha da önem kazanır. Onboarding sırasında her ekstra dokunuş, kullanıcı kaybını artırır. Destekte yanlış ekrana düşmek aramaları uzatır ve fazla tekrar gerektirir. Saha ekiplerinde yanlış iş veya varlık kaydını açmak geri alınması zor hatalara yol açabilir.

İnsanlar derin linkleri QR kodlarla karşılaştırırken genellikle birkaç tahmin edilebilir hatadan kaçınmaya çalışırlar:

• Telefon linki tanımadığı için yanlış uygulama açılır (veya hiçbir şey açılmaz).
• Uygulama açılır ama ana ekrana düşer ve kullanıcı kaybolur.
• Kurulum, teknik olmayan ekipler için çok yavaş veya kafa karıştırıcıdır.
• Birisi paylaşılmaması gereken bir kod veya link paylaşır.

Kullanıcı açısından başarı sıkıcı hissettirmeli: tek bir eylem, cihazlar arasında aynı sonuç ve bir şey ters gittiğinde net bir yedek yol. Ayrıca güvenli olmalı; yani sadece doğru kişi doğru veriyi görebilmeli.

Örnek: Yeni bir çalışan hoş geldin mesajı alır ve “Profil Kurulumu Adım 2”yi tamamlaması gerekir. Eğer link veya tarama onları genel bir panoya düşürürse, görevi bulamayabilirler. İyi bir akış onları doğrudan o adıma götürür; ya zaten giriş yapılmış olur ya da önce nasıl giriş yapacakları açıkça gösterilir.

AppMaster gibi bir araçla uygulamayı inşa ediyorsanız hedef ekranları ve yönlendirme mantığını görsel olarak tasarlayabilirsiniz. Deneyim yine de gerçek telefonlarda nasıl davrandığınıza bağlıdır.

Derin linkler ve QR kodları nasıl çalışır (basit açıklama)

Derin link, uygulamanın sadece ana ekranını değil, uygulama içindeki belirli bir yeri açan özel bir URL’dir. Birini doğrudan “Şifreyi sıfırla”, “E-postayı doğrula” veya “İş emri #4182” gibi bir yere götürebilir.

Birkaç çeşidi vardır:

• Temel derin linkler uygulamanızın anladığı özel adresler gibi davranır, fakat uygulama yüklü değilse genellikle başarısız olurlar.
• Universal Links (iOS) ve App Links (Android) daha güvenilirdir. Bunlar uygulamanızın işlem yapmasına izin verilen normal web tarzı URL’ler kullanır. Uygulama URL’yi işleyebiliyorsa telefon uygulamayı açar; aksi halde tarayıcıda kalır.

QR kodu tek başına bir gezinme yöntemi değildir. Bir teslimat yöntemidir: kamera taraması genellikle bir URL (veya bazen bir ID gibi kısa bir yük) içerir. Sonrasında ne olacağı o QR kodunun neye işaret ettiğine bağlıdır.

Pratikte QR kodu genellikle üç şeyden birine işaret eder: uygulamaya derin bir link, tarayıcıda işi yapan bir web sayfası veya uygulama eksikse mağaza sayfası.

Cihazlar ve işletim sistemleri arasında güvenilirlik

Güvenilirlik tartışmanın gerçek kısmıdır. Her iki yaklaşım da iyi çalışabilir ama zayıf noktaları farklıdır. Derin linkler OS düzeyinde ilişkilendirme ve tarayıcı davranışına bağlıdır. QR kodları ise tarama uygulamasına ve onun neyi açmaya karar verdiğine bağlıdır.

iOS’te Universal Links doğru kurulduğunda genelde düzgün çalışır. Safari uygulamayı doğrudan daha az istemle açabilir. Diğer tarayıcılar ve uygulama içi tarayıcılar farklı davranabilir ve kullanıcılar yine de iptal edebilecekleri bir seçim ekranı görebilir.

Android’de App Links ve intent’ler güçlüdür, fakat davranış cihaz üreticisine ve varsayılan uygulamalara göre daha fazla değişir. “Benim telefonumda çalışıyor” demek, tüm cihazlarda çalışıyor demek değildir.

En büyük ayrım uygulamanın yüklü olup olmamasıdır:

• Uygulama yüklüyse ve linkler doğru şekilde ilişkilendirilmişse, bir derin link kullanıcıyı doğrudan doğru ekrana götürebilir.
• Uygulama yüklü değilse bir yedek gerekir (genellikle web sayfası veya mağaza sayfası). Bu geçiş, tarayıcıların yönlendirmeleri engellediği veya kullanıcıların bağlamı kaybettiği durumlarda bozulabilir.

QR kodları bir katman daha ekler: kamera uygulaması. Bazı kamera uygulamaları linkleri önizlemede açar, bazıları hemen açar, bazıları ise kullanıcının varsayılan tarayıcısından farklı davranan yerleşik bir tarayıcıya yönlendirir. Yaygın bir hata, “tarama çalıştı ama açılan sayfa uygulamaya bağlamı aktaramıyor” şeklindedir.

Kurumsal ve eski cihazlar özel bir durumdur. Yönetilen telefonlar tarayıcıları kısıtlayabilir, mağaza erişimini engelleyebilir veya belirli handler’ları devre dışı bırakabilir. Eski OS sürümleri modern link-ilişkilendirme kurallarını desteklemeyebilir; bu da daha fazla istem ve daha fazla kullanıcı kararı gerektirir.

Birkaç telefonla test etmek yeterli değildir. Küçük bir test matrisi çoğu sürprizi yakalar:

• iOS: Safari artı bir non-Safari tarayıcı
• Android: Chrome artı bir üretici tarayıcısı (Samsung, Xiaomi vb.)
• Yüklü ve yüklü olmayan durumlar
• Yönetilen cihaz politikası açık ve kapalı (ilgiliyse)
• Hedef kitlenizde hâlâ yaygın olan bir eski OS sürümü

Ağ ve çevrimdışı gerçeklik (özellikle sahada)

Bir dokunuş veya tarama “başarılı” görünebilir ama iş yüklenemeyebilir. QR kodlarında kamera kodu anında okur, bu yüzden çalışmış gibi hissedilir. Sonra telefon bir sayfa açmaya, uygulama ekranı açmaya veya veri almaya çalışır ve sonraki adımda başarısız olur. Derin linkler de aynı şekilde başarısız olabilir: uygulama açılır ama hedef ekran yine de doğru kaydı yüklemek için ağ çağrısı gerektirir.

Saha koşulları bunu yaygın hale getirir. Bodrumlar, depolar, asansör boşlukları ve kırsal sahalar genellikle zayıf servis, captive Wi‑Fi ağları veya kısa bağlantı kopmaları anlamına gelir. Bu, uygulamayı başlatmak için yeterli olabilir ama ağır bir ekranı yüklemek veya yeni yapılandırma indirmek için yetmeyebilir.

Çevrimdışı dostu desenler, yöntem seçmekten daha önemlidir. İyi çalışan birkaç yaklaşım:

• Önce hafif bir ekran açın (zorunlu API çağrısı yok), sonra ayrıntıları arka planda yükleyin.
• Son verileri (işler, konumlar, formlar) önbelleğe alın ve hemen gösterin.
• İşlemleri (check-in, fotoğraf yükleme, notlar) sıraya alın ve ağ geri geldiğinde eşitleyin.
• Otomatik yönlendirme başarısız olursa manuel bir yedek sağlayın (kısa kod girme, isimle arama).

Bazen yerel bir kod internetsiz çalışacak bir ekranı açmalı. Örneğin, bir makinedeki QR kodu yalnızca bir makine ID’si içerebilir ve teknisyenin çevrimdışıyken de kontrol listesini başlatmasına, fotoğraf çekmesine ve not eklemesine izin veren bir “Hızlı İşlemler” sayfasına yönlendirebilir. Uygulama her şeye makine ID’sini ekler ve daha sonra eşitler.

Cihaz çevrimdışıyken, ne olduğunu ve neyin güvenli olduğunu doğrudan belirtin. İyi bir mesaj neyin kullanılamadığını (“İş detayları bağlantı olmadan yüklenemiyor”), neyin çalıştığını (çevrimdışı kontrol listesi, kaydedilmiş taslak) ve net bir sonraki adımı açıklar: yeniden dene, manuel giriş yap veya daha sonra kaydet. AppMaster gibi bir platformla inşa ediyorsanız, bu çevrimdışı durumları tek satırlık hata pop-up’ları değil, gerçek ekranlar olarak planlayın.

Güvenlik ve gizlilik hususları

Güvenlik, seçimin önem kazandığı yerdir. Her iki yöntem de kullanıcıyı doğru yere götürebilir ve her ikisi de koruyucu önlem yoksa kullanıcıyı yanlış yere gönderebilir. Çoğu problem formattan kaynaklanmaz; zayıf doğrulama ve belirsiz hedefler asıl sorunlardır.

Gerçek dünyada sık karşılaşılan riskler:

• Benzeyen alan adları veya uygulama isimleri ile oltalama
• Orijinal kodun üzerine yapıştırılmış manüpile edilmiş QR etiketleri
• Kullanıcıyı sessizce başka yere gönderen yönlendirme zincirleri
• Linkin uygulamayı açması ancak yanlış hesap veya workspace’e düşürmesi
• URL veya QR yüküne kişisel detay koyarak verilerin fazla paylaşılması

Kullanıcıyı korumak için hedefi öngörülebilir kılın. Mobilde mümkünse doğrulanmış uygulama linkleri ve domain allowlist kullanın. Uygulama içinde açık bir hedef etiketi gösterin (ör. “ACME Depo — İş Emri 1832’yi Aç”) ve eylem hassassa (ödeme, şifre sıfırlama, yönetici işlemleri) bir onay ekranı ekleyin. Bu küçük duraklama pek çok “tara ve panik yap” hatasını önler.

Veriyi koruyun: QR yüklerini ve URL’leri sade tutun. E-posta, telefon numarası veya kişiyi tanımlayan başka bir şeyi gömmeyin. Bunun yerine opak tanımlayıcılar veya tokenlar kullanın.

Sağlam bir token düzeni genellikle kısa ömürlüdür (dakikalar, günler değil). Yüksek riskli işlemler için tek kullanımlık yapın. İzinleri sadece gerekli ekran ve eylemle sınırlayın ve mümkünse tokenı bağlamla (tenant, cihaz veya oturum) ilişkilendirin.

Operasyonel kontroller de önemlidir, özellikle saha iş akışları için. Hasarlı kodları nasıl değiştireceğinizi, personelin şüpheli etiketleri nasıl raporlayacağını ve tarama ve link açılışlarının denetim günlüklerini nasıl tutacağınızı planlayın. Ne inşa ederseniz edin, kimin eylemi başlattığını, hangi kodun kullanıldığını ve hangi ekranın açıldığını kaydedin ki hızlıca soruşturma yapabilesiniz.

Onboarding akışları için en iyi UX

Onboarding, kullanıcıyı “başlamak istiyorum” halinden neredeyse düşünmeden ihtiyaç duyduğu ekrana götürdüğünde en iyi çalışır. UX hedefi basittir: şüpheyi ortadan kaldırmak ve çıkmazları yok etmek.

İlk kullanım sürtüşmesi genelde uygulama yüklü değilken ortaya çıkar. Eğer link veya tarama sadece uygulama içinde çalışıyorsa insanları boş bir sayfada veya kafa karıştırıcı bir hatada bırakmayın. Uygulamayı yüklemeleri, sonra aynı davet veya kurulum adımına geri dönmeleri gerektiğini açıkça söyleyen bir yedek sayfaya yönlendirin.

Hedefi belirgin kılın. Bir davete dokunan kişi “Team Acme’ye Katıl” diyorsa ilk ekran bunu düz metinle onaylamalıdır. Yükleme ekranı üzerinden yönlendirmeniz gerekiyorsa kısa tutun ve ne yaptığınızı söyleyin (“Çalışma alanınız açılıyor…”).

İlk dakikalarda izinleri minimum tutun. Kamera, bildirimler ve konum izinlerini başta sormayın. Bunları sadece tarama yapmak veya hesap etkinliği için uyarı gerekli olduğunda isteyin.

Bir şey başarısız olduğunda nazikçe toparlayın. İnsanlara tek dokunuşla ilerleme yolu verin: tekrar dene, kısa kodu elle gir, yardım adımlarını gör (veya bir yöneticiye ulaş), ya da sınırlı modda devam et.

Son olarak, insanların nerede düştüğünü ölçün. Davet açıldı, uygulama yüklendi, derin link çözüldü, tarama başarılı oldu ve yedek kullanıldı gibi olayları takip edin. AppMaster ile onboarding inşa ediyorsanız, bunları açık ekranlar ve eylemler olarak modellemek, tüm uygulamayı yeniden inşa etmeden akışı ayarlamayı kolaylaştırır.

Basit bir örnek: Yeni bir çalışan e-posta daveti alır, uygulama eksikse temiz bir kurulum sayfasına gelir, yükler ve aynı davet doğrudan “Şifre Belirle” ve “Workspace’e Katıl” ekranına açılır; kamera izni sadece “Rozetini sonra tara” seçeneği seçildiğinde istenir.

Saha iş akışları için en iyi UX

Saha işi genellikle “saniyeler önemli” durumudur. En iyi UX, bir çalışanın telefona dokunur dokunmaz doğru ekranda olmasını sağlar; yazma veya menülerde gezinme gerekmez.

QR kodları burada öne çıkar çünkü tarama hızlıdır ve kişi varlık ID’sini bilmiyorsa bile işe yarar. QR’yi bir derin link ile eşleştirin ki tarama uygulamada tam doğru ekranı açsın (ör. “Varlık 1842 - Denetim kontrol listesi”), genel ana sayfayı değil.

Taramanın daha sık başarıyla gerçekleşmesini sağlayan küçük tasarım seçimleri vardır. Büyük kodlar basın ve düz bir etiket ekleyin (“Pompa P-1842”) ki insanlar doğru kodu aldıklarını anlasın. Kod etrafında boş alan bırakın, parlak yüzeylerden kaçının; eldivenli ve tek elle kullanım varsayın: büyük düğmeler, küçük geçişler yok, kısa formlar. Aynı zamanda tekrar kullanım için optimize edin; aynı tarama her seferinde aynı birincil eylemi tetiklesin.

Ayrıca tarama başarısız olduğunda destek yolunu tasarlayın. Çalışanları tahmin ettirmeyin. Açık hata mesajları kullanın (“Kod okunamadı” vs “Ağ yok”), bir el feneri düğmesi ve hızlı ipuçları içeren yeniden dene ekranı sunun, ve manuel yedek (kısa varlık kodu girişi veya aranabilir liste) sağlayın. Kısmi çalışmayı yerelde kaydedin ve çevrimiçi olduğunda eşitleyin.

AppMaster gibi no-code bir araçla inşa ediyorsanız, tarama sonuçlarının tutarlı olmasını sağlayın: tara, varlığı çöz, tek bir adanmış ekranı aç.

Adım adım: kullanım durumunuza uygun yaklaşımı seçmek

En iyi seçim genellikle “derin link mi yoksa QR kod mu” değildir. Anın gerektirdiği birincil yolu seçmek (onboarding, saha işi, müşteri desteği) ve ardından bir şeyler ters gittiğinde insanları hareket halinde tutacak bir yedek eklemektir.

1. Her hedef ekranı listeleyin. Spesifik olun: “İş Emri Detaylarını Aç” “Uygulamayı Aç”dan daha iyidir. Ekranın neye ihtiyacı olduğunu not edin (sipariş ID, konum ID, davet token) ve sonra ne olması gerektiğini belirtin.
2. Kullanıcı eylemini nasıl başlatacağınıza karar verin: dokunma, tarama veya her ikisi. Eller meşgulse veya fiziksel ekipmanın yanındaysanız tarama doğaldır. Eylem e-posta, SMS veya portaldaysa dokunmak daha kolaydır.
3. Bir birincil yol ve bir yedek seçin. Yaygın bir desen: uygulama yüklüyse uygulamada aç; değilse aynı işlemi tarayıcıda yapacak basit bir web sayfasına yönlendir. İç kullanıcılar için kameralar kapalıysa manuel kod girişi iyi bir yedek olur.
4. Yükü minimum tutun. Uygulamanın doğru şekilde yönlendirmek için bilmesi gereken tek şey (ID ve kısa ömürlü token gibi) koyun. İsimler, e-postalar veya hassas veriler eklemeyin.
5. Gerçek cihaz karışımınız ve rolleriniz üzerinde test edin. iOS ve Android, farklı tarayıcılar, çalışma profilleri ve zayıf ağ koşullarını kontrol edin. Aynı akışı yeni bir kullanıcı, oturum açmış bir kullanıcı ve kilitli bir kullanıcı ile deneyin.

AppMaster ile inşa ediyorsanız, rotaları bir ürün özelliği gibi ele alın: adlandırın, versiyonlayın ve her sürümde test edin.

Bakımı kolay kalan uygulama desenleri

Bakımı kolaylaştırmak için her tarama veya dokunuşun tek, stabil bir giriş noktasına gitmesi ve yönlendirmenin tek bir yerde yapılması iyidir. Böylece ekranlar değiştiğinde kurşun etiketleri yeniden basmak veya eski linkleri aramak zorunda kalmazsınız.

Pratik bir kurulum:

• Okunabilir parametrelerle (ör. /open/job ve job_id=123, mode=checkin) stabil yollar kullanın. URL’ye çok fazla durum bilgisi sıkıştırmaktan kaçının.
• Daha sonra davranışı kırmadan değiştirebilmek için hafif versiyonlama (v=1) ekleyin.
• Ne yapılacağını karar veren tek bir yönlendirici URL kullanın: uygulamayı aç (mümkünse), değilse aynı işlemi yapan web ekranına git; hiçbir şey işe yaramazsa net bir sonraki adım göster.
• Geçişleri planlayın. Eski rotaları bir süre çalışır tutun, bunları yenilerine eşleyin ve eski kodların artık kullanılmadığından emin olana kadar kullanımdan kaldırmayın.
• Yönlendirme mantığını merkezileştirin (küçük bir servis veya backend kuralı gibi). AppMaster ile inşa ediyorsanız backend ve uygulama akışları yollar ve parametreler geliştikçe yeniden üretilebilir.

QR baskısı için “gerçek dünyada çalışması” görünümden daha önemlidir. Yeterince büyük kod, yüksek kontrast ve etrafında boş margin kullanın. Çizilmelere dayanacak hata düzeltme seviyesini seçin ve insanların kullanacağı gerçek aydınlatma ve mesafede taramayı test edin.

Analitik için minimum tutun: açıldı (tarama veya dokunuş), uygulamaya veya web’e yönlendirildi, başarı (doğru ekran gösterildi), hata nedeni (uygulama yok, süresi dolmuş, çevrimdışı) ve tamamlanma süresi. Kısa ömürlü tokenlar varken hassas ID’leri günlüklemeyin.

Örnek senaryo: onboarding artı saha taramaları

Yeni bir saha teknisyeni, Maya, bir tesis ekibine katılıyor. Hedef basit: her tarama onu mümkün olduğunca az yazma ile tam doğru ekrana götürsün. İşte derin linkler ve QR kodlarının birlikte çalıştığı yer.

1. Gün: Maya’ya QR kodlu bir rozet verilir. Taramada kısa bir onboarding akışına gelir. Uygulama zaten yüklüyse tarama uygulamayı açar ve doğru çalışma alanına düşürür (ör. “North Campus” takımı). Uygulama yüklü değilse aynı QR kod bir web sayfası açar; burada sonraki adımlar açıkça belirtilir: uygulamayı yükle, giriş yap, sonra devam etmek için tek bir butona dokun.

Onboarding QR’si kısa ömürlü bir davet tokeni taşıyabilir, böylece daha sonra tekrar kullanılmaz. Girişten sonra uygulama bu tokeni normal bir oturuma çevirir ve token artık işe yaramaz.

Sahada, Maya bir havalandırma ünitesi üzerindeki QR etiketi tarar. Bu sefer tarama varlık zaten seçili olan bir bakım formunu açar. Form konum, model ve son servis tarihi gibi bilgileri önden doldurabilir; böylece sadece değişenleri cevaplar.

Deneyim tutarlı kalır:

• Rozet QR’sını tara: doğru takım çalışma alanına katıl
• Ekipman QR’sını tara: tam doğru varlık formunu aç
• Bir şeyler ters giderse: açık bir yedek ekran ve net sonraki adımlar göster

Güvenlik açısı: ekip, değiştirilmiş etiketlere karşı tetikte olacak şekilde eğitilir. Uygulama QR’nin onaylı bir domaine çözülüp çözülmediğini kontrol eder; eşleşmiyorsa uyarı gösterir ve site liderinin hızlıca değiştirebilmesi için tek dokunuşla “etiketi bildir” seçeneği sunar.

Göndermeden önce hızlı kontrol listesi

Çoğu sorun fark edilmeden kalan boşluklarda ortaya çıkar: farklı cihazlar, eksik uygulamalar, zayıf sinyal ve belirsiz hata ekranları. Bir final turunu “hiçbir şey yolunda gitmiyor” yaklaşımıyla yapın.

Aynı link veya QR kodu kullanarak en az bir iPhone ve bir Android telefonda (mümkünse bir eski cihaz da) şu kontrolleri yapın:

• Dokunuş veya tarama hem iOS’te hem Android’de hedeflenen tam ekrana iniş yapıyor mu, sadece uygulamanın ana ekranına değil? Kamera, bir mesajlaşma uygulaması ve e-postadan açma gibi yaygın varyantları test edin.
• Uygulamayı kaldırın ve tekrar deneyin. Bir sonraki adımı belirgin kılın: net bir yükleme istemi ve yüklemeden sonra hedefe doğrudan dönme (veya basit bir web yedeği).
• Her QR kodu sahte olabilecekmiş gibi ele alın. Devam etmeden önce hedef domaini veya uygulama adını gösterin ve yüksek riskli işlemler için onay adımı kullanın.
• Bağlantının kendisinde kişisel veya gizli veri tutmayın. E-postalar, telefon numaraları, müşteri ID’leri veya ekran görüntülerde, günlüklerde ya da basılı etiketlerde ortaya çıkabilecek açık metin tokenlardan kaçının.
• Kullanıcı dostu bir hata ekranı yayınlayın. Bir cümlede neyin yanlış gittiğini açıklasın ve güvenli bir ileri yol sunsun: tekrar dene, uygulamayı aç veya destekle iletişime geç (kullanıcının sözlü olarak okuyabileceği bir referans kodu ile).

AppMaster ile akışı inşa ediyorsanız, doğrulama yapıp kontroller geçtikten sonra yönlendiren özel bir “link/tarama giriş” ekranı işe yarar.

Sonraki adımlar: pilot, ölç, sonra ölçeklendir (basit bir yapı yolu ile)

Her yerde dağıtmayın. Cihaz tuhaflıklarını, tarama sorunlarını ve kullanıcı kafa karışıklığını destek yükü olmadan önce yakalamak için küçük başlayın.

Önemli bir iş akışı seçin (ör. “yeni kullanıcı ekibe katılır” veya “teknisyen saha iş emrini onaylar”), bir ekip ve bir cihaz grubu seçin. Pilot, gerçek insanların kullandığını görebileceğiniz kadar dar olsun; sadece günlükleri okumak yeterli değildir.

Yedek kurallarınızı bir kez yazın, sonra her yerde yeniden kullanın. Basit bir set: mümkünse uygulamada doğru ekrana aç; değilse aynı eylemi destekleyen bir web sayfası aç; hiçbiri çalışmıyorsa kısa destek talimatları göster. Tutarlılık zekice yönlendirmelerden daha önemlidir.

Ayrıca fiziksel tarafın kimin işi olduğunu belirleyin. Sahada en sık rastlanan sorun link değil, hasarlı veya eksik etikettir. Bir kişiyi veya rolü etiketleri değiştirmek, yedek tutmak ve yeni etiketin kaydedildiğini doğrulamakla görevlendirin.

Düşük riskli bir yapı yolu:

• Bir router giriş prototipi oluşturun: taramayı veya derin linki oku, bağlamı kontrol et (giriş yapılmış mı, takım, izinler) ve kullanıcıyı doğru ekrana gönder.
• Birkaç metrik takip edin: taramadan başarıya oran, görevin tamamlanma süresi ve en yaygın hata nedenleri.
• İlk 2–3 sorunu düzeltin, sonra ikinci bir iş akışına genişletin.
• Ancak o zaman cihaz kapsamını genişletin ve daha fazla lokasyona yayın.

Hızlı ilerlemek isterseniz, AppMaster (appmaster.io) routing mantığını, ekranları ve backend akışlarını tek bir yerde prototiplemenize yardımcı olabilir; pilot sırasında neye ihtiyaç duyduğunuzu öğrendikçe uygulamayı evriltin.