7. iOS ਉੱਤੇ ਪਾਇਥਨ ਦੀ ਵਰਤੋਂ¶

ਲੇਖਕ:: Russell Keith-Magee (2024-03)

iOS ਉੱਤੇ ਪਾਇਥਨ ਦੀ ਵਰਤੋਂ ਡੈਸਕਟਾਪ ਪਲੇਟਫਾਰਮਾਂ ਉੱਤੇ ਪਾਇਥਨ ਦੀ ਵਰਤੋਂ ਤੋਂ ਵੱਖਰੀ ਹੈ। ਡੈਸਕਟਾਪ ਪਲੇਟਫਾਰਮ ਉੱਤੇ ਪਾਇਥਨ ਆਮ ਤੌਰ 'ਤੇ ਇੱਕ ਸਿਸਟਮ ਸਰੋਤ ਵਜੋਂ ਇੰਸਟਾਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸਦੀ ਵਰਤੋਂ ਉਸ ਕੰਪਿਊਟਰ ਦਾ ਕੋਈ ਵੀ ਉਪਭੋਗਤਾ ਕਰ ਸਕਦਾ ਹੈ। ਇਸ ਤੋਂ ਬਾਅਦ ਉਪਭੋਗਤਾ python ਐਗਜ਼ਿਕਿਊਟੇਬਲ ਚਲਾ ਕੇ ਅਤੇ ਇੰਟਰਐਕਟਿਵ ਪ੍ਰੌਮਪਟ ਉੱਤੇ ਕਮਾਂਡਾਂ ਦਰਜ ਕਰਕੇ ਜਾਂ ਪਾਇਥਨ ਸਕ੍ਰਿਪਟ ਚਲਾ ਕੇ ਪਾਇਥਨ ਨਾਲ ਕੰਮ ਕਰਦੇ ਹਨ।

iOS ਉੱਤੇ ਸਿਸਟਮ ਸਰੋਤ ਵਜੋਂ ਇੰਸਟਾਲ ਕਰਨ ਦੀ ਕੋਈ ਧਾਰਣਾ ਨਹੀਂ ਹੈ। ਸਾਫਟਵੇਅਰ ਵੰਡ ਦੀ ਇਕੋ ਇਕ ਇਕਾਈ "ਐਪ" ਹੈ। ਇੱਥੇ ਕੋਈ ਐਸਾ ਕੰਸੋਲ ਵੀ ਨਹੀਂ ਹੁੰਦਾ ਜਿੱਥੇ ਤੁਸੀਂ python ਐਗਜ਼ਿਕਿਊਟੇਬਲ ਚਲਾ ਸਕੋ ਜਾਂ Python REPL ਨਾਲ ਇੰਟਰਐਕਟ ਕਰ ਸਕੋ।

ਨਤੀਜੇ ਵਜੋਂ, iOS ਉੱਤੇ ਪਾਇਥਨ ਦੀ ਵਰਤੋਂ ਕਰਨ ਦਾ ਇਕੋ ਤਰੀਕਾ ਐਮਬੈਡਡ ਮੋਡ ਹੈ — ਅਰਥਾਤ ਇੱਕ ਮੂਲ iOS ਐਪਲੀਕੇਸ਼ਨ ਲਿਖਣਾ, libPython ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਾਇਥਨ ਇੰਟਰਪ੍ਰੀਟਰ ਨੂੰ ਐਮਬੈਡ ਕਰਨਾ ਅਤੇ Python embedding API ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਾਇਥਨ ਕੋਡ ਨੂੰ ਚਲਾਉਣਾ। ਫਿਰ ਪੂਰਾ ਪਾਇਥਨ ਇੰਟਰਪ੍ਰੀਟਰ, ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਤੁਹਾਡਾ ਸਾਰਾ ਪਾਇਥਨ ਕੋਡ ਇੱਕ ਸੁਤੰਤਰ bundle ਦੇ ਰੂਪ ਵਿੱਚ ਪੈਕੇਜ ਕੀਤਾ ਜਾਂਦਾ ਹੈ ਜਿਸਨੂੰ iOS App Store ਰਾਹੀਂ ਵੰਡਿਆ ਜਾ ਸਕਦਾ ਹੈ।

If you're looking to experiment for the first time with writing an iOS app in Python, projects such as BeeWare, Kivy, and Flet will provide a much more approachable user experience. These projects manage the complexities associated with getting an iOS project running, so you only need to deal with the Python code itself.

7.1. iOS ਉੱਤੇ ਰਨਟਾਈਮ ਦੌਰਾਨ ਪਾਇਥਨ¶

7.1.1. iOS ਸੰਸਕਰਣ ਅਨੁਕੂਲਤਾ¶

ਸਮਰਥਿਤ ਘੱਟੋ-ਘੱਟ iOS ਸੰਸਕਰਣ ਕੰਪਾਈਲ ਸਮੇਂ configure ਦੀ --host ਵਿਕਲਪ ਰਾਹੀਂ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਮੂਲ ਰੂਪ ਵਿੱਚ, iOS ਲਈ ਕੰਪਾਈਲ ਕੀਤੇ ਜਾਣ 'ਤੇ ਪਾਇਥਨ ਨੂੰ ਘੱਟੋ-ਘੱਟ 13.0 iOS ਸੰਸਕਰਣ ਦੇ ਸਮਰਥਨ ਨਾਲ ਕੰਪਾਈਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਕਿਸੇ ਹੋਰ ਘੱਟੋ-ਘੱਟ iOS ਸੰਸਕਰਣ ਦੀ ਵਰਤੋਂ ਕਰਨ ਲਈ ਸੰਸਕਰਣ ਨੰਬਰ ਨੂੰ --host ਆਰਗਿਊਮੈਂਟ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਦਿਓ — ਉਦਾਹਰਨ ਵਜੋਂ, --host=arm64-apple-ios15.4-simulator ਇੱਕ ARM64 simulator build ਨੂੰ 15.4 deployment target ਨਾਲ ਕੰਪਾਈਲ ਕਰੇਗਾ।

7.1.2. ਪਲੇਟਫਾਰਮ ਪਛਾਣ¶

ਜਦੋਂ iOS ਉੱਤੇ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, sys.platform ਦਾ ਮੁੱਲ ios ਹੋਵੇਗਾ। ਇਹ ਮੁੱਲ iPhone ਜਾਂ iPad ਦੋਹਾਂ ਉੱਤੇ ਵਾਪਸ ਕੀਤਾ ਜਾਵੇਗਾ, ਭਾਵੇਂ ਐਪ simulator ਉੱਤੇ ਚੱਲ ਰਹੀ ਹੋਵੇ ਜਾਂ ਅਸਲ ਡਿਵਾਈਸ ਉੱਤੇ।

ਖਾਸ ਰਨਟਾਈਮ ਵਾਤਾਵਰਣ ਬਾਰੇ ਜਾਣਕਾਰੀ, ਜਿਸ ਵਿੱਚ iOS ਸੰਸਕਰਣ, ਡਿਵਾਈਸ ਮਾਡਲ ਅਤੇ ਇਹ ਕਿ ਡਿਵਾਈਸ simulator ਹੈ ਜਾਂ ਨਹੀਂ, platform.ios_ver() ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕੀਤੀ ਜਾ ਸਕਦੀ ਹੈ। platform.system() ਡਿਵਾਈਸ ਦੇ ਅਨੁਸਾਰ iOS ਜਾਂ iPadOS ਦਰਸਾਏਗਾ।

os.uname() ਕਰਨਲ ਪੱਧਰ ਦੀ ਜਾਣਕਾਰੀ ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ; ਇਹ Darwin ਨਾਮ ਦਰਸਾਏਗਾ।

7.1.3. ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਦੀ ਉਪਲਬਧਤਾ¶

iOS ਉੱਤੇ ਪਾਇਥਨ ਦੀ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਕੁਝ ਮਹੱਤਵਪੂਰਨ ਪਾਬੰਦੀਆਂ ਅਤੇ ਗੈਰਹਾਜ਼ਰ ਵਿਸ਼ੇਸ਼ਤਾਵਾਂ ਹਨ। ਵੇਰਵਿਆਂ ਲਈ API availability guide for iOS ਵੇਖੋ।

7.1.4. ਬਾਈਨਰੀ ਐਕਸਟੈਂਸ਼ਨ ਮੋਡੀਊਲ¶

iOS ਪਲੇਟਫਾਰਮ ਦੀ ਇੱਕ ਮਹੱਤਵਪੂਰਨ ਵਿਸ਼ੇਸ਼ਤਾ ਇਹ ਹੈ ਕਿ App Store ਰਾਹੀਂ ਵੰਡ ਲਈ ਐਪਲੀਕੇਸ਼ਨ ਦੀ ਪੈਕੇਜਿੰਗ ਸੰਬੰਧੀ ਸਖ਼ਤ ਲੋੜਾਂ ਹੁੰਦੀਆਂ ਹਨ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਇੱਕ ਲੋੜ ਇਹ ਨਿਰਧਾਰਤ ਕਰਦੀ ਹੈ ਕਿ ਬਾਈਨਰੀ ਐਕਸਟੈਂਸ਼ਨ ਮੋਡੀਊਲ ਕਿਵੇਂ ਵੰਡੇ ਜਾਣਗੇ।

iOS App Store ਦੀ ਲੋੜ ਹੈ ਕਿ iOS ਐਪ ਵਿੱਚ ਮੌਜੂਦ ਸਾਰੇ ਬਾਈਨਰੀ ਮੋਡੀਊਲ dynamic libraries ਹੋਣ, ਉਚਿਤ metadata ਵਾਲੇ framework ਵਿੱਚ ਸ਼ਾਮਲ ਹੋਣ ਅਤੇ ਪੈਕੇਜ ਕੀਤੀ ਐਪ ਦੇ Frameworks ਫੋਲਡਰ ਵਿੱਚ ਸਟੋਰ ਕੀਤੇ ਜਾਣ। ਹਰ framework ਵਿੱਚ ਕੇਵਲ ਇੱਕ ਬਾਈਨਰੀ ਹੋ ਸਕਦੀ ਹੈ ਅਤੇ Frameworks ਫੋਲਡਰ ਤੋਂ ਬਾਹਰ ਕੋਈ executable ਬਾਈਨਰੀ ਸਮੱਗਰੀ ਨਹੀਂ ਹੋ ਸਕਦੀ।

ਇਹ ਬਾਈਨਰੀਆਂ ਨੂੰ ਵੰਡਣ ਦੇ ਆਮ ਪਾਇਥਨ ਤਰੀਕੇ ਨਾਲ ਟਕਰਾਉਂਦਾ ਹੈ, ਜਿਸ ਵਿੱਚ ਬਾਈਨਰੀ ਐਕਸਟੈਂਸ਼ਨ ਮੋਡੀਊਲ ਨੂੰ sys.path ਉੱਤੇ ਕਿਸੇ ਵੀ ਸਥਾਨ ਤੋਂ ਲੋਡ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। App Store ਨੀਤੀਆਂ ਦੀ ਪਾਲਣਾ ਯਕੀਨੀ ਬਣਾਉਣ ਲਈ iOS ਪ੍ਰੋਜੈਕਟ ਨੂੰ Python ਪੈਕੇਜਾਂ ਦੀ post-processing ਕਰਨੀ ਪੈਂਦੀ ਹੈ, ਜਿਸ ਵਿੱਚ .so ਬਾਈਨਰੀ ਮੋਡੀਊਲਾਂ ਨੂੰ ਉਚਿਤ metadata ਅਤੇ signing ਵਾਲੇ ਵੱਖਰੇ frameworks ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਜਾਂਦਾ ਹੈ। ਇਸ post-processing ਨੂੰ ਕਿਵੇਂ ਕਰਨਾ ਹੈ, ਇਸ ਬਾਰੇ ਵੇਰਵਿਆਂ ਲਈ adding Python to your project ਮਾਰਗਦਰਸ਼ਿਕਾ ਵੇਖੋ।

ਪਾਇਥਨ ਨੂੰ ਨਵੇਂ ਸਥਾਨ ਉੱਤੇ ਬਾਈਨਰੀਆਂ ਖੋਜਣ ਵਿੱਚ ਮਦਦ ਕਰਨ ਲਈ, sys.path ਉੱਤੇ ਮੌਜੂਦ ਅਸਲ .so ਫਾਈਲ ਨੂੰ .fwork ਫਾਈਲ ਨਾਲ ਬਦਲਿਆ ਜਾਂਦਾ ਹੈ। ਇਹ ਇੱਕ ਟੈਕਸਟ ਫਾਈਲ ਹੁੰਦੀ ਹੈ ਜਿਸ ਵਿੱਚ framework ਬਾਈਨਰੀ ਦਾ ਸਥਾਨ, ਐਪ bundle ਦੇ ਅਨੁਸਾਰ, ਦਰਜ ਹੁੰਦਾ ਹੈ। Framework ਨੂੰ ਮੁੜ ਅਸਲ ਸਥਾਨ ਤੱਕ ਪਹੁੰਚਣ ਦੇ ਯੋਗ ਬਣਾਉਣ ਲਈ framework ਵਿੱਚ ਇੱਕ .origin ਫਾਈਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜਿਸ ਵਿੱਚ .fwork ਫਾਈਲ ਦਾ ਸਥਾਨ, ਐਪ bundle ਦੇ ਅਨੁਸਾਰ, ਦਰਜ ਹੋਵੇ।

ਉਦਾਹਰਨ ਲਈ, from foo.bar import _whiz ਇੰਪੋਰਟ ਦੇ ਮਾਮਲੇ ਨੂੰ ਵੇਖੋ, ਜਿੱਥੇ _whiz ਨੂੰ sources/foo/bar/_whiz.abi3.so ਬਾਈਨਰੀ ਮੋਡੀਊਲ ਨਾਲ ਲਾਗੂ ਕੀਤਾ ਗਿਆ ਹੈ ਅਤੇ sources ਐਪ bundle ਦੇ ਅਨੁਸਾਰ sys.path ਉੱਤੇ ਦਰਜ ਸਥਾਨ ਹੈ। ਇਹ ਮੋਡੀਊਲ ਲਾਜ਼ਮੀ ਤੌਰ ਉੱਤੇ Frameworks/foo.bar._whiz.framework/foo.bar._whiz ਵਜੋਂ ਵੰਡਿਆ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ (framework ਦਾ ਨਾਮ ਮੋਡੀਊਲ ਦੇ ਪੂਰੇ import path ਤੋਂ ਬਣਾਇਆ ਜਾਂਦਾ ਹੈ), ਅਤੇ .framework ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਇੱਕ Info.plist ਫਾਈਲ ਹੋਣੀ ਚਾਹੀਦੀ ਹੈ ਜੋ ਬਾਈਨਰੀ ਨੂੰ framework ਵਜੋਂ ਪਛਾਣਦੀ ਹੋਵੇ। ਅਸਲ ਸਥਾਨ ਉੱਤੇ foo.bar._whiz ਮੋਡੀਊਲ ਨੂੰ sources/foo/bar/_whiz.abi3.fwork marker ਫਾਈਲ ਦੁਆਰਾ ਦਰਸਾਇਆ ਜਾਵੇਗਾ, ਜਿਸ ਵਿੱਚ Frameworks/foo.bar._whiz/foo.bar._whiz ਮਾਰਗ ਹੋਵੇਗਾ। Framework ਵਿੱਚ Frameworks/foo.bar._whiz.framework/foo.bar._whiz.origin ਵੀ ਹੋਵੇਗੀ, ਜਿਸ ਵਿੱਚ .fwork ਫਾਈਲ ਦਾ ਮਾਰਗ ਦਰਜ ਹੋਵੇਗਾ।

ਜਦੋਂ iOS ਉੱਤੇ ਚਲਾਇਆ ਜਾਂਦਾ ਹੈ, ਪਾਇਥਨ ਇੰਟਰਪ੍ਰੀਟਰ AppleFrameworkLoader ਇੰਸਟਾਲ ਕਰੇਗਾ ਜੋ .fwork ਫਾਈਲਾਂ ਨੂੰ ਪੜ੍ਹ ਅਤੇ ਇੰਪੋਰਟ ਕਰ ਸਕਦਾ ਹੈ। ਇੰਪੋਰਟ ਹੋਣ ਤੋਂ ਬਾਅਦ ਬਾਈਨਰੀ ਮੋਡੀਊਲ ਦਾ __file__ ਗੁਣ .fwork ਫਾਈਲ ਦਾ ਸਥਾਨ ਦਰਸਾਏਗਾ। ਹਾਲਾਂਕਿ ਲੋਡ ਕੀਤੇ ਮੋਡੀਊਲ ਦਾ ModuleSpec ਆਪਣਾ origin framework ਫੋਲਡਰ ਵਿੱਚ ਮੌਜੂਦ ਬਾਈਨਰੀ ਦੇ ਸਥਾਨ ਵਜੋਂ ਦਰਸਾਏਗਾ।

7.1.5. ਕੰਪਾਈਲਰ ਸਟਬ ਬਾਈਨਰੀਆਂ¶

Xcode iOS ਲਈ ਸਿੱਧੇ ਕੰਪਾਈਲਰ ਪ੍ਰਦਾਨ ਨਹੀਂ ਕਰਦਾ; ਇਸ ਦੀ ਬਜਾਏ ਇਹ xcrun ਸਕ੍ਰਿਪਟ ਵਰਤਦਾ ਹੈ ਜੋ ਪੂਰੇ ਕੰਪਾਈਲਰ ਮਾਰਗ ਦਾ ਨਿਰਧਾਰਣ ਕਰਦੀ ਹੈ (ਉਦਾਹਰਨ ਵਜੋਂ, iPhone ਡਿਵਾਈਸ ਲਈ clang ਪ੍ਰਾਪਤ ਕਰਨ ਲਈ xcrun --sdk iphoneos clang)। ਹਾਲਾਂਕਿ ਇਸ ਸਕ੍ਰਿਪਟ ਦੀ ਵਰਤੋਂ ਨਾਲ ਦੋ ਸਮੱਸਿਆਵਾਂ ਪੈਦਾ ਹੁੰਦੀਆਂ ਹਨ:

xcrun ਦਾ ਆਉਟਪੁੱਟ ਮਸ਼ੀਨ-ਵਿਸ਼ੇਸ਼ ਮਾਰਗਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਦਾ ਹੈ, ਜਿਸ ਕਾਰਨ ਬਣਿਆ sysconfig ਮੋਡੀਊਲ ਵੱਖ-ਵੱਖ ਉਪਭੋਗਤਾਵਾਂ ਵਿਚਕਾਰ ਸਾਂਝਾ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ; ਅਤੇ
ਇਸ ਨਾਲ CC/CPP/LD/AR ਪਰਿਭਾਸ਼ਾਵਾਂ ਵਿੱਚ ਖਾਲੀ ਥਾਵਾਂ (spaces) ਸ਼ਾਮਲ ਹੋ ਜਾਂਦੀਆਂ ਹਨ। C ecosystem ਦੇ ਬਹੁਤ ਸਾਰੇ ਸੰਦ ਇਹ ਮੰਨਦੇ ਹਨ ਕਿ ਪਹਿਲੀ ਖਾਲੀ ਥਾਂ ਤੱਕ ਦੀ ਜਾਣਕਾਰੀ ਕੰਪਾਈਲਰ executable ਦਾ ਮਾਰਗ ਹੈ; xcrun ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਸਮੇਂ ਇਹ ਧਾਰਣਾ ਸਹੀ ਨਹੀਂ ਰਹਿੰਦੀ।

ਇਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਤੋਂ ਬਚਣ ਲਈ ਪਾਇਥਨ ਇਨ੍ਹਾਂ ਸੰਦਾਂ ਲਈ stubs ਪ੍ਰਦਾਨ ਕਰਦਾ ਹੈ। ਇਹ stubs ਅਸਲ xcrun ਸੰਦਾਂ ਦੇ shell script wrappers ਹੁੰਦੇ ਹਨ ਅਤੇ ਕੰਪਾਈਲ ਕੀਤੇ iOS framework ਦੇ ਨਾਲ ਵੰਡੇ ਜਾਣ ਵਾਲੇ bin ਫੋਲਡਰ ਵਿੱਚ ਸ਼ਾਮਲ ਹੁੰਦੇ ਹਨ। ਇਹ ਸਕ੍ਰਿਪਟਾਂ relocatable ਹੁੰਦੀਆਂ ਹਨ ਅਤੇ ਹਮੇਸ਼ਾਂ ਉਚਿਤ ਸਥਾਨਕ ਸਿਸਟਮ ਮਾਰਗਾਂ ਨੂੰ ਲੱਭ ਲੈਂਦੀਆਂ ਹਨ। Framework ਦੇ ਨਾਲ ਦਿੱਤੇ bin ਫੋਲਡਰ ਵਿੱਚ ਇਨ੍ਹਾਂ ਸਕ੍ਰਿਪਟਾਂ ਨੂੰ ਸ਼ਾਮਲ ਕਰਨ ਨਾਲ sysconfig ਮੋਡੀਊਲ ਦੀ ਸਮੱਗਰੀ ਉਪਭੋਗਤਾਵਾਂ ਲਈ ਆਪਣੇ ਮੋਡੀਊਲ ਕੰਪਾਈਲ ਕਰਨ ਵਿੱਚ ਲਾਭਕਾਰੀ ਬਣ ਜਾਂਦੀ ਹੈ। iOS ਲਈ ਤੀਜੇ-ਪੱਖ ਦੇ ਪਾਇਥਨ ਮੋਡੀਊਲ ਕੰਪਾਈਲ ਕਰਦੇ ਸਮੇਂ ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ stub binaries ਤੁਹਾਡੇ path ਉੱਤੇ ਮੌਜੂਦ ਹਨ।

7.2. iOS ਉੱਤੇ ਪਾਇਥਨ ਇੰਸਟਾਲ ਕਰਨਾ¶

7.2.1. iOS ਐਪਾਂ ਬਣਾਉਣ ਲਈ ਸੰਦ¶

iOS ਲਈ ਬਿਲਡ ਕਰਨ ਵਾਸਤੇ Apple ਦੇ Xcode ਸੰਦਾਂ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। ਇਹ ਬਹੁਤ ਜ਼ੋਰ ਨਾਲ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ ਕਿ ਤੁਸੀਂ Xcode ਦਾ ਸਭ ਤੋਂ ਨਵਾਂ ਸਥਿਰ ਸੰਸਕਰਣ ਵਰਤੋ। ਇਸ ਲਈ ਆਮ ਤੌਰ ਉੱਤੇ macOS ਦੇ ਸਭ ਤੋਂ ਨਵੇਂ ਜਾਂ ਦੂਜੇ ਸਭ ਤੋਂ ਨਵੇਂ ਸੰਸਕਰਣ ਦੀ ਲੋੜ ਪਵੇਗੀ, ਕਿਉਂਕਿ Apple ਪੁਰਾਣੇ macOS ਸੰਸਕਰਣਾਂ ਲਈ Xcode ਦੀ ਸੰਭਾਲ ਨਹੀਂ ਕਰਦਾ। iOS ਵਿਕਾਸ ਲਈ Xcode Command Line Tools ਕਾਫ਼ੀ ਨਹੀਂ ਹਨ; ਤੁਹਾਨੂੰ ਪੂਰੀ Xcode ਇੰਸਟਾਲੇਸ਼ਨ ਦੀ ਲੋੜ ਹੈ।

ਜੇ ਤੁਸੀਂ ਆਪਣਾ ਕੋਡ iOS simulator ਉੱਤੇ ਚਲਾਉਣਾ ਚਾਹੁੰਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ ਇੱਕ iOS Simulator Platform ਵੀ ਇੰਸਟਾਲ ਕਰਨਾ ਪਵੇਗਾ। ਜਦੋਂ ਤੁਸੀਂ ਪਹਿਲੀ ਵਾਰ Xcode ਚਲਾਉਂਦੇ ਹੋ, ਤਾਂ ਤੁਹਾਨੂੰ iOS Simulator Platform ਚੁਣਨ ਲਈ ਕਿਹਾ ਜਾਣਾ ਚਾਹੀਦਾ ਹੈ। ਵਿਕਲਪਕ ਤੌਰ ਉੱਤੇ, ਤੁਸੀਂ Xcode Settings ਪੈਨਲ ਦੇ Platforms ਟੈਬ ਤੋਂ iOS Simulator Platform ਸ਼ਾਮਲ ਕਰ ਸਕਦੇ ਹੋ।

7.2.2. ਇੱਕ iOS ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਪਾਇਥਨ ਸ਼ਾਮਲ ਕਰਨਾ¶

ਪਾਇਥਨ ਨੂੰ Swift ਜਾਂ Objective C ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋਏ ਕਿਸੇ ਵੀ iOS ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਸ਼ਾਮਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਹੇਠਾਂ ਦਿੱਤੇ ਉਦਾਹਰਨ Objective C ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹਨ; ਜੇ ਤੁਸੀਂ Swift ਵਰਤ ਰਹੇ ਹੋ ਤਾਂ PythonKit ਵਰਗੀ ਲਾਇਬ੍ਰੇਰੀ ਤੁਹਾਡੇ ਲਈ ਲਾਭਕਾਰੀ ਹੋ ਸਕਦੀ ਹੈ।

iOS Xcode ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਪਾਇਥਨ ਸ਼ਾਮਲ ਕਰਨ ਲਈ:

Build or obtain a Python XCFramework. See the instructions in Platforms/Apple/iOS/README.md (in the CPython source distribution) for details on how to build a Python XCFramework. At a minimum, you will need a build that supports arm64-apple-ios, plus one of either arm64-apple-ios-simulator or x86_64-apple-ios-simulator.
XCframework ਨੂੰ ਆਪਣੇ iOS ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਖਿੱਚ ਕੇ ਸ਼ਾਮਲ ਕਰੋ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਹਦਾਇਤਾਂ ਵਿੱਚ ਅਸੀਂ ਮੰਨਦੇ ਹਾਂ ਕਿ ਤੁਸੀਂ XCframework ਨੂੰ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਦੀ ਰੂਟ ਡਾਇਰੈਕਟਰੀ ਵਿੱਚ ਰੱਖਿਆ ਹੈ; ਹਾਲਾਂਕਿ ਤੁਸੀਂ ਮਾਰਗਾਂ ਨੂੰ ਲੋੜ ਅਨੁਸਾਰ ਬਦਲ ਕੇ ਕੋਈ ਹੋਰ ਸਥਾਨ ਵੀ ਵਰਤ ਸਕਦੇ ਹੋ।
ਆਪਣੇ Xcode ਪ੍ਰੋਜੈਕਟ ਵਿੱਚ ਆਪਣਾ ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਇੱਕ ਫੋਲਡਰ ਵਜੋਂ ਸ਼ਾਮਲ ਕਰੋ। ਹੇਠਾਂ ਦਿੱਤੀਆਂ ਹਦਾਇਤਾਂ ਵਿੱਚ ਅਸੀਂ ਮੰਨਦੇ ਹਾਂ ਕਿ ਤੁਹਾਡਾ ਕੋਡ ਪ੍ਰੋਜੈਕਟ ਦੀ ਰੂਟ ਵਿੱਚ app ਨਾਮਕ ਫੋਲਡਰ ਵਿੱਚ ਹੈ; ਤੁਸੀਂ ਮਾਰਗਾਂ ਨੂੰ ਲੋੜ ਅਨੁਸਾਰ ਬਦਲ ਕੇ ਕੋਈ ਹੋਰ ਸਥਾਨ ਵੀ ਵਰਤ ਸਕਦੇ ਹੋ। ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਇਹ ਫੋਲਡਰ ਤੁਹਾਡੇ ਐਪ target ਨਾਲ ਸੰਬੰਧਿਤ ਹੈ।
ਆਪਣੇ Xcode ਪ੍ਰੋਜੈਕਟ ਦੇ root node ਨੂੰ ਚੁਣ ਕੇ ਅਤੇ ਫਿਰ sidebar ਵਿੱਚ ਦਿਖਾਈ ਦੇਣ ਵਾਲੇ target ਨਾਮ ਨੂੰ ਚੁਣ ਕੇ ਐਪ target ਦੀ ਚੋਣ ਕਰੋ।
"General" ਸੈਟਿੰਗਾਂ ਵਿੱਚ, "Frameworks, Libraries and Embedded Content" ਦੇ ਅਧੀਨ Python.xcframework ਸ਼ਾਮਲ ਕਰੋ ਅਤੇ "Embed & Sign" ਚੁਣੋ।
"Build Settings" ਟੈਬ ਵਿੱਚ ਹੇਠ ਲਿਖੀਆਂ ਸੈਟਿੰਗਾਂ ਸੋਧੋ:
- ਬਿਲਡ ਵਿਕਲਪ
  - User Script Sandboxing: ਨਹੀਂ
  - Enable Testability: ਹਾਂ
- ਖੋਜ ਮਾਰਗ
  - Framework Search Paths: $(PROJECT_DIR)
  - Header Search Paths: "$(BUILT_PRODUCTS_DIR)/Python.framework/Headers"
- Apple Clang - ਚੇਤਾਵਨੀਆਂ - ਸਾਰੀਆਂ ਭਾਸ਼ਾਵਾਂ
  - Quoted Include In Framework Header: ਨਹੀਂ
ਇੱਕ ਬਿਲਡ ਕਦਮ ਸ਼ਾਮਲ ਕਰੋ ਜੋ ਪਾਇਥਨ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਅਤੇ ਤੁਹਾਡੀਆਂ ਆਪਣੀਆਂ ਪਾਇਥਨ ਬਾਈਨਰੀ ਨਿਰਭਰਤਾਵਾਂ ਨੂੰ ਪ੍ਰਕਿਰਿਆ ਕਰੇ। "Build Phases" ਟੈਬ ਵਿੱਚ "Embed Frameworks" ਕਦਮ ਤੋਂ ਪਹਿਲਾਂ ਪਰ "Copy Bundle Resources" ਕਦਮ ਤੋਂ ਬਾਅਦ ਇੱਕ ਨਵਾਂ "Run Script" ਬਿਲਡ ਕਦਮ ਸ਼ਾਮਲ ਕਰੋ। ਇਸ ਕਦਮ ਦਾ ਨਾਮ "Process Python libraries" ਰੱਖੋ, "Based on dependency analysis" ਚੈਕਬਾਕਸ ਨੂੰ ਅਯੋਗ ਕਰੋ ਅਤੇ ਸਕ੍ਰਿਪਟ ਦੀ ਸਮੱਗਰੀ ਨੂੰ ਹੇਠ ਲਿਖੇ ਤਰੀਕੇ ਨਾਲ ਸੈੱਟ ਕਰੋ:
```
set -e
source $PROJECT_DIR/Python.xcframework/build/build_utils.sh
install_python Python.xcframework app
```
ਜੇ ਤੁਸੀਂ ਆਪਣੇ XCframework ਨੂੰ ਪ੍ਰੋਜੈਕਟ ਦੀ ਰੂਟ ਡਾਇਰੈਕਟਰੀ ਤੋਂ ਇਲਾਵਾ ਕਿਸੇ ਹੋਰ ਸਥਾਨ ਉੱਤੇ ਰੱਖਿਆ ਹੈ, ਤਾਂ ਪਹਿਲੇ ਆਰਗਿਊਮੈਂਟ ਦਾ ਮਾਰਗ ਉਸ ਅਨੁਸਾਰ ਸੋਧੋ।
Embedded ਮੋਡ ਵਿੱਚ ਪਾਇਥਨ ਇੰਟਰਪ੍ਰੀਟਰ ਨੂੰ ਸ਼ੁਰੂ ਕਰਨ ਅਤੇ ਵਰਤਣ ਲਈ Objective C ਕੋਡ ਸ਼ਾਮਲ ਕਰੋ। ਇਹ ਯਕੀਨੀ ਬਣਾਓ ਕਿ:
- UTF-8 ਮੋਡ (PyPreConfig.utf8_mode) ਸਮਰਥਿਤ ਹੋਵੇ;
- Buffered stdio (PyConfig.buffered_stdio) ਅਸਮਰਥਿਤ ਹੋਵੇ;
- Bytecode ਲਿਖਣਾ (PyConfig.write_bytecode) ਅਸਮਰਥਿਤ ਹੋਵੇ;
- Signal handlers (PyConfig.install_signal_handlers) ਸਮਰਥਿਤ ਹੋਣ;
- System logging (PyConfig.use_system_logger) ਸਮਰਥਿਤ ਹੋਵੇ (ਵਿਕਲਪਿਕ ਹੈ, ਪਰ ਮਜ਼ਬੂਤੀ ਨਾਲ ਸਿਫਾਰਸ਼ ਕੀਤੀ ਜਾਂਦੀ ਹੈ; ਇਹ ਮੂਲ ਰੂਪ ਵਿੱਚ ਸਮਰਥਿਤ ਹੁੰਦੀ ਹੈ);
- ਇੰਟਰਪ੍ਰੀਟਰ ਲਈ PYTHONHOME ਤੁਹਾਡੇ ਐਪ bundle ਦੇ python ਉਪ-ਫੋਲਡਰ ਵੱਲ ਸੰਰਚਿਤ ਹੋਵੇ; ਅਤੇ
- ਇੰਟਰਪ੍ਰੀਟਰ ਲਈ PYTHONPATH ਵਿੱਚ ਹੇਠ ਲਿਖੇ ਸ਼ਾਮਲ ਹੋਣ:
  - ਤੁਹਾਡੇ ਐਪ bundle ਦਾ python/lib/python3.X ਉਪ-ਫੋਲਡਰ,
  - ਤੁਹਾਡੇ ਐਪ bundle ਦਾ python/lib/python3.X/lib-dynload ਉਪ-ਫੋਲਡਰ, ਅਤੇ
  - ਤੁਹਾਡੇ ਐਪ bundle ਦਾ app ਉਪ-ਫੋਲਡਰ
ਤੁਹਾਡੇ ਐਪ bundle ਦਾ ਸਥਾਨ [[NSBundle mainBundle] resourcePath] ਦੀ ਵਰਤੋਂ ਕਰਕੇ ਪਤਾ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ।

ਇਨ੍ਹਾਂ ਹਦਾਇਤਾਂ ਦੇ ਕਦਮ 7 ਅਤੇ 8 ਇਹ ਮੰਨਦੇ ਹਨ ਕਿ ਤੁਹਾਡੇ ਕੋਲ app ਨਾਮ ਦਾ ਇੱਕ ਇਕੱਲਾ ਫੋਲਡਰ ਹੈ ਜਿਸ ਵਿੱਚ ਸਿਰਫ਼ Python ਐਪਲੀਕੇਸ਼ਨ ਕੋਡ ਹੈ। ਜੇ ਤੁਹਾਡੇ ਐਪ ਵਿੱਚ ਤੀਜੇ-ਪੱਖ ਦੇ ਬਾਈਨਰੀ ਮੋਡੀਊਲ ਹਨ, ਤਾਂ ਕੁਝ ਵਾਧੂ ਕਦਮ ਲੋੜੀਂਦੇ ਹੋਣਗੇ:

ਤੁਹਾਨੂੰ ਇਹ ਯਕੀਨੀ ਬਣਾਉਣਾ ਹੋਵੇਗਾ ਕਿ ਤੀਜੇ-ਪੱਖ ਦੀਆਂ ਬਾਈਨਰੀਆਂ ਵਾਲੇ ਸਾਰੇ ਫੋਲਡਰ ਜਾਂ ਤਾਂ ਐਪ target ਨਾਲ ਸੰਬੰਧਿਤ ਹੋਣ ਜਾਂ ਕਦਮ 7 ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸਪਸ਼ਟ ਤੌਰ ਉੱਤੇ ਕਾਪੀ ਕੀਤੇ ਜਾਣ। ਕਦਮ 7 ਨੂੰ ਉਹ ਬਾਈਨਰੀਆਂ ਵੀ ਹਟਾਉਣੀਆਂ ਚਾਹੀਦੀਆਂ ਹਨ ਜੋ ਕਿਸੇ ਖਾਸ build ਦੇ ਟਾਰਗੇਟ ਪਲੇਟਫਾਰਮ ਲਈ ਉਚਿਤ ਨਹੀਂ ਹਨ (ਉਦਾਹਰਨ ਲਈ, ਜੇ ਤੁਸੀਂ simulator ਲਈ ਐਪ ਬਣਾ ਰਹੇ ਹੋ ਤਾਂ device binaries ਹਟਾਓ)।
ਜੇ ਤੁਸੀਂ ਤੀਜੇ-ਪੱਖ ਦੇ ਪੈਕੇਜਾਂ ਲਈ ਵੱਖਰਾ ਫੋਲਡਰ ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ ਯਕੀਨੀ ਬਣਾਓ ਕਿ ਉਹ ਫੋਲਡਰ ਕਦਮ 7 ਵਿੱਚ install_python ਕਾਲ ਦੇ ਅੰਤ ਵਿੱਚ ਅਤੇ ਕਦਮ 8 ਵਿੱਚ PYTHONPATH ਸੰਰਚਨਾ ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਸ਼ਾਮਲ ਕੀਤਾ ਗਿਆ ਹੋਵੇ।
ਜੇ ਤੀਜੇ-ਪੱਖ ਦੇ ਪੈਕੇਜਾਂ ਵਾਲੇ ਕਿਸੇ ਵੀ ਫੋਲਡਰ ਵਿੱਚ .pth ਫਾਈਲਾਂ ਹੋਣਗੀਆਂ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਸ ਫੋਲਡਰ ਨੂੰ ਸਿੱਧੇ PYTHONPATH ਜਾਂ sys.path ਵਿੱਚ ਜੋੜਨ ਦੀ ਬਜਾਏ ਇੱਕ site directory ਵਜੋਂ ( site.addsitedir() ਦੀ ਵਰਤੋਂ ਕਰਕੇ ) ਸ਼ਾਮਲ ਕਰਨਾ ਚਾਹੀਦਾ ਹੈ।

7.2.3. ਪਾਇਥਨ ਪੈਕੇਜ ਦੀ ਜਾਂਚ¶

The CPython source tree contains a testbed project that is used to run the CPython test suite on the iOS simulator. This testbed can also be used as a testbed project for running your Python library's test suite on iOS.

After building or obtaining an iOS XCFramework (see Platforms/Apple/iOS/README.md for details), create a clone of the Python iOS testbed project. If you used the Platforms/Apple build script to build the XCframework, you can run:

$ python cross-build/iOS/testbed clone --app <path/to/module1> --app <path/to/module2> app-testbed

ਜਾਂ, ਜੇ ਤੁਸੀਂ ਆਪਣਾ ਖੁਦ ਦਾ XCframework ਵਰਤ ਰਹੇ ਹੋ, ਤਾਂ:

$ python Platforms/Apple/testbed clone --platform iOS --framework <path/to/Python.xcframework> --app <path/to/module1> --app <path/to/module2> app-testbed

--app ਫਲੈਗ ਨਾਲ ਦਰਸਾਏ ਗਏ ਸਾਰੇ ਫੋਲਡਰ clone ਕੀਤੇ testbed project ਵਿੱਚ ਕਾਪੀ ਕੀਤੇ ਜਾਣਗੇ। ਨਤੀਜੇ ਵਜੋਂ testbed app-testbed ਫੋਲਡਰ ਵਿੱਚ ਬਣੇਗਾ। ਇਸ ਉਦਾਹਰਨ ਵਿੱਚ module1 ਅਤੇ module2 runtime ਦੌਰਾਨ import ਕੀਤੇ ਜਾ ਸਕਣ ਵਾਲੇ ਮੋਡੀਊਲ ਹੋਣਗੇ। ਜੇ ਤੁਹਾਡੇ project ਦੀਆਂ ਹੋਰ ਨਿਰਭਰਤਾਵਾਂ ਹਨ, ਤਾਂ ਉਹਨਾਂ ਨੂੰ app-testbed/Testbed/app_packages ਫੋਲਡਰ ਵਿੱਚ ਇੰਸਟਾਲ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ (ਉਦਾਹਰਨ ਲਈ pip install --target app-testbed/Testbed/app_packages ਦੀ ਵਰਤੋਂ ਕਰਕੇ)।

ਇਸ ਤੋਂ ਬਾਅਦ ਤੁਸੀਂ ਆਪਣੇ ਐਪ ਦੀ test suite ਚਲਾਉਣ ਲਈ app-testbed ਫੋਲਡਰ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। ਉਦਾਹਰਨ ਲਈ, ਜੇ module1.tests ਤੁਹਾਡੀ test suite ਦਾ entry point ਹੈ, ਤਾਂ ਤੁਸੀਂ ਹੇਠ ਲਿਖੀ ਕਮਾਂਡ ਚਲਾ ਸਕਦੇ ਹੋ:

$ python app-testbed run -- module1.tests

ਇਹ ਡੈਸਕਟਾਪ Python build ਉੱਤੇ python -m module1.tests ਚਲਾਉਣ ਦੇ ਬਰਾਬਰ ਹੈ। -- ਤੋਂ ਬਾਅਦ ਦਿੱਤੇ ਸਾਰੇ ਆਰਗਿਊਮੈਂਟ testbed ਨੂੰ ਉਸੇ ਤਰ੍ਹਾਂ ਭੇਜੇ ਜਾਣਗੇ ਜਿਵੇਂ ਉਹ ਡੈਸਕਟਾਪ ਮਸ਼ੀਨ ਉੱਤੇ python -m ਨੂੰ ਦਿੱਤੇ ਗਏ ਹੋਣ।

ਤੁਸੀਂ ਹੇਠ ਲਿਖੀ ਕਮਾਂਡ ਚਲਾ ਕੇ testbed project ਨੂੰ Xcode ਵਿੱਚ ਵੀ ਖੋਲ੍ਹ ਸਕਦੇ ਹੋ:

$ open app-testbed/iOSTestbed.xcodeproj

ਇਸ ਨਾਲ ਤੁਸੀਂ debugging ਲਈ Xcode ਦੇ ਪੂਰੇ ਸੰਦ-ਸਮੂਹ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕੋਗੇ।

Test suite ਚਲਾਉਣ ਲਈ ਵਰਤੇ ਜਾਣ ਵਾਲੇ ਆਰਗਿਊਮੈਂਟ test plan ਦੇ ਹਿੱਸੇ ਵਜੋਂ ਪਰਿਭਾਸ਼ਿਤ ਹੁੰਦੇ ਹਨ। Test plan ਨੂੰ ਸੋਧਣ ਲਈ project tree ਵਿੱਚ test plan node ਚੁਣੋ (ਇਹ root node ਦਾ ਪਹਿਲਾ child ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ) ਅਤੇ "Configurations" ਟੈਬ ਚੁਣੋ। ਟੈਸਟਿੰਗ ਆਰਗਿਊਮੈਂਟ ਬਦਲਣ ਲਈ "Arguments Passed On Launch" ਮੁੱਲ ਸੋਧੋ।

Test plan parallel testing ਨੂੰ ਅਯੋਗ ਕਰਦਾ ਹੈ ਅਤੇ debugger ਸੰਰਚਨਾ ਪ੍ਰਦਾਨ ਕਰਨ ਲਈ Testbed.lldbinit ਫਾਈਲ ਦੀ ਵਰਤੋਂ ਨਿਰਧਾਰਤ ਕਰਦਾ ਹੈ। ਮੂਲ debugger ਸੰਰਚਨਾ SIGINT, SIGUSR1, SIGUSR2 ਅਤੇ SIGXFSZ signals ਉੱਤੇ ਆਟੋਮੈਟਿਕ breakpoints ਨੂੰ ਅਯੋਗ ਕਰਦੀ ਹੈ।

7.3. App Store ਅਨੁਕੂਲਤਾ¶

ਤੀਜੇ-ਪੱਖ ਦੇ iOS ਡਿਵਾਈਸਾਂ ਉੱਤੇ ਐਪਾਂ ਵੰਡਣ ਦਾ ਇਕੋ ਤਰੀਕਾ iOS App Store ਵਿੱਚ ਐਪ ਜਮ੍ਹਾਂ ਕਰਵਾਉਣਾ ਹੈ; ਵੰਡ ਲਈ ਜਮ੍ਹਾਂ ਕੀਤੀਆਂ ਐਪਾਂ ਨੂੰ Apple ਦੀ app review ਪ੍ਰਕਿਰਿਆ ਪਾਸ ਕਰਨੀ ਪੈਂਦੀ ਹੈ। ਇਸ ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਆਟੋਮੈਟਿਕ ਜਾਂਚ ਨਿਯਮਾਂ ਦਾ ਇੱਕ ਸਮੂਹ ਸ਼ਾਮਲ ਹੁੰਦਾ ਹੈ ਜੋ ਜਮ੍ਹਾਂ ਕੀਤੇ application bundle ਵਿੱਚ ਸਮੱਸਿਆਜਨਕ ਕੋਡ ਦੀ ਜਾਂਚ ਕਰਦਾ ਹੈ। ਕੁਝ ਕਦਮ ਲਾਜ਼ਮੀ ਹਨ ਤਾਂ ਜੋ ਤੁਹਾਡੀ ਐਪ ਇਹ ਜਾਂਚਾਂ ਪਾਸ ਕਰ ਸਕੇ।

7.3.1. ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਅਣਅਨੁਕੂਲ ਕੋਡ¶

ਪਾਇਥਨ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਕੁਝ ਐਸਾ ਕੋਡ ਸ਼ਾਮਲ ਹੈ ਜੋ ਇਨ੍ਹਾਂ ਆਟੋਮੈਟਿਕ ਨਿਯਮਾਂ ਦੀ ਉਲੰਘਣਾ ਕਰਦਾ ਹੈ। ਹਾਲਾਂਕਿ ਇਹ ਉਲੰਘਣਾਵਾਂ ਅਕਸਰ false positives ਲੱਗਦੀਆਂ ਹਨ, ਪਰ Apple ਦੇ review ਨਿਯਮਾਂ ਨੂੰ ਚੁਣੌਤੀ ਨਹੀਂ ਦਿੱਤੀ ਜਾ ਸਕਦੀ; ਇਸ ਲਈ App Store review ਪਾਸ ਕਰਨ ਲਈ ਪਾਇਥਨ ਮਿਆਰੀ ਲਾਇਬ੍ਰੇਰੀ ਵਿੱਚ ਸੋਧ ਕਰਨੀ ਲਾਜ਼ਮੀ ਹੈ।

Python source tree ਵਿੱਚ a patch file ਸ਼ਾਮਲ ਹੈ ਜੋ App Store review ਪ੍ਰਕਿਰਿਆ ਵਿੱਚ ਸਮੱਸਿਆ ਪੈਦਾ ਕਰਨ ਵਾਲੇ ਜਾਣੇ-ਪਹਿਚਾਣੇ ਕੋਡ ਨੂੰ ਹਟਾ ਦਿੰਦੀ ਹੈ। iOS ਲਈ build ਕਰਦੇ ਸਮੇਂ ਇਹ patch ਆਪਣੇ ਆਪ ਲਾਗੂ ਕੀਤੀ ਜਾਂਦੀ ਹੈ।

7.3.2. ਗੋਪਨੀਯਤਾ ਘੋਸ਼ਣਾਵਾਂ (Privacy Manifests)¶

ਅਪ੍ਰੈਲ 2025 ਵਿੱਚ, Apple ਨੇ ਇਹ ਲੋੜ ਲਾਗੂ ਕੀਤੀ ਕਿ ਕੁਝ ਤੀਜੇ-ਪੱਖ ਦੀਆਂ ਲਾਇਬ੍ਰੇਰੀਆਂ ਨੂੰ Privacy Manifest ਪ੍ਰਦਾਨ ਕਰਨਾ ਲਾਜ਼ਮੀ ਹੈ। ਇਸ ਕਾਰਨ, ਜੇ ਤੁਹਾਡੇ ਕੋਲ ਕੋਈ ਐਸਾ ਬਾਈਨਰੀ ਮੋਡੀਊਲ ਹੈ ਜੋ ਪ੍ਰਭਾਵਿਤ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚੋਂ ਕਿਸੇ ਇੱਕ ਦੀ ਵਰਤੋਂ ਕਰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਉਸ ਲਾਇਬ੍ਰੇਰੀ ਲਈ ਇੱਕ .xcprivacy ਫਾਈਲ ਪ੍ਰਦਾਨ ਕਰਨੀ ਹੋਵੇਗੀ। OpenSSL ਇਸ ਲੋੜ ਨਾਲ ਪ੍ਰਭਾਵਿਤ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ, ਪਰ ਹੋਰ ਵੀ ਹਨ।

ਜੇ ਤੁਸੀਂ mymodule.so ਨਾਮ ਦਾ ਇੱਕ ਬਾਈਨਰੀ ਮੋਡੀਊਲ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ ਉੱਪਰ ਦਿੱਤੇ ਕਦਮ 7 ਵਿੱਚ ਵਰਣਿਤ Xcode build script ਦੀ ਵਰਤੋਂ ਕਰਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ mymodule.so ਦੇ ਨਾਲ ਇੱਕ mymodule.xcprivacy ਫਾਈਲ ਰੱਖ ਸਕਦੇ ਹੋ। ਜਦੋਂ ਬਾਈਨਰੀ ਮੋਡੀਊਲ ਨੂੰ framework ਵਿੱਚ ਤਬਦੀਲ ਕੀਤਾ ਜਾਵੇਗਾ, ਤਾਂ privacy manifest ਆਪਣੇ ਆਪ ਲੋੜੀਂਦੇ ਸਥਾਨ ਉੱਤੇ ਇੰਸਟਾਲ ਕਰ ਦਿੱਤਾ ਜਾਵੇਗਾ।