8 dk

Dijital Form İmzaları İçin Mobil Uygulama Nasıl Oluşturulur

Formlarda geçerli e‑imzalar alabilen, çevrimdışı imzalamayı destekleyen ve backend ile güvenli şekilde eşleyen bir mobil uygulama oluşturmanın adımlarını öğrenin.

Dijital Form İmzaları İçin Mobil Uygulama Nasıl Oluşturulur

Mobil İmza Uygulamasının Yapması Gerekenler

Bir mobil imza uygulaması sadece "ekrana adınızı çizme" özelliğinden daha fazlasıdır. Uçtan uca bir iş akışıdır: niyeti yakalayın, bunu doğru belgeye ekleyin, neler olduğunu kaydedin ve sonucu daha sonra saklamayı, paylaşmayı ve doğrulamayı kolay hâle getirin.

“Dijital form imzaları” ne anlama gelebilir

İnsanlar “dijital imza” derken birkaç farklı şeyi kasteder. Uygulamanız bir veya daha fazlasını destekleyebilir:

  • Yazılı imza: imzalayan ismini yazar ve uygulama bunu bir fontla render eder. Basit ve hızlı, ama tek başına daha zayıf kanıt.\n- Çizilmiş (parmak/stilus) imza: dokunmatik ekranda uygulama içi imza yakalama. Teslimatlar ve saha çalışmaları için yaygın.\n- Görüntü tabanlı imza: imzalayan önceden kaydedilmiş bir imza görüntüsü ekler (veya daha önce yakalanmış birini yeniden kullanırsınız). Kullanışlı ama yeniden kullanımı dikkatle kontrol etmelisiniz.\n- Sertifikaya dayalı dijital imza: genellikle bir sertifikayla bağlanan kriptografik imza (düzenlenmiş veya yüksek güven gerektiren senaryolarda kullanılır). Birçok kurumsal müşterinin manipülasyona dayanıklı PDF imzalama dediği budur.

Yaygın gerçek dünya kullanım durumları

Çoğu mobil e‑imza uygulaması birkaç kalıp etrafında toplanır:

  • Teslimat kanıtı: müşteri mal teslim aldıktan sonra imzalar; genellikle fotoğraflar, konum ve zaman damgaları içerir.
  • Onay formları: sağlık, okullar, etkinlikler—şartların açık sunumu ve kabul kaydı.
  • Saha servisi: iş emirleri, tamamlanma onayları, kullanılan parçalar ve müşteri onayı.
  • İK işe alım: teyitler, politika onayları ve sırayla imzalanan belge paketleri.

Bu kılavuz neleri kapsar

Rehberin geri kalanı güvenilir bir imzalama deneyimi sunmak için önemli olan konulara odaklanır:

  • Mobilde UX: formları okunur tutmak, hataları azaltmak ve imzanın kasıtlı hissetmesini sağlamak.
  • Teknik tercihler: belge üretimi, imza yakalama ve gerektiğinde mobilde PDF imzalama.
  • Güvenlik ve güven: kimlik seçenekleri (biyometrik dahil), güvenli belge depolama ve imzalar için denetim izi.
  • Çevrimdışı form imzalama: bağlantı olmadan imzaları toplama ve güvenli şekilde senkronize etme.
  • Yayın hazırlığı: test ve zamanla iyileştirme için pratik bir kontrol listesi.

Hukuk ve Uyumluluk Temelleri (Basit Dilde)

Mobil bir e‑imza uygulaması sadece cam üzerinde parmak karalaması almak değildir. Birisi “Bunu kim imzaladı, ne zaman ve değiştirilmiş mi?” diye sorduğunda dayanacak imzalar gerekir.

E‑imzaların genelde uygun olduğu durumlar (ve olmadığı durumlar)

Günlük anlaşmaların çoğu—hizmet yetkilendirmeleri, teslimat onayları, dahili onaylar—elektronik imza ile genelde kabul edilebilir; yeter ki imzalayanın onayladığını gösterebilesiniz ve belge sonradan değiştirilmemiş olsun.

Daha yüksek riskli durumlar için daha sıkı yöntemler gerekebilir (ör. düzenlenmiş finans belgeleri, bazı gayrimenkul veya devlet formları, belirli bağlamlarda sağlık onayları veya sözleşmede özel bir imza standardı talep edilmişse). Gereksinimler ülkeye, eyalete ve sektöre göre geniş ölçüde değişir.

Önemli üç şey: niyet, kimlik, bütünlük

  • Niyet: kişinin imzalamak istediğini gösterin. Eylemi netleştirin (örn. “Kabul ediyorum ve imzalıyorum”) ve kazara dokunuşları engelleyin.
  • Kimlik: imzalayanı imzayla makul biçimde ilişkilendirebiliyor olun. Bu bir e‑posta/SMS bağlantısı, hesap girişi veya risk seviyesine göre kimlik doğrulama ya da biyometrik olabilir.
  • Bütünlük: imzalı belge sonradan sessizce değiştirilemesin. Manipülasyon tespiti, sürümleme ve (birçok kurumsal vaka için) PDF'ler için kriptografik koruma gerekir.

Kaydetmeniz gerekenler (denetim iziniz)

Asgari olarak saklayın:

  • İmzalayan detayları (isim, e‑posta/telefon, hesap ID'si, uygun olduğunda cihaz/oturum bilgisi)
  • Zaman damgası(lar) zaman dilimiyle birlikte
  • İmzalanan belge kimliği ve tam versiyon/hash
  • İmzalama sırasında gösterilen onay metni (örn. “İmzalamak için Dokunuyorum, kabul ediyorum…”) ve kullanıcının eylemi

Kullandığınız duruma göre kuralları doğrulayın

Bunu ürün rehberi olarak ele alın, hukuki tavsiye olarak değil. Yayından önce, hizmet verdiğiniz bölge ve sektör için imza, saklama ve kimlik gereksinimlerini doğrulayın—özellikle düzenlenmiş müşterilere hizmet veriyorsanız.

İmza İş Akışınızı ve Gereksinimleri Tanımlayın

Ekranları tasarlamadan veya araçları seçmeden önce mobil e‑imza uygulamanızın ne yapması gerektiğini netleştirin. Kesin bir iş akışı tanımı, özellikle çevrimdışı form imzalama, onaylar ve güvenli belge depolama eklediğinizde yeniden çalışmayı önler.

Form türlerinizle başlayın

Farklı girdi türleri her şeyi UX'ten depolamaya kadar şekillendirir.

  • Mobilde PDF imzalama: kullanıcılar bir PDF yükler veya üretir, alanları (isim, tarih, imza) yerleştirir, sonra imzalar.
  • Şablonlar: sabit alanlara sahip tekrar kullanılabilir formlar (ör. teslimat onayı).
  • Dinamik alanlar: bileşenlerden (metin, onay kutusu, fotoğraf, konum) formlar oluşturun ve paylaşmak için PDF üretin.

Birden fazla türü destekleyecekseniz, v1'de neyin çıkacağını ve nelerin sonraya kalabileceğine karar verin.

Roller ve sorumluluğu tanımlayın

Her belgede kim ne yapabilir haritasını çıkarın. Yaygın roller:

  • İmzalayan: gerekli alanları doldurur ve uygulama içi imza verir.
  • Onaylayan: gözden geçirir ve kabul/ret eder (çoğunlukla düzenlemez).
  • Şahit (uygunsa): imzalayanın ardından imzalar; bazen ekstra kimlik kontrolleri gerekir.

Ayrıca bir kişinin birden fazla rolü olup olmayacağını ve birinin reddetmesi durumunda ne olacağını belirleyin.

Uçtan uca akışı eşleştirin

Mutlu yolunuzu bir cümleyle yazın: form oluştur → doldur → imzala → sakla → paylaş.

Sonra “gerçek hayat” adımlarını ekleyin: hatırlatmalar, yeniden atama, düzenlemeler, iptaller ve sürümleme (imzadan sonra hangi değişikliklere izin veriliyor?).

Tek cihaz mı yoksa dış imzalayanlar mı

İmzaların nasıl toplanacağını açıkça belirtin:

  • Tek cihaz imzalama: herkes aynı telefon/tablette imzalar (yüz yüze iş akışları için harika).
  • Uzaktan imzalama: dış imzalayanlara e‑posta/SMS ile bir bağlantı gönderin; zaman aşımı, kimlik doğrulama ve imzalayanın ne görebileceğini tanımlayın.

Bu seçimler, imzalar için denetim izi, kimlik kontrolleri (biyometrik dahil) ve kimin neyi ne zaman imzaladığını kanıtlama biçiminizi etkiler.

Mobilde İmzalama Deneyimini Tasarlayın (UX)

Bir telefon üzerindeki imza akışı “doldur, imzala, bitti” gibi hissettirmeli—bir sonraki adım hakkında belirsizlik olmamalı. Mükemmel UX, yasal ayrıntılardan çok daha fazla formun tamamlanmasını sağlar.

Doğru imza giriş seçeneklerini sunun

Farklı kullanıcılar farklı şekillerde imzalar; mobil cihazlar da değişir. En azından şunları sağlayın:

  • Çizilmiş imza (parmak veya stilus) ve net bir “Buraya imza atın” alanı
  • Yazılı isim imza tarzı bir fontla render edilip açıkça "yazılı" olarak etiketlenmeli
  • İmza fotoğrafı yükleme (erişilebilirlik ve bazı iş süreçleri için kullanışlı)

Varsayılanı akıllı yapın: bir stilus algılanırsa çizim ön seçilsin; aksi halde seçenekler görünür kalsın.

Yaygın alanları hızlı tamamlanır hale getirin

Çoğu form imzadan daha fazlasını gerektirir. Küçük ekranlarda hızlı olmaya yardımcı alan araçları ekleyin:

  • Baş harfler (sayfalar arasında tekrar eden)
  • Otomatik doldurulan tarih ama düzenlenebilir
  • Kısa ve okunabilir onay metni ile onay kutusu
  • İsim/unvan alanları (metin için optimize edilmiş klavye)
  • Gerekli yerlerde serbest metin notları

Kullanıcı “İleri”ye dokunduğunda bir sonraki gerekli alana atlayın ve ilerlemeyi gösterin (örn. “3 / 7”).

Hataları önlemek için esnek kontroller ekleyin

İnsanlar titrek parmaklarla, parlama ve dikkat dağınıklığıyla imzalar. Koruyucu önlemler ekleyin:

  • İmza alanına otomatik yakınlaştırma
  • Stroke düzgünleştirme (hafif—imzanın karakterini bozmayacak şekilde)
  • Geri al/yinele son darbeler için
  • Belirgin bir Temizle düğmesi ve onay

Ayrıca kullanıcıların neyi imzaladığını bilmeleri için final belge bölümünün basit bir önizlemesini gösterin.

Erişilebilirlik temellerini kapsayın

Mobil imzalama herkes için çalışmalı:

  • Büyük dokunma hedefleri kullanın (özellikle onay kutuları ve “İmzala” eylemleri için)
  • İyi kontrast ve okunabilir font boyutları koruyun
  • Her alan, buton ve hata mesajı için ekran okuyucu etiketleri ekleyin

Kullanıcılar güvenle imza atamıyorsa imzalamazlar—bu yüzden UX'i ana özellik olarak ele alın.

Belgeleri Üretin ve İmzaları Doğru Uygulayın

“İmza”yı belgeye koymak işin yarısıdır. Diğer yarısı ise son dosyanın her yerde doğru görünmesi, bozulmaması ve ileride doğrulanabilir olmasıdır.

Tahmin edilebilir bir PDF'den başlayın

PDF'leri sunucu tarafı bir şablondan (veya iyi test edilmiş bir istemci şablonundan) oluşturun ki alan pozisyonları cihazlar arasında kaymasın. Yazdırma‑PDF kısayollarından kaçının; fontlar ve aralık değişebilir.

Formlar veri odaklıysa form verilerini ayrı (JSON) olarak saklayın ve paylaşım için insan tarafından okunabilir bir PDF sürümü de oluşturun.

İmzaları gömün: düzleştirme vs düzenlenebilir açıklamalar

İmza işaretini yerleştirmenin iki yaygın yolu vardır:

  • Düzenlenebilir açıklamalar (nihai belgeler için önerilmez): eklemek ve taşımak kolaydır, ancak bazı görüntüleyicilerde seçilebilir veya kaldırılabilir durumda kalabilir.
  • Düzleştirilmiş içerik (son kopya için önerilir): imza görüntüsü ve etiket sayfa içeriğine birleşir, normal mürekkep gibi davranır.

Pratik bir yaklaşım, imzalayan düzenlerken açıklamaları tutmak ve sonra **“Bitir”**te düzleştirmektir; böylece dışa aktarılan PDF tutarlı ve tespit edilmesi zor olur.

Değişikliği tespit edilebilir çıktı ile koruyun

Tam sertifikalı dijital imza yapmıyorsanız bile değişiklikleri tespit edilebilir kılabilirsiniz:

  • Nihai PDF için bir belge hash'i (örn. SHA-256) oluşturun ve kayıtta saklayın.
  • İmzalandıktan sonra iş akışınızda belgeyi kilitleyin: imzalandığında yeni bir “final” sürüm oluşturun ve önceki taslakları salt okunur yapın.
  • Destek ekibinin yetkili kopyayı hızlıca bulabilmesi için bir sürüm IDsi ekleyin.

Makbuz sayfası (veya tamamlama sertifikası) ekleyin

Kim, ne, ne zaman ve nasıl sorularına cevap veren basit bir makbuz sayfası ekleyin.

Tipik alanlar:

  • İmzalayan adı ve imzalama rolü
  • Zaman damgası (zaman dilimiyle) ve belge ID'si
  • Temel cihaz/uygulama bilgisi
  • IP adresi uygunsa ve gizlilik politikanız uygunsa

Okunur tutun—paydaşlar genellikle önce bu sayfaya bakar.

Her yerde çalışan dışa aktarma formatları

  • PDF: paylaşım ve yazdırma için varsayılanınız.
  • PDF/A: uzun süreli arşivleme için düşünün (font ve dış bağımlılıkları kısıtlar).
  • Görsel önizleme: kullanıcıların büyük bir PDF açmadan doğru belgeyi doğrulayabilmesi için PNG/JPEG önizleme oluşturun.
  • Paylaşılabilir bağlantı: bağlantı sunuyorsanız, bunları süre sınırlı ve izinli yapın; kesin imzalanmış sürüme işaret etsin.

Arka Uç, API'ler ve Veri Modelinizi Planlayın

Hazır Olunca Canlıya Geçin
Paylaşmaya hazır olduğunuzda özel alan adları destekleyen dağıtım ve barındırma seçenekleriyle uygulamanızı yayınlayın.

Cihazdaki iyi bir imzalama deneyimi, arka ucun belgeleri güvenilir şekilde oluşturup kim neyi imzaladığını izleyebildiğinde işe yarar. Kod yazmadan önce sistemin yönettiği “şeyleri” ve kullanıcıların yaptığı eylemleri eşleştirin.

Temel servisler (ne depolarsınız ve neyi takip edersiniz)

Çoğu mobil e‑imza uygulaması birkaç temel servise oturur:

  • Form şablonları: tekrar kullanılabilir tanımlar (alanlar, zorunlu imzalar, marka öğeleri)
  • Belgeler: imzalanacak oluşturulmuş veya yüklenmiş dosya
  • İmzalar: yakalanmış imza verisi artı yerleşim ve doğrulama bilgisi
  • Kullanıcılar/katılımcılar: kimin görüntüleyebileceği, imzalayabileceği, onaylayabileceği
  • Denetim olayları: eklenebilir zaman çizelgesi (oluşturuldu, görüntülendi, imzalandı, sonlandırıldı)

Bu ayrım veri modelinizi anlaşılır kılar ve karşı‑imzalama veya hatırlatıcılar gibi özellikleri eklemeyi daha kolaylaştırır.

Mobil uygulamanızın ihtiyaç duyacağı API'ler

Uç noktaları basit ve görev odaklı tutun. Tipik çağrılar:

  • Belge oluştur (isteğe bağlı şablondan)
  • Mevcut PDF yükle
  • İmzala (imza + alan değerlerini gönder)
  • Sonlandır (belgeyi kilitle, mühürle, nihai PDF oluştur)
  • İndir (orijinal + nihai)
  • Webhook geri çağrıları (imzalama tamamlandığında diğer sistemleri bilgilendir)

“İmzala” ve “sonlandır” için idempotentlik ekleyin ki kötü bağlantı çoğalmaya yol açmasın.

Depolama + sürümleme kuralları

Dosyalar için nesne depolama (orijinal PDF, nihai PDF, ekler) ve meta için bir veritabanı (katılımcılar, alan değerleri, imza yerleşimi, denetim olayları) kullanın.

Önceden sürümleme planlayın:

  • Bir şablon değiştiğinde mevcut belgelerin eski sürümle devam edip etmeyeceğine karar verin.
  • Yeniden imzalamanın ne zaman gerekli olduğunu tanımlayın (ör. alan değişikliklerinden sonra).
  • İptal kuralları: bir belgeyi kim geçersiz kılabilir ve denetim izi ne olur (geçersiz olarak işaretlenmiş şekilde kalmalı).

Kimlik, Güvenlik ve Denetim İzi

Bir mobil e‑imza uygulaması güven üzerine kuruludur. Kullanıcıların doğru kişinin imzaladığına, belgenin değiştirilmediğine ve sonradan ne olduğu kanıtlanabileceğine güvenmesi gerekir.

Kimlik doğrulama (sen kimsin?)

Birincil oturum açma yöntemi sunun ve imzalama öncesi adım atma seçeneği ekleyin.

E‑posta girişi birçok ekip için yeterlidir, fakat kurumsal müşteriler hesap ve erişimi merkezi yönetebilsin diye SSO (SAML/OIDC) isteyebilir.

Passkeys güçlü ve modern bir varsayılandır: oltalama dayanıklıdır ve parola sıfırlamalarını azaltır. İmzalamadan önce “yeniden kimlik doğrulama” için biyometri (Face ID/Touch ID) veya cihaz PIN'i destekleyin—kullanıcılar için hızlıdır ve cihaz sahibinin hazır olduğunu doğrular.

Yetkilendirme (ne yapmaya hakkın var?)

Rolleri ve izinleri erken tanımlayın. Yaygın eylemler: görüntüle, form alanlarını düzenle, imzala, karşı‑imzala, devret, indir ve iptal et.

Yetkilendirmeyi sadece uygulama arayüzünde değil sunucuda zorunlu kılın. Ayrıca belge düzeyi izinleri (bu sözleşme) ve alan düzeyi kuralları (sadece İK maaşı doldurabilir) düşünün. Destek ekibinin “neden imzalayamıyorum?” sorusuna hızlı cevap verebilmesi için net bir “gerçek kaynak” tutun.

Güvenlik temelleri (veriler nasıl korunur?)

Tüm ağ trafiği için TLS kullanın. Belgeleri ve hassas metadataları dinlenmede şifreleyin. Anahtarları kim yönetecek kararını verin: bulut KMS (yönetilen anahtarlar) mı yoksa düzenlenmiş müşteriler için müşteri yönetimli anahtarlar mı. Cihazda depolananları en aza indirin ve önbelleğe alınan dosyaları OS düzeyinde güvenli depolamayla koruyun.

Denetim izi (ne olduğu kanıtlanabilir mi?)

Her belge için değiştirilemez bir olay günlüğü oluşturun: oluşturuldu, görüntülendi, alanlar tamamlandı, imzalama başlatıldı, imza uygulandı, karşı‑imzalandı, indirildi ve iptal edildi. Her giriş aktör kimliği, zaman damgası, cihaz/uygulama sürümü ve değişiklikleri tespit edilebilir hash zinciri içermeli.

Açık bir denetim dışa aktarımı (PDF/JSON) “Ben bunu imzalamadım” iddiasını doğrulanabilir bir cevaba dönüştürür.

Çevrimdışı İmzalama ve Veri Kaybı Olmadan Senkronizasyon

İmza İş Akışınızı Prototipleyin
Ekran, roller ve denetim olaylarını sohbetle anlatarak çalışan bir imza uygulaması prototipi oluşturun.

Çevrimdışı imzalama, eksikliği fark edildiğinde kullanıcıların dikkatini çeken bir özelliktir—iş sahasında, bodrumda veya bağlantının düştüğü her yerde. Ama hedef sadece “internet olmadan çalışsın” değil, “asla çalışmayı kaybetmesin” olmalı.

“Çevrimdışı hazır” ne demeli

Çevrimdışı hazır genellikle dört yetenek içerir:

  • Formları ve şablonları önbelleğe alma ki kullanıcı doğru belgeyi ve alanları ağ çağrısı olmadan açabilsin.
  • Her girdiyi yerelde kaydetme (alan değerleri, fotoğraflar, onay kutuları, imza darbeleri) kullanıcı ilerledikçe.
  • Gönderimleri kuyruğa alma olarak değiştirilemez paketler (doldurulmuş form + imza + metadata) beklemeye alarak.
  • Bağlantı döndüğünde otomatik yükleme; kullanıcının formu tekrar açmasını gerektirmeden.

Göz ardı edilemeyecek çatışma yönetimi

Çevrimdışı karmaşık uç vakalar yaratır. Bunları açıkça planlayın:

  • Güncellenmiş şablon: biri çevrimdışı iken şablon değişirse, kullanıcının tamamladığı versiyonu koruyun ve bunu eski revizyon karşısında imzalanmış olarak ele alın. Birleştirmeye çalışmayın; inceleme için işaretleyin.
  • Çift gönderimler: her imzalama oturumu için istemci tarafından oluşturulmuş benzersiz bir ID kullanın ki yeniden denemeler birden çok kayıt oluşturmasın.
  • Kısmi yüklemeler: büyük bir ek yüklemesi ortasında başarısız olursa, nerede kaldığına göre devam edin (parçalı yükleme) veya temiz bir yeniden başlatma yapın; çift imzalama olmamalı.

Cihazda depolama ve temizlik

Çevrimdışı verileri güvenli bir kapsayıcıda saklayın: alan verileri için şifrelenmiş bir veritabanı ve PDF/ekler için şifrelenmiş dosyalar. Anahtarları platform anahtar deposunda tutun (iOS Keychain/Android Keystore).

Temizlik kuralları ekleyin: başarıyla senkronize edilmiş paketleri X günden sonra otomatik silme ve oturum kapatma sırasında taslakları temizleme.

Güven inşa eden kullanıcı geri bildirimi

Basit bir senkronizasyon durumu gösterin: “Cihazda kaydedildi,” “Senkronize bekliyor,” “Senkronize ediliyor,” “Senkronize edildi,” “İlgilenilmesi gerekiyor.” Tekrar dene düğmesi sağlayın, hataları sade dille açıklayın ve sunucu onayı gelmeden “gönderildi” demeyin.

Küçük bir yardım sayfası çevrimdışı destek taleplerini azaltır.

Mobil Teknoloji Yığını ve Araçları Seçin

Doğru yığın, imza deneyiminin nasıl “yerel” hissettireceğini, ne kadar hızlı yayınlayacağınızı ve ilerideki güncellemelerin ne kadar zahmetli olacağını belirler. İmza uygulamaları için pürüzsüz çizim, güvenilir PDF işleme ve öngörülebilir çevrimdışı depolama öncelikli olmalı.

Yerel mi yoksa çapraz platform mu

Yerel (Swift/Kotlin) genellikle kalem ve parmak tepki hızında daha iyi performans, dosyalar/ paylaşım/ güvenli depolama ile sıkı entegrasyon ve daha az render hatası sunar. İki kod tabanını korumak maliyetli olabilir.

Çapraz platform (React Native / Flutter) geliştirme süresini kısaltır ve UI tutarlılığı sağlar. Ancak karmaşık PDF render veya yüksek sıklıklı dokunuş olayları (imza çizimi) için genellikle native modüller gerekir—bu yüzden platforma özel iş gerekebilir.

İmza yakalama: kütüphane mi yoksa özel canvas mı?

Kanıtlanmış bir imza yakalama kütüphanesi genellikle en hızlı yoldur: stroke düzgünleştirme, basınç benzeri eğriler (simüle edilmiş) ve PNG/SVG dışa aktarımlarını ele alır.

Seçin ki:

  • Yüksek DPI çıkışı desteklesin (PDF'ler için temiz imzalar)
  • Silme/geri al işlevleri olsun
  • Cihazlar arasında tutarlı sonuç versin

Sadece özel mürekkep davranışı gerekiyorsa (ör. stilus optimizasyonu) veya veri formatları üzerinde sıkı kontrol istiyorsanız kendi canvas'ınızı inşa edin.

PDF araçları seçimi

Mobilde PDF imzalama için genelde üç yetenek gerekir:

  1. PDF'i doğru render etme (yakınlaştırma ve sayfa döndürme dahil)
  2. Form alanlarını okuma/düzenleme (AcroForms) eğer doldurulabilir formlar varsa
  3. İmza görüntüsü ve metadata'yı doğru sayfa koordinatlarına damgalama

Mobil desteği güçlü ve lisansı net bir PDF araç takımı seçin.

Sürdürülebilir tutun

Uygulamayı modüler bileşenler halinde yapılandırın: Formlar, İmzalama ve Depolama/Senkronizasyon. Bu, daha sonra bir kütüphaneyi (ör. PDF motoru) değiştirmeyi zorunlu kılmaz.

Kimlik kontrolleri veya daha derin bir denetim izi eklediğinizde, temiz sınırlar haftalar kazandırır.

Prototipleme hızınızı Koder.ai ile artırın (isteğe bağlı)

İş akışını hızlı doğrulamak istiyorsanız—şablonlar, roller, denetim olayları, çevrimdışı kuyruklama mantığı ve basit bir yönetici panosu—Koder.ai sohbet odaklı bir oluşturma süreciyle çalışan bir prototip elde etmenize yardımcı olabilir.

Koder.ai, tipik üretim yapı taşları (web konsolları için React, API/veri için Go + PostgreSQL, mobil için Flutter) ürettiğinden, hem mobil uygulama hem de sürümleme, güvenli depolama ve denetim izlerine sahip bir arka uç gerektiğinde uygundur. Planlama modu ve anlık görüntü/geri alma gibi özellikler, uyumluluk açısından hassas akışlarda yineleme yaparken faydalıdır. Hazır olduğunuzda kaynak kodunu dışa aktarabilir ve özel alan adlarıyla dağıtabilirsiniz.

Formlar ve İmzalar için Test Kontrol Listesi

Mobil e‑imza uygulamasını test etmek "çalışıyor mu?" sorusundan ziyade "kullanıcılar stresli, aceleci veya çevrimdışıyken bile çalışıyor mu?" sorusudur. Aşağıda her sürümden önce çalıştırabileceğiniz pratik bir kontrol listesi var.

Form doğrulama kuralları

Veri kalitesini koruyan kuralları test ederek başlayın. Sadece mutlu yolu test etmeyin—kendinizi kırmaya çalışın.

  • Zorunlu alanlar: zorunlu alanların gönderimi engellediğini doğrulayın; hata mesajları açık ve alanın yakınında olsun.
  • Format kontrolleri: e‑posta, telefon, posta kodu, kimlik ve tarihler (farklı yerel ayarlar ve klavye tipleri dahil).
  • Sayısal kısıtlar: min/maks değerler, ondalık hassasiyet, para formatlama.
  • Koşullu sorular: önceki yanıtlara göre görünen/kayıp alanlar şunları sağlamalıdır:
    • güvenli biçimde sıfırlansın (gizli geçersiz değer olmasın),
    • kullanıcı geri gittiğinde durumu korusun,
    • yalnızca görünür olduklarında doğrulansın.

Ayrıca kısmi kayıtları doğrulayın: “Taslak kaydet” izni varsa, taslaklar tam aynı durumla yeniden açılmalı ve aynı doğrulama davranışını göstermeli.

Mobil UX uç vakaları (destek taleplerine neden olanlar)

Mobil cihazlar masaüstü testlerinin yakalayamayacağı başarısızlık modları getirir.

  • Küçük ekranlar: uzun etiketler, yardım metinleri ve hata mesajları üst üste binmemeli veya kesilmemeli.
  • Yatay moda geçiş: form ortasında ve imza ortasında döndürün; düzen yeniden akmalı ve giriş kaybolmamalı.
  • Kesintiler: aramalar, uygulama değişimleri, hesap değişimi ve OS'nin arka planda uygulamayı öldürmesi gibi durumları test edin.
  • Erişilebilirlik temelleri: büyük metin ayarları, ekran okuyucu etiketleri ve odak sırası (özellikle imza adımı çevresinde).

İmza yakalama yüzeyi

İmza pedi küçük bir çizim uygulaması gibi ele alınmalı ve kendi test planı olmalı.

  • Cihaz kapsamı: düşük ve yüksek uç cihazları, farklı yenileme oranlarını ve OS sürümlerini test edin.
  • Stylus desteği: palm reddetme rastgele stroke üretmiyor mu, stylus girişi pürüzsüz mü?
  • Gecikme: hızlı darbeler ve noktalar çizin; mürekkep takip ediyor mu, atlama yapmıyor mu?
  • Kenar davranışı: kenarlara yakın yazma, kazara kaydırma hareketleri, çoklu dokunuş olayları.
  • Kontroller: temizle/yeniden/geri al, kullanılansa “Kabul ediyorum” onay kutusu ve gönderimden önce yeniden imzalama yolu.

Güvenlik testleri temelleri

Tam bir güvenlik laboratuvarına gerek yok ama niyet test edilmelidir.

  • Erişim kontrolü testleri: kullanıcılar bir ID değiştirerek, derin bağlantı veya önbellek dosya adı değiştirerek başkasının belgelerini açamamalı.
  • Tahrif denemeleri: yerel dosyaları, yakalanan istekleri veya çevrimdışı paketleri değiştirmeyi deneyin; sunucu değiştirilmiş içeriği reddetmeli ve denemeyi kaydetmelidir.
  • Logging: imza olaylarının tutarlı şekilde (oluşturuldu, görüntülendi, imzalandı, reddedildi, iptal edildi) kaydedildiğini ve loglarda hassas form verisi olmadığını doğrulayın.

Eğer denetim izi tutuyorsanız, her test çalışması şunu yanıtlamalı: Kim neyi, ne zaman ve hangi cihazda imzaladı açıklanabiliyor mu?

Gizlilik, Saklama ve Destek İş Akışları

Denetim İzlerini Erken Kurun
Kim, neyi ve ne zaman imzaladı sorusunun cevabını verebilmek için eklenebilir-yalnız log olarak bir denetim izi oluşturun.

Bir imza uygulaması sadece karalama almakla ilgili değildir—imzalandıktan sonra kişisel verileri sorumlu şekilde işlemekle ilgilidir. Burada net kurallar riski azaltır ve desteği kolaylaştırır.

Gizlilik‑özel tasarım (daha az topla, daha çok koru)

Uygulamanızın topladığı her veri noktasını listeleyin: isim, e‑posta/telefon, imza görüntüsü, zaman damgaları, konum, cihaz tanımlayıcıları ve herhangi bir kimlik bilgisi.

Her birini sorgulayın: Bu veriyi gerçekten anlaşmayı tamamlamak veya yasal gereksinimleri karşılamak için gerekli miyiz?

Rızayı imzalama anında veya kimlik yüklemeden önce açık ve görünür kılın. Eğer biyometri (Face ID/Touch ID) kullanıyorsanız, bunun cihaz üzerinde gerçekleştiğini ve biyometrik verileri saklamadığınızı açıklayın.

Ayrıca “ikincil kullanım” sınırlamalarını düşünün: imza verilerini analiz veya pazarlama için yeniden kullanmayın, kullanıcı açıkça izin vermedikçe.

Saklama ve silme kuralları

Saklamayı belge türüne ve müşteri tipine göre tanımlayın. Örnekler:

  • İmzalı sözleşmeleri X yıl saklayın (sektöre göre belirleyin).
  • Başarısız/terk edilmiş taslakları çok daha kısa süre saklayın.

Silme işlemini pratik yapın: elle silmeyi destekleyin (izinliyse), otomatik süre sonu ve hukuki bekletmeler. Silmelerin yedekleri kapsayıp kapsamadığını mümkün olduğunca düşünün ve hassas dosyayı saklamadan silindiğine dair kanıt tutun.

Kullanıcıların gerçekten ihtiyaç duyduğu destek iş akışları

Yaygın yardım isteklerini uygulama içi eylemler olarak planlayın:

  • Makbuz/confirm e‑postasını veya SMS'i yeniden gönderme.
  • İmzalı PDF'i yeniden indirme (erişim kontrolleriyle).
  • Hata düzeltme (örn. yanlış imzalayan e‑posta): genellikle “iptal et + yeniden düzenle” ile çözülür, imzalı bir dosyanın düzenlenmesiyle değil.

Yardım merkezinizde politikaları net olarak yayınlayın ve bunlara uygulama içinden erişim sağlayın; uyumluluk konularını kapsayan daha derin bir açıklamayı blog'da tutabilirsiniz.

Lansman, İzleme ve Zamanla İyileştirme

Mobil e‑imza uygulamasını yayınlamak bitiş çizgisi değildir—gerçek dünya geri bildirimi başlangıçtır. İyi bir lansman, mağaza kurallarını karşılamayı, operasyonel sorunları izlemeyi ve insanların nerede zorlandığını öğrenip önce doğru şeyleri düzeltmeyi gerektirir.

Uygulama mağazası gereksinimleri

Mağaza incelemesi ve politika detayları için zaman planlayın:

  • İzinler: sadece gerçekten ihtiyaç duyduklarınızı isteyin (kamera tarama için, dosyalar/PDF kaydetme için, bildirimler için durum güncellemeleri). Gereksiz izinler benimsemeyi yavaşlatır ve ekstra incelemeyi tetikleyebilir.
  • Veri güvenliği açıklamaları: ana mağazalar ne topladığınız (profil bilgileri, belgeler, cihaz tanımlayıcıları), nasıl kullandığınız ve paylaşılıp paylaşılmadığı hakkında açık beyan ister. Bunları uygulama içi gizlilik metniyle uyumlu tutun.
  • Ekran görüntüleri ve önizleme medyası: imza akışını, onayın nasıl alındığını ve imzalı dosyaların nerede saklandığını gösterin. Gerçek UI'yı yansıtmayan pazarlama görsellerinden kaçının.

Eğer biyometrik açılış destekliyorsanız, bunun uygulamaya giriş için kullanıldığını, tek başına imza kanıtı olmadığını açıklayın.

Operasyonel izleme (yabanda ne bozulur)

Yayın sonrası çoğu sorun “imza çalışmıyor” değil; ağ, depolama ve belge render hataları gibi kenar vakalardır. İzleyin:

  • Başarısız senkronizasyonlar (özellikle çevrimdışı imzalamadan sonra): tekrar denemeler, çatışmalar ve kısmi yüklemeler.
  • İmza uygulama hataları: render farklılıkları, eksik fontlar, yanlış sayfa koordinatları veya düzleştirme sorunları.
  • Depolama limitleri: büyük ekler, önbelleğe alınmış PDF'ler veya fotoğraf taramaları cihaz depolamayı doldurup kayıt hatalarına yol açabilir.

Loglarınızı eyleme geçirilebilir yapın: belge ID'si, adım adı (yakalama/uygulama/yükleme) ve destekin kullanabileceği insan tarafından okunabilir bir sebep içersin.

Analitikler ki gerçekten fayda sağlasın

UX sürtünmesi ve iş akışı uyuşmazlıklarını gösteren sinyalleri takip edin:

  • Form türü ve adım başına tamamlama oranı (aç → doldur → incele → imzala → gönder)
  • Terk noktaları (örn. kimlik kontrolü, inceleme ekranı, imza yerleştirme)
  • Belgelerin uzunluğuna ve imzalayanın çevrimiçi/çevrimdışı olmasına göre segmentlenmiş imzalama süresi

Bu metrikleri kullanıcıları izlemek için değil, UX değişikliklerini doğrulamak için kullanın. Varsayılan olarak toplulaştırın.

Kullanıcıların isteyeceği yol haritası fikirleri

Çekirdek akış stabil hale geldikten sonra, tekrar eden işleri azaltan ve ekipleri güçlendiren özelliklere öncelik verin:

  • İmzalayan davetleri (bir bağlantı gönder, durumunu takip et, hatırlatıcılar)
  • Sablonlar ve yeniden kullanılabilir alanlar
  • Takım rolleri (admin, hazırlayan, imzalayan, görüntüleyici) ve paylaşılan belge klasörleri
  • Entegrasyonlar (bulut depolama, CRM, ticket sistemleri) API ve webhook'lar aracılığıyla

Küçük bir değişiklik günlüğünü uygulama içinde veya blog'da tutun ki müşteriler neyin iyileştiğini ve nedenini anlasın.

SSS

Mobil imza uygulaması hangi tür “dijital imzaları” desteklemeli?

İhtiyaçlarınıza ve uyumluluk gereksinimlerinize göre yöntemi seçin:

  • Yazılı/çizilmiş/görsel imzalar hız ve yüz yüze iş akışları için iyidir, ancak ikna edici olmak için sağlam bir denetim izi gerekir.
  • Sertifikaya dayalı dijital imzalar güçlü değiştirilmezlik sağlar ve düzenlenmiş ortamlarda sıkça gereklidir.

V1'de ne destekleyeceğinize karar verin ve iş akışını (kimlik + bütünlük) buna göre tasarlayın.

Bir e‑imza daha sonra itiraz edilirse ayakta kalması için ne gerekir?

Üç ana sütuna odaklanın:

  • Niyet: imzalamanın kasti olduğunu netleştirin (ör. “Kabul ediyorum ve imzalıyorum”), kazara dokunuşları engelleyin ve önizleme gösterin.
  • Kimlik: imzalayanı eyleme bağlayın (hesap girişi, e‑posta/SMS doğrulama veya biyometrik gibi adım atma yöntemleri).
  • Bütünlük: imzadan sonra gizli değişiklikleri önleyin (kilitleme/sonlandırma, son PDF için hash oluşturma, belge sürümlerini saklama).
Mobil imzalar için denetim izine neler dahil edilmeli?

En azından şunları saklayın:

  • Ürününüz için uygun imzalayan bilgileri (isim, e‑posta/telefon, hesap ID'si, cihaz/oturum bilgisi)
  • Zaman damgaları zaman dilimiyle birlikte
  • İmzalanan belge kimliği ve tam versiyon/hash
  • İmzalama sırasında gösterilen onay metni ve kullanıcının eylemi (dokunma, onay kutusu vb.)

Bunu sadece eklenebilen bir günlük olarak tutun, böylece güvenilir bir olay zaman çizelgesi sunabilirsiniz.

Ekranları oluşturmadan önce bir imza iş akışı nasıl tanımlanır?

Net bir “mutlu yol” ile başlayın, sonra kenar durumları tanımlayın:

  • create → fill → review → sign → finalize → store/share
  • Roller: imzalayan, onaylayan, şahit (ve bir kişinin birden fazla rolü alıp alamayacağı)
  • Düzenlemeler için kurallar: hangi değişikliklerin yeniden imza gerektirdiği ve hangilerinin sonlandırma öncesi kabul edilebileceği
  • Reddetme/iptal akışları ve bunların denetim kaydında nasıl görüneceği
Mobil imzalamada hataları ve terk etmeyi azaltan hangi UX özellikleri önemlidir?

Birden fazla girdi sunun ve koruyucu önlemler ekleyin:

  • Varsayılan olarak çizilmiş imza sunun, fakat yazılı ve yükleme seçeneklerini görünür tutun.
  • İmza alanına otomatik yakınlaştırma yapın, ince stroke düzgünleştirme ekleyin ve geri al/yinele + onaylı bir “Temizle” düğmesi sağlayın.
  • "Sonraki gerekli alan" navigasyonu kullanın ve ilerlemeyi gösterin (ör. “3 / 7”).

Son adımı net yapın: incele → onay → imzala → gönder.

PDF'lere imzalar nasıl uygulanmalı ki tutarlı ve değiştirilemez olsun?

Tahmin edilebilir bir yöntem kullanın:

  • PDF'leri kararlı şablonlardan oluşturun, böylece alan pozisyonları cihazlar arasında kaymaz.
  • Düzenleme sırasında açıklama (annotation) kullanabilirsiniz—ancak tamamlandığında imza içeriğini PDF'e düzleştirin.
  • Bir “final” değiştirilemez sürüm oluşturun ve metadata ile birlikte SHA-256 (veya benzeri) bir hash saklayın.

Bu, dışa aktarılan dosyanın görüntüleyiciler arasında tutarlı olmasını ve tespit edilmeden değiştirilememesini sağlar.

Mobil imza uygulaması çevrimdışı güvenli çalışır mı?

Evet—eğer “çalışmayı asla kaybetmeme” hedefiyle tasarlanırsa:

  • Formu/şablonu önbelleğe alın ve kullanıcı ilerledikçe tüm girdileri yerelde kaydedin.
  • Tamamlanan imzalama oturumunu yüklemeye hazır değiştirilemez paketler olarak kuyruğa alın.
  • Yinelenen gönderimleri önlemek için idempotentite (istemci kaynaklı oturum ID'leri) kullanın.
  • Çatışmaları açıkça yönetin (ör. çevrimdışıyken şablon güncellendiğinde, kullanıcının versiyonunu eski revizyon olarak tutup inceleme için işaretleyin).
İmza uygulaması için hangi arka uç servisleri ve veri modeli gerekir?

Pratik bir ayrım şudur:

  • Dosyalar için nesne depolama: orijinal PDF, son PDF, ekler.
  • Meta için veritabanı: katılımcılar, alan değerleri, imza yerleşimi, denetim olayları, sürüm ID'leri.

Başlangıçta şablon/ belge sürümlemesi için kurallar koyun (ne zaman yeniden imza gereklidir, bir belge nasıl iptal edilir ancak denetim geçmişi korunur).

Mobil e‑imzalar için kimlik ve güvenlik nasıl ele alınmalı?

Katmanlı kontroller kullanın:

  • Kimlik doğrulama: hesap girişi, gerekirse SSO, imzalamadan önce adım atma için biyometrik veya cihaz PIN'i.
  • Yetkilendirme: sunucuda uygulanan roller (görme, düzenleme, imzalama, karşı-imzalama, indirme, iptal).
  • Koruma: iletimde TLS, dinlenmede şifreleme, cihazda minimum saklama ve OS anahtar deposu.

Biyometrinin uygulamaya giriş için kullanıldığını; tek başına imza kanıtı olmadığını açıkça belirtin.

Mobil imza uygulamasını yayınlamadan önce ne test etmeliyim?

İyi bir lansman öncesi test listesi:

  • Doğrulama kuralları: zorunlu alanlar, yerel tarih formatları, koşullu alanlar, taslak kaydetme/geri açma.
  • Mobil kenar durumları: form ortasında döndürme, araya giren çağrılar/uygulama değişimleri, küçük ekranlar, erişilebilirlik ayarları.
  • İmza yastığı testi: gecikme, kenar yazımı, çoklu dokunuş, stylus/palm reddetme.
  • Güvenlik kontrolleri: erişim kontrolü, çevrimdışı paket manipülasyonu, tutarlı denetim olayları.

Yayın sonrası başarısız senkronizasyonlar, PDF yerleşim hataları ve depolama kaynaklı çökme izlerini izleyin.

Related posts