Masaüstü Program Hangi Dille Yapılır? Electron, Tauri ve .NET

Teknoloji seçmeden önce sorulması gereken soru şu: bu iş gerçekten masaüstünde mi yaşamalı? Masaüstü uygulama, işletim sistemine kurulan ve dosya sistemine, seri porta, yazıcıya ya da ekran kartına doğrudan erişebilen programdır. Web uygulaması tarayıcıda çalışır, kurulum istemez, güncellemesi sunucuda bir kez yapılır. Aradaki fark teknik olmaktan çok operasyoneldir: kim, nerede, hangi cihazla ve internet varken mi yokken mi çalışıyor?

Teklif görüşmelerinde en sık duyduğum cümle “masaüstü daha güvenli olur” cümlesi. Kendiliğinden değil. Kurulum dosyası her bilgisayara yayıldığında, veritabanı bağlantı bilgisi ve iş kuralları da o bilgisayarlara yayılır. Güvenlik gerekçesiyle masaüstü seçiliyorsa veri modeli ve sunucu tarafı da buna göre tasarlanmalıdır.

Aşağıdaki akış, keşif toplantılarımızda sorduğumuz üç sorunun sırasını gösteriyor. Birine net bir “evet” çıkıyorsa masaüstü gündeme gelir. Üçü de “hayır” ise büyük olasılıkla bir web uygulaması daha ucuza yapılır ve daha kolay yönetilir.

Arada bir seçenek daha var: PWA (Progressive Web App). Tarayıcıdan “uygulama olarak yükle” denilebilen, kendi penceresinde açılan, service worker ile bazı ekranları çevrimdışı gösterebilen bir web uygulamasıdır. Donanım ve uzun süreli çevrimdışı çalışma gerekmiyorsa masaüstü hissini kurulum paketi olmadan verir. Mobil tarafta aynı ayrımı (native, cross-platform, PWA) mobil uygulama geliştirme rehberimizde karşılaştırdık. Elinizdeki iş bugün paylaşılan bir Excel dosyasında dönüyorsa Excel yerine ne kullanılır yazısı hazır yazılım ile özel yazılım kararını da kapsıyor.

Masaüstü uygulama hangi dil sorusunda karışıklığın çoğu, dil ile çatının (framework) aynı şey sanılmasından çıkar. “C# ile masaüstü uygulama” dediğinizde arkasında en az beş farklı arayüz çatısı var; “JavaScript ile masaüstü” dediğinizde ise neredeyse her zaman Electron kastediliyor. Dil, ekibin üretkenliğini ve eleman bulma kolaylığını belirler. Çatı ise programın hangi işletim sistemlerinde açılacağını, kurulum paketinin boyutunu ve donanıma giden yolun uzunluğunu.

Aşağıdaki harita Türkiye'deki ekip profillerine göre kurulmuş. Eleman havuzu değerlendirmesi nitel: kurumsal yazılımda C# ve web tarafında TypeScript bilen geliştirici bulmak görece kolay, Rust ve Qt deneyimli geliştirici bulmak daha zor. Bu bir dilin iyi ya da kötü olduğunu söylemez. Söylediği tek şey, beş yıl sonra kodu kimin devralacağı.

• C# / .NETEleman havuzu: GenişWinForms, WPF, WinUI 3, .NET MAUI, AvaloniaKime uyar: Windows ağırlıklı kurumlar, ERP ve muhasebe entegrasyonu, veri giriş ekranları.Dikkat: macOS veya Linux gerekiyorsa çatı seçimi ayrı bir karar: WPF ve WinForms yalnız Windows'ta çalışır.
• TypeScript / JavaScriptEleman havuzu: En genişElectron; Tauri'nin arayüz katmanıKime uyar: Web ekibi olan şirketler, üç işletim sistemi, var olan bir web uygulamasının masaüstü sürümü.Dikkat: Bellek ve paket boyutu; Electron sürüm takvimine ayak uydurma yükü.
• RustEleman havuzu: DarTauri (arka uç), Slint, eguiKime uyar: Küçük paket, düşük kaynak tüketimi, bellek güvenliği önemli olan ürünler.Dikkat: Öğrenme eğrisi ve derleme süreleri. Tauri'de arayüz web teknolojisiyle yazıldığı için Rust bilgisi küçük bir çekirdekte toplanabilir.
• C++Eleman havuzu: Dar ama deneyimliQt (Widgets / QML), wxWidgetsKime uyar: Endüstriyel ve gömülü sistemler, yoğun grafik, yüksek performanslı görselleştirme.Dikkat: Qt'nin LGPL/GPL ve ticari lisans seçenekleri ürününüzün dağıtım modeline göre ayrıca incelenmeli.
• DartEleman havuzu: OrtaFlutter desktopKime uyar: Zaten Flutter ile mobil uygulaması olan ve aynı kodu masaüstüne taşımak isteyen ekipler.Dikkat: Masaüstüne özgü eklentiler (yazıcı, seri port, sistem tepsisi) mobil kadar olgun değil.
• Java / KotlinEleman havuzu: Geniş (arka uçta)JavaFX, Compose MultiplatformKime uyar: Java ekosistemine yatırım yapmış kurumlar, iç araçlar.Dikkat: Çalışma zamanını paketlemek (jpackage) ve yerel görünüm beklentisi.
• PythonEleman havuzu: GenişPySide / PyQt, TkinterKime uyar: İç araçlar, veri betiklerine arayüz, hızlı prototip.Dikkat: Tek dosyalık paketler (PyInstaller) antivirüs yanlış alarmlarına sık takılır; satılacak bir ürün için önermiyoruz.

Electron, Chromium tarayıcı motorunu ve Node.js çalışma zamanını her uygulamanın içine paketleyen açık kaynaklı bir çatıdır. Uygulamanız bir ana süreç (main process: pencereleri açar, dosya sistemine ve işletim sistemine erişir) ile bir ya da daha fazla arayüz sürecinden (renderer: HTML, CSS ve JavaScript ile çizilen ekran) oluşur. Visual Studio Code, Slack ve Discord'un masaüstü uygulamaları Electron üzerinde çalışır; yani çatı, milyonlarca kullanıcıya dağıtılan ürünlerde sınanmış durumda.

Bunun faturası da belli: her Electron uygulaması kendi Chromium kopyasını taşır. En basit uygulamanın kurulum paketi bile onlarca megabayttan başlar ve her pencere bir tarayıcı sekmesi kadar bellek ister. Güçlü bir ofis bilgisayarında bu fark edilmez. Belleği sınırlı bir kasa bilgisayarında, aynı anda üç Electron uygulaması açık bir muhasebe ofisinde ya da yavaş bir şube hattından güncelleme indiren yüzlerce makinede fark edilir.

Güvenlik tarafında varsayılanlar yıllar içinde sıkılaştı. Electron 5'ten beri nodeIntegration kapalı, 12'den beri contextIsolation açık, 20'den beri arayüz süreçleri sandbox içinde geliyor. Doğru kurulumda arayüz kodu Node.js'e doğrudan erişemez; işletim sistemine giden her istek bir preload betiğinde tanımlanmış dar bir köprüden (IPC) geçer ve ana süreç, isteğin hangi pencereden geldiğini kontrol eder. Kod incelemelerinde en sık gördüğüm ve en tehlikeli hata, uzak bir web sayfasını Node yetkisiyle açan pencere.

// main.ts — pencere ayarları
const win = new BrowserWindow({
  webPreferences: {
    preload: path.join(__dirname, "preload.js"),
    contextIsolation: true, // varsayılan; yine de açıkça yazın
    nodeIntegration: false,
    sandbox: true,
  },
});

ipcMain.handle("yazici:fis-bas", async (event, fis) => {
  if (!izinliPencere(event.senderFrame)) throw new Error("izinsiz istek");
  return fisBas(fisDogrula(fis)); // gelen veriyi her zaman doğrulayın
});

// preload.ts — arayüze açılan tek kapı
contextBridge.exposeInMainWorld("kasa", {
  fisBas: (fis: Fis) => ipcRenderer.invoke("yazici:fis-bas", fis),
});

Bakım yükünü baştan hesaba katın: Electron yaklaşık sekiz haftada bir yeni ana sürüm çıkarır ve yalnız son üç ana sürüme güvenlik desteği verir. Yani bir Electron uygulaması, kimse yeni özellik istemese bile yılda birkaç kez güncellenmek zorundadır; Chromium'daki güvenlik açıkları sizin uygulamanızın da açığıdır. Paketleme ve güncelleme için en yaygın ikili electron-builder ve electron-updater; resmi alternatif ise Electron Forge.

Tauri da arayüzü web teknolojileriyle çizer, ama tarayıcı motorunu paketlemez. Windows'ta WebView2'yi, macOS'ta WKWebView'ü, Linux'ta WebKitGTK'yı, yani işletim sisteminin zaten taşıdığı WebView bileşenini kullanır. Uygulamanın arka ucu Node.js yerine Rust ile yazılır ve tek bir yerel çalıştırılabilir dosyaya derlenir. Sonuç, Electron'a kıyasla belirgin biçimde küçük bir kurulum paketi ve daha düşük boştaki bellek kullanımıdır. Kesin oranlar uygulamaya göre çok değiştiği için burada rakam vermiyorum; kendi ekranlarınızla hedef makinede ölçmek tek güvenilir yöntem.

Tauri 2, Ekim 2024'te kararlı sürüme ulaştı ve iki önemli şey getirdi. Birincisi capability (yetki) modeli: arayüzün hangi pencerede hangi komutu çağırabileceği bir yapılandırma dosyasında tek tek açılır; açılmayan yetki kullanılamaz. İkincisi resmi eklenti seti: updater, SQL, dosya sistemi, store, single-instance, autostart, bildirimler ve daha fazlası. Seri port için resmi eklenti yok; topluluk eklentileri var ya da Rust'ın serialport kütüphanesiyle kendi komutunuzu yazarsınız.

Tauri'nin de eksikleri var. Üç farklı WebView, üç farklı tarayıcı motoru demek: Windows'ta Chromium tabanlı Edge motoru, macOS ve Linux'ta WebKit. Bir CSS özelliğinin ya da bir JavaScript API'sinin üçünde aynı davrandığını varsayamazsınız; test matrisi Electron'a göre genişler. Rust öğrenme maliyeti de ekipte Rust bilen kimse yoksa küçümsenmemeli. Ben Rust tarafında çalışan biri olarak Tauri'ye yakınım, ama ekipte tek Rust bilen kişi olduğum projelerde bunu bir risk olarak yazarım.

// src-tauri/capabilities/kasa.json
{
  "identifier": "kasa-varsayilan",
  "windows": ["main"],
  "permissions": [
    "core:default",
    "updater:default",
    "sql:allow-load",
    "sql:allow-select",
    "sql:allow-execute"
  ]
}

// src-tauri/src/lib.rs — arayüzün çağırabileceği komut
#[tauri::command]
fn fis_bas(fis: Fis) -> Result<(), String> {
    yazici::esc_pos_gonder(&fis).map_err(|e| e.to_string())
}

Program yalnız Windows'ta çalışacaksa ve ekip C# biliyorsa, tarayıcı motoru taşımayan yerel bir .NET uygulaması hâlâ en öngörülebilir seçenektir. Bellek kullanımı düşüktür, Windows'un yazıcı kuyruğuna, Active Directory'ye, sertifika deposuna ve seri porta doğrudan erişir, MSI ya da MSIX olarak paketlenip Intune veya Configuration Manager ile dağıtılır. Bu durumda asıl karar dil değil, hangi .NET arayüz çatısının seçileceği.

• WinFormsWindowsEn iyi olduğu işVeri giriş ekranları, iç araçlar, hızlı form geliştirme. Visual Studio'daki sürükle-bırak tasarımcısı hâlâ en hızlı yol.Zayıf yanıYüksek DPI ve modern görünüm ek çaba ister; karmaşık, duruma göre değişen arayüzlerde kod hızla dağılır.
• WPFWindowsEn iyi olduğu işXAML ile tanımlanan zengin arayüzler, veri bağlama (data binding), MVVM ile test edilebilir ekran mantığı, stil ve tema.Zayıf yanıÖğrenme eğrisi WinForms'tan dik; XAML ve MVVM disiplini olmayan ekipte hızla karmaşıklaşır.
• WinUI 3Windows 10 / 11En iyi olduğu işWindows App SDK ile en güncel Windows görünümü (Fluent), modern kontroller.Zayıf yanıEkosistem WPF kadar olgun değil; üçüncü taraf kontrol seçenekleri daha sınırlı.
• .NET MAUIWindows, macOS (Mac Catalyst), iOS, AndroidEn iyi olduğu işAynı C# koduyla mobil ve masaüstü hedefleyen ekipler.Zayıf yanıResmî Linux desteği yok; masaüstüne özgü ihtiyaçlarda (çoklu pencere, yoğun tablo) mobil kökenli olduğu hissedilir.
• AvaloniaWindows, macOS, LinuxEn iyi olduğu işWPF'e çok benzeyen XAML ile üç işletim sistemi; WPF bilen ekip için en kısa çapraz platform yolu.Zayıf yanıMicrosoft ürünü değil, topluluk ve şirket destekli; bazı üçüncü taraf kontroller için ticari lisans gerekebilir.

Destek takvimi tarafında kısa not: .NET 8 ve .NET 9'un desteği 10 Kasım 2026'da bitiyor; .NET 10, 11 Kasım 2025'te LTS (uzun süreli destek) olarak yayımlandı ve 14 Kasım 2028'e kadar destekleniyor. Bugün başlayan yeni bir proje .NET 10 ile başlamalı. Eski .NET Framework 4.8 uygulamaları Windows'la birlikte çalışmayı sürdürüyor ama yeni özellik almıyor; taşıma takvimini VB6 ve Delphi modernizasyon yazısında tablo hâlinde verdik.

Tablodaki değerlendirmeler nitel ve sahadaki genel deneyime dayanıyor; benchmark sonucu değil. Bir hücredeki “zayıf” ifadesi o işin yapılamayacağı anlamına gelmez, yalnız daha fazla iş ve test gerektirdiğini gösterir.

Tek cümlelik karar

• ElectronÜç işletim sistemi ve web ekibi varsa en düşük riskli yol; bellek ve güncelleme disiplinini kabul edin.
• TauriPaket boyutu ve kaynak tüketimi belirleyiciyse; Rust bilen bir kişi ve üç OS'ta test bütçesi şart.
• WPFYalnız Windows, .NET ekibi ve uzun ömürlü bir iş uygulaması için en öngörülebilir seçim.
• AvaloniaWPF bilgisini macOS ve Linux'a taşımanın en kısa yolu.

Sekiz soruyu projenize göre yanıtlayın. Her yanıt altı seçeneğin puanını artırır ya da azaltır; bazı yanıtlar bir seçeneği tamamen eler (ör. macOS gerekiyorsa WPF ve WinForms). Sonuçta kazanan için gerekçeler, riskler, bir başlangıç yığını ve ilk iki haftada doğrulamanız gerekenler çıkar. Yanıtlamadığınız sorular puanı etkilemez.

Masaüstünü seçmenin en sağlam gerekçesi donanımdır; çatılar arasındaki fark da en çok burada hissedilir. .NET, Windows'ta donanıma en kısa yoldan ulaşır: seri port için System.IO.Ports paketi, yazıcı kuyruğu için Windows API'leri, üretici SDK'ları için de doğrudan DLL çağrısı. Electron'da aynı iş Node.js modülleriyle yapılır; en yaygını serialport paketidir ve yerel derlenen bir modül olduğu için her Electron sürüm yükseltmesinde yeniden derlenmesi gerekir. Tauri'de Rust'ın serialport kütüphanesiyle kendi komutunuzu yazar ya da bir topluluk eklentisi kullanırsınız.

Barkod okuyucuların çoğu kutudan çıktığında klavye gibi (USB HID) davranır: okunan kodu, imleç neredeyse oraya yazar. Bu her teknolojide çalışır ama kırılgandır; imleç yanlış alandaysa kod oraya düşer. Kasada daha güvenilir yol, okuyucuyu seri (sanal COM port) moduna almak ve okumayı uygulamanın arka planda dinlemesidir. Fiş yazıcılar büyük ölçüde ESC/POS komut setini konuşur; etiket yazıcılarda Zebra için ZPL, TSC için TSPL yaygındır. Terazilerde protokol çoğu zaman üreticiye özeldir, PLC tarafında ise Modbus TCP veya Modbus RTU sık görülür.

Bir cihaz kernel düzeyinde özel bir sürücü ya da yalnız 32 bit çalışan eski bir üretici DLL'i istiyorsa, hangi çatıyı seçerseniz seçin en temiz yol küçük bir yerel yardımcı servis yazmaktır: cihazla bu servis konuşur, arayüz uygulaması servise yerel bir kanal (named pipe ya da yalnız localhost'a açık, kimlik doğrulamalı bir uç) üzerinden bağlanır. Böylece arayüz teknolojisi değişse bile cihaz katmanı yerinde kalır.

Zorluk değerlendirmesi nitel ve Windows ortamı içindir; üretici SDK’sının hangi dilleri desteklediği sonucu tamamen değiştirebilir.

using System.IO.Ports;

using var port = new SerialPort("COM3", 9600, Parity.None, 8, StopBits.One);
port.NewLine = "\r\n";
port.ReadTimeout = 2000;
port.Open();

var satir = port.ReadLine();          // ör. "ST,GS,+0001.250kg" (biçim üreticiye göre değişir)
var kararli = satir.StartsWith("ST"); // ST = kararlı, US = sallanıyor

^XA
^CI28
^FX Üstteki satır UTF-8'i açar. ğ, ş ve İ için yazıcıda bu harfleri içeren bir font yüklü olmalı.
^FO40,30^A0N,32,32^FDÜrün: Zeytinyağı 1 L^FS
^FO40,74^A0N,24,24^FDRaf: B-14 · Şube: Kadıköy^FS
^FO40,112^BY2^BCN,80,Y,N,N^FD123456789012^FS
^XZ

Üretim hattında PLC ve terazi senaryolarını üretim tesisleri için masaüstü yazılım, kasa tarafındaki yazıcı, okuyucu ve ödeme cihazı entegrasyonunu perakende POS terminali için masaüstü yazılım sayfasında ayrıntılı anlattık. Cihaz envanteriyle başlayan bir projenin kapsamı ve teslim adımları masaüstü yazılım geliştirme hizmeti sayfasında.

“İnternetsiz de çalışsın” istemek kolay, doğru kurmak zor. Çevrimdışı öncelikli (offline-first) mimaride ekran her zaman yerel veritabanından okur ve oraya yazar; sunucu, arka planda senkronize edilen ikinci kaynaktır. Masaüstünde bunun için neredeyse her zaman SQLite kullanılır: tek dosyadır, kurulum istemez, .NET'te Microsoft.Data.Sqlite, Electron'da better-sqlite3, Tauri'de resmi SQL eklentisi ile erişilir.

Sunucuya gidecek her değişiklik önce bir outbox tablosuna yazılır. Bağlantı geldiğinde senkron döngüsü bu tabloyu sırayla boşaltır. Burada iki kurala baştan uyun, ikisini de sonradan eklemek pahalıdır. Birincisi, her kayda istemcide üretilmiş benzersiz bir kimlik (UUID) verin ve sunucu API'sini idempotent yapın: aynı kayıt iki kez gelirse ikinci kez işlenmez. Bağlantı tam gönderim anında koptuğunda istemci yanıtı alamaz ve yeniden dener; idempotent olmayan bir API'de bu, mükerrer satış demektir. İkincisi, sıralamayı istemcinin saatine bırakmayın. Kasa bilgisayarlarının saati kayar; sürüm numarası ya da sunucunun verdiği sıra numarası kullanın.

-- Yerel SQLite: sunucuya gidecek değişiklik kuyruğu
CREATE TABLE outbox (
  id           TEXT PRIMARY KEY,   -- istemcide üretilen UUID (idempotency anahtarı)
  entity       TEXT NOT NULL,      -- 'satis', 'stok_hareket', 'musteri'
  payload      TEXT NOT NULL,      -- JSON gövde
  base_version INTEGER,            -- kaydın bilinen son sunucu sürümü (çakışma tespiti)
  created_at   TEXT NOT NULL,
  attempts     INTEGER NOT NULL DEFAULT 0,
  last_error   TEXT,
  sent_at      TEXT                -- NULL = henüz gönderilmedi
);
CREATE INDEX ix_outbox_pending ON outbox(sent_at, created_at);

Senkron döngüsü adım adım

1. 1Bağlantıyı kontrol et; yoksa beklemeye devam et, kullanıcıya “çevrimdışı, n kayıt bekliyor” göster.
2. 2Gönderilmemiş kayıtları oluşturulma sırasıyla küçük paketler hâlinde al.
3. 3Her kaydı kimliğiyle gönder; sunucu daha önce işlediyse “zaten var” yanıtını başarı say.
4. 4Sunucu çakışma bildirirse kaydı çakışma kuyruğuna taşı, diğerlerini göndermeye devam et.
5. 5Başarılı kayıtları işaretle, ardından sunucudaki değişiklikleri (fiyat, stok, kampanya) yerele çek.
6. 6Hata alan kayıtların deneme sayısını artır; belirli bir eşikten sonra destek ekibine bildirim üret.

Çakışma çözümü: hangi veri için hangi kural?

• Son yazan kazanırNe zaman: Not, açıklama gibi kaybı tolere edilebilen alanlar.Risk: Sessiz veri kaybı; kimin değişikliğinin ezildiği görünmez.
• Alan bazlı birleştirmeNe zaman: Farklı kişilerin aynı kaydın farklı alanlarını değiştirdiği müşteri kartları.Risk: Aynı alan iki yerde değiştiyse yine kural gerekir.
• Kullanıcıya sorNe zaman: Sipariş, reçete, sözleşme gibi yanlış birleştirilmesi pahalı kayıtlar.Risk: Kullanıcı yorulur; yalnız gerçekten belirsiz durumlarda kullanın.
• Sunucu otoritesiNe zaman: Stok, bakiye, seri numarası: tek doğrunun merkezde olduğu veriler.Risk: Çevrimdışı satılan son ürün merkezde başka kanalda satılmış olabilir; iş kuralı gerekir.

Senkronizasyonun karşı tarafı sunucu API'sidir ve çoğu zaman projenin en az konuşulan ama en çok emek isteyen kısmıdır. API tasarımını API geliştirme hizmetimizde ayrıca yürütüyoruz; temel kavramlar için API nedir, entegrasyon nasıl yapılır yazısına bakabilirsiniz.

Masaüstü projelerinde en çok küçümsenen iş, programın kullanıcının makinesine güvenle ulaşması ve orada güncel kalmasıdır. Bir web uygulamasında “yayına almak” bir komuttur; masaüstünde paket biçimi, kod imzalama sertifikası, macOS için notarization (Apple'ın otomatik onay taraması), güncelleme sunucusu ve sürüm geri alma planı ayrı ayrı iş kalemleridir.

Kod imzalama kurulum dosyasının kimden geldiğini ve sonradan değiştirilmediğini kanıtlar. Haziran 2023'ten beri herkese açık güvenilir kod imzalama sertifikalarının özel anahtarı, FIPS 140-2 Seviye 2 veya Common Criteria EAL 4+ sertifikalı bir donanımda (USB token ya da HSM) tutulmak zorunda; anahtarı bir dosya olarak CI sunucusuna koymak artık mümkün değil. Bulut tabanlı imzalama hizmetleri ve Microsoft'un Artifact Signing (eski adıyla Trusted Signing) hizmeti bu yüzden yaygınlaştı. Türkiye'deki şirketler için bir ayrıntı: Artifact Signing, herkese açık güvenilir sertifikayı Ekim 2026 itibarıyla yalnız ABD, Kanada, AB ve Birleşik Krallık'taki kurumlara veriyor. Türkiye'de kurulu bir şirket için pratik yol, bir sertifika otoritesinden alınan OV sertifika ile USB token ya da otoritenin bulut imzalama hizmeti. 1 Mart 2026'dan itibaren düzenlenen ya da yenilenen sertifikaların azami geçerlilik süresi 460 gün; yani yenileme artık her yıl takvime yazılan bir iş.

İmzaya her zaman zaman damgası (timestamp) ekleyin. Zaman damgalı imza, sertifikanın süresi dolduktan sonra da geçerli kalır; damgasız imzada sertifika bittiği gün eski kurulum dosyalarınız “imzası geçersiz” görünmeye başlar. macOS'ta App Store dışında dağıtılan uygulamaların Developer ID ile imzalanması ve Apple'ın notarization servisinden geçirilmesi gerekir; notarytool ile gönderip stapler ile onayı pakete iliştirirsiniz.

Otomatik güncelleme kanalları

• electron-updaterelectron-builder ile gelir; kendi sunucunuzdan, S3 benzeri bir depodan veya GitHub Releases'tan güncelleme çeker.
• Tauri updaterResmi eklenti; güncelleme paketlerinin ayrı bir anahtarla imzalanması zorunludur, imzasız paketi kabul etmez.
• MSIX App InstallerWindows'un kendi mekanizması; .appinstaller dosyasıyla açılışta ya da arka planda güncelleme denetimi.
• Intune / Configuration ManagerKurum içinde güncellemeyi BT yönetir; uygulamanın kendi güncelleyicisi kapatılır, sürümü merkez belirler.

Yüzlerce makineye giden bir güncellemeyi asla tek seferde yaymayın. Önce pilot grup (birkaç mağaza ya da bir departman), sorun çıkmazsa daha geniş bir halka, en son herkes. Her halkada çökme raporlarını ve destek taleplerini izleyin; güncelleme sunucusunda bir önceki sürüme dönmeyi tek adımlık bir işlem hâline getirin. Kademeli dağıtımın ve imzalama altyapısının yıllık maliyetini masaüstü program yaptırmak: fiyatlar ve maliyet kalemleri yazısında kalem kalem ele alıyoruz.

Kullanıcının gördüğü iki Windows uyarısı sık karıştırılır. Sarı UAC penceresinde “Yayımcı: Bilinmiyor” yazıyorsa dosya imzasızdır ya da imzası bozulmuştur; çözüm imzalamaktır. Mavi SmartScreen penceresi (“Windows bilgisayarınızı korudu”) ise itibarla ilgilidir: imzalı bir dosya da, henüz yeterince indirilmemişse bu uyarıyı alabilir. Microsoft'un güncel belgelerine göre EV sertifika artık SmartScreen'i atlatmıyor; OV ve EV imzalı yeni dosyalar itibar biriktirene kadar uyarı görebilir, yalnız pencerede yayıncı adınız görünür.

İtibar, dosya karması (hash) ve yayıncı sertifikası üzerinden birikir. Aynı sertifikayla tutarlı biçimde imzaladığınız her sürüm, yayıncı itibarından yararlanabilir; sertifikayı değiştirmek bu sinyali zayıflatır. Kurumsal ortamlarda BT yöneticileri dosyayı Microsoft Security Intelligence portalına inceleme için gönderebilir. Aşağıdaki araç, kullanıcının gördüğü uyarıdan yola çıkarak muhtemel nedeni ve iki tarafın yapması gerekenleri çıkarıyor. Hiçbir senaryoda kullanıcıya SmartScreen'i ya da antivirüsü kapatmasını önermiyoruz; bu, sorunu sizin uygulamanızdan bütün bilgisayara taşır.

Masaüstü uygulama, kullanıcının makinesinde, sizin denetiminiz dışında çalışır. Dosyaları kopyalanabilir, ayarları okunabilir, trafiği izlenebilir. Bu yüzden güvenlik modeli “istemciye güvenme” ilkesiyle kurulmalı. Kod incelemelerinde en sık karşımıza çıkan altı açık şunlar:

1. 1Yapılandırma dosyasında parolaVeritabanı bağlantı dizesi ya da API anahtarı appsettings.json veya .env içinde düz metin duruyor. Kullanıcı bazlı kimlik doğrulama kullanın; makinede saklanması gereken sırları DPAPI, Kimlik Bilgileri Yöneticisi veya Keychain'e koyun.
2. 2İstemciden doğrudan veritabanına bağlanmakHer kurulum veritabanına tam yetkiyle bağlanıyorsa bir makinenin ele geçirilmesi tüm verinin ele geçirilmesidir. Araya yetki kontrolü yapan bir API koyun.
3. 3İmzasız güncellemeGüncelleme paketinin imzası istemcide doğrulanmıyorsa, ağın ortasındaki biri (sahte Wi-Fi, ele geçirilmiş bir proxy) kendi dosyasını “güncelleme” diye yükletebilir.
4. 4Electron'da uzak içerikUzak bir sayfayı Node yetkisiyle açmak, o sayfadaki herhangi bir XSS açığını uzaktan kod çalıştırmaya çevirir. Uzak içerik yalnız yetkisiz bir görünümde açılmalı.
5. 5Yerelde açık bırakılan portDonanım servisi localhost'ta kimlik doğrulamasız bir uç açıyorsa, kullanıcının tarayıcısındaki kötü niyetli bir sayfa da o uca istek atabilir.
6. 6Loglarda kişisel veriHata ayıklama için açılan ayrıntılı loglar TC kimlik numarası, telefon ya da sağlık verisi biriktirir. KVKK (6698 sayılı Kanun) kapsamında veri minimizasyonu ilkesini loglara da uygulayın; saklama süresi ve maskeleme belirleyin.

Kurulum dosyası, güncelleme kanalı ve yerel API'ler dâhil masaüstü uygulamanızı yayından önce dışarıdan test ettirmek isterseniz güvenlik ve sızma testi kapsamına alabiliriz. Kişisel veri işleyen uygulamalar için teknik tedbirlerin bütününü KVKK teknik ve idari tedbirler listesi yazısında topladık.

Teknoloji kararı bir toplantıda verilir ama doğruluğu ilk iki haftada anlaşılır. Bizim ekipte bu iki haftayı “geri dönmenin hâlâ ucuz olduğu dönem” olarak görüyoruz; aşağıdaki altı adım bittiğinde karar ya kesinleşir ya da az kayıpla değişir.

1. 1-2. günDonanım ve makine envanteriBağlanacak her cihazın marka, model ve yazılım sürümünü; sahadaki en zayıf bilgisayarın işlemcisini, belleğini ve işletim sistemi sürümünü listeleyin.
2. 2-5. günEn zor ekranın prototipiEn kolay ekranı değil, en çok kullanılan ve en karmaşık ekranı çizip çalıştırın. Arayüz akışını kullanıcıyla birlikte doğrulamak için UI/UX tasarım çalışması bu aşamada en çok işe yarar.
3. 4-7. günGerçek cihazla provaYazıcıdan Türkçe karakterli bir fiş, teraziden kararlı bir ağırlık, okuyucudan arka arkaya yirmi barkod. Hata durumlarını da deneyin: kabloyu çekin, kağıdı bitirin.
4. 6-9. günHedef makinede kurulabilir sürümPrototipi imzalı bir kurulum paketine dönüştürüp sahadaki en zayıf makineye kurun; açılış süresini ve boştaki belleği not edin.
5. 8-11. günGüncelleme ve geri alma provasıBir sonraki sürümü güncelleme kanalından gönderin, sonra bilerek bozuk bir sürüm yayımlayıp geri almayı deneyin.
6. 10-14. günÇevrimdışı ve karar kaydıAğ kablosunu çekip bir günlük işi simüle edin, bağlantı gelince senkronu izleyin. Ardından seçimi gerekçeleriyle tek sayfalık bir karar kaydına yazın.

Bu iki haftalık doğrulamayı tedarikçinizden de isteyin. Teklif aşamasında hangi soruların sorulacağını yazılım firması seçerken dikkat edilmesi gerekenler yazımızda listeledik. Ürününüzü satılacak bir masaüstü yazılımı olarak kurguluyorsanız lisanslama ve aktivasyon tarafını masaüstü ürün şirketleri için sayfasında ele alıyoruz.

Projeniz eski bir VB6 ya da Delphi programının yerini alacaksa eski Delphi ve VB uygulamaları için masaüstü yazılım sayfası veri ve iş kurallarını koruyarak geçişin nasıl planlandığını anlatıyor. Doğrudan konuşmak isterseniz teklif formunu doldurabilirsiniz.