10 puan yazan GN⁺ 2025-12-09 | 1 yorum | WhatsApp'ta paylaş
  • macOS uygulamaları, komut satırı programlarından daha karmaşık bileşenlere sahiptir ve pencere ile menü gibi arayüz kaynaklarını ayrı bir yapıda yönetir
  • Classic Mac OS'ta çalıştırılabilir kod ve kaynaklar dosyanın resource fork bölümünde saklanıyordu, ancak Mac OS X ile birlikte bundle yapısına geçildi
  • Uygulama bundle'ı, Contents dizini etrafında; MacOS, Resources, Frameworks gibi alt klasörler ve Info.plist gibi temel dosyalardan oluşur
  • Daha sonra kod imzalama, App Store makbuzu, notarization gibi unsurlar eklendi ve yapı güvenlik ile bütünlüğü güçlendirecek şekilde gelişti
  • Bu kendine yeterli app bundle yapısı, kurulum, güncelleme ve kaldırmayı basitleştirirken güvenlik ve bakım verimliliğini artıran temel bir zemin haline geldi

Classic Mac OS'ta uygulama yapısı

  • İlk Mac OS sürümlerinde pencere, menü gibi UI kaynakları, çalıştırılabilir dosyadan ayrılarak resource fork içinde saklanıyordu
    • Örnek olarak QuarkXPress 4.11 kaynakları ResEdit içinde görüntülenebiliyordu
    • Çalıştırma kodu CODE resource içinde yer alıyor, Finder'ın tanıyabilmesi için dosya türü (type) ve creator bilgileri de birlikte saklanıyordu

Mac OS X'in bundle yapısı

  • Mac OS X, NeXTSTEP kökenli bundle yapısını benimsedi
    • Uygulama, .app uzantılı bir dizin biçimindedir ve içinde Contents klasörü bulunur
    • MacOS klasörü, GUI uygulamasının çalıştırılabilir dosyasını ve komut satırı araçlarını içerir
    • Resources klasörü, uygulama simgesi, GUI bileşenleri ve benzeri kaynak dosyaları saklar
    • Bazı uygulamalar, Frameworks klasörü içinde dylib (dinamik kütüphane) gömülü olarak gelir
  • Info.plist dosyası zorunludur; çalıştırılabilir dosya adını, simgeyi, minimum macOS sürümünü, belge türlerini ve sürüm numaralarını tanımlar
  • PkgInfo dosyası, Classic Mac OS'taki type/creator bilgisini korur ancak zorunlu değildir
  • Uygulama çalıştırıldığında launchd yürütme kodunu başlatır; LaunchServices ve RunningBoard ise Info.plist bilgisine dayanarak başlatma sürecini yürütür

macOS'ta güvenlik ve genişleme

  • Mac OS X 10.5 Leopard (2007) ile birlikte Code Signature kullanıma girdi ve _CodeSignature klasörü eklendi
    • CodeResources dosyası, uygulama bütünlüğünü doğrulamak için kod dizini hash'ini (CDHash) içerir
  • App Store üzerinden dağıtılan uygulamalar, _MASReceipt klasöründe mağaza makbuzunu içerir
  • 2018'den sonra notarization devreye girdi; Apple tarafından verilen ticket, CodeResources dosyası üzerinden bundle'a staple edilebilir
  • Modern uygulama bundle'ları, geçmişte sistem klasörlerine kurulan bileşenleri artık kendi içinde taşır
    • Library klasörü: LaunchDaemons, LoginItems vb.
    • XPCServices klasörü: uygulamanın kullandığı ayrı yürütme servisleri
    • Plugins / Extensions klasörü: uygulama genişletmeleri ve App Intents içerir
    • Bazı uygulamalarda ayrıca version.plist dosyası da bulunur

Uygulama bundle'ının avantajları

  • Tüm bileşenlerin bundle içinde birleştirilmesi, kurulum, güncelleme ve kaldırmayı kolaylaştırır
  • Bileşen eksikliği olasılığı azalır; imzalama ve notarization koruması sayesinde güvenlik güçlenir
  • App Store uygulamaları, ek olarak makbuz ve notarization ticket içererek güvenilirlik sağlar
  • Intel ve Arm mimarileri arasında yapısal fark yoktur; Mach-O çalıştırılabilir dosyası, her iki platformun kodunu birlikte içeren universal (fat) binary biçiminde saklanır
    • Aynı dosya içinde her mimariye ait signature da birlikte bulunur

Uygulama yapısının görsel özeti

  • Diyagramda açık sarı, zorunlu ya da neredeyse tüm uygulamalarda bulunan bileşenleri gösterir
  • Yeşil, yalnızca App Store dağıtımlı uygulamalarda bulunan öğeleri; mavi ise isteğe bağlı notarization ticket'ını ifade eder
  • Ek olarak Automator workflow'ları, script'ler gibi yardımcı unsurlar da yer alabilir
  • Genel olarak macOS uygulamaları, kendine yeterli ve güvenlik odaklı bir yapıya doğru evrilmiştir

1 yorum

 
GN⁺ 2025-12-09
Hacker News yorumu
  • Maviyle işaretlenen kısım notarisation ticket (noter onayı bileti); pratikte aslında isteğe bağlı değil
    Noter onayı olmayan uygulamalar kullanıcı açısından o kadar zahmetli ki sonunda yıllık 99 dolarlık Apple geliştirici kayıt ücretini ödemek gerekiyor
    Sadece kişisel kullanım için derleyip çalıştıracaksanız sorun yok, ama dağıtım içinse macOS uyarı penceresi çıkarıyor ve uygulama bozukmuş gibi görünüyor
    Eskiden sağ tıklayıp çalıştırabiliyordunuz, ama artık izin vermek için Sistem Ayarları'na kadar girmeniz gerekiyor
    İlgili ekran görüntülerine Apple destek belgesinde ve geliştirici haberlerinde bakılabilir
    Apple'ın güvenlik felsefesini seviyorum ama App Store dışı uygulamalar için noter onayı sisteminin herkes için zararlı olduğunu düşünüyorum
    Noter onayının gerçekten bir güvenlik sorununu engellediği bir örnek bulamadım

    • macOS noter onayının can sıkıcı olduğunu düşünüyordum, ama Windows dağıtımı yapınca onun daha da kötü olduğunu gördüm
      Windows Defender'ın güvenini kazanmak için sertifika satın almanız gerekiyor ve hem şirketler hem bireyler derin kimlik doğrulamasından geçmek zorunda
      Donanım token'ıyla imzalama gerektiği için sürümü yalnızca tek bir kişi dağıtabiliyor
      Üstelik sertifika otoritesi anahtarı keyfi biçimde kilitleyebiliyor; güvenlik yaması yayımlamanız gerektiğinde buna takılmak korkunç olur
      Bu açıdan macOS ekosisteminin çok daha iyi olduğunu düşünüyorum

    • Birden çok platforma derlenen bir programlama dili geliştiriyorum ve imzalama ile noter onayı bu süreçle hiç uyuşmuyor
      Bu tür imza sistemleri sadece bir kontrol aracı ve Epic örneğinde olduğu gibi kötüye kullanılma riski taşıyor
      İmzasız ikili dosyaları makul şekilde çalıştırmak mümkün değilse o platformu kapalı sayar ve desteklemem
      iOS ya da Android gibi kapalı platformlar bir ölçüde PWA ile ikame edilebilir
      Ama Google'ın kendi imzalı uygulamaları çalıştırmaya izin vermeyi sürdüreceğine dair güvenim azaldı

    • Apple'ın App Store dışı uygulamaların sertifikalarını iptal ettiği yalnızca iki vaka biliyorum
      Biri Facebook'un Research App'i, diğeri Google'ın Screenwise Meter'ıydı
      İkisi de gençleri hedef alan casus yazılım niteliğinde uygulamalardı ve sertifika iptali yüzünden iç araçlar bile felç oldu
      Sonrasında Screenwise Meter'ın App Store'a yeniden döndüğü anlaşılıyor
      İlgili yazılar: Wired, EFF

    • Uygulama klasörümdekilerin yaklaşık yarısı noter onaylı değil, ama pratikte pek bir sorun yok

    • Noter onayından sonra stapled ticket (eklenmiş bilet) isteğe bağlıdır
      Bileti eklemezseniz kullanıcının noter onayı durumunu internet bağlantısıyla doğrulaması gerekir

  • AppBundler.jl geliştirirken macOS uygulama yapısından çok rahatsız oldum
    Frameworks klasör yapısının zorunlu tutulması görünüşte düzenli ama gerçekte paketlemeyi zahmetli hale getiriyor; ben de Libraries klasörüyle dolaşıyorum
    En büyük sorun kod imzalama — her ikiliye imza eklemek israf gibi geliyor
    Dosya hash'lerini toplayıp bir kez imzalamak yeterliyken bunu neden bu kadar karmaşık hale getirdiklerini anlamak zor
    Ayrıca entitlements'ın yalnızca launcher ikilisine eklenmesi de verimsiz
    Noter onayı kriterleri zamanla sıkılaştığı için uygulama ileride aniden geçemez hale gelebilir

  • Tauri uygulamasını imzalayıp noter onayından geçirmek için Apple Developer Program'a katıldım ama 3 haftadır başarısızım
    Mac'im olmadığı için GitHub Actions kullandım, ama ilk noter onayının uzun sürmesi yaygın deniyor
    Yalnızca GitHub maliyetine neredeyse 100 dolar harcadım ve hâlâ noter onayı alamadım
    Apple destek ekibi, Mac'im olmadığı ve Tauri kullandığım için yardım etmeyi reddediyor
    Noter onayı API kimlik doğrulama süreci de tam bir kabus — PKCS8 ile JWT üretmek gerekiyor ama neredeyse hiç belge yoktu, bu yüzden kendi Node programımı yazmak zorunda kaldım
    Şimdiye kadar yaşadığım en kötü geliştirici deneyimi (DX) buydu

    • 150 dolara ikinci el bir Mac mini alıp onunla imzalama yapmam tavsiye edildi
      Apple donanımı olmadan bunu çözmeye çalışmak zaman kaybı deniyor
  • İlk OS ekran görüntüsünü görünce içim cız etti
    Eskiden pratik ve sade bir arayüz vardı; şimdi ise yuvarlatılmış köşeler ve köpüksü simgelerle sadece alan israf ediliyor
    Yine de Mac donanımının kalitesi iyi olduğu için ThinkPad'e geçemiyorum

    • Yuvarlatılmış köşeler aslında insan görsel algısı için faydalı bir özellik
      Keskin köşelerin görsel yorgunluğa yol açtığını söyleyen araştırmalar var
      İlgili yazı: Round Rects Are Everywhere

    • Ben de modern macOS'u pek sevmiyorum ama o ekran görüntüsü de kusursuz değil
      Çizgi çok fazla, renk az; bu yüzden bakış dağılıyor
      Bana göre Leopard dönemindeki Aqua UI, bilgi yoğunluğu ile görsel derinlik arasında iyi bir denge kuruyordu

    • Piksel oranına bakarsanız eski arayüz aslında daha fazla yer kaplıyor
      5K çözünürlükte modern MacBook Pro tarafı daha verimli
      Klasik Mac'lerde de zaten hafif yuvarlatılmış köşeler vardı
      Bakınız: Infinite Mac

    • Bilgisayarlar yalnızca iş için değil, keyif için de bir araçtır
      Ama günümüz arayüzleri pratiklikten fazla uzaklaşmış gibi geliyor

    • Ekranın büyük kısmı işe yaramayan 101101 benzeri bilgilerle dolu, bu yüzden buna pratik demek zor

  • macOS'ta komut satırı aracını launchd'nin çalıştırdığı iddiası yanlış
    Gerçekte diğer UNIX sistemlerinde olduğu gibi shell içinden fork/spawn ile çalıştırılır

  • NeXTSTEP'in bundle sistemi Java'nın JAR dosyası tasarımına ilham verdi

    • Ama JAR aslında sadece uzantısı değiştirilmiş bir ZIP dosyası
  • Klasik Mac OS'teki Power Mac uygulamalarında PPC kodu data fork içinde saklanıyordu
    CFM-68K ikilileri de aynıydı; CODE resource kullananlar yalnızca eski 68K kodlarıydı

  • Eskiden ResEdit ile uygulama düzenlediğim günleri keyifle hatırlıyorum

  • Son diyagramdaki gibi bürokrasinin patlaması iyiye işaret değil
    macOS 26'ya “yükseltme” yapmak için bir neden daha az

    • Uygulama bundle'ına birkaç klasör daha eklenmiş diye bu kadar büyütmeye gerek olmadığını söyleyenler de var
  • Mevcut yapı macOS'in “standart”ı olsa da tek yol bu değil
    RPATH doğru ayarlanırsa kütüphaneleri rastgele alt klasörlere koyup yine de noter onayı alınabiliyor
    Örneğin AppName.App/Contents/Libraries yolu da çalışıyor
    Ama bunun pratikte neredeyse hiçbir avantajı yok ve sistemimdeki yaklaşık 100 uygulamanın hiçbirinde /Libraries klasörü kullanılmıyor

    • iOS bu konuda çok daha katı ve belirsiz
      .dylib yerine mutlaka .framework biçimi kullanılmalı ve bu belgelenmemiş bir kural
      Gönderim sırasında otomatik tespit edilip reddedilebiliyor