30 ਜੁਲਾ 2025·8 ਮਿੰਟ
ਸਵਿਫਟ ਕਿਉਂ ਮੌਜੂਦ ਹੈ: iOS ਵਿੱਚ ਇਹ Objective‑C ਦੀ ਥਾਂ ਕਿਵੇਂ ਲਿਆ
ਜਾਣੋ ਕਿ Apple ਨੇ Swift ਕਿਉਂ ਬਣਾਇਆ, ਇਹ Objective‑C ਨੂੰ iOS ਐਪਾਂ ਵਿੱਚ ਹੌਲੀ-ਹੌਲੀ ਕਿਵੇਂ ਬਦਲਿਆ, ਅਤੇ ਅਜੋਕੇ ਟੂਲਿੰਗ, hiring ਅਤੇ ਕੋਡਬੇਸਾਂ ਲਈ ਇਸ ਦਾ ਕੀ ਅਰਥ ਹੈ।
ਜਾਣੋ ਕਿ Apple ਨੇ Swift ਕਿਉਂ ਬਣਾਇਆ, ਇਹ Objective‑C ਨੂੰ iOS ਐਪਾਂ ਵਿੱਚ ਹੌਲੀ-ਹੌਲੀ ਕਿਵੇਂ ਬਦਲਿਆ, ਅਤੇ ਅਜੋਕੇ ਟੂਲਿੰਗ, hiring ਅਤੇ ਕੋਡਬੇਸਾਂ ਲਈ ਇਸ ਦਾ ਕੀ ਅਰਥ ਹੈ।
Swift ਸਿਰਫ਼ ਇਸ ਲਈ ਨਹੀਂ ਆਇਆ ਕਿ Apple ਨੂੰ ਕੋਈ ਨ੍ਯਾ ਭਾਸ਼ਾ ਚਾਹੀਦੀ ਸੀ। ਇਹ iOS ਵਿਕਾਸ ਵਿੱਚ ਅਸਲ ਸਮੱਸਿਆਵਾਂ ਦਾ ਜਵਾਬ ਸੀ: ਆਹਿਸਤਾ iteration, ਅਣਸੁਰੱਖਿਅਤ ਪੈਟਰਨ ਜੋ ਅਕਸਰ ਗਲਤੀ ਨਾਲ ਲਿਖੇ ਜਾ ਸਕਦੇ ਸਨ, ਅਤੇ ਆਧੁਨਿਕ ਐਪ ਦੀ ਜਟਿਲਤਾ ਨਾਲ Objective‑C ਦੇ ਹੋਏ ਅੰਤਰ।
ਇਸ ਪੋਸਟ ਦਾ ਪ੍ਰਸ਼ਨ ਦਾ ਅੰਸਰ ਹੈ: Swift ਕਿਉਂ ਮੌਜੂਦ ਹੈ, ਇਸ ਨੇ ਡਿਫਾਲਟ ਕਿਵੇਂ ਬਣਿਆ, ਅਤੇ ਉਹ ਇਤਿਹਾਸ ਅਜੇ ਵੀ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਅਤੇ ਟੀਮ ਫੈਸਲਿਆਂ 'ਤੇ ਕਿਵੇਂ ਪ੍ਰਭਾਵ ਰੱਖਦਾ ਹੈ।
ਤੁਸੀਂ ਇੱਕ ਸਪਸ਼ਟ, ਹਲਕੀ ਟਾਈਮਲਾਈਨ ਪਾਵੋਗੇ—ਸ਼ੁਰੂਆਤੀ Swift ਰਿਲੀਜ਼ ਤੋਂ ਲੈ ਕੇ ਇਕ ਸਥਿਰ, ਚੌੜੀ ਤੌਰ ਤੇ ਅਪਨਾਈ ਗਈ ਟੂਲਚੇਨ ਤੱਕ—ਬਿਨਾਂ ਫੁਟਕਲ ਵਿੱਚ ਘਿਰੇ। ਰਸਤੇ ਵਿੱਚ ਅਸੀਂ ਇਤਿਹਾਸ ਨੂੰ ਦੈਨੀਕ ਨਤੀਜਿਆਂ ਨਾਲ ਜੋੜਾਂਗੇ: ਡਿਵੈਲਪਰ ਕਿਵੇਂ ਜ਼ਿਆਦਾ ਸੁਰੱਖਿਅਤ ਕੋਡ ਲਿਖਦੇ ਹਨ, APIs ਕਿਵੇਂ ਬਦਲੇ, Xcode ਵਰਕਫਲੋਜ਼ ਵਿੱਚ ਕੀ ਬਦਲਿਆ, ਅਤੇ "ਆਧੁਨਿਕ Swift" ਦਾ ਕੀ ਅਰਥ ਹੈ—ਜਿਵੇਂ concurrency ਅਤੇ SwiftUI ਵਰਗੀਆਂ ਫੀਚਰਾਂ ਨਾਲ।
Objective‑C ਅਜੇ ਵੀ ਕਈ ਕਾਮਯਾਬ ਐਪਾਂ ਵਿੱਚ ਮੌਜੂਦ ਹੈ, ਖਾਸ ਕਰਕੇ ਪੁਰਾਣੇ ਕੋਡਬੇਸ ਅਤੇ ਕੁਝ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵਿੱਚ। ਮਕਸਦ ਡਰ ਜਾਂ ਤੁਰੰਤਤਾ ਨਹੀਂ—ਸਪਸ਼ਟਤਾ ਹੈ: Swift ਨੇ Objective‑C ਨੂੰ ਇਕਦਮ ਮਿਟਾ ਦਿੱਤਾ ਨਹੀਂ; ਇਸ ਨੇ ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਅਤੇ ਇਕੋਸਿਸਟਮ ਬਦਲਾਵਾਂ ਰਾਹੀਂ ਹੌਲੀ-ਹੌਲੀ ਥਾਂ ਬਣਾਈ।
Objective‑C ਦਹਾਕਿਆਂ ਤੱਕ Apple ਵਿਕਾਸ ਦੀ ਬੁਨਿਆਦ ਸੀ। 2008 ਵਿੱਚ ਪਹਿਲਾ iPhone SDK ਆਇਆ ਤੇ Objective‑C (ਨਾਲ Cocoa Touch ਫ੍ਰੇਮਵਰਕ) ਮੁੱਖ ਢੰਗ ਸੀ ਐਪ ਬਣਾਉਣ ਦਾ। ਜੇ ਤੁਸੀਂ ਸ਼ੁਰੂਆਤੀ ਸਾਲਾਂ ਵਿੱਚ iOS ਐਪ ਲਿਖਦੇ ਸੀ, ਤਾਂ ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ Objective‑C ਰਾਹੀਂ Apple ਦੇ ਪਲੇਟਫਾਰਮ ਰੀਤ-ਰਿਵਾਜ ਸਿੱਖ ਰਹੇ ਸੀ।
Objective‑C ਦੇ ਕੋਲ ਬਹੁਤ ਕੁਝ ਸੀ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ “Cocoa way” ਨੂੰ ਅਪਨਾਂਦੇ ਸੀ।
ਇਹ ਇੱਕ ਤਾਕਤਵਰ ਡਾਇਨੈਮਿਕ ਰਨਟਾਈਮ ਤੇ ਖੜਾ ਸੀ: messaging, introspection, categories, ਅਤੇ method swizzling ਨੇ ਲਚਕੀਲੇ ਪੈਟਰਨ ਮੁਹੱਈਆ ਕੀਤੇ। Cocoa ਦੀਆਂ ਰੀਤਾਂ ਜਿਵੇਂ delegation, target–action, notifications, ਅਤੇ KVC/KVO (key-value coding/observing) ਗਹਿਰਾਈ ਨਾਲ ਇਕੱਠੀਆਂ ਅਤੇ ਚੰਗੀ ਤਰ੍ਹਾਂ ਦਸਤਾਵੇਜ਼ ਕੀਤੀਆਂ ਹੋਈਆਂ ਸਨ।
ਇਸ ਤੋਂ ਇਲਾਵਾ, ਇਸ ਦਾ ਇਕ ਪਰਿਪੱਕ ecosystem ਸੀ। Apple ਦੇ ਫ੍ਰੇਮਵਰਕ, ਤੀਜੀ-पਾਰਟੀ ਲਾਇਬ੍ਰੇਰੀਆਂ, ਅਤੇ ਸਾਲਾਂ ਦੇ Stack Overflow ਜਵਾਬ Objective‑C ਨੂੰ ਮੰਨਦੇ ਸਨ। ਟੂਲਿੰਗ ਅਤੇ APIs ਇਸ ਦੇ ਆਲੇ ਦੁਆਲੇ ਬਣੇ ਸਨ, ਅਤੇ ਟੀਮਾਂ predictable ਹુਨਰ ਵਾਲੇ ਡਿਵੈਲਪਰ ਹਾਇਰ ਕਰ ਸਕਦੀਆਂ ਸਨ।
ਦਰਦ ਦੇ ਨੁਕਤੇ ਫਲਸਫ਼ੀਕ ਨਹੀਂ ਸਨ—ਇਹ ਦੈਨੀਕ ਘਰਾਗਾਰ ਤਕਲੀਫਾਂ ਸਨ।
Objective‑C verbose ਹੋ ਸਕਦਾ ਸੀ, ਖਾਸ ਕਰਕੇ ਸਧਾਰਨ ਕੰਮਾਂ ਲਈ। ਥੋੜੀ ਲੰਬੀਆਂ method signatures, ਬ੍ਰੈਕਟ ਅਤੇ boilerplate ਕੋਡ ਨੇ ਕੋਡ ਨੂੰ ਲੰਬਾ ਅਤੇ ਪੜ੍ਹਨ ਵਿੱਚ ਔਖਾ ਕੀਤਾ। ਕਈ APIs pointer-ਭਰੇ ਕਨਸੈਪਟ ਦਿਖਾਉਂਦੇ ਸਨ, ਜਿਸ ਨਾਲ ਗਲਤੀਆਂ ਦੀ ਸੰਭਾਵਨਾ ਵਧਦੀ ਸੀ, ਖ਼ਾਸ ਕਰਕੇ ARC ਤੋਂ ਪਹਿਲਾਂ।
ਮੇਮੋਰੀ ਅਤੇ ਸੁਰੱਖਿਆ ਸੰਬੰਧੀ ਮੁੱਦੇ ਚਲਦੇ ਹੀ ਰਹਿੰਦੇ ਸਨ। ARC ਹੋਣ ਦੇ ਬਾਵਜੂਦ, ਤੁਹਾਡੇ ਨੂੰ ownership, reference cycles ਅਤੇ nullability ਨੂੰ ਸਮਝਣ ਦੀ ਲੋੜ ਰਹਿੰਦੀ ਸੀ।
C APIs ਨਾਲ ਇੰਟਰਨਫੇਸ ਵੀ ਆਮ ਸੀ—ਅਤੇ ਹਮੇਸ਼ਾਂ ਆਸਾਨ ਨਹੀਂ। C ਟਾਈਪਾਂ ਨੂੰ ਬ੍ਰਿਜ ਕਰਨਾ, Core Foundation ਨਾਲ ਨਿੱਜੀ ਮੈਲ-ਜੋਲ, ਅਤੇ “toll-free bridging” ਇਹ ਮਨੋਵੈज्ञानिक ਓਵਰਹੈਡ ਵਧਾਉਂਦੇ ਸਨ ਜੋ ਆਧੁਨਿਕ ਐਪ ਕੋਡ ਲਿਖਣ ਵਰਗਾ ਨਹੀਂ ਲੱਗਦਾ।
ਲੈਗੇਸੀ iOS ਕੋਡਬੇਸ ਅਕਸਰ Objective‑C 'ਤੇ ਨਿਰਭਰ ਹੁੰਦੇ ਹਨ ਕਿਉਂਕਿ ਉਹ ਸਥਿਰ, ਬੈਟਲ‑ਟੈਸਟ ਕੀਤੇ ਹੋਏ ਅਤੇ ਰੀਰਾਈਟ ਕਰਕੇ ਮਹਿੰਗੇ ਪੈਂਦੇ ਹਨ। ਬਹੁਤ ਸਾਰੇ ਲੰਬੇ ਸਮੇਂ ਚੱਲਣ ਵਾਲੇ ਐਪਾਂ ਵਿੱਚ Objective‑C ਲੇਅਰ ਹਨ ਜੋ ਅਜੇ ਵੀ ਅਹੁਦੇ ਕੰਮ ਕਰ ਰਹੇ ਹਨ—ਅਤੇ ਭਰੋਸੇਯੋਗੀ ਤਰੀਕੇ ਨਾਲ।
Apple ਨੇ Swift ਇਸ ਲਈ ਨਹੀਂ ਬਣਾਇਆ ਕਿ Objective‑C “ਟੁੱਟ ਗਿਆ” ਸੀ। Objective‑C ਨੇ ਸਾਲਾਂ ਦੇ ਸਫਲ iPhone ਅਤੇ Mac ਐਪਾਂ ਨੂੰ ਚਲਾਇਆ। ਪਰ ਜਿਵੇਂ-ਜਿਵੇਂ ਐਪ ਵੱਡੇ ਹੋਏ, ਟੀਮਾਂ ਵੱਡੀਆਂ ਹੋਈਆਂ, ਅਤੇ APIs ਫੈਲੇ, Objective‑C ਦੇ ਕੁਝ ਡਿਫਾਲਟਸ ਦੀ ਲਾਗਤ ਜ਼ਿਆਦਾ ਨਜ਼ਰ ਆਉਣ ਲੱਗੀ—ਖ਼ਾਸ ਕਰਕੇ ਜਦੋਂ ਤੁਸੀਂ ਮਿਲੀਅਨਾਂ ਲਾਈਨਾਂ ਕੋਡ 'ਤੇ ਛੋਟੇ-ਛੋਟੇ ਜੋਖਮ ਜੋੜਦੇ ਹੋ।
ਇੱਕ ਵੱਡਾ ਮਕਸਦ ਸੀ ਕਿ ਆਮ ਗਲਤੀਆਂ ਲਿਖਣਾ ਔਖਾ ਕੀਤਾ ਜਾਵੇ। Objective‑C ਦੀ ਲਚੀਲਤਾ ਤਾਕਤਵਰ ਹੈ, ਪਰ ਇਹ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਰਨਟਾਈਮ ਤੱਕ ਲੁਕਾ ਸਕਦੀ ਹੈ: nil ਨੂੰ ਮੈਸੇਜ ਭੇਜਣਾ, id ਕਿਸਮਾਂ ਨਾਲ ਗਲਤੀਆਂ, ਜਾਂ APIs ਵਿੱਚ nullability ਦੀ ਗੜਬੜ। ਇਨ੍ਹਾਂ ਵਿੱਚੋਂ ਬਹੁਤ ਕੁਝ ਸਭਿਆਚਾਰ, conventions ਅਤੇ ਚੰਗੀ ਕੋਡ ਰਿਵਿਊ ਨਾਲ ਸੰਭਾਲੇ ਜਾ ਸਕਦੇ ਸਨ—ਪਰ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਉਹ ਮਹਿੰਗੇ ਸਾਬਤ ਹੋ ਸਕਦੇ ਸਨ।
Swift ਅੰਦਰਧਾਰਨ ਤੌਰ 'ਤੇ gardeRails ਬਨਾਉਂਦਾ ਹੈ: optionals ਤੁਹਾਨੂੰ ਸੋਚਣ 'ਤੇ ਮਜਬੂਰ ਕਰਦੇ ਹਨ ਕਿ “ਕੀ ਇਹ ਗੁਆਚ ਸਕਦਾ ਹੈ?”, strong typing ਅਚਾਨਕ ਗਲਤ ਵਰਤੋਂ ਘਟਾਉਂਦਾ ਹੈ, ਅਤੇ guard, switch ਦੀ exhaustive ਚেকਿੰਗ ਅਤੇ ਸੁਰੱਖਿਅਤ collection ਹੈਂਡਲਿੰਗ ਬਹੁਤ ਸਾਰੀਆਂ ਬਗਸ ਕੰਪਾਈਲ-ਟਾਈਮ 'ਤੇ ਧੱਕ ਦਿੰਦੇ ਹਨ ਨਾ ਕਿ ਪ੍ਰੋਡਕਸ਼ਨ ਵਿੱਚ।
Swift ਨੇ ਦੈਨੰਦਿਨ ਕੋਡ ਲਿਖਣ ਦੇ ਤਜਰਬੇ ਨੂੰ ਆਧੁਨਿਕ ਬਣਾਇਆ। ਸੰਖੇਪ syntax, type inference, ਅਤੇ ਇੱਕ ਅਮੀਰ standard library ਬਹੁਤ ਕੰਮਾਂ ਨੂੰ ਕਮ boilerplate ਨਾਲ ਜ਼ਿਆਦਾ ਸਪਸ਼ਟ ਬਣਾਉਂਦੇ ਹਨ।
ਪਰਫਾਰਮੈਂਸ ਦੇ ਮਾਮਲੇ ਵਿੱਚ, Swift ਨੂੰ ਕੰਪਾਇਲਰ-ਵਿਕਸਿਤ ਅਪਟੀਮਾਈਜੇਸ਼ਨ (ਖਾਸ ਕਰਕੇ value types ਅਤੇ generics ਨਾਲ) ਲਈ ਡਿਜ਼ਾਈਨ ਕੀਤਾ ਗਿਆ। ਇਸਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਹਰ Swift ਐਪ ਹਰ Objective‑C ਐਪ ਤੋਂ ਤੇਜ਼ ਹੋਵੇਗਾ, ਪਰ ਇਹ Apple ਨੂੰ ਇੱਕ ਭਾਸ਼ਾ ਮਾਡਲ ਦਿੰਦਾ ਹੈ ਜੋ ਗਤੀ ਵੱਲ ਵਿਕਸਿਤ ਹੋ ਸਕਦਾ ਹੈ ਬਿਨਾਂ ਇਸਤੋਂ ਬਹੁਤ ਡਾਇਨੈਮਿਕ ਰਨਟਾਈਮ 'ਤੇ ਨਿਰਭਰ ਰਹਿਣ ਦੇ।
Apple ਨੂੰ ਚਾਹੀਦਾ ਸੀ ਕਿ iOS ਵਿਕਾਸ ਨਵੇਂ ਡਿਵੈਲਪਰਾਂ ਲਈ ਪਹੁੰਚਯੋਗ ਹੋਵੇ ਅਤੇ ਲੰਮੇ ਸਮੇਂ ਵਾਲੀਆਂ ਉਤਪਾਦਾਂ ਲਈ ਟਿਕਾਉ ਹੋਵੇ। Swift ਦੀਆਂ API ਨਾਮ-ਰੁਪਾਂ, ਕਾਲ ਸਾਈਟਸ 'ਤੇ ਸਪਸ਼ਟ ਇਰਾਦਾ ਅਤੇ ਪ੍ਰਗਟ ਟਾਈਪਜ ਰੀਝ ਘੱਟ "tribal knowledge" ਅਤੇ ਮਹੀਨਿਆਂ ਬਾਅਦ ਕੋਡਬੇਸ ਨੂੰ ਆਸਾਨ ਪੜ੍ਹਨਯੋਗ ਬਣਾਉਂਦੀਆਂ ਹਨ।
ਨਤੀਜਾ: ਘੱਟ foot-guns, ਸਾਫ਼ APIs, ਅਤੇ ਇੱਕ ਭਾਸ਼ਾ ਜੋ ਵੱਡੀਆਂ ਟੀਮਾਂ ਨੂੰ ਸਾਲਾਂ ਤੱਕ ਐਪ ਵਿੱਚ ਕੰਮ ਕਰਨ ਵਿੱਚ ਅਸਾਨੀ ਦੇਂਦੀ ਹੈ—ਬਿਨਾਂ ਇਹ ਕਹਿਣ ਦੇ ਕਿ Objective‑C ਕੰਮ ਨਹੀਂ ਕਰ ਸਕਦਾ।
Swift ਇੱਕ ਦਿਨ ਵਿੱਚ “ਜਿੱਤ” ਨਹੀਂ ਗਿਆ। Apple ਨੇ ਇਸਨੂੰ ਨਵੇਂ ਕੋਡ ਲਈ ਇੱਕ ਚੰਗਾ ਵਿਕਲਪ ਵਜੋਂ ਪੇਸ਼ ਕੀਤਾ, ਫਿਰ ਸਾਲਾਂ ਤੱਕ ਇਸਨੂੰ ਸਥਿਰ, ਤੇਜ਼, ਅਤੇ ਮੌਜੂਦਾ Objective‑C ਐਪਾਂ ਦੇ ਨਾਲ ਅਪਨਾਉਣ ਯੋਗ ਬਣਾਇਆ।
ABI stability ਦਾ ਅਰਥ ਹੈ ਕਿ Swift ਰਨਟਾਈਮ ਅਤੇ standard libraries ਡਾਇਨਾਮਿਕ ਤੌਰ 'ਤੇ Swift 5 ਵਰਜ਼ਨ ਦੇ ਨਾਲ ਬਾਈਨਰੀ-ਸਥਿਰ ਹਨ। Swift 5 ਤੋਂ ਪਹਿਲਾਂ, ਕਈ ਐਪਾਂ ਨੂੰ Swift ਲਾਇਬਰੇਰੀਆਂ ਐਪ ਵਿੱਚ ਬੰਡਲ ਕਰਨੀ ਪੈਂਦੀਆਂ ਸਨ, ਜਿਸ ਨਾਲ ਐਪ ਦਾ ਸਾਈਜ਼ ਵੱਧ ਜਾਂਦਾ ਸੀ ਅਤੇ distribution ਮੁਸ਼ਕਲ ਹੋ ਜਾਂਦੀ ਸੀ। ABI stability ਨਾਲ, Swift Objective‑C ਵਾਂਗ ਹੀ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਭਰੋਸੇਯੋਗ ਹੋਣ ਲੱਗਾ, ਜਿਸ ਨੇ Swift ਨੂੰ ਲੰਬੇ ਸਮੇਂ ਲਈ ਪ੍ਰੋਡਕਸ਼ਨ ਕੋਡਬੇਸਾਂ 'ਤੇ ਵਰਤੋਂਯੋਗ ਬਣਾਇਆ।
ਕਈ ਸਾਲਾਂ ਤੱਕ, ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਨਵੀਆਂ ਫੀਚਰਾਂ ਲਈ Swift ਵਰਤਦੀਆਂ ਸਨ ਪਰ ਕੋਰ ਮੌਡਿਊਲ Objective‑C ਵਿੱਚ ਰਹਿੰਦੀਆਂ। ਇਹ ਹੌਲੀ-ਹੌਲੀ ਰਾਹ—ਇੱਕ ਵੱਡੇ ਰੀਰਾਈਟ ਦੀ ਬਜਾਏ—ਅਸਲੀ ਐਪਾਂ ਅਤੇ ਅਸਲੀ ਡੈਡਲਾਈਨਾਂ ਲਈ ਪ੍ਰਯੋਗਯੋਗ ਬਣਾਇਆ।
Swift ਨੇ ਜਿੱਤ ਨਹੀਂ ਹਾਸਿਲ ਕੀਤੀ ਕਿ ਹਰ ਟੀਮ ਨੇ ਆਪਣਾ Objective‑C ਧਰੋਹਰ ਸੁਆਪਣ ਕੀਤਾ। Apple ਨੇ ਯਕੀਨੀ ਬਣਾਇਆ ਕਿ ਦੋਹਾਂ ਭਾਸ਼ਾਂ ਇੱਕੋ ਐਪ ਟਾਰਗੇਟ ਵਿੱਚ ਇਕੱਠੇ ਰਹਿ ਸਕਦੀਆਂ ਹਨ। ਇਹ ਅਨੁਕੂਲਤਾ ਹੀ ਇੱਕ ਵੱਡਾ ਕਾਰਨ ਹੈ ਕਿ Swift ਦੀ ਗ੍ਰਹਿਣ ਪਹਿਲੇ ਦਿਨ 'ਤੇ ਰੁਕ ਗਈ ਨਹੀਂ।
iOS 'ਤੇ ਮਿਕਸਡ ਕੋਡਬੇਸ ਸਧਾਰਣ ਹੈ: ਤੁਸੀਂ ਪੁਰਾਣੀ ਨੈੱਟਵਰਕਿੰਗ, analytics, ਜਾਂ UI ਕੰਪੋਨੈਂਟ Objective‑C ਵਿੱਚ ਰੱਖ ਸਕਦੇ ਹੋ ਜਦ ਕਿ ਨਵੀਆਂ ਫੀਚਰਾਂ Swift ਵਿੱਚ ਲਿਖੀਆਂ ਜਾਣ। Xcode ਇਹ ਸਿੱਧਾ ਸਪੋਰਟ ਕਰਦਾ ਹੈ, ਇਸ ਲਈ "Swift ਨੇ Objective‑C ਨੂੰ ਰਿੱਪਲੇਸ ਕੀਤਾ" ਆਮ ਤੌਰ 'ਤੇ ਹੌਲੀ ਤਬਦੀਲੀ ਨੂੰ ਦਰਸਾਉਂਦਾ ਹੈ, ਨਾ ਕਿ ਇਕ ਵੱਡਾ ਰੀਰਾਈਟ।
ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਦੋ ਪੂਰੇ ਕੀ ਤਰੀਕਿਆਂ ਰਾਹੀਂ ਕੰਮ ਕਰਦੀ ਹੈ:
YourModuleName-Swift.h ਜਿਹੀ ਹੈਡਰ ਫ਼ਾਈਲ ਜਨਰੇਟ ਕਰਦਾ ਹੈ ਜੋ Objective‑C ਲਈ ਅਨੁਕੂਲ Swift ਕਲਾਸਾਂ ਅਤੇ ਮੈਥਡਾਂ ਨੂੰ ਜ਼ਾਹਰ ਕਰਦਾ ਹੈ। ਤੁਸੀਂ ਆਮ ਤੌਰ 'ਤੇ @objc ਦਰਜ ਕਰਕੇ (ਜਾਂ NSObject ਤੋਂ ਵਿਰਾਸਤ ਲੈ ਕੇ) ਇਸ ਨੂੰ ਚੁਣਦੇ ਹੋ।ਤੁਹਾਨੂੰ ਪਲੰਬਿੰਗ ਯਾਦ ਰੱਖਣ ਦੀ ਜ਼ਰੂਰਤ ਨਹੀਂ—ਪਰ ਇਹ ਸਮਝਣਾ ਕਿ "ਇਸ ਨੂੰ ਦੂਜੇ ਭਾਸ਼ਾ ਲਈ ਖੋਲ੍ਹੋ" ਇੱਕ ਸਪਸ਼ਟ ਕਦਮ ਹੈ, ਇਸ ਨਾਲ ਸਮਝ ਆਉਂਦੀ ਹੈ ਕਿ ਕਿਉਂ ਕੁਝ ਟਾਇਪ ਆਪ-ਮੇਲ ਨਾਲ ਦਿਸਦੇ ਹਨ ਅਤੇ ਹੋਰ ਨਹੀਂ।
ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਕੁਝ ਮੁੜ-ਆਉਣ ਵਾਲੇ ਇੰਟੈਗ੍ਰੇਸ਼ਨ ਮੁੱਦਿਆਂ ਦਾ ਸਾਹਮਣਾ ਕਰਦੀਆਂ ਹਨ:
ਅਸਲ ਐਪ ਲੰਬੇ ਸਮੇਂ ਲਈ ਰਹਿੰਦੇ ਹਨ। ਇੰਟਰਓਪਰੇਬਿਲਿਟੀ ਤੁਹਾਨੂੰ feature-by-feature ਮਾਈਗ੍ਰੇਟ ਕਰਨ, shipping ਜਾਰੀ ਰੱਖਣ ਅਤੇ ਜੋਖਮ ਘੱਟ ਕਰਨ ਦਿੰਦੀ ਹੈ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ third-party SDKs, ਪੁਰਾਣੇ ਕੰਪੋਨੈਂਟ, ਜਾਂ ਸਮਾਂ ਸੀਮਾਵਾਂ ਇੱਕ ਸਾਰੇ-ਇੱਕ ਵਾਰੀ ਤਬਦੀਲੀ ਨੂੰ ਅਣਸਭਵ ਬਣਾਉਂਦੀਆਂ ਹਨ।
Swift ਸਿਰਫ਼ syntax ਆਧੁਨਿਕ ਨਹੀਂ ਕੀਤਾ—ਇਸ ਨੇ ਇਹ ਤੈਅ ਕੀਤਾ ਕਿ “ਦੀਨ-ਪ੍ਰਤੀ ਦਿਨ” iOS ਕੋਡ ਕਿਵੇਂ ਦਿਖਦਾ ਹੈ। ਕਈ ਪੈਟਰਨ ਜਿਹੜੇ ਪਹਿਲਾਂ convention ਤੇ code review ਉੱਤੇ ਨਿਰਭਰ ਸੀ, ਹੁਣ ਕੰਪਾਇਲਰ ਨਾਲ enforced ਹੋ ਸਕਦੇ ਹਨ।
Objective‑C devs ਆਮ ਤੌਰ 'ਤੇ nil ਨੂੰ ਸੁਨੇਹਾ ਭੇਜਣ ਨਾਲ ਸੁੰਨੀ ਹੋ ਜਾਨਦੇ ਸਨ। Swift ਅਣਮੌਜੂਦਗੀ ਨੂੰ optionals (String?) ਨਾਲ ਸਪਸ਼ਟ ਕਰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਤੁਸੀ if let, guard, ਜਾਂ ?? ਵਰਤ ਕੇ ਖਾਲੀਅਤ ਨੂੰ ਪਹਿਲਾਂ ਹੀ ਸੰਭਾਲਦੇ ਹੋ। ਇਹ ਅਕਸਰ crashes ਅਤੇ "ਇਹ ਕੀ ਐਮਪਟੀ ਹੈ?" ਲੋਜਿਕ ਬਗਸ ਨੂੰ ਰੋਕਦਾ ਹੈ—ਇਸ ਦਾ ਮਤਲਬ ਇਹ ਨਹੀਂ ਕਿ ਗਲਤੀਆਂ ਨਹੀਂ ਹੋ ਸਕਦੀਆਂ, ਪਰ ਉਨ੍ਹਾਂ ਦੇ ਆਉਣ ਦੇ ਅਸਰ ਘੱਟ ਹੁੰਦੇ ਹਨ।
Swift ਕਈ ਥਾਵਾਂ 'ਤੇ ਟਾਈਪ infer ਕਰ ਸਕਦਾ ਹੈ, ਜਿਸ ਨਾਲ boilerplate ਘੱਟ ਹੁੰਦਾ ਹੈ:
let title = "Settings" // inferred as String
ਉਨ੍ਹਾਂ ਤੋਂ ਵੀ ਜ਼ਿਆਦਾ ਮਹੱਤਵਪੂਰਨ, generics ਤੁਹਾਨੂੰ reusable, type-safe ਕੋਡ ਲਿਖਣ ਦਿੰਦੇ ਹਨ ਬਿਨਾਂ id ਅਤੇ ਰਨਟਾਈਮ checks 'ਤੇ ਨਿਰਭਰ ਹੋਏ। "ਕੁਝ ਵੀ ਦੀ array" ਦੀ ਥਾਂ "ਠੀਕ-ਉਮੀਦ ਵਾਲੀ array" ਹੋਣ ਨਾਲ ਅਣਚਾਹੇ objects ਘੱਟ ਨਿਕਲਦੇ ਹਨ ਅਤੇ forced casts ਘੱਟ ਹੁੰਦੇ ਹਨ।
Swift ਦਾ throw/try/catch explicit error paths ਨੂੰ ਉਤਸ਼ਾਹਿਤ ਕਰਦਾ ਹੈ ਨਾ ਕਿ ਫੇਲ੍ਹਯਰ ਨੂੰ ਅਣਦੇਖਾ ਕਰਨ ਜਾਂ NSError ** ਨੂੰ ਇਸ਼ਾਰਾ ਕਰਨ। ਕਲੇਕਸ਼ਨਾਂ ਨੂੰ ਸ਼ਕਤੀਸ਼ਾਲੀ ਟਾਈਪ ([User], [String: Int]) ਮਿਲਦੇ ਹਨ, ਅਤੇ strings Unicode-correct String ਹੁੰਦੇ ਹਨ ਨਿਵੜ ਕੇ C strings, NSString, ਅਤੇ ਮੈਨੁਅਲ encoding ਦੇ ਮਿਕਸ ਤੋਂ। ਕੁੱਲ ਮਿਲਾ ਕੇ ਨਤੀਜਾ ਘੱਟ off-by-one ਗਲਤੀਆਂ, ਘੱਟ ਅਣਜਾਣ ਅਨੁਮਾਨ, ਅਤੇ ਘੱਟ "ਕਮਪਾਇਲ ਹੁੰਦਾ ਹੈ ਪਰ ਰਨਟਾਈਮ 'ਤੇ ਟੁੱਟਦਾ ਹੈ" ਦੀਆਂ ਪ੍ਰਸੰਗਿਕਤਾਵਾਂ ਹਨ।
Objective‑C ਦਾ runtime ਅਜੇ ਵੀ runtime-heavy ਪੈਟਰਨ ਲਈ ਕੀਮਤੀ ਹੈ: method swizzling, dynamic message forwarding, ਕੁਝ dependency injection ਤਰੀਕੇ, KVC/KVO-ਚਲਿਤ ਕੋਡ, ਅਤੇ ਬਜ਼ੁਰਗ plugin-ਸਟਾਈਲ ਆਰਕੀਟੈਕਚਰ। Swift ਇਨ੍ਹਾਂ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਜੇ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ runtime dynamism ਦੀ ਲੋੜ ਹੈ, ਤਾਂ Objective‑C ਅਜੇ ਵੀ ਇੱਕ ਹਕੀਕਤੀ ਉਪਕਾਰਣ ਹੈ।
Swift ਨੇ ਸਿਰਫ਼ syntax ਨੂੰ ਨਹੀਂ ਬਦਲਿਆ—ਇਸ ਨੇ iOS ਇਕੋਸਿਸਟਮ ਨੂੰ ਇਸਦੀ ਟੂਲਿੰਗ ਅਤੇ ਰੀਤਾਂ ਨੂਂ ਆਧੁਨਿਕ ਬਣਾਉਣ ਲਈ ਮਜਬੂਰ ਕੀਤਾ। ਇਹ ਟ੍ਰਾਂਜੀਸ਼ਨ ਹਮੇਸ਼ਾਂ ਸੁਗਮ ਨਹੀਂ ਸੀ: ਸ਼ੁਰੂਆਤੀ Swift ਰਿਲੀਜ਼ਾਂ ਮਤਲਬ ਸੀ ਹੌਲੀ ਬਿਲਡ, ਥੋੜ੍ਹੀ autocomplete ਦੀ ਠਹਿਰਾਵਟ, ਅਤੇ refactors ਜਿਨ੍ਹਾਂ ਨੂੰ ਕਰਨਾ ਖਤਰਨਾਕ ਮਹਿਸੂਸ ਹੁੰਦਾ ਸੀ। ਸਮੇਂ ਦੇ ਨਾਲ, developer experience Swift ਦਾ ਇੱਕ ਵੱਡਾ ਫਾਇਦਾ ਬਣ ਗਿਆ।
Xcode ਦੀ Swift ਸਹਾਇਤਾ ਦੈਨੀਕ ਤੌਰ 'ਤੇ ਸੁਧਰੀ:
ਜੇ ਤੁਸੀਂ Swift ਦੇ 1.x/2.x ਦੌਰ ਵਿੱਚ ਸੀ, ਤਾਂ ਤੁਹਾਨੂੰ ਕਦਾਚਿਤ rough edges ਯਾਦ ਹੋਣਗੀਆਂ। ਉਸ ਤੋਂ ਬਾਅਦ ਰੁਝਾਨ ਸਥਿਰ ਰਿਹਾ: ਚੰਗਾ indexing, ਬਿਹਤਰ source stability, ਅਤੇ ਘੱਟ "Xcode ਸੰਭਾਲਨ ਤੋਂ ਉਲਝਿਆ" ਮੋਮੈਂਟ।
Swift Package Manager (SPM) ਨੇ ਕਈ ਟੀਮਾਂ ਲਈ ਬਾਹਰੀ dependency ਸਿਸਟਮ ਦੀ ਲੋੜ ਘਟਾ ਦਿੱਤੀ। ਬੁਨਿਆਦੀ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ packages ਅਤੇ ਵਰਜ਼ਨਾਂ ਨੂੰ ਘੋਸ਼ਿਤ ਕਰਦੇ ਹੋ, Xcode ਉਹਨਾਂ ਨੂੰ resolve ਕਰਦਾ ਹੈ, ਅਤੇ build ਵਿੱਚ ਬਿਨਾਂ ਵਾਧੂ ਪ੍ਰੋਜੈਕਟ ਫ਼ਾਈਲ ਗਿਆਨ ਕੇ ਏਨ੍ਹਾ ਨੂੰ ਜੋੜ ਲੈਂਦਾ ਹੈ। ਇਹ ਹਰ setup ਲਈ ਪਰਫੈਕਟ ਨਹੀਂ, ਪਰ ਕਈ ਐਪਾਂ ਲਈ onboarding ਸਧਾਰਨ ਅਤੇ dependency updates ਅਨੁਮਾਨਕ ਬਣਾਇਆ।
Apple ਦੀ API Design Guidelines ਨੇ frameworks ਨੂੰ ਸਪਸ਼ਟ naming, ਬਿਹਤਰ ਡਿਫਾਲਟ ਵਿਹਾਰ, ਅਤੇ types ਜੋ ਇरਾਦਾ ਦਿਖਾਉਂਦੇ ਹਨ ਵੱਲ ਧਕੇ। ਇਹ ਪ੍ਰਭਾਵ ਆਉਟਸਾਈਡ ਵੀ ਫੈਲਿਆ: ਤੀਜੀ-ਪਾਰਟੀ ਲਾਇਬ੍ਰੇਰੀਆਂ ਵੱਧ ਤੋਂ ਵੱਧ Swift-first APIs ਨੂੰ ਅਪਨਾਉਣ ਲੱਗੀਆਂ, ਜਿਸ ਨਾਲ ਆਧੁਨਿਕ iOS ਕੋਡਬੇਸ ਜ਼ਿਆਦਾ ਇੱਕਸਾਰ ਹੋਏ—ਭਾਵੇਂ ਉਹ ਹੇਠਾਂ Objective‑C ਤੋਂ ਬ੍ਰਿਜ ਹੀ ਕਰ ਰਹੇ ਹੋਣ।
UIKit ਕਿੱਥੇ ਨਹੀਂ ਗਿਆ। ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਡਕਸ਼ਨ iOS ਐਪ ਅਜੇ ਵੀ ਇਸ 'ਤੇ ਤੱਕਦੀਰ ਕਰਦੇ ਹਨ, ਖਾਸ ਕਰਕੇ ਉਹਨਾਂ ਲਈ ਜਿੱਥੇ ਕੰਪਲੈਕਸ ਨੈਵੀਗੇਸ਼ਨ, ਜਟਿਲ ਜੇਸਚਰ, ਟੈਕਸਟ ਹੈਂਡਲਿੰਗ ਅਤੇ ਬਹੁਤ ਸਾਰੇ UI ਕੰਪੋਨੈਂਟ ਹਨ ਜੋ ਟੀਮਾਂ ਨੇ ਬੈਟਲ‑ਟੈਸਟ ਕੀਤੇ ਹੋਏ ਹਨ। ਜੋ ਬਦਲਿਆ ਹੈ ਉਹ ਇਹ ਹੈ ਕਿ Swift ਹੁਣ ਮੁੱਖ ਤਰੀਕਾ ਹੈ ਜਿਵੇਂ ਲੋਕ UIKit ਕੋਡ ਲਿਖਦੇ ਹਨ—ਭਾਵੇਂ ਉਹ ਫਰੇਮਵਰਕ ਸਮਾਨ ਰਹੇ।
ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਲਈ, “UIKit app” ਹੁਣ Objective‑C ਦਾ ਸੁਚਕ ਨਹੀਂ ਰਹੀ। Storyboards, nibs, ਅਤੇ programmatic views ਰੋਜਾਨਾ Swift view controllers ਅਤੇ Swift models ਨਾਲ ਚਲਾਏ ਜਾਂਦੇ ਹਨ।
ਇਹ ਬਦਲਾਅ ਮਹੱਤਵਪੂਰਨ ਹੈ ਕਿਉਂਕਿ Apple ਨਵੇਂ APIs ਨੂੰ Swift ergonomics ਨੂੰ ਧਿਆਨ ਵਿੱਚ ਰੱਖ ਕੇ ਡਿਜ਼ਾਈਨ ਕਰਨ ਲੱਗਾ (ਸਪਸ਼ਟ naming, optionals, generics, result types)। ਭਾਵੇਂ ਕੋਈ API Objective‑C ਲਈ ਹੋਵੇ, Swift overlay ਅਕਸਰ "ਮਨਜ਼ੂਰ ਕੀਤੀ surface" ਜਿਹਾ ਮਹਿਸੂਸ ਹੁੰਦਾ ਹੈ, ਜਿਸ ਨਾਲ ਨਵੇਂ ਡਿਵੈਲਪਰ UIKit ਕੋਡਬੇਸ ਵਿੱਚ ਜ਼ਿਆਦਾ ਤੇਜ਼ ਰਸਤੀ ਤੇ ਆ ਜਾਂਦੇ ਹਨ।
SwiftUI ਸਿਰਫ਼ ਬਟਨ ਦਰਸਾਉਣ ਦਾ ਨਵਾਂ ਤਰੀਕਾ ਨਹੀਂ ਸੀ। ਇਸ ਨੇ ਇੱਕ ਵੱਖਰਾ ਮਨੋ-ਮਾਡਲ ਪ੍ਰਭਾਵਿਤ ਕੀਤਾ:
ਅਮਲੀ ਤੌਰ 'ਤੇ, ਇਸ ਨੇ ਐਪ ਆਰਕੀਟੈਕਚਰ ਦੀਆਂ ਚਰਚਾਂ ਨੂੰ ਬਦਲ ਦਿੱਤਾ। ਜੋ ਟੀਮ SwiftUI ਅਪਨਾਉਂਦੀਆਂ ਹਨ, ਉਹ ਅਕਸਰ unidirectional data flow, ਛੋਟੇ view ਕੰਪੋਨੈਂਟ, ਅਤੇ view ਕੋਡ ਤੋਂ side effects (networking, persistence) ਨੂੰ ਵੱਖ ਕਰਨਾ ਜ਼ਿਆਦਾ ਤਰਜੀਹ ਦਿੰਦੀਆਂ ਹਨ। ਭਾਵੇਂ ਤੁਸੀਂ "ਸਾਰੇ-ਇੱਦੇ" ਨਾ ਜਾਓ, SwiftUI ਐਸੇ ਸਕ੍ਰੀਨਾਂ ਲਈ ਬੋਅਲਰਪਲੇਟ ਘੱਟ ਕਰ ਸਕਦਾ ਹੈ ਜੋ zyada ਤਰ forms, lists, ਅਤੇ state-driven layouts ਹਨ।
Shipping apps ਅਕਸਰ ਦੋਹਾਂ ਫਰੇਮਵਰਕ ਮਿਲਾ ਕੇ ਵਰਤਦੇ ਹਨ:
UIHostingController ਰਾਹੀਂ SwiftUI ਨੂੰ UIKit ਵਿੱਚ ਐਮਬੈਡ ਕਰੋ।ਇਹ ਹਾਇਬਰਿਡ ਰਵੱਈਆ ਟੀਮਾਂ ਨੂੰ mature UIKit infrastructure—navigation stacks, coordinators, ਮੌਜੂਦਾ design systems—ਰੱਖਦੇ ਹੋਏ SwiftUI ਅਪਨਾਉਣ ਦਿੰਦਾ ਹੈ। ਇਹ ਜੋਖਮ ਨੂੰ ਸਮਭਾਲਣ ਯੋਗ ਰੱਖਦਾ ਹੈ: ਤੁਸੀਂ ਸੀਮਤ ਖੇਤਰਾਂ ਵਿੱਚ SwiftUI ਪਾਇਲਟ ਕਰ ਸਕਦੇ ਹੋ ਬਿਨਾਂ Poore UI ਲੇਅਰ ਨੂੰ ਰੀਰਾਈਟ ਕੀਤੇ।
ਜੇ ਤੁਸੀਂ ਅੱਜ ਨਵਾਂ ਪ੍ਰਾਜੈਕਟ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ, Apple ਦੀ ਨਵੀਂ UI ਕਹਾਣੀ SwiftUI ਹੈ, ਅਤੇ ਕਈ ਨਾਲ-ਜੁੜੀਆਂ ਤਕਨਾਲੋਜੀਆਂ (widgets, Live Activities, ਕੁਝ app extensions) ਮਜ਼ਬੂਤੀ ਨਾਲ Swift-ਉਦ੍ਦੇਸ਼ੀ ਹਨ। UI ਦੇ ਬਾਹਰ ਵੀ, Swift-ਅਨੁਕੂਲ APIs ਅਕਸਰ ਡਿਫਾਲਟਸ ਨੂੰ ਸ਼ੇਪ ਕਰਦੇ ਹਨ: ਨਵੇਂ ਪ੍ਰੋਜੈਕਟ ਆਮ ਤੌਰ 'ਤੇ Swift ਨਾਲ ਯੋਜਨਾ ਬਣਾਏ ਜਾਂਦੇ ਹਨ, ਅਤੇ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ "ਸਾਨੂੰ ਕਿੰਨਾ UIKit ਲੋੜੀਦਾ ਹੈ?" ਨਾ ਕਿ "ਕੀ ਅਸੀਂ Objective‑C ਵਰਤਾਂ?"
ਨਤੀਜਾ ਇਹ ਹੈ ਕਿ ਇਹ ਇਕ ਫਰੇਮਵਰਕ ਦੂਜੇ ਨੂੰ ਬਦਲਣਾ ਨਹੀਂ, ਬਲਕਿ Swift ਦੋਹਾਂ legacy-friendly path (UIKit) ਅਤੇ ਨਵੇਂ Swift-native path (SwiftUI) ਵਿੱਚ ਆਮ ਭਾਸ਼ਾ ਬਣ ਗਿਆ ਹੈ।
Concurrency ਬਣਾਉਂਦਾ ਹੈ ਕਿ ਐਪ ਇੱਕ ਸਮੇਂ ਵਿੱਚ ਕਈ ਕੰਮ ਕਰੋ—ਡੇਟਾ ਲੋਡ ਕਰਨਾ, JSON decode ਕਰਨਾ, ਅਤੇ ਸਕ੍ਰੀਨ ਅਪਡੇਟ—ਬਿਨਾਂ interface ਨੂੰ freeze ਕੀਤੇ। Swift ਦਾ ਆਧੁਨਿਕ ਤਰੀਕਾ ਇਹ ਕੰਮ ਉਹਨੀ ਤਰ੍ਹਾਂ ਮਹਿਸੂਸ ਕਰਵਾਉਂਦਾ ਹੈ ਜਿਵੇਂ ਸਧਾਰਨ ਕੋਡ, ਨਾ ਕਿ ਥਰੈੱਡ ਜਾਦੂगरी।
async/await ਨਾਲ ਤੁਸੀਂ asynchronous ਕੰਮ (ਜਿਵੇਂ network request) ਨੂੰ top-to-bottom ਸ਼ੈਲੀ ਵਿੱਚ ਲਿਖ ਸਕਦੇ ਹੋ:
async ਉਹ ਫੰਕਸ਼ਨ ਨਿਸ਼ਾਨ ਲਾਉਂਦਾ ਹੈ ਜੋ ਰੁਕ ਸਕਦਾ ਹੈ।await ਉਹ ਬਿੰਦੂ ਹੈ ਜਿੱਥੇ ਪਹਿਲ ਰੁਕ ਕੇ ਨਤੀਜੇ ਦਾ ਇੰਤਜ਼ਾਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ।ਗਹਿਰੇ nested completion handlers ਦੀ ਥਾਂ, ਤੁਸੀਂ ਇਸਨੂੰ ਇੱਕ ਰੈਸਪੀ ਵਾਂਗ ਪੜ੍ਹਦੇ ਹੋ: ਡੇਟਾ ਲਿਆਓ, parse ਕਰੋ, ਫਿਰ state ਅਪਡੇਟ ਕਰੋ।
Swift async/await ਨਾਲ structured concurrency ਨਾਲ ਜੋੜਦਾ ਹੈ, ਜਿਸਦਾ ਅਰਥ ਹੈ: "background ਕੰਮ ਦਾ ਇੱਕ ਸਾਫ਼ ਮਾਲਿਕ ਅਤੇ ਲਾਈਫਟਾਈਮ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ।" ਟਾਸਕ ਕਿਸੇ ਸਕੋਪ ਵਿੱਚ ਬਣਦੇ ਹਨ, ਅਤੇ child tasks ਆਪਣੇ parent ਨਾਲ ਜੁੜੇ ਹੁੰਦੇ ਹਨ।
ਇਸਦਾ ਪ੍ਰਭਾਵ:
ਦੋ ਧਾਰਨਾਵਾਂ “random” crashes ਨੂੰ ਘੱਟ ਕਰਨ ਵਿੱਚ ਸਹਾਇਤਾ ਕਰਦੀਆਂ ਹਨ:
ਅਧਿਕਤਮ ਟੀਮਾਂ ਇੱਕ switch ਰਾਫਤੇ ਕੁਦਮ ਨਹੀਂ ਚੁੱਕਦੀਆਂ। ਪੁਰਾਣੀਆਂ ਰੀਤਾਂ—OperationQueue, GCD, delegate callbacks, ਅਤੇ completion handlers—ਅਕਸਰ modern Swift concurrency ਨਾਲ ਮਿਲਾਈਆਂ ਜਾਂਦੀਆਂ ਹਨ, ਖਾਸ ਕਰਕੇ legacy ਲਾਇਬ੍ਰੇਰੀਆਂ ਜਾਂ ਪੁਰਾਣੇ UIKit ਫਲੋਜ਼ ਦੇ ਇੰਟੇਗਰੇਸ਼ਨ ਵੇਲੇ।
ਇੱਕ ਅਸਲ iOS ਐਪ ਨੂੰ ਮਾਈਗ੍ਰੇਟ ਕਰਨਾ “ਸਭ ਕੁਝ ਤਬਦੀਲ ਕਰੋ” ਪ੍ਰਾਜੈਕਟ ਨਹੀਂ—ਇਹ ਜੋਖਮ-ਪ੍ਰਬੰਧਨ ਪ੍ਰਾਜੈਕਟ ਹੈ। ਮਕਸਦ shipping ਜਾਰੀ ਰੱਖਣਾ ਹੁੰਦਾ ਹੈ ਜਦ ਕਿ ਹੌਲੀ-ਹੌਲੀ Objective‑C ਦੀ ਰੱਖ-ਰਖਾਵ ਘੱਟ ਕਰਨੀ ਹੁੰਦੀ ਹੈ।
ਇੱਕ ਆਮ ਪਹੁੰਚ incremental migration ਹੈ:
ਇਸ ਨਾਲ ਤੁਸੀਂ ਭਰੋਸਾ ਬਣਾਉਂਦੇ ਹੋ ਅਤੇ blast radius ਘੱਟ ਰੱਖਦੇ ਹੋ—ਖਾਸ ਕਰਕੇ ਜਦੋਂ ਡੈਢਲਾਈਨ ਰੋਕਦੀ ਨਹੀਂ।
ਕਈ Objective‑C ਪੈਟਰਨ ਸਿੱਧੇ ਤੌਰ 'ਤੇ ਅਨੁਵਾਦ ਨਹੀਂ ਹੁੰਦੇ:
objc_runtime ਤਕਨੀਕਾਂ ਵਾਲਾ ਕੋਡ redesign ਮੰਗ ਸਕਦਾ ਹੈ ਨਾ ਕਿ ਸਿੱਧਾ translation।ਮਾਈਗ੍ਰੇਸ਼ਨ ਨੂੰ ਇੱਕ implementation swap ਵਜੋਂ ਟ੍ਰੀਟ ਕਰੋ, ਨਾ ਕਿ ਫੀਚਰ ਬਦਲਣ ਵਜੋਂ। ਅਹੰਕਾਰਿਕ flows (networking, caching, payments, auth) ਦੇ ਆਲੇ-ਦੁਆਲੇ characterization tests ਜੋੜੋ, ਫਿਰ port ਕਰੋ। UIKit ਕੋਡ Swift ਵਿੱਚ ਸ਼ਿਫਟ ਕਰਦਿਆਂ UI regressions ਪਕੜਨ ਲਈ snapshot tests ਮਦਦਗਾਰ ਹੁੰਦੇ ਹਨ।
ਟੀਮਾਂ ਲਈ ਇੱਕ ਫ਼ੈਲਾਈਟ ਮਿਆਰੀ ਬਣਾਓ: ਕੋਡ ਕੰਵੈਨਸ਼ਨ, linting (SwiftLint ਜਾਂ ਸਮਾਨ), module boundaries, bridging header ਨਿਯਮ, ਅਤੇ "ਨਵਾਂ Objective‑C ਨਾ ਲਿਖੋ ਜੇ ਤੱਕ ਜ਼ਰੂਰੀ ਨਾ ਹੋਵੇ"। ਇਹ ਲਿਖਿਤ ਨੀਤੀਆਂ ਤੁਹਾਡੇ ਕੋਡਬੇਸ ਨੂੰ inconsistent bilingual ਬਣਨ ਤੋਂ ਰੋਕਦੀਆਂ ਹਨ।
Swift ਨੇ ਸਿਰਫ਼ syntax ਨਹੀਂ ਬਦਲਿਆ—ਇਸ ਨੇ iOS ਟੀਮ ਵੱਲੋਂ "ਸਧਾਰਣ" ਕੀ ਹੁੰਦਾ ਹੈ ਉਸ ਨੂੰ ਵੀ ਬਦਲਿਆ। ਭਾਵੇਂ ਤੁਹਾਡੇ ਉਤਪਾਦ 'ਚ Objective‑C ਅਜੇ ਵੀ ਹੋਵੇ, ਦੈਨੰਦਿਨ ਫੈਸਲੇ—ਲੋਕ, ਪ੍ਰਕਿਰਿਆ, ਅਤੇ ਲੰਬੀ ਅਵਧੀ ਦੀ ਸੰਭਾਲ—ਹੁਣ Swift-first ਉਮੀਦਾਂ ਨਾਲ ਰੂਪ ਲੈਂਦੇ ਹਨ।
ਅਧਿਕਤਰ ਨਵੀਆਂ iOS ਨੌਕਰੀਆਂ Swift ਨੂੰ ਡਿਫਾਲਟ ਮੰਨ ਲੈਂਦੀਆਂ ਹਨ। ਉਮੀਦਵਾਰਾਂ ਨੇ ਹੋ ਸਕਦਾ ਹੈ ਕਿ ਉਹਨੇ ਕਦੇ Objective‑C ਪੇਸ਼ੇਵਰ ਤੌਰ 'ਤੇ ship ਨਾ ਕੀਤਾ ਹੋਵੇ, ਜਿਸ ਨਾਲ ਮਿਕਸਡ ਕੋਡਬੇਸ ਵਿੱਚ ramp-up ਸਮਾਂ ਪ੍ਰਭਾਵਤ ਹੁੰਦਾ ਹੈ।
ਅਮਲੀ ਨਤੀਜਾ: Objective‑C ਨੂੰ “ਪਲਸ” ਵਜੋਂ ਸਮਝੋ, ਨਾ ਕਿ ਦਰਵਾਜ਼ਾ। onboarding ਸਮਗਰੀ ਵਿੱਚ ਸਪਸ਼ਟ ਕਰੋ ਕਿ Objective‑C ਕਿੱਥੇ ਹੈ ਅਤੇ ਕਿਉਂ। bridging headers, file ownership, ਅਤੇ "context ਦੇ ਬਿਨਾਂ ਨਾ ਛੇੜੋ" ਵਾਲੇ ਛੋਟੇ internal guides early mistakes ਰੋਕ ਸਕਦੇ ਹਨ।
Swift ਦੀ ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ ਅਤੇ ਸਪਸ਼ਟ optionals ਨਾਲ reviews ਤੇਜ਼ ਹੋ ਸਕਦੀਆਂ ਹਨ: reviewers ਘੱਟ ਸਮਾਂ ਇਸ ਗੱਲ 'ਤੇ ਗੁਜ਼ਾਰਦੇ ਹਨ ਕਿ ਇੱਕ value ਕੀ ਹੋ ਸਕਦੀ ਹੈ, ਅਤੇ ਵੱਧ ਸਮਾਂ intent ਦੀ ਜਾਂਚ 'ਤੇ ਖਰਚ ਹੁੰਦਾ ਹੈ। protocols, generics, ਅਤੇ value types ਵਰਗੇ ਪੈਟਰਨਾਂ ਨਾਲ ਸਮਰਥਿਤ ਆਰਕੀਟੈਕਚਰ ਵੀ ਮਨਵਾਇਆ ਜਾ ਸਕਦਾ ਹੈ—ਜੇ ਸੰਤੁਲਨ ਨਾਲ ਵਰਤੇ ਜਾਣ।
ਉਲਟ ਪਾਸਾ style drift ਹੈ। ਟੀਮਾਂ ਨੂੰ ਇੱਕ साझा Swift style guide ਅਤੇ automated formatting/linting ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ ਤਾਂ ਜੋ reviews ਵਿਹਾਰ 'ਤੇ ਕੇਵਲ ਫੋਕਸ ਕਰਨ, ਨਾ ਕਿ whitespace ਉੱਤੇ।
ਆਧੁਨਿਕ APIs ਤੇ ਸੀਧਾ ਨਿਰਭਰ ਕਰਨ ਨਾਲ maintenance ਆਸਾਨ ਹੁੰਦਾ ਹੈ, ਬਜਾਏ ਕਿ ਬਜ਼ੁਰਗ ਪੈਟਰਨਾਂ 'ਤੇ ਬਣੀ ਕਸਟਮ wrappers ਨੂੰ ਖਜਾਂਦਾ ਰਹੇ। ਪਰ Objective‑C ਇੱਕ ਦਿਨ ਵਿੱਚ ਗਾਇਬ ਨਹੀਂ ਹੋਵੇਗਾ—ਖਾਸ ਕਰਕੇ ਪਰਿਪੱਕ apps ਵਿੱਚ ਜਿੱਥੇ modules ਸਥਿਰ ਅਤੇ ਬੈਟਲ‑ਟੈਸਟ ਕੀਤੇ ਹੋਏ ਹਨ।
Mixd codebases ਲਈ ਹਕੀਕਤੀਤਾਵਾਦੀ ਬਜਟ ਬਣਾਓ: migration ਕਾਰੋਬਾਰੀ ਮੀਲ ਪੱਥਰਾਂ ਦੇ ਆਲੇ-ਦੁਆਲੇ ਯੋਜਨਾ ਬਣਾਓ, ਨਾ ਕਿ ਇੱਕ ਅਨੰਤ "ਸਫਾਈ"। "Done" ਦੇ ਮਿਆਰ ਨਿਰਧਾਰਤ ਕਰੋ (ਉਦਾਹਰਨ: ਸਭ ਨਵਾਂ ਕੋਡ Swift ਵਿੱਚ, legacy modules ਸਿਰਫ਼ ਜਦੋਂ ਮੌਕਾ ਮਿਲੇ ਤਬ) ਅਤੇ ਜ਼ਰੂਰੀ ਸਮੇਂ 'ਤੇ ਇਸ ਨੀਤੀ ਨੂੰ ਮੁੜ ਵੇਖੋ।
ਇਕ ਫੈਸਲਾ-ਫਰੇਮਵਰਕ ਲਈ, ਵੇਖੋ /blog/migrating-objective-c-to-swift.
Swift ਅਤੇ Objective‑C ਵਿਚੋਂ ਚੋਣ ਆਮ ਤੌਰ 'ਤੇ ਫਲਸਫ਼ੀ ਵਾਦ-ਵਿਵਾਦ ਨਹੀਂ—ਇਹ ਲਾਗਤ, ਜੋਖਮ, ਅਤੇ ਸਮਾਂ-ਸਾਰਣੀ ਦਾ ਫੈਸਲਾ ਹੁੰਦਾ ਹੈ। ਚੰਗੀ ਗੱਲ ਇਹ ਹੈ ਕਿ ਤੁਹਾਨੂੰ ਅਕਸਰ "ਸਭ ਜਾਂ ਕੁਝ ਨਹੀਂ" ਚੁਣਨਾ ਲੋੜੀਂਦਾ ਨਹੀਂ। ਜ਼ਿਆਦਾਤਰ ਟੀਮਾਂ ਸਭ ਤੋਂ ਵਧੀਆ ਨਤੀਜਾ ਅਪਣਦੇ ਕੋਡਬੇਸ ਨੂੰ ਅੰਦਰੋਂ ਹੀ ਵਿਕਸਤ ਕਰਕੇ ਪ੍ਰਾਪਤ ਕਰਦੀਆਂ ਹਨ।
ਜੇ ਤੁਸੀਂ ਨਵਾਂ ਪ੍ਰਾਜੈਕਟ ਸ਼ੁਰੂ ਕਰ ਰਹੇ ਹੋ, Swift ਤੁਹਾਡਾ ਡਿਫਾਲਟ ਹੋਣਾ ਚਾਹੀਦਾ ਹੈ। ਇਹ Apple ਦੀਆਂ ਨਵੀਂ APIs ਨਾਲ ਸੰਗਤ ਹੈ, ਬੇਹਤਰ ਸੁਰੱਖਿਆ ਫੀਚਰ ਦਿੰਦਾ ਹੈ, ਅਤੇ async/await ਵਰਗੇ ਆਧੁਨਿਕ ਪੈਟਰਨਾਂ ਤੱਕ ਸਿਧਾ ਪਹੁੰਚ ਦਿੰਦਾ ਹੈ।
ਤੁਹਾਡਾ ਪਹਿਲਾ ਫੈਸਲਾ UI ਰਣਨੀਤੀ ਹੈ: UIKit in Swift, SwiftUI, ਜਾਂ ਮਿਕਸ। ਜੇ ਪੁਰਾ ਪਤਾਕਾ ਨਹੀਂ, ਤਦੋਂ tradeoffs /blog/swiftui-vs-uikit ਵਿੱਚ ਤੁਲਨਾ ਕਰੋ।
ਇੱਕ ਮੌਜੂਦਾ Objective‑C ਐਪ ਲਈ, ਸਥਿਰ, ਚੰਗੀ ਤਰ੍ਹਾਂ ਟੈਸਟ ਕੀਤੇ ਮੌਡਿਊਲਾਂ ਨੂੰ Objective‑C ਵਿੱਚ ਰੱਖੋ ਅਤੇ Swift ਉਥੇ ਲਿਆਓ ਜਿੱਥੇ ਤੁਹਾਨੂੰ ਤੁਰੰਤ ਫਾਇਦਾ ਮਿਲੇਗਾ:
ਇੱਕ ਅਮਲੀ ਨਿਯਮ: ਜਦੋਂ ਤੁਸੀਂ ਸਪਸ਼ਟ ਸਰਹੱਦ (API surface, ownership, tests) ਤੈਅ ਕਰ ਸਕਦੇ ਹੋ ਤਾਂ ਇੱਕ ਨਵਾਂ Swift ਮੋਡਿਊਲ ਬਣਾਉ। ਜਦੋਂ ਕੋਡ mature ਅਤੇ ਘਣੀ ਤਰ੍ਹਾਂ ਇੰਟਰਵਾਇਨਡ ਹੋਵੇ ਤਾਂ Objective‑C ਨੂੰ ਸਥਿਰ ਰੱਖੋ।
ਪਲਾਨਿੰਗ ਲਈ, ਵੇਖੋ /blog/ios-migration-checklist.
ਇਹ ਕ੍ਰਮ ਦੈਨਿੰਦਿਨ iOS ਵਿਕਾਸ ਲਈ ਚੰਗਾ ਮੇਲ ਖਾਂਦਾ ਹੈ:
iOS ਨੂੰ ਮਾਡਰਨਾਈਜ਼ ਕਰਨਾ ਅਕਸਰ ਅਸਮੱਖ ਕੰਮ ਉਤਪੰਨ ਕਰਦਾ ਹੈ ਜੋ ਇੱਕੋ ਹੀ ਇੰਜੀਨੀਅਰਿੰਗ ਸਮੇਂ ਲਈ ਮੁਕਾਬਲਾ ਕਰਦੇ ਹਨ: admin dashboards, ਅੰਦਰੂਨੀ ਟੂਲ, backend services, ਅਤੇ APIs ਜਿਨ੍ਹਾਂ 'ਤੇ iOS ਐਪ ਨਿਰਭਰ ਹੈ। ਜੇ ਤੁਸੀਂ ਚਾਹੁੰਦੇ ਹੋ ਕਿ iOS ਟੀਮ Swift ਮਾਈਗ੍ਰੇਸ਼ਨ 'ਤੇ ਧਿਆਨ ਦਿੰਦੇ ਹੋਵੇ ਪਰ ਸਹਾਇਕ ਸੌਫਟਵੇਅਰ ਵੀ ਬਨਦਾ ਰਹੇ, ਤਾਂ Koder.ai ਤੁਹਾਡੇ ਲਈ ਵੈਬ ਐਪ, Go ਬੈਕਐਂਡ (PostgreSQL ਨਾਲ), ਜਾਂ Flutter companion ਐਪ ਤੇਜ਼ੀ ਨਾਲ ਚਲਾਉਣ ਵਿੱਚ ਮਦਦ ਕਰ ਸਕਦਾ ਹੈ—chat-driven workflow ਰਾਹੀਂ—ਫਿਰ ਤੁਸੀਂ source code export ਕਰ ਸਕਦੇ ਹੋ, ਡਿਪਲੋਏ, ਅਤੇ snapshots/rollback ਨਾਲ iteration ਸੁਰੱਖਿਅਤ ਤਰੀਕੇ ਨਾਲ ਹੁੰਦੀ ਹੈ।
ਜੇ ਤੁਸੀਂ ਬਾਹਰੀ ਮਦਦ ਚਾਹੁੰਦੇ ਹੋ ਜੋ ਸਭ ਤੋਂ ਸੁਰੱਖਿਅਤ ਅਗਲਾ ਕਦਮ ਸਕੋਪ ਕਰੇ—ਨਵਾਂ ਮੋਡਿਊਲ, ਅੰਸ਼ਿਕ ਮਾਈਗ੍ਰੇਸ਼ਨ, ਜਾਂ "ਛੱਡ ਦੇਓ"—ਤਾਂ ਵੇਖੋ /pricing.
Swift ਨੂੰ ਆਮ iOS ਵਿਕਾਸ ਦੇ ਖਤਰਾ ਘੱਟ ਕਰਨ (ਜਿਵੇਂ ਕਿ ਅਣਉਮੀਦਿਤ nil ਵਹਿਵਾਰ ਅਤੇ ਧਿੱਲੇ ਟਾਈਪਿੰਗ), ਵੱਡੇ ਕੋਡਬੇਸ ਲਈ ਪੜ੍ਹਨਯੋਗਤਾ/ਮੈਂਟੇਨਬਿਲਿਟੀ ਬਿਹਤਰ ਕਰਨ ਅਤੇ ਸਮੇਂ ਦੇ ਨਾਲ ਕਮਪਾਈਲਰ ਆਪਟਿਮਾਈਜੇਸ਼ਨ ਦੀ ਯੋਗਤਾ ਦੇਣ ਲਈ ਬਣਾਇਆ ਗਿਆ ਸੀ। ਇਹ ਇਸ ਲਈ ਨਹੀਂ ਸੀ ਕਿ Objective‑C “ਖਰਾਬ” ਹੈ—ਪਰ ਇਹ ਆਧੁਨਿਕ ਡੀਫ਼ਾਲਟਸ ਨੂੰ ਆਸਾਨ ਬਣਾਉਣ ਲਈ ਸੀ ਜੋ ਵੱਡੇ ਪੈਮਾਨੇ 'ਤੇ ਸੁਰੱਖਿਅਤ ਹਨ।
Swift ਨੇ ਦੌਰਾਨਿਕ ਅਤੇ ਹੌਲੀ ਅਪਨਾਏ ਜਾਣ ਵਾਲੇ ਤੱਤਾਂ ਰਾਹੀਂ ਪ੍ਰਸਿੱਧਤਾ ਹਾਸਲ ਕੀਤੀ:
ਇਸ ਕਰਕੇ ਬਹੁਤ ਸਾਰੀਆਂ ਟੀਮਾਂ ਲਈ “ਨਵਾਂ ਕੋਡ Swift ਵਿੱਚ” ਲੈਣਾ ਸਭ ਤੋਂ ਆਸਾਨ ਰਸਤਾ ਬਣ ਗਿਆ।
Swift 5 ਨੇ Apple ਪਲੇਟਫਾਰਮਾਂ ਉੱਤੇ ABI stability ਲਿਆਂਦੀ, ਜਿਸਦਾ ਮਤਲਬ ਇਹ ਹੈ ਕਿ Swift 5.x ਵਰਜ਼ਨਾਂ ਨਾਲ ਕਮਪਾਈਲ ਕੀਤੀ ਕੋਡ ਬਾਈਨਰੀ-ਸੰਕੇਤਿਕ ਤੌਰ 'ਤੇ ਅਨੁਕੂਲ ਰਹਿ ਸਕਦੀ ਹੈ। ਪਹਿਲਾਂ, ਅਪਾਂ ਨੂੰ Swift ਲਾਇਬਰੇਰੀਆਂ ਐਪ ਵਿੱਚ ਬੰਡਲ ਕਰਨੀਆਂ ਪੈਂਦੀਆਂ ਸਨ, ਜਿਸ ਨਾਲ ਐਪ ਸਾਈਜ਼ ਵੱਧ ਜਾਂਦੀ ਸੀ ਅਤੇ ਡਿਸਟ੍ਰਿਬਿਊਸ਼ਨ ਔਖਾ ਹੋ ਜਾਂਦਾ ਸੀ। ABI ਸਥਿਰਤਾ ਨਾਲ, Swift Objective‑C ਵਰਗਾ ਭਰੋਸੇਯੋਗ ਮਹਿਸੂਸ ਹੋਇਆ ਅਤੇ ਲੰਬੇ ਸਮੇਂ ਲਈ ਪ੍ਰੋਡਕਸ਼ਨ ਕੋਡਬੇਸਾਂ 'ਤੇ ਵਰਤੋਂ ਲਈ ਸੁਰੱਖਿਅਤ ਬਣਿਆ।
ਤੁਸੀਂ ਇੱਕੋ ਹੀ ਐਪ ਟਾਰਗੇਟ ਵਿੱਚ ਦੋਹਾਂ ਮਿਲਾ ਸਕਦੇ ਹੋ:
YourModuleName-Swift.h) ਬਣਾ ਦਿੰਦਾ ਹੈ ਜੋ Objective‑C-ਅਨੁਕੂਲ Swift APIs ਨੂੰ ਰਫ਼ਤਾਰ ਦਿੰਦਾ ਹੈ; ਆਮ ਤੌਰ 'ਤੇ ਤੁਸੀਂ @objc ਜਾਂ NSObject ਵਰਤ ਕੇ ਇਸ ਨੂੰ ਚੁਣਦੇ ਹੋ।ਹਰ Swift ਫੀਚਰ Objective‑C ਲਈ ਦਿਖਾਈ ਨਹੀਂ ਦਿੰਦਾ, ਇਸ ਲਈ ਬਚਨਬੱਧ ਸਰਹੱਦ ਤੈਅ ਕਰਨਾ ਮਹੱਤਵਪੂਰਨ ਹੈ।
Optionals (T?) “ਮੌਜੂਦ ਨਾ ਹੋਣ” ਨੂੰ ਸਪਸ਼ਟ ਕਰਦੇ ਹਨ ਅਤੇ ਕੰਪਾਈਲ-ਟਾਈਮ 'ਤੇ ਹੈਂਡਲਿੰਗ ਲਾਜ਼ਮੀ ਕਰਦੇ ਹਨ (ਉਦਾਹਰਣ: if let, guard, ??)। Objective‑C ਵਿੱਚ, nil ਨੂੰ ਮੈਸੇਜ ਭੇਜਣਾ ਅਤੇ ਅਸਪਸ਼ਟ nullability ਬਗਸ ਨੂੰ ਰਨਟਾਈਮ ਤੱਕ ਛੁਪਾ ਸਕਦੇ ਹਨ। ਵਿਆਵਹਾਰਿਕ ਨਤੀਜਾ: ਘੱਟ crashes ਅਤੇ ਘੱਟ “ਇਹ ਵੈਲਿਊ ਅਣਉਮੀਦਿਤ ਤੌਰ 'ਤੇ ਖਾਲੀ ਸੀ” ਸਮੱਸਿਆਵਾਂ।
Swift ਦੇ ਗੇਨੇਰਿਕ ਅਤੇ ਮਜ਼ਬੂਤ ਟਾਈਪਿੰਗ ਨਾਲ ਕੰਪਾਇਲ-ਟਾਈਮ ਸੁਰੱਖਿਆ ਵਧੀ: casting ਘੱਟ ਹੁੰਦਾ ਹੈ ਅਤੇ runtime type checks ਘੱਟ ਹੋ ਜਾਂਦੇ ਹਨ (ਜੋ Objective‑C ਵਿੱਚ id ਅਤੇ ਅਨਟਾਈਪਡ ਕਲੇਕਸ਼ਨਾਂ ਨਾਲ ਆਮ ਸੀ)। ਅਮਲੀ ਤੌਰ 'ਤੇ, ਤੁਸੀਂ ਪ੍ਰਾਪਤ ਕਰੋ:
[User] ਵਰਗੀਆਂ ਸੁਰੱਖਿਅਤ ਕਲੇਕਸ਼ਨਾਂਹਾਂ — ਜਦੋਂ ਤੁਹਾਨੂੰ ਸੱਚਮੁੱਚ ਰਨਟਾਈਮ ਡਾਇਨਾਮਿਜ਼ਮ ਦੀ ਲੋੜ ਹੋਵੇ ਤਾਂ Objective‑C ਅਜੇ ਵੀ ਬਿਹਤਰ ਚੋਣ ਹੋ ਸਕਦੀ (ਉਦਾਹਰਣ: ਭਾਰੀ KVC/KVO, method swizzling, selector-ਆਧਾਰਿਤ APIs, ਜਾਂ ਕੁਝ ਪਲੱਗਇਨ-ਸਟਾਈਲ ਆਰਕੀਟੈਕਚਰ)। Swift ਇਨ੍ਹਾ ਨਾਲ ਇੰਟਰਓਪਰੇਟ ਕਰ ਸਕਦਾ ਹੈ, ਪਰ ਕੁਝ ਕ੍ਰਿਪਟਿਕ ਡਾਇਨਾਮਿਕ ਪੈਟਰਨਾਂ ਲਈ ਨਕਲ ਨਹੀਂ, ਬਲਕਿ ਰੀਡਿਜ਼ਾਈਨ ਦੀ ਲੋੜ ਪੈ ਸਕਦੀ ਹੈ।
ਇੱਕ ਅਮਲੀ ਰਣਨੀਤੀ ਹੌਲੀ-ਹੌਲੀ ਮਾਈਗ੍ਰੇਸ਼ਨ ਹੈ:
ਇਸਨੂੰ ਜੋਖਮ ਪ੍ਰਬੰਧਨ ਵਜੋਂ ਲਓ: ਸਮੇਂ ਦੇ ਨਾਲ Shipping ਜਾਰੀ ਰੱਖੋ ਤੇ ਲੰਬੇ ਸਮੇਂ ਦੀ ਸੰਭਾਲ ਘਟਾਉ।
ਆਮ ਗਲਤੀਆਂ ਵਿੱਚ ਸ਼ਾਮਲ ਹਨ:
@objc, NSObject, ਅਤੇ ਭਾਗੀ ਭਾਗੀ ਭਾਸ਼ਾ ਫੀਚਰਾਂ ਦੀ ਲੋੜ)ਮਾਈਗ੍ਰੇਸ਼ਨ ਤੋਂ ਪਹਿਲਾਂ ਸਰਹੱਦ ਯੋਜਨਾ ਬਣਾਓ ਅਤੇ ਟੈਸਟ ਜੋੜੋ।
ਬਿਲਕੁਲ ਨਹੀਂ। ਬਹੁਤ ਸਾਰੇ ਪ੍ਰੋਡਕਸ਼ਨ ਐਪ ਹਾਇਬਰਿਡ ਹਨ:
UIHostingController ਰਾਹੀਂ ਐਮਬੈਡ ਕਰੋ।ਇਸ ਨਾਲ ਟੀਮਾਂ SwiftUI ਨੂੰ ਓਥੇ ਅਪਨਾਉਂਦੀਆਂ ਹਨ ਜਿੱਥੇ ਇਹ ਬੋਅਲਰਪਲੇਟ ਘਟਾਉਂਦਾ ਹੈ, ਅਤੇ ਓਹ成熟 UIKit ਨੈਵੀਗੇਸ਼ਨ ਅਤੇ ਕੰਪੋਨੇਟਾਂ ਨੂੰ ਬਰਕਰਾਰ ਰੱਖ ਸਕਦੀਆਂ ਹਨ।