Yerel mobil uygulamalar için derin bağlantılar: rotalar, token devri, uygulamada açma

Derin bağlantının sade bir anlatımı

Birisi telefondaki bir bağlantıya dokunduğunda tek bir sonuç bekler: onu doğru yere, hemen götürsün. Yakın bir yere değil. Arama çubuğu olan bir ana ekrana değil. Neden geldiğini unutan bir giriş ekranına değil.

İyi bir derin bağlantı deneyimi şöyle görünür:

• Uygulama yüklüyse, bağlantının ima ettiği tam ekrana açılır.
• Uygulama yüklü değilse, dokunuş yine yardımcı olur (örneğin, bir web yedeği veya uygulama mağazası açılır ve kurulum sonrası kullanıcı aynı hedefe döndürülebilir).
• Kullanıcının giriş yapması gerekiyorsa, bir kez giriş yapar ve hedef ekrana ulaşır; uygulamanın varsayılan başlangıcına değil.
• Bağlantı bir işlem taşıyorsa (daveti kabul et, siparişi gör, e-postayı onayla), işlem açık ve güvenli şekilde iletilir.

Çoğu frustrasyon, “biraz çalışıyor” gibi görünen ama akışı bozan bağlantılardan kaynaklanır. Kullanıcı yanlış ekran görür, yaptıklarını kaybeder veya bir döngüde sıkışır: bağlantıya dokun, giriş yap, panoya gel, tekrar bağlantıya dokun, tekrar giriş yap. Tek bir ekstra adım bile kullanıcıların vazgeçmesine neden olabilir; özellikle davetler veya parola sıfırlamalar gibi tek seferlik işlemlerde.

Kotlin veya SwiftUI kodu yazmadan önce, bağlantıların ne anlama gelmesini istediğinize karar verin. Hangi ekranlar dışarıdan açılabilir? Uygulama kapalıyken mi yoksa zaten çalışırken mi fark nedir? Kullanıcı çıkış yapmışsa ne olmalı?

Planlama, sonraki çoğu acıyı önler: net rotalar, öngörülebilir “uygulamada aç” davranışı ve gizli bilgileri doğrudan URL'ye koymadan tek kullanımlık kod devri.

Derin bağlantı türleri ve “uygulamada aç”ın neden bozulduğu

Her "uygulamayı açan bağlantı" aynı şekilde davranmaz. Bunları birbirinin yerine kullanırsanız klasik hatalarla karşılaşırsınız: bağlantı yanlış yeri açar, tarayıcıyı açar ya da yalnızca bir platformda çalışır.

Üç yaygın tür:

• Özel şemalar (örneğin, uygulamaya özgü myapp: gibi). Kurulumu kolaydır, ama birçok uygulama ve tarayıcı bunları dikkatli ele alır.
• Universal Links (iOS) ve App Links (Android). Bunlar normal web bağlantılarını kullanır; uygulama yüklüyse uygulamayı açar, değilse web sitesine düşer.
• Uygulama içi tarayıcı bağlantıları. E-posta uygulaması veya messenger’ın gömülü tarayıcısında açılan bağlantılar. Genellikle Safari veya Chrome'dan farklı davranırlar.

“Uygulamada aç” dokunuşun nerede gerçekleştiğine bağlı olarak farklı anlamlar taşıyabilir. Safari'de dokunulan bir bağlantı doğrudan uygulamaya atlayabilir. Aynı bağlantı e-posta veya mesajlaşmada dokunulduğunda önce gömülü bir web görünümü açabilir ve kişinin ekstra bir “uygulamada aç” düğmesine basması gerekebilir (ya da hiç görünmeyebilir). Android'de Chrome App Links'i dikkate alabilirken bir sosyal uygulamanın uygulama içi tarayıcısı onları görmezden gelebilir.

Cold start ile uygulamanın zaten çalışıyor olması bir diğer tuzaktır.

• Cold start: OS uygulamanızı başlatır, uygulama başlatılır ve ancak sonra derin bağlantıyı alırsınız. Eğer başlatma akışınız splash ekranı gösteriyor, kimlik kontrolü yapıyor veya uzak yapılandırma yüklüyorsa, bağlantı saklanıp uygulama hazır olduğunda tekrar oynatılmazsa kaybolabilir.
• Zaten çalışıyor: Bağlantıyı kullanıcı aktif bir oturumdayken alırsınız. Navigasyon yığını mevcut olduğu için aynı hedef farklı şekilde ele alınabilir (ekranı push etmek vs yığını sıfırlamak gibi).

Basit bir örnek: Telegram'dan dokunulan bir davet bağlantısı genellikle önce uygulama içi bir tarayıcıda açılır. Uygulamanız OS'nin her zaman doğrudan devredeceğini varsayıyorsa, kullanıcılar bir web sayfası görür ve bağlantının bozuk olduğunu düşünebilir. Bu ortamlar için baştan plan yapın, böylece platforma özel yapışkan kodu daha az yazarsınız.

Uygulamaya başlamadan önce rotalarınızı planlayın

Çoğu derin bağlantı hatası Kotlin veya SwiftUI hatası değildir. Planlama hatasıdır. Bağlantı temiz bir şekilde bir ekrana haritalanmıyordur veya çok fazla “belki” seçeneği taşır.

İnsanların uygulamanızı nasıl düşündüğüne uygun, tutarlı bir rota deseniyle başlayın: liste, detay, ayarlar, ödeme, davet. Okunabilir ve stabil tutun; e-postalarda, QR kodlarda ve web sayfalarında yeniden kullanacaksınız.

Basit bir rota seti şunları içerebilir:

• Ana sayfa
• Siparişler listesi ve Sipariş detayları (orderId)
• Hesap ayarları
• Davet kabulü (inviteId)
• Arama (query, tab)

Sonra parametrelerinizi tanımlayın:

• Tek nesneler için ID kullanın (orderId).
• UI durumu için isteğe bağlı parametreler kullanın (tab, filter).
• Her bağlantının bir en iyi hedefi olmasını sağlamak için varsayılanları kararlaştırın.

Bağlantı yanlış olduğunda ne olacağını da belirleyin: eksik veri, geçersiz ID veya erişilemeyen içerik. En güvenli varsayılan, en yakın sabit ekranı (ör. liste) açmak ve kısa bir mesaj göstermek. Kullanıcıları boş bir ekrana veya bağlamsız bir giriş ekranına atmayın.

Ayrıca kaynağa göre planlayın. QR kod genelde kısa bir rota, hızlı açılma ve zayıf bağlantıya tolerans gerektirir. E-posta bağlantısı daha uzun olabilir ve ekstra bağlam içerebilir. Web sayfası düzgün düşüş yapmalı: uygulama yüklü değilse kişi ne yapacağına dair bilgi almalı.

Eğer backend odaklı bir yaklaşımla çalışıyorsanız (ör. API uç noktaları ve ekranlar üreten bir platform olarak AppMaster), bu rota planı paylaşılan bir sözleşme haline gelir: uygulama nereye gideceğini bilir, backend hangi ID'lerin ve durumların geçerli olduğunu bilir.

Gizli bilgileri URL'ye koymadan güvenli token devri

Derin bağlantı genellikle güvenli bir zarf gibi muamele görür. Gerçekte öyle değildir. URL'deki her şey tarayıcı geçmişine, ekran görüntülerine, paylaşılan önizlemelere, analiz kayıtlarına veya kopyalanmış sohbetlere düşebilir.

URL'ye gizli bilgiler koymaktan kaçının. Buna uzun ömürlü erişim tokenları, refresh tokenlar, parolalar, kişisel veriler veya link ile paylaşıldığında kullanıcı adına hareket edilebilecek hiçbir şey dahil.

Daha güvenli bir desen kısa ömürlü, tek kullanımlık bir koddur. Bağlantı sadece bu kodu taşır ve uygulama açıldıktan sonra gerçek bir oturum almak için bunu sunucuyla değiş tokuş eder. Birisi bağlantıyı çalarsa, kod bir veya iki dakika sonra ya da ilk kullanımda işe yaramaz hâle gelmelidir.

Basit bir devrediş akışı:

• Bağlantı bir oturum tokenı yerine tek kullanımlık kısa ömürlü bir kod taşır.
• Uygulama açılır ve kodu kullanmak için backend'inize bir çağrı yapar.
• Backend süresinin dolup dolmadığını ve daha önce kullanılıp kullanılmadığını doğrular, sonra kodu kullanılmış olarak işaretler.
• Backend uygulama için normal bir kimlikli oturum döner.
• Uygulama kodu kullandıktan sonra bellekten temizler.

Başarılı bir kullanım sonrası bile, hassas bir işlem yapmadan önce uygulama içinde kimliği doğrulamayı onaylayın. Bağlantı ödeme onayı, e-posta değişikliği veya veri ihracı içindir ise, biyometri veya taze bir giriş gibi hızlı bir yeniden doğrulama isteyin.

Ortaya çıkan oturumu güvenli şekilde saklayın. iOS'ta bu tipik olarak Keychain'de olur. Android'de Keystore destekli depolamayı kullanın. Yalnızca gereken veriyi saklayın ve çıkış, hesap silme veya şüpheli yeniden kullanım algılandığında temizleyin.

Somut bir örnek: bir workspace daveti gönderiyorsunuz. Bağlantı 10 dakika içinde süresi dolan tek kullanımlık bir kod taşır. Uygulama bunu kullanır, sonra kullanıcıya hangi workspace'e katılacağı açıkça gösterilir. Kullanıcı onayladıktan sonra katılım tamamlanır.

AppMaster ile inşa ediyorsanız, bu kodları doğrulayan ve bir oturum döndüren bir uç noktaya kolayca eşlenir; mobil UI ise yüksek etkili bir işlemi gerçekleştirmeden önce onay adımını yönetir.

Kimlik doğrulama ve “bıraktığın yerden devam etme”

Derin bağlantılar genellikle özel veriler içeren ekranlara işaret eder. Önce neyin herkese açık (public), neyin oturum gerektiren (protected) olduğunu belirleyin. Bu tek karar çoğu “testte çalıştı” sürprizini önler.

Basit bir kural: önce güvenli bir açılış durumu gösterin, sonra kullanıcının kimliğini doğrulayın ve ancak onaylandıktan sonra korumalı ekrana gidin.

Ne herkese açık ne ise korumalı olarak karar verin

Derin bağlantıları yanlış kişiye iletilebilecekmiş gibi ele alın.

• Herkese açık: pazarlama sayfaları, yardım makaleleri, parola sıfırlama başlangıcı, davet kabulü başlangıcı (henüz veri gösterilmez)
• Korumalı: sipariş detayları, mesajlar, hesap ayarları, yönetici ekranları
• Karma: önizleme ekranı uygun olabilir; ancak giriş olana kadar yalnızca hassas olmayan yer tutucular gösterin

Girişten sonra doğru yere dönme

Güvenilir yaklaşım: bağlantıyı ayrıştırın, hedefi saklayın, sonra kimlik durumuna göre yönlendirin.

Örnek: kullanıcı oturum dışıyken belirli bir destek biletine gitmeye çalışan bir “uygulamada aç” bağlantısına dokunuyor. Uygulamanız nötr bir ekrana açılmalı, oturum istemeli ve ardından otomatik olarak o bilete götürmelidir.

Bunu güvenilir kılmak için, yerel olarak küçük bir “geri dönme hedefi” (rota adı artı bilet ID'si gibi) saklayın ve kısa süre sonra süresi dolacak şekilde ayarlayın. Giriş tamamlandıktan sonra bunu bir kez okuyun, gezinmeyi yapın ve temizleyin. Giriş başarısız olursa veya hedef süresi dolmuşsa güvenli bir ana ekrana geri dönün.

Kenarlık durumları saygıyla ele alın:

• Süresi dolmuş oturum: kısa bir mesaj gösterin, yeniden kimlik doğrulayın ve sonra devam edin.
• Erişim iptal edilmiş: hedef kabuğunu açın, sonra “Artık erişiminiz yok” gösterin ve güvenli bir sonraki adım önerin.

Ayrıca kilit ekranı önizlemelerinde, uygulama değiştiricide veya bildirim önizlemelerinde özel verileri göstermeyin. Veri yüklenip oturum doğrulanana kadar hassas ekranları boş tutun.

Özel navigasyon karmasını önleyen bir yönlendirme yaklaşımı

Her ekranın URL'leri kendi biçiminde ayrıştırdığı durumlarda derin bağlantılar karışır. Bu durum küçük kararları (hangi şey opsiyonel, hangi şey zorunlu, ne geçerli) uygulama genelinde yayar ve güvenli şekilde değiştirmeyi zorlaştırır.

Rotaları paylaşılan bir boru hattı gibi ele alın. Tek bir rota tablosu ve tek bir ayrıştırıcı tutun; UI temiz girdiler alsın.

Tek bir paylaşılan rota tablosu kullanın

iOS ve Android'in tek, insan tarafından okunabilir bir rota listesinde anlaşmasını sağlayın. Bunu bir sözleşme gibi düşünün.

Her rota şuna eşleşir:

1. bir ekran, ve
2. küçük bir girdi modeli.

Örneğin, “Sipariş detayları” bir Order ekranına ve OrderRouteInput(id) gibi bir girdiye eşlenir. Bir rota ekstra değerler gerektiriyorsa (ref kaynağı gibi), bunlar input modelinde olmalıdır, view kodunda dağınık olmamalıdır.

Ayrıştırma ve doğrulamayı merkezileştirin

Ayrıştırma, kod çözme ve doğrulamayı tek bir yerde tutun. UI "Bu token var mı?" veya "Bu ID geçerli mi?" diye sormamalı. Ya geçerli bir rota girdisi ya da net bir hata durumu almalıdır.

Pratik akış:

• URL alınır (dokunma, tarama, paylaşım menüsü)
• Bilinen bir rotaya ayrıştırılır
• Gerekli alanlar ve formatlar doğrulanır
• Bir ekran hedefi ve bir girdi modeli üretilir
• Tek bir giriş noktasından gezinme yapılır

Bir "bilinmeyen bağlantı" yedek ekranı ekleyin. Bunu çıkmaz bir nokta yapmayın: açılamayanı gösterin, nedenini sade bir dille açıklayın ve Ana Sayfa, arama veya giriş gibi bir sonraki eylem teklif edin.

Adım adım: derin bağlantıları ve “uygulamada aç” davranışını tasarlama

İyi derin bağlantılar en iyi anlamda sıkıcıdır. İnsanlar dokunur ve doğru ekrana gelir, uygulama yüklü olsun ya da olmasın.

Adım 1: önemli giriş noktalarını seçin

İlk 10 gerçekten kullanılan bağlantı türünü listeleyin: davetler, parola sıfırlamalar, sipariş makbuzları, "bileti görüntüle" bağlantıları, promosyonlar. Bilerek küçük tutun.

Adım 2: desenleri bir sözleşme gibi yazın

Her giriş noktası için bir kanonik desen ve doğru ekranı açmak için gereken minimum veriyi tanımlayın. Tekil isimler yerine stabil ID'leri tercih edin. Hangi parametrelerin zorunlu, hangilerinin isteğe bağlı olduğunu belirleyin.

Yararlı kurallar:

• Her rota için bir amaç (davet, sıfırlama, makbuz).
• Zorunlu parametreler her zaman mevcut; isteğe bağlıların güvenli varsayılanları olsun.
• iOS (SwiftUI) ve Android (Kotlin) arasında aynı desenleri kullanın.
• Değişiklik bekliyorsanız basit bir sürüm prefix'i ayırın (ör. v1).
• Parametre eksikse ne olacağını tanımlayın (hata ekranı göster, boş sayfa değil).

Adım 3: giriş davranışını ve giriş sonrası hedefi kararlaştırın

Her bağlantı türü için giriş gerekip gerekmediğini yazın. Gerekliyse hedefi hatırlayın ve giriş sonrası devam edin.

Örnek: bir makbuz bağlantısı önizlemeyi giriş olmadan gösterebilir, ama “Faturayı indir”e dokunmak giriş gerektirebilir ve kullanıcı tekrar aynı makbuza dönmelidir.

Adım 4: token devri kurallarını belirleyin (gizlilikleri URL'de tutmayın)

Bağlantı tek kullanımlık bir token gerektiriyorsa, ne kadar süre geçerli olacağını ve nasıl kullanılacağını tanımlayın.

Pratik yaklaşım: URL kısa ömürlü, tek kullanımlık bir kod taşır; uygulama bunu backend ile değiş tokuş ederek gerçek bir oturum alır.

Adım 5: üç gerçek dünya durumunu test edin

Derin bağlantılar uç noktalarda bozulur. Her bağlantı türünü bu durumlarda test edin:

• Cold start (uygulama kapalı)
• Warm start (uygulama bellekte)
• Uygulama yüklü değil (bağlantı hâlâ mantıklı bir yere düşmeli)

Rota, kimlik kontrolleri ve token değiş tokuş kurallarını tek bir yerde tutarsanız, Kotlin ve SwiftUI ekranlarına dağılmış özel yönlendirme mantığını engellersiniz.

Derin bağlantıları bozan yaygın hatalar (ve nasıl kaçınılır)

Derin bağlantılar sıkıcı nedenlerle başarısız olur: küçük bir varsayım, yeniden adlandırılmış bir ekran veya “geçici” bir tokenın her yerde dolaşması.

Yaban hayatta gördüğünüz hatalar (ve düzeltmeleri)

• Erişim tokenlarını URL'ye koymak (loglara sızma). Sorgu dizeleri kopyalanır, paylaşılır, tarayıcı geçmişinde saklanır ve analiz/crash loglarında yakalanır. Düzeltme: bağlantıda yalnızca kısa, tek kullanımlık bir kod bulundurun; uygulama içinde bunu kullanın ve çabuk süresini doldurun.

• Uygulamanın yüklü olduğunu varsaymak (yedek yok). Bağlantı hata sayfasına gidiyorsa veya hiçbir şey yapmıyorsa kullanıcı vazgeçer. Düzeltme: ne olacağını açıklayan bir web yedeği sağlayın ve normal bir kurulum yolu sunun.

• Bir cihazda birden fazla hesabı ele almamak. Yanlış kullanıcı için doğru ekranı açmak, bozuk bir bağlantıdan daha kötüdür. Düzeltme: bağlantı alındığında aktif hesabı kontrol edin, kullanıcıya onay veya hesap değiştirme isteyin, sonra devam edin. Eğer işlem belirli bir workspace gerektiriyorsa (gizli olmayan) bir workspace tanımlayıcısı ekleyin ve doğrulayın.

• Ekranlar veya rotalar değiştiğinde bağlantıları kırmak. Rotanız UI adlarına bağlıysa, bir sekmeyi yeniden adlandırdığınız anda eski bağlantılar çalışmaz. Düzeltme: stabil, niyete dayalı rotalar (davet, bilet, sipariş) tasarlayın ve eski sürümlere destek sunun.

• Bir şey ters gittiğinde iz bırakmamak. Ne olduğunu yeniden oynatma imkânı yoksa destek yalnızca tahmin edebilir. Düzeltme: bağlantıda hassas olmayan bir istek ID'si ekleyin, bunu sunucuda ve uygulamada loglayın ve hata mesajında o ID'yi gösterin.

Kısa bir gerçeklik kontrolü: bir grup sohbetinde gönderilen davet bağlantısını hayal edin. Birisi bunu iş telefonunda iki hesapla açıyor, uygulama tabletinde yüklü değil ve bağlantı bir meslektaşa iletiliyor. Bağlantı yalnızca bir davet kodu taşıyorsa, yedek davranış sunuyorsa, doğru hesabı seçmeyi istiyorsa ve bir istek ID'si logluyorsa, o tek bağlantı tüm bu durumlarda gizlilik açığa çıkarmadan başarılı olabilir.

Örnek: her seferinde doğru ekranı açan bir davet bağlantısı

Davetler klasik bir derin bağlantıdır: birisi takım arkadaşına mesajla bir bağlantı gönderir ve alıcı tek dokunuşla davet ekranına gelmeyi bekler, genel bir ana sayfaya değil.

Senaryo: bir yönetici “Support Team” workspace'ine yeni bir destek elemanı davet ediyor. Ajan Telegram'da davete dokunuyor.

Uygulama yüklüyse, sistem uygulamayı açmalı ve davet detaylarını uygulamaya geçirmeli. Uygulama yüklü değilse kullanıcı basit bir web sayfasına düşmeli; bu sayfa davetin ne için olduğunu açıklar ve kurulum yolunu önerir. Kurulum ve ilk başlatmadan sonra uygulama yine davet akışını tamamlayabilmelidir, böylece kullanıcı bağlantıyı tekrar aramak zorunda kalmaz.

Uygulama içinde, Kotlin ve SwiftUI'de akış aynıdır:

• Gelen bağlantıdan davet kodunu okuyun.
• Kullanıcının giriş yapıp yapmadığını kontrol edin.
• Daveti backend ile doğrulayın, sonra doğru ekrana yönlendirin.

Doğrulama önemlidir. Bağlantı uzun ömürlü oturum tokenları gibi gizli veriler içermemelidir. Bağlantı kısa ömürlü bir davet kodu taşımalı ve sunucunuz bunu doğruladığında işe yarar hâle gelmelidir.

Kullanıcının deneyimi öngörülebilir olmalıdır:

• Giriş yapılmamışsa: giriş ekranı görülür, sonra davet kabulüne geri dönülür.
• Giriş yapılmışsa: bir “Workspace'e katıl” onayı görünür ve sonra doğru workspace'e yönlendirilir.

Davet süresi dolmuş veya zaten kullanılmışsa, kullanıcıyı boş bir hata sayfasına atmayın. Açık bir mesaj ve sonraki adım sunun: yeni davet isteyin, hesap değiştirin veya bir admin ile iletişime geçin. “Bu davet zaten kabul edildi” ifadesi “Geçersiz token”dan daha iyidir.

Hızlı kontrol listesi ve sonraki adımlar

Derin bağlantılar, kapalı başlatma, sıcak başlatma ve kullanıcı zaten oturum açmış olduğunda her yerde aynı şekilde davranıyorsa ancak "tamamlanmış" hissi verir.

Hızlı kontrol listesi

Yayına almadan önce, gerçek cihazlar ve OS sürümlerinde her öğeyi test edin:

• Bağlantı cold start ve warm start'ta doğru ekranı açıyor.
• URL içinde hassas bir şey yok. Eğer bir token gerekiyorsa, kısa ömürlü ve tercihen tek kullanımlık olsun.
• Bilinmeyen, süresi dolmuş veya zaten kullanılmış bağlantılar, net bir mesaj ve güvenli bir sonraki adım sunan ekrana düşüyor.
• E-posta uygulamaları, tarayıcılar, QR kod tarayıcıları ve messenger önizlemelerinden çalışıyor (bazıları linkleri önceden açar).
• Loglama neler olduğunu söylüyor (alınan link, ayrıştırılan rota, gerekli auth, başarı veya hata nedeni).

Davranışı doğrulamanın basit bir yolu: çalışması gereken birkaç bağlantı türü seçin (davet, parola sıfırlama, sipariş detayı, destek bileti, promosyon) ve bunları aynı test akışından geçirin: e-postadan dokun, sohbetten dokun, QR tarayın, yeniden kurulum sonrası açın.

Sonraki adımlar (bakımı kolay tutmak için)

Derin bağlantılar ekranlara yayılmaya başladıysa, yönlendirme ve kimlik doğrulamayı ekran başı kod yerine paylaşılan bir boru hattı olarak ele alın. Rota ayrıştırmayı merkezileştirin ve her hedefin temiz parametreler (ham URL değil) kabul ettiğinden emin olun. Kimlik için de aynı şeyi yapın: "şimdi devam et" vs "önce giriş yap, sonra devam et" kararını tek yerde verin.

Özel yapışkan kodu azaltmak istiyorsanız, backend, auth ve mobil uygulamaları birlikte inşa etmek yardımcı olabilir. AppMaster (appmaster.io) üretime hazır backendler ve native mobil uygulamalar üreten no-code bir platformdur; bu, rota isimlerini ve tek kullanımlık kod doğrulama uç noktalarını gereksinimler değiştikçe hizalı tutmayı kolaylaştırabilir.

Gelecek hafta tek bir şey yapacaksanız, şu olsun: kanonik rotalarınızı ve her hata durumunda tam olarak ne yapılacağını yazın, sonra bu kuralları tek bir yönlendirme katmanında uygulayın.