Deprem uygulaması, depremle ilgili bilgiyi kullanıcının telefonuna taşıyan mobil uygulamadır. Mağazada “deprem uygulaması” diye aradığınızda karşınıza üç farklı ürün tipi çıkar: son depremleri listeleyen takip uygulamaları, bildirim gönderen uygulamalar ve binanın deprem riskini raporlayan uygulamalar. Bu üçü farklı veriyle çalışır, farklı kullanıcıya hitap eder ve farklı bir geliştirme süreci gerektirir.
Bu rehberde bir deprem uygulaması yapmadan önce vermeniz gereken kararları anlatıyoruz. Uygulama türlerini, veri kaynaklarını, bina risk raporu uygulamasının kurgusunu ve geliştirme sürecini ele alıyoruz. Örnek olarak, tasarım ve geliştirmesini Neon Apps olarak baştan sona yaptığımız Bina Deprem Raporum uygulamasını kullanıyoruz.
Deprem Uygulaması Türleri Nelerdir?
Fikrinizi netleştirmenin ilk adımı, hangi sorunu çözeceğinizi seçmektir. Deprem alanındaki uygulamalar üç ana gruba ayrılır.
Deprem takip uygulaması. Kurumların yayınladığı deprem kayıtlarını liste ve harita üzerinde gösterir. Büyüklük, derinlik, yer ve zaman bilgisi sunar. Teknik olarak en basit gruptur, çünkü ürünün temeli veriyi doğru çekmek ve okunur göstermektir.
Deprem bildirim uygulaması. Takip uygulamasına bir katman ekler: belirli büyüklüğün üzerindeki bir deprem kaydedildiğinde kullanıcıya bildirim gönderir. Burada bildirim altyapısı, kullanıcı tercihleri (konum, büyüklük eşiği) ve bildirimin gecikmesi öne çıkar.
Bina deprem risk raporu uygulaması. Depremden sonra ne olduğunu değil, depremden önce binanın durumunu anlatır. Kullanıcı binasına dair bilgileri girer, uygulama bir risk raporu üretir. Bu grup veri akışı değil, rapor üretimi ve kullanıcı yönlendirmesi üzerine kuruludur.
Deprem uyarı uygulaması aramalarında sık geçen “erken uyarı” ise ayrı bir konudur. Depremin başladığı anda saniyeler önce haber vermek özel sensör ağı ve uzmanlık gerektirir. Bu bir mobil uygulama fikrinden çok altyapı projesidir. Bu yüzden ürününüzün erken uyarı vaat edip etmediğini baştan net karara bağlayın ve yalnızca gerçekten sağlayabildiğinizi söyleyin.
Deprem Uygulaması İçin Veri Kaynakları ve API
Takip ve bildirim uygulamalarının hammaddesi deprem kayıtlarıdır. Türkiye’de bu kayıtları AFAD ve Kandilli Rasathanesi gibi kurumlar yayınlar, uluslararası tarafta EMSC gibi merkezler de benzer bir akış sunar. Aramalarda “deprem api”, “AFAD API” ve “Kandilli API” sorgularının görülmesi, geliştiricilerin ilk soruyu buradan sorduğunu gösterir.
Veri kaynağı seçerken şu noktaları kontrol edin:
Erişim biçimi: Kurumun resmi bir API’si mi var, yoksa liste sayfası mı yayınlıyor? Biçim kurumdan kuruma değişir.
Kullanım koşulları: Veriyi ticari bir uygulamada göstermek için izin ve atıf kuralları olabilir. Geliştirmeye başlamadan önce her kaynağın koşullarını okuyun.
Gecikme ve güncelleme sıklığı: Kayıtlar kurumun doğrulama sürecinden geçtikten sonra yayınlanır. Uygulamada gösterilen zamanın bir anlık bildirim olmadığını kullanıcıya açık yazın.
Birden fazla kaynak: Aynı depremi farklı kurumlar farklı büyüklükle yayınlayabilir. Kaynak adını her kayıtta göstermek kullanıcıya şeffaflık sağlar.
Bina risk raporu uygulamasında ise ana veri kullanıcının girdiği bina bilgisidir. Burada API’den çok, hangi sorulara cevap alacağınız ve raporun nasıl üretileceği önem kazanır.
Bina Risk Raporu Uygulaması Nasıl Kurgulanır?
“Binam depreme dayanıklı mı?” sorusu, deprem sonrası arama trafiğinin sürekli bir parçasıdır. İnsanlar “bina deprem riski sorgulama”, “bina deprem dayanıklılık testi” ve “deprem risk raporu” gibi ifadelerle aynı ihtiyacı arar: konutlarının durumu hakkında anlaşılır bir bilgi. Bu ihtiyacı karşılayan bir uygulama kurarken beş karar belirleyicidir.
Rapor kimin için ve ne kadar derin? Ev sahibi teknik bilgi sahibi değildir. Rapor jargon yerine sade bir dille risk seviyesini ve sonraki adımı göstermelidir.
Kademeli hizmet modeli. Herkesin aynı derinlikte analize ihtiyacı yoktur. Hızlı bir ilk bakış ücretsiz sunulabilir, daha ayrıntılı değerlendirme ayrı bir kademe olabilir. Bu model hem kullanıcıya seçenek verir hem de ürünün ilk denemesini kolaylaştırır.
Bilgi toplama deneyimi. Kullanıcıdan bina yaşı, kat sayısı, fotoğraf gibi bilgiler istenir. Soru sayısı arttıkça terk oranı da artar. Formu kısa tutmak ve her alanın neden istendiğini açıklamak gerekir.
Raporun güvenilirliği. PDF çıktının sonradan doğrulanabilmesi için QR gibi bir doğrulama yöntemi eklenebilir. Bu, raporu paylaşan kişi ile alan kişi arasında güven kurar.
Sonraki adım yönlendirmesi. Rapor tek başına bir sonuç değil, bir başlangıçtır. Kullanıcıya raporun ne anlama geldiğini ve bundan sonra hangi resmi ya da uzman yolunun izlenebileceğini göstermek, uygulamayı basit bir rapor üreticisinden gerçek bir yardımcıya dönüştürür.
Bina Deprem Raporum: Neon Apps’in Yaptığı Bir Örnek
Bina Deprem Raporum, ev sahiplerinin konutlarının deprem riskini teknik uzmanlık gerekmeden anlayabilmesi için geliştirdiğimiz bir bina risk raporu uygulamasıdır. Müşterimiz İsmail Taygun Kır için tasarımı ve geliştirmesini baştan Neon Apps olarak yaptık. Proje üç ayda tamamlandı ve uygulama 2 Temmuz 2026’da App Store’da yayına girdi.
Uygulamanın temel kurgusu şöyledir:
İki kademeli hizmet: Ücretsiz kademede otomatik olarak anında bir PDF risk raporu üretiliyor. Ücretli kademede kullanıcı fotoğraf yükleyebiliyor ve 48 saat içinde teslim edilen ayrıntılı bir uzman değerlendirmesi alabiliyor.
Yönetim paneli: Gelen taleplerin ve raporların takibi için bir yönetim paneli tasarlandı.
Rapor doğrulama: Üretilen raporlar QR kod ile doğrulanabiliyor.
Bildirimler: Rapor durumu hakkında kullanıcıya bildirim gönderiliyor.
Deprem takibi: Uygulama bina risk raporunun yanında AFAD, Kandilli ve EMSC kayıtlarını liste ve harita üzerinde de gösteriyor.
Bu kurgunun amacı, ev sahibinin teknik terimlerle uğraşmadan ücretsiz bir ilk bakış alması, daha derin bir değerlendirme isterse ikinci kademeye geçmesidir. Böylece uygulamayı denemenin önünde bir engel kalmaz.
Burada önemli bir sınır var: Bina Deprem Raporum bir erken uyarı uygulaması değildir ve uygulamadaki rapor bilgilendirme amaçlıdır. Resmi “riskli yapı tespiti” 6306 sayılı kanun kapsamında yapılan ayrı bir işlemdir ve uygulamadaki rapor bunun yerine geçmez. Resmi süreç için e-Devlet üzerindeki Riskli Yapı Tespiti sayfasına bakılabilir. Böyle bir sınırı uygulama içinde ve mağaza açıklamasında net yazmak, hem kullanıcıyı doğru yönlendirir hem de ürünün güvenilirliğini korur.
Projenin tüm ayrıntılarını Bina Deprem Raporum proje sayfasında bulabilirsiniz.
Deprem Uygulamasında Teknik Kararlar
Takip ve bildirim uygulamalarında veriyi doğrudan telefondan kuruma sormak yerine kendi sunucunuz üzerinden çekmek genellikle daha sağlıklıdır. Sunucu kayıtları düzenler, kaynaklar arasındaki farkları birleştirir ve bildirimi tek merkezden gönderir. Böylece her kullanıcı aynı kuruma ayrı istek atmaz, kaynak biçimi değiştiğinde yalnızca sunucuyu güncellersiniz. Bu ayrım, uygulamanız büyüdüğünde bakımı da kolaylaştırır.
Bağlantı zayıfken uygulamanın nasıl davrandığını da planlayın. Deprem sonrasında ağlar yoğunlaşabilir. Son görüntülenen listeyi telefonda saklamak ve verinin ne zaman güncellendiğini göstermek, boş bir ekrandan daha iyi bir deneyim sunar. Bildirimlerde ise gönderim servisinin ve kullanıcı tercihlerinin (konum, büyüklük eşiği) baştan tasarlanması gerekir.
Deprem Uygulaması Yaparken Dikkat Edilecekler
Deprem gibi hassas bir konuda ürün yaparken teknik kararlar kadar iletişim kararları da önem taşır.
Ne vaat ettiğinizi sınırlayın. Uygulamanız tahmin, erken uyarı ya da resmi tespit sunmuyorsa bunu açıkça yazın. Kullanıcı yanlış bir güven duygusuyla karar verebilir.
Kaynakları gösterin. Deprem verisinin hangi kurumdan geldiğini ve ne zaman güncellendiğini belirtin.
Sade bir dil kullanın. Kriz anında ya da endişeli bir ruh halinde uygulamayı açan kullanıcı karmaşık ekranlarla uğraşmak istemez. Büyük yazı, net renk ve az adım şarttır.
Kişisel veriyi koruyun. Konum, adres ve bina fotoğrafı hassas veridir. Hangi veriyi neden topladığınızı gizlilik politikanızda açıkça anlatın.
Bildirimleri ölçülü kullanın. Her küçük deprem için bildirim göndermek kullanıcıyı bildirimleri kapatmaya iter. Eşik ve konum tercihi sunun.
Erişilebilirlik. Bu tür uygulamaları her yaştan insan açar. Yazı boyutu, kontrast ve ekran okuyucu desteğini baştan düşünün. Kriz anında yalnızca tek elle ve kısa sürede kullanılabilen ekranlar işe yarar.
Gerçek senaryoyla test edin. Uygulamayı yalnızca geliştirme ortamında denemek yetmez. Farklı telefonlarda, yavaş bağlantıda ve bildirim izni kapalıyken nasıl davrandığını kontrol edin. Bildirimin zamanında gelip gelmediğini ve metnin kolay anlaşıldığını gerçek kullanıcılarla doğrulayın.
Kaynakları güncel tutun. Kurumlar veri biçimini ya da erişim koşullarını değiştirebilir. Kaynakları düzenli izleyin ve beklenmedik bir değişiklikte uygulamanın boş ya da hatalı veri göstermemesi için kontrol ekleyin.
Deprem Uygulaması Geliştirme Süreci
Türünden bağımsız olarak süreç benzer adımları izler. Önce ürünün hangi sorunu çözdüğünü ve hangi iddialarda bulunmayacağını yazılı hale getirin. Ardından kapsamı küçük tutan bir ilk sürüm planlayın. MVP geliştirme yaklaşımı burada işe yarar: çekirdek özelliği hızlıca kullanıcıya ulaştırır, geri bildirimle sonraki özellikleri belirlersiniz.
Tasarım tarafında, stresli bir bağlamda kullanılacak ekranlar için UI/UX tasarım süreci özellikle önemlidir. Geliştirme tarafında ise iOS ve Android’i birlikte hedefliyorsanız mobil uygulama geliştirme hizmetimizde bu kararları birlikte ele alıyoruz.
İlk sürümü yayınladıktan sonra mağaza açıklamasını, ekran görüntülerini ve uygulama içi metinlerdeki iddiaları yeniden gözden geçirin. Deprem gibi konularda yanlış anlaşılabilecek her cümle, kullanıcının uygulamadan beklentisini yanlış yönlendirebilir. Gerçek kullanıcıların hangi ekranda takıldığını izleyip ikinci sürümü buna göre planlayın.
Süre ve maliyet; kapsama, kademe sayısına, yönetim paneline ve entegrasyonlara göre değişir. Bina Deprem Raporum üç ayda tamamlandı, ancak her proje farklıdır. Fikrinizi konuşmak için bizimle iletişime geçin.
