- 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-केंद्रित संरचना की ओर विकसित हुए हैं
अभी कोई टिप्पणी नहीं है.