macOS ऐप की संरचना

 (eclecticlight.co)
10 पॉइंट द्वारा GN⁺ 2025-12-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • macOS एप्लिकेशन में command-line प्रोग्राम की तुलना में अधिक जटिल components होते हैं, और window व menu जैसे interface resources को अलग संरचना में प्रबंधित किया जाता है
  • Classic Mac OS में executable code और resources फ़ाइल के resource fork में संग्रहीत होते थे, लेकिन Mac OS X से यह bundle संरचना में बदल गया
  • app bundle, Contents directory को केंद्र में रखकर, MacOS·Resources·Frameworks जैसे subfolders और Info.plist जैसी मुख्य फ़ाइलों से बना होता है
  • बाद में code signing·App Store receipt·notarization आदि जोड़े गए, और यह सुरक्षा व integrity को मजबूत करने वाली संरचना के रूप में विकसित हुआ
  • यह स्व-निहित app bundle संरचना installation·update·deletion को सरल बनाती है और security तथा maintenance efficiency बढ़ाने की एक प्रमुख नींव बनती है

Classic Mac OS की ऐप संरचना

  • शुरुआती Mac OS में window, menu आदि UI resources को executable file से अलग करके resource fork में संग्रहीत किया जाता था
    • उदाहरण के तौर पर QuarkXPress 4.11 के resources ResEdit में दिखाए जाते हैं
    • executable code CODE resource में शामिल होता था, और Finder द्वारा पहचाने जाने के लिए file type और creator जानकारी भी साथ में संग्रहीत की जाती थी

Mac OS X की bundle संरचना

  • Mac OS X ने NeXTSTEP से आई हुई bundle संरचना को अपनाया
    • app, .app extension वाली directory के रूप में होता है, जिसके अंदर Contents folder शामिल होता है
    • MacOS folder में GUI app का executable file और command-line tools शामिल होते हैं
    • Resources folder में app icon, GUI components आदि resource files संग्रहीत होती हैं
    • कुछ apps में Frameworks folder शामिल होता है, जिसमें dylib (dynamic library) अंतर्निहित होती हैं
  • Info.plist फ़ाइल अनिवार्य है, और यह executable file का नाम, icon, न्यूनतम macOS version, document types, version number आदि परिभाषित करती है
  • PkgInfo फ़ाइल Classic Mac OS की type·creator जानकारी को बनाए रखती है, लेकिन यह अनिवार्य नहीं है
  • app चलने पर launchd executable code शुरू करता है, और LaunchServices तथा RunningBoard, Info.plist की जानकारी के आधार पर initialization प्रक्रिया चलाते हैं

macOS में सुरक्षा और विस्तार

  • Mac OS X 10.5 Leopard (2007) से code signing (Code Signature) लागू किया गया, जिससे _CodeSignature folder जोड़ा गया
    • CodeResources file में code directory hash (CDHash) शामिल होता है, जो app integrity की जांच करता है
  • App Store के ज़रिये वितरित apps में _MASReceipt folder के भीतर store receipt शामिल होती है
  • 2018 के बाद notarization लागू की गई, जिससे Apple द्वारा जारी ticket को CodeResources file के ज़रिये bundle में ‘staple’ किया जा सकता है
  • आधुनिक app bundles अब उन components को भी अपने भीतर शामिल करते हैं जो पहले system folders में install होते थे
    • Library folder: LaunchDaemons, LoginItems आदि
    • XPCServices folder: app द्वारा उपयोग की जाने वाली अलग executable services
    • Plugins / Extensions folder: app extension features और App Intents शामिल
    • कुछ apps में version.plist फ़ाइल भी मौजूद होती है

app bundle के लाभ

  • सभी components को bundle के भीतर एकीकृत करने से installation·update·deletion आसान हो जाते हैं
  • components के छूटने की संभावना कम होती है, और signing तथा notarization protection के ज़रिये security मजबूत होती है
  • App Store apps अतिरिक्त रूप से receipt और notarization ticket शामिल करके विश्वसनीयता सुनिश्चित करते हैं
  • Intel और Arm architecture के बीच संरचनात्मक अंतर नहीं है, और Mach-O executable file दोनों platforms के लिए code शामिल करने वाले universal (fat) binary के रूप में संग्रहीत होती है
    • एक ही file के भीतर हर architecture का signature भी साथ मौजूद होता है

app संरचना का दृश्य अवलोकन

  • diagram में हल्का पीला रंग उन components को दर्शाता है जो अनिवार्य हैं या लगभग हर app में मौजूद होते हैं
  • हरा रंग केवल App Store distribution apps में मौजूद items को, और नीला रंग वैकल्पिक notarization ticket को दर्शाता है
  • अतिरिक्त रूप से Automator workflow, script आदि सहायक तत्व शामिल हो सकते हैं
  • कुल मिलाकर macOS apps स्व-निहित और security-केंद्रित संरचना की ओर विकसित हुए हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-12-09
Hacker News की राय

  • नीले रंग में दिखाया गया हिस्सा notarisation ticket है, और यह व्यवहार में लगभग वैकल्पिक नहीं है
    बिना notarize किए गए apps यूज़र के लिए इतने असुविधाजनक होते हैं कि अंततः सालाना $99 की Apple डेवलपर रजिस्ट्रेशन फ़ीस देनी पड़ती है
    अगर केवल निजी उपयोग के लिए build और run कर रहे हैं तो ठीक है, लेकिन distribution के लिए macOS warning dialog दिखाता है जिससे app टूटा हुआ लगता है
    पहले right-click करके चलाया जा सकता था, लेकिन अब अनुमति देने के लिए system settings तक जाना पड़ता है
    संबंधित screenshots Apple सहायता दस्तावेज़ और developer news में देखे जा सकते हैं
    मुझे Apple की security philosophy पसंद है, लेकिन App Store के बाहर वाले apps के लिए notarization system सभी पक्षों के लिए नुकसानदेह लगता है
    मुझे ऐसा कोई वास्तविक मामला नहीं मिला जहाँ notarization ने security issue रोका हो

    • मुझे लगा था macOS notarization झंझट है, लेकिन Windows distribution करके देखा तो वह उससे भी बदतर निकला
      Windows Defender का trust पाने के लिए certificate खरीदना पड़ता है, और company तथा individual दोनों को गहन identity verification से गुजरना पड़ता है
      hardware token से sign करना पड़ता है, इसलिए केवल एक व्यक्ति release deploy कर सकता है
      ऊपर से certificate authority मनमाने ढंग से key lock भी कर सकती है, इसलिए security patch जारी करनी हो और उसी समय रुक जाएँ तो बहुत भयानक स्थिति होगी
      इस लिहाज़ से macOS ecosystem काफ़ी बेहतर लगता है

    • मैं एक programming language विकसित कर रहा हूँ जो कई platforms के लिए compile होती है, और signing तथा notarization इस प्रक्रिया के बिल्कुल अनुकूल नहीं हैं
      ऐसी signing systems सिर्फ़ control mechanism हैं, और Epic वाले मामले की तरह इनके दुरुपयोग का जोखिम है
      अगर unsigned binaries को तार्किक तरीके से चलाया ही नहीं जा सकता, तो मैं उस platform को बंद मानता हूँ और support नहीं करता
      iOS या Android जैसे बंद platforms को कुछ हद तक PWA से बदला जा सकता है
      लेकिन Google self-signed apps चलाने की अनुमति देता रहेगा या नहीं, इस पर भरोसा कम हो गया है

    • मुझे केवल दो मामले पता हैं जहाँ Apple ने App Store के बाहर वाले apps के certificate revoke किए
      एक Facebook का Research App था, दूसरा Google का Screenwise Meter
      दोनों ही किशोरों को target करने वाले spyware जैसे apps थे, और certificate revoke होने से internal tools तक ठप हो गए
      उसके बाद Screenwise Meter शायद फिर से App Store पर आ गया
      संबंधित लेख: Wired, EFF

    • मेरे app folder का लगभग आधा हिस्सा notarize नहीं है, लेकिन व्यवहार में कोई खास समस्या नहीं है

    • notarization के बाद stapled ticket वैकल्पिक है
      अगर ticket attach नहीं किया जाए तो यूज़र को इंटरनेट connection के ज़रिए notarization status verify करना पड़ता है

  • AppBundler.jl बनाते समय macOS app structure को लेकर काफ़ी असंतोष हुआ
    Frameworks folder structure को मजबूरी से लागू करना देखने में साफ़-सुथरा लगता है, लेकिन असल में bundling को झंझटी बनाता है, इसलिए मैं Libraries folder का रास्ता ले रहा हूँ
    सबसे बड़ी समस्या code signing है — हर binary पर sign लगाना बेकार सा लगता है
    file hashes इकट्ठा करके एक बार sign करने से काम चल सकता है, फिर इसे इतना जटिल क्यों बनाया गया है समझना मुश्किल है
    इसके अलावा entitlements का केवल launcher binary पर लगना भी अप्रभावी है
    notarization के मानदंड समय के साथ सख़्त होते जाते हैं, इसलिए बाद में अचानक app पास न करे ऐसा हो सकता है

  • Tauri app को sign और notarize करने के लिए मैंने Apple Developer Program join किया, लेकिन 3 हफ़्तों से असफल हूँ
    मेरे पास Mac नहीं है, इसलिए GitHub Actions से कोशिश की, लेकिन कहते हैं पहली notarization में ज़्यादा समय लगना आम बात है
    केवल GitHub पर ही लगभग $100 खर्च हो गए, फिर भी notarization नहीं हुआ
    Apple support टीम ने Mac न होने और Tauri इस्तेमाल करने की वजह से मदद देने से मना कर दिया
    notarization API authentication process भी किसी दुःस्वप्न से कम नहीं है — PKCS8 से JWT बनाना पड़ता है, लेकिन documentation लगभग न के बराबर है, इसलिए मुझे खुद Node program लिखना पड़ा
    अब तक का यह सबसे खराब developer experience (DX) रहा

    • सलाह मिली कि $150 में पुराना Mac mini खरीदो और उसी से sign करो
      Apple hardware के बिना इसे सुलझाने की कोशिश समय की बर्बादी बताई गई

  • पहले OS screenshot को देखकर दिल बैठ गया
    पहले व्यावहारिक और साफ़ UI हुआ करता था, लेकिन आजकल गोल कोने और बुलबुले जैसे icons सिर्फ़ जगह बर्बाद करते लगते हैं
    फिर भी Mac hardware की quality अच्छी है, इसलिए ThinkPad पर switch नहीं कर पा रहा हूँ

    • गोल कोने दरअसल मानव दृष्टि के लिए फायदेमंद फीचर हैं
      इस बारे में शोध है कि नुकीले कोने visual fatigue पैदा करते हैं
      संबंधित लेख: Round Rects Are Everywhere

    • मुझे भी नया macOS ज़्यादा पसंद नहीं, लेकिन वह screenshot भी परफ़ेक्ट नहीं है
      उसमें lines बहुत ज़्यादा हैं और color कम, इसलिए नज़र बँटती है
      निजी तौर पर मुझे Leopard युग का Aqua UI information density और visual depth के संतुलन के लिहाज़ से बेहतर लगता था

    • pixel ratio के हिसाब से देखें तो पुराना UI उल्टा ज़्यादा जगह घेरता है
      5K resolution के आधार पर आधुनिक MacBook Pro ज़्यादा कुशल है
      पुराने Mac में भी थोड़े बहुत rounded corners पहले से थे
      संदर्भ: Infinite Mac

    • कंप्यूटर सिर्फ़ काम के लिए नहीं, आनंद के लिए भी एक उपकरण है
      लेकिन आजकल का UI व्यावहारिकता से बहुत दूर चला गया लगता है

    • स्क्रीन का ज़्यादातर हिस्सा 101101 जैसी बेकार जानकारी से भरा है, इसलिए इसे व्यावहारिक कहना मुश्किल है

  • macOS में command-line tools चलाते समय launchd ही execution entity है, यह बात ग़लत है
    वास्तव में दूसरे UNIX systems की तरह shell से fork/spawn के ज़रिए execution होता है

  • NeXTSTEP का bundle system Java के JAR files के डिज़ाइन के लिए प्रेरणा बना था

    • लेकिन JAR असल में सिर्फ़ ZIP file है जिसका extension बदला गया है

  • classic Mac OS में Power Mac apps का PPC code data fork में stored होता था
    CFM-68K binaries के साथ भी यही था, और CODE resource का उपयोग सिर्फ़ पुराने 68K code में होता था

  • पुराने ResEdit से apps modify करने के दिन याद करके अच्छा लगता है

  • आख़िरी diagram की तरह bureaucracy का विस्फोट होना अच्छा संकेत नहीं है
    macOS 26 में “upgrade” करने की वजह और कम हो जाती है

    • एक प्रतिक्रिया यह भी है कि app bundle में कुछ folders बढ़ जाने पर इतना हंगामा करने की ज़रूरत नहीं

  • अभी की structure macOS का “standard” ज़रूर है, लेकिन यही एकमात्र तरीका नहीं है
    अगर RPATH सही सेट हो तो libraries को किसी भी subfolder में रखकर भी notarization pass कराया जा सकता है
    उदाहरण के लिए AppName.App/Contents/Libraries path भी काम करता है
    लेकिन इस तरीके का व्यावहारिक लाभ लगभग नहीं के बराबर है, और मेरे system के लगभग 100 apps में से एक भी /Libraries folder इस्तेमाल नहीं करता

    • iOS में यह हिस्सा कहीं ज़्यादा सख़्त और अस्पष्ट है
      .dylib की जगह .framework format अनिवार्य है, और यह undocumented rule है
      submission के समय इसे अपने-आप detect करके reject किया जा सकता है