Belajar Desktop Developer - Cross-Platform Mastery

#Pendahuluan

Di episode 24 kita mengelola banyak window dengan benar. Tapi ada janji yang belum kita tuntaskan sejak episode 0: satu codebase yang berjalan di Windows, macOS, dan Linux. Janji ini mudah disalahartikan — "write once, run anywhere" terdengar seperti menulis sekali dan semuanya selesai. Kenyataannya lebih halus: write once, adapt everywhere.

Episode ini membedah cross-platform mastery: layer abstraksi yang menyerap perbedaan OS, teknik deteksi platform, area yang paling sering meleset (shortcut, path, dialog, theming), dan matriks uji penuh yang membuktikan aplikasi kalian benar di semua platform — bukan hanya di OS tempat kalian develop.

#Strategi Satu Codebase

#Layer Abstraksi, Bukan Percabangan Sembarangan

Prinsip intinya: platform differences diserap oleh layer abstraksi, sementara UI dan logika bisnis tetap satu. Kalian mendefinisikan antarmuka (interface) untuk setiap capability sistem, lalu menulis implementasi per platform di belakangnya — pola yang sama seperti storage di episode 8 dan plugin SDK di episode 23.

export interface PlatformService {
  openPathDialog(): Promise<string | null>;
  notify(title: string, body: string): Promise<void>;
  getDataDir(): Promise<string>;
  getPrimaryModifier(): "ctrl" | "meta";
  openExternal(url: string): Promise<void>;
}

UI memanggil PlatformService, bukan implementasi spesifik OS. Ketika macOS butuh meta untuk shortcut dan Windows butuh ctrl, hanya implementasi yang berubah — komponen UI tidak tersentuh.

#Deteksi Platform vs Deteksi Fitur

Ada dua gaya deteksi:

• Deteksi platform — "kalau di macOS, lakukan X" — mudah tapi rapuh saat platform baru muncul.
• Deteksi fitur — "kalau OS punya fitur Y, pakai Y" — lebih tahan masa depan dan disarankan untuk capability yang tersebar tidak merata antar OS.

Gunakan deteksi platform untuk hal yang memang melekat pada OS (modifier key, dialog style), dan deteksi fitur untuk hal teknis (dukungan GPU, format notification).

#Area yang Paling Sering Berbeda Antar OS

Ini peta area yang hampir selalu meleset antar OS:

Banyak perbedaan ini sudah ditangani framework (menus, notifications). Tugas kalian adalah tidak meng-hardcode yang seharusnya di-delegasikan, dan menulis implementasi per platform untuk yang benar-benar berbeda.

#Kondisional Platform di Tiga Framework

Cara menulis cabang platform di tiap framework CatatanKu:

#[cfg(target_os = "macos")]
fn primary_modifier() -> &'static str { "meta" }
 
#[cfg(not(target_os = "macos"))]
fn primary_modifier() -> &'static str { "ctrl" }
 
// di webview: window.navigator.userAgent atau TAURI_ENV_PLATFORM

const primaryModifier = process.platform === "darwin" ? "meta" : "ctrl";
 
// di renderer, jangan andalkan navigator — tanya lewat IPC
ipcRenderer.invoke("platform:modifier"); // → "ctrl" | "meta"

import 'dart:io' show Platform;
 
final modifier = Platform.isMacOS ? "meta" : "ctrl";

Cmd+S   → save  (macOS)
Ctrl+S  → save  (Windows & Linux)

Perhatikan pola di Electron: renderer tidak membaca process.platform untuk keputusan UI penting — ia bertanya ke main process lewat IPC. Alasan keamanannya persis seperti episode 18 dan 24: renderer seharusnya tidak menggenggam informasi sistem yang bisa dipalsukan; satu sumber kebenaran di main/core.

#Praktik: Matriks Uji Penuh

Menulis kode lintas platform tanpa menguji di semua platform adalah perjudian. Kembali ke episode 17, CI kita sudah membangun artefak per OS — sekarang perkuat dengan matriks uji:

name: cross-platform-tests
on: [push, pull_request]
 
jobs:
  test:
    strategy:
      fail-fast: false
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    runs-on: ${{ matrix.os }}
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
      - run: bun install --frozen-lockfile
      - run: bun run build
      - run: bun run test:unit          # episode 15
      - run: bun run test:e2e           # Playwright lintas OS

Yang diuji di semua OS:

• E2E (episode 15) untuk alur inti — buka catatan, edit, sinkron, install plugin.
• Golden/snapshot test untuk rendering — tema, font, DPI yang berbeda.
• Unit test untuk PlatformService — gunakan fake per platform sehingga logika bisnis teruji tanpa OS nyata.
• Manual checklist — perilaku yang sulit di-automasi (drag-drop, notification, menu bar) diverifikasi per OS sebelum release.

#Strategi Artefak per OS

Satu codebase tidak berarti satu artefak. Tiap OS punya bentuk distribusinya sendiri (episode 12): .exe/.msi untuk Windows, .dmg/.pkg untuk macOS, .deb/.AppImage/.rpm untuk Linux — masing-masing dengan signing dan notarization-nya. CI matrix menghasilkan semuanya dari kode yang sama; itulah makna sebenarnya dari cross-platform mastery.

#Common Pitfalls

• Hanya menguji di OS development — bug platform tersembunyi sampai release; selalu matriks CI penuh.
• Meng-hardcode path separator — pakai API path framework (path.join), bukan string dengan / atau \.
• Shortcut Ctrl untuk semua OS — pengguna macOS akan frustrasi; hormati meta/Cmd.
• Mengabaikan DPI/scale — piksel yang sama terlihat berbeda di layar HiDPI; uji golden test di beberapa skala.
• Renderer membaca platform sendiri — di Electron, biarkan main process menjadi sumber tunggal kebenaran.

#Penutup

Inti yang harus dibawa pulang:

• Satu codebase = layer abstraksi: perbedaan OS diserap PlatformService, UI dan logika bisnis tetap satu.
• Deteksi fitur lebih tahan masa depan daripada deteksi platform untuk capability teknis; deteksi platform untuk hal yang melekat pada OS.
• Shortcut, path, titlebar, notification, dan theming adalah area yang paling sering meleset antar OS — jangan di-hardcode.
• Matriks uji penuh (unit + E2E + golden + manual checklist) di semua OS membuktikan kualitas, bukan sekadar asumsi.

Di episode 26 berikutnya kita melangkah mundur melihat gambaran besar: ekosistem & tren modern 2026 — peta posisi Tauri 2, Electron, Flutter, dan arah industri desktop ke depan. Sampai jumpa di episode 26!