৩০ জুল, ২০২৫·8 মিনিট
কেন Swift জরুরি: কিভাবে এটি iOS-এ Objective‑C-এর স্থল নিয়েছে
জানুন Apple কেন Swift তৈরি করলো, কিভাবে ধাপে ধাপে এটি iOS-এ Objective‑C প্রতিস্থাপন করল, এবং আজকের টুলিং, হায়ারিং ও কোডবেসে সেই পরিবর্তনগুলোর অর্থ কী।
জানুন Apple কেন Swift তৈরি করলো, কিভাবে ধাপে ধাপে এটি iOS-এ Objective‑C প্রতিস্থাপন করল, এবং আজকের টুলিং, হায়ারিং ও কোডবেসে সেই পরিবর্তনগুলোর অর্থ কী।
Swift কেবল Apple-কে একটি নতুন ভাষা “মনোরঞ্জনের” জন্য তৈরি করতে হলো না। এটি iOS উন্নয়নের বাস্তব কষ্টের জবাব ছিল: ধীর ইটারেশন, অনিচ্ছাকৃতভাবে সহজে লিখে ফেলার মত অননিরাপদ প্যাটার্ন, এবং আধুনিক অ্যাপ জটিলতার সাথে Objective‑C-এর পুরনো ডিজাইনের বেঠিক মিল।
এই পোস্ট একটি ব্যবহারিক প্রশ্নের উত্তর দেয়: Swift কেন আছে, কিভাবে এটি ডিফল্ট হয়ে উঠল, এবং কেন সেই ইতিহাস আজও আপনার কোডবেস ও টিমের সিদ্ধান্তকে প্রভাবিত করে।
আপনি একটি স্পষ্ট, হালকা টাইমলাইন পাবেন—প্রারম্ভিক Swift রিলিজ থেকে স্থিতিশীল, ব্যাপকভাবে গৃহীত টুলচেইন পর্যন্ত—বিনা প্রয়োজনীয় টু্ইটিভালির মধ্যে হারিয়ে না গিয়ে। পথে, আমরা ইতিহাসকে দৈনন্দিন ফলাফলগুলোর সাথে যুক্ত করব: ডেভেলপাররা কিভাবে নিরাপদ কোড লিখে, API গুলো কিভাবে বিবর্তিত হলো, Xcode ওয়ার্কফ্লোতে কী বদলেছে, এবং concurrency ও SwiftUI মতো ফিচার সহ “আধুনিক Swift” বলতে আমরা কী বুঝি।
Objective‑C অনেক সফল অ্যাপে এখনও আছে, বিশেষ করে পুরনো কোডবেস ও কিছু লাইব্রেরিতে। উদ্দেশ্য এখানে ভয় বা ত্বরা নয়—স্পষ্টতা: Swift Objective‑C-কে একরাতে মুছে দিল না; ইন্টারঅপারেবিলিটি ও ইকোসিস্টেম পরিবর্তনের মাধ্যমেই ধীরে ধীরে স্থান দখল করে নিলো।
Objective‑C কয়েক দশক ধরে Apple উন্নয়নের ভিত্তি ছিল। 2008‑এ প্রথম iPhone SDK আসার সময় Objective‑C (ও Cocoa Touch ফ্রেমওয়ার্ক) ছিল অ্যাপ তৈরি করার প্রধান উপায়। যদি আপনি প্রথম বছরগুলিতে iOS অ্যাপ লিখেছিলেন, আপনি মূলত Objective‑C-র মাধ্যমে Apple-দের প্ল্যাটফর্ম কনভেনশন শিখছিলেন।
Objective‑C-এ অনেক ভাল জিনিস ছিল—বিশেষ করে যখন আপনি “Cocoa way”‑তে ঢুকে পড়তেন।
এটি শক্তিশালী ডায়নামিক রানটাইমের ওপর বসে ছিল: মেসেজিং, ইন্ট্রোস্পেকশন, ক্যাটাগরি, এবং মেথড সুইজলিং এমন প্যাটার্নসমূহকে সক্ষম করত যা নমনীয় এবং প্লাগ‑ইন‑ফ্রেন্ডলি মনে হত। ডেলিগেশন, টার্গেট–অ্যাকশন, নোটিফিকেশন, এবং KVC/KVO (key-value coding/observing) মতো Cocoa কনভেনশনগুলো গভীরভাবে ইন্টিগ্রেটেড এবং ভাল ডকুমেন্টেড ছিল।
ততটাই গুরুত্বপূর্ণ, এটি একটি পরিণত ইকোসিস্টেম ছিল। Apple-র ফ্রেমওয়ার্ক, থার্ড‑পার্টি লাইব্রেরি, এবং Stack Overflow তে বছরের পর বছর উত্তরগুলো Objective‑C-কে ধরে রেখেছিল। টুলিং ও API গুলো তার ওপর ভিত্তি করেই তৈরি ছিল, এবং টিমগুলো পূর্বানুমানযোগ্য দক্ষতা সহ ডেভেলপার নিয়োগ করতে পারত।
কষ্টের পয়েন্টগুলো দর্শনিক নয়—সেগুলো ছিল ব্যবহারিক, দৈনন্দিন ঘর্ষণ।
Objective‑C verbose হতে পারত, বিশেষ করে “সহজ” কাজগুলোর জন্য। মেথড সিগনেচার, ব্র্যাকেট, এবং বয়লারপ্লেট কোডকে দীর্ঘ এবং স্ক্যান করা কঠিন করত। অনেক API পয়ন্টার-ভিত্তিক ধারণা উন্মুক্ত করত যা ভুলের সম্ভাবনা বাড়াত, বিশেষত ARC (Automatic Reference Counting) স্ট্যান্ডার্ড হওয়ার আগে।
মেমরি এবং সুরক্ষা বিষয়গুলো একটি চলমান উদ্বেগ ছিল। ARC-সহও, আপনাকে মালিকানা, রেফারেন্স সাইকেল, এবং কীভাবে nullable আচরণে runtime-এ আচমকা ধরা পড়তে পারে তা বুঝতে হত।
C API‑র সাথে ইন্টারফেস করাও সাধারণ ছিল—এবং সবসময় আরামদায়ক নয়। C টাইপ ব্রিজ করা, Core Foundation-এর সাথে কাজ করা, এবং “toll‑free bridging” ম্যানেজ করা মানসিক ওভারহেড বাড়াত যা আধুনিক অ্যাপ কোড লিখার মত লাগত না।
লিগ্যাসি iOS কোডবেসগুলো প্রায়ই Objective‑C-এ নির্ভর করে কারণ সেগুলো স্থিতিশীল, পরীক্ষিত এবং রিরাইট করতে ব্যয়বহুল। অনেক দীর্ঘস্থায়ী অ্যাপে Objective‑C লেয়ার আছে (বা পুরনো ডিপেন্ডেন্সি) যা এখনো কার্যকরভাবে কাজ করছে।
Apple Swift তৈরি করেনি শুধু Objective‑C “ভাঙা” বলার জন্য। Objective‑C বহু বছর ধরে সফল iPhone ও Mac অ্যাপ চালিয়েছে। কিন্তু অ্যাপগুলো বড় হওয়ার সাথে, টিমগুলো বাড়ার সাথে, এবং API বিস্তারের সাথে নির্দিষ্ট Objective‑C ডিফল্টগুলোর খরচ আরও চোখে পড়ার মতো হয়ে উঠল—বিশেষ করে যখন আপনি ইস্যুগুলো মিলিয়ন লাইনের কোডে গুণ করবেন।
একটি বড় লক্ষ্য ছিল সাধারণ ভুলগুলো লেখা কঠিন করে তোলা। Objective‑C‑র নমনীয়তা শক্তিশালী, কিন্তু এটি সমস্যা লুকিয়ে রাখতে পারে runtime‑পর্যন্ত: nil‑এ মেসেজ পাঠানো, id টাইপগুলোর বিভ্রান্তি, বা API‑তে nullability ভুল ম্যানেজ করা। অনেক বিষয় ডিসিপ্লিন, কনভেনশন, ও ভালো রিভিউ দিয়ে ম্যানেজ করা যেত—কিন্তু বড় পরিসরে এগুলো ব্যয়বান ছিল।
Swift গার্ডরেল বেঁধে দেয়: optionals আপনাকে ভাবতে বাধ্য করে “এইটা কি অনুপস্থিত হতে পারে?”, শক্ত টাইপিং আকস্মিক ভুল কমায়, এবং guard, switch এক্সহস্টিভনেস, ও নিরাপদ কালেকশন হ্যান্ডলিং-এর মতো ফিচার অনেক বাগকে কম্পাইল টাইমে ঠেলে দেয়।
Swift দৈনন্দিন কোড লেখার অভিজ্ঞতাকেও আধুনিকাকরণ করল। সংক্ষিপ্ত সিনট্যাক্স, টাইপ ইনফারেন্স, এবং সমৃদ্ধ স্ট্যান্ডার্ড লাইব্রেরি অনেক কাজকে কম বয়লারপ্লেটের সঙ্গে পরিষ্কার করে তোলে।
পারফরম্যান্সে, Swift এমনভাবে ডিজাইন করা হয় যাতে কম্পাইলার আগ্রেসিভ অপ্টিমাইজেশন করতে পারে (বিশেষত value types ও generics নিয়ে)। এর মানে এই নয় যে প্রতিটি Swift অ্যাপ অপরাজেয়ভাবে Objective‑C অ্যাপের চাইতে দ্রুত হবে, কিন্তু এটি Apple‑কে একটি ভাষার মডেল দেয় যা গতির দিকে বিবর্তিত হতে পারে ডায়নামিক রানটাইমে এতটা নির্ভর না করে।
Apple চেয়েছিল iOS উন্নয়ন নতুন ডেভেলপারদের জন্য প্রবেশযোগ্য এবং দীর্ঘস্থায়ী পণ্যগুলোর জন্য টেকসই হোক। Swift-এর API নামকরণ কনভেনশন, কল সাইটে পরিষ্কার উদ্দেশ্য, এবং প্রকাশকর টাইপ‑ব্যবহার “ট্রাইবাল নলেজ” কমাতে ও কোডবেস মাস খানেক পরে পড়তে সহজ করতে সাহায্য করে।
ফলাফল: কম ফুটি‑গান, পরিষ্কার API, এবং এমন একটি ভাষা যা বড় টিমগুলোকে বছর ধরে অ্যাপ রক্ষণা করতে সহায়তা করে—এমন নয় যে Objective‑C কাজ করতে পারে না।
Swift একদিনে “জিতল” না। Apple এটি নতুন কোডের জন্য একটি ভালো বিকল্প হিসেবে উপস্থাপন করল, তারপর বছরখানেক ধরে এটিকে স্থিতিশীল, দ্রুত এবং বিদ্যমান Objective‑C অ্যাপগুলোর সাথে গ্রহণযোগ্য করে তুলল।
ABI স্থিতিশীলতার মানে Swift রানটাইম ও স্ট্যান্ডার্ড লাইব্রেরিগুলো Swift 5 সংস্করণের মধ্যে বাইনারি‑স্তরে সামঞ্জস্যপূর্ণ। Swift 5‑এর আগে, অনেক অ্যাপকে Swift লাইব্রেরি অ্যাপে বাণ্ডল করতে হত, যা অ্যাপ সাইজ বাড়ায় ও ডিস্ট্রিবিউশন জটিল করে। ABI স্থিতিশীলতার ফলে Swift Objective‑C-এর মতই OS আপডেটের মধ্যেও কম্পাইল করা কোডকে নির্ভরযোগ্যভাবে চালাতে পারে, ফলে Swift দীর্ঘস্থায়ী প্রোডাকশন কোডবেসে “নিরাপদ” মনে হতে শুরু করে।
কয়েক বছর ধরে অনেক টিম নতুন ফিচারের জন্য Swift ব্যবহার করত, যখন কোর মডিউল Objective‑C-তে রেখে দিত। এই স্টেপ‑বাই‑স্টেপ পথ—বড় রিরাইট নয়—Swift‑এর উত্থানকে বাস্তব অ্যাপ ও প্রকল্প সময়সীমার সঙ্গে সামঞ্জস্যপূর্ণ করল।
Swift জিতল না সব টিমকে কাজ করে থাকা Objective‑C কোড ফেলে দিয়ে নতুন করে লেখার মাধ্যমে। Apple নিশ্চিত করলো উভয় ভাষাই একই অ্যাপে একসাথে থাকতে পারে। এই সামঞ্জস্যই Swift গ্রহণযোগ্যতা প্রথমদিনেই আটকে যেত না—এর একটি বড় কারণ।
iOS‑এ মিশ্র কোডবেস স্বাভাবিক: আপনি পুরনো নেটওয়ার্কিং, অ্যানালিটিক্স, বা UI কম্পোনেন্ট Objective‑C-তে রেখে নতুন ফিচারগুলো Swift-এ লিখতে পারেন। Xcode এটি সরাসরি সমর্থন করে, তাই “Swift Objective‑C প্রতিস্থাপন করছে” মানে সাধারণত ধাপে ধাপে পরিবর্তন, এক বড় রিরাইট নয়।
ইন্টারঅপারেবিলিটি দুটি পরস্পর পরিপূরক মেকানিজমের মাধ্যমে কাজ করে:
YourModuleName-Swift.h) যা Objective‑C-র জন্য সুবিধাজনক Swift ক্লাস ও মেথড এক্সপোজ করে। সাধারণত @objc অ্যাট্রিবিউট বা NSObject ইনহেরিটেন্স দিয়ে আপনি অপ্ট‑ইন করেন।আপনাকে প্লাম্বিং সব গুলো মুখস্থ করার দরকার নেই—কিন্তু বোঝা যে “এইটা অন্য ভাষার কাছে এক্সপোজ কর” একটি স্পষ্ট ধাপ আছে, তা সাহায্য করে কেন কিছু টাইপ স্বয়ংক্রিয়ভাবে দেখা যায় এবং অন্যগুলো নয়।
বেশিরভাগ টিম কয়েকটি পুনরাবৃত্তি পয়েন্টে আসে:
বাস্তব অ্যাপ দীর্ঘস্থায়ী। ইন্টারঅপারেবিলিটি আপনাকে ফিচার-বাই-ফিচার মাইগ্রেশন করতে দেয়, শিপিং চালিয়ে রাখতে দেয়, এবং ঝুঁকি কমায়—বিশেষত যখন থার্ড‑পার্টি SDK, পুরনো কম্পোনেন্ট, বা সময়সীমা একসাথে বড় রিরাইটকে বাস্তবসম্মত করে না।
Swift কেবল সিনট্যাক্স আধুনিক করেনি—এটি দৈনন্দিন iOS কোডের চেহারা বদলে দিয়েছে। অনেক প্যাটার্ন যা আগে কনভেনশন ও সাবধানে কোড রিভিউতে নির্ভর করত, এখন কম্পাইলার সাহায্য করতে পারে।
Objective‑C ডেভেলপাররা nil-এ মেসেজ পাঠালে কিছুই না ঘটানো সহ্য করতে অভ্যস্ত ছিল। Swift অনুপস্থিতিকে optionals (String?) দিয়ে স্পষ্ট করে, আপনাকে if let, guard, বা ?? দিয়ে আগে হ্যান্ডল করতে বাধ্য করে। এটি সাধারণত একধরনের ক্র্যাশ ও “কেন এটা খালি?” বাগ রোধ করে—এবং এর মানে এই নয় যে ত্রুটি আর হবে না, কিন্তু সম্ভাবনা কমে যায়।
Swift অনেক জায়গায় টাইপ ইনফার করতে পারে, যা বয়লারপ্লেট কমায়:
let title = "Settings" // inferred as String
আরও গুরুত্বপূর্ণভাবে, জেনারিকস আপনাকে পুনঃব্যবহারযোগ্য, টাইপ‑সেফ কোড লিখতে দেয় id ও রানটাইম চেকে ভরসা না করে। “যেকোনো কিছুর অ্যারে” বনাম “ঠিক আমি যা চাই তার অ্যারে”—অপ্রত্যাশিত অবজেক্ট ঢুকতে পারে না এবং ফরস কাস্ট কমে।
Swift‑এর throw/try/catch স্পষ্ট এরর পাথ উৎসাহিত করে, NSError ** দিয়ে ব্যর্থতা অগ্রাহ্য করার বদলে। কালেকশনগুলো শক্তভাবে টাইপকৃত ([User], [String: Int]), এবং স্ট্রিংগুলো Unicode‑correct String যা C স্ট্রিং, NSString, ও ম্যানুয়াল এনকোডিং মিশ্রণের থেকে পরিষ্কার সুবিধা দেয়। সারমর্মে কম অফ‑বাই‑ওয়ান ত্রুটি, কম অবৈধ অনুমান, এবং কম “কোড কম্পাইল হয় কিন্তু রানটাইমে ভেঙে যায়” সমস্যা দেখা যায়।
রানটাইম‑ভিত্তিক প্যাটার্নগুলোর জন্য Objective‑C রানটাইম এখনো মূল্যবান: মেথড সুইজলিং, ডায়নামিক মেসেজ ফরওয়ার্ডিং, নির্দিষ্ট dependency injection কৌশল, KVC/KVO‑চালিত কোড, এবং পুরনো প্লাগইন‑স্টাইল আর্কিটেকচার। Swift এগুলোকে ইন্টারঅপারেট করতে পারে, কিন্তু যখন সত্যি রানটাইম ডায়নামিজম দরকার, Objective‑C এখনো বক্সে একটি ব্যবহারিক টুল।
Swift কেবল সিনট্যাক্স বদলে দেয়নি—এটি iOS ইকোসিস্টেমকে টুলিং ও কনভেনশনে আধুনিক করতে বাধ্য করেছে। এই ট্রানজিশন সবসময় মসৃণ ছিল না: প্রারম্ভিক Swift রিলিজগুলো প্রায়ই বিল্ড ধীর করে, অটোকমপ্লিট দুর্বল ছিল, এবং রিফ্যাক্টরিং ঝুঁকিপূর্ণ মনে হত। সময়ের সাথে ডেভেলপার এক্সপেরিয়েন্স Swift‑এর সবচেয়ে বড় সুবিধাগুলোর এক হয়ে উঠল।
Xcode‑এর Swift সাপোর্ট ব্যবহারিক, দৈনন্দিনভাবে উন্নতি করেছে:
আপনি যদি Swift 1.x/2.x কালে Swift ব্যবহার করে থাকেন, সম্ভবত মনে আছে কতটা কটু ছিল। এখন ট্রেন্ড ধারাবাহিক: ইন্ডেক্সিং উন্নত, সোর্স স্থিতিশীলতা উন্নত, এবং "Xcode বিভ্রান্ত" মুহূর্ত কম।
Swift Package Manager (SPM) অনেক টিমে বাইরের ডিপেন্ডেন্সি সিস্টেমের প্রয়োজন কমিয়েছে। মূলত, আপনি প্যাকেজ ও ভার্সন ডিক্লেয়ার করেন, Xcode সেগুলো রেজলভ করে, এবং বিল্ডে ইন্টিগ্রেট করে—অতিরিক্ত প্রজেক্ট ফাইল জটিলতা ছাড়াই। সব সেটআপে এটা নিখুঁত নয়, কিন্তু অনেক অ্যাপের জন্য অনবোর্ডিং সহজ ও ডিপেন্ডেন্সি আপডেট পূর্বানুমানযোগ্য করেছে।
Apple‑এর API ডিজাইন গাইডলাইন ফ্রেমওয়ার্কগুলিকে পরিষ্কার নামকরণ, ভাল ডিফল্ট আচরণ, এবং ইচ্ছা প্রকাশকারী টাইপের দিকে ঠেলে দিয়েছে। ঐ প্রভাব বাইরে ছড়িয়ে পড়ল: থার্ড‑পার্টি লাইব্রেরিগুলোও ক্রমশ Swift‑ফার্স্ট API গ্রহণ করেছে, ফলে আধুনিক iOS কোডবেসগুলো আরও সামঞ্জস্যপূর্ণ হয়ে উঠেছে—এমনকি সেগুলো Objective‑C‑এর ওপর ব্রিজ করেও থাকলে।
UIKit এখনো আছে। বেশীরভাগ প্রোডাকশন iOS অ্যাপ এখনো এটিই ব্যবহার করে, বিশেষ করে জটিল নেভিগেশন, সূক্ষ্ম জেসচার, উন্নত টেক্সট হ্যান্ডলিং, এবং দীর্ঘ‑তালিকার UI কম্পোনেন্টের জন্য যেগুলো টিমরা বছর ধরেই পরীক্ষা করে এসেছে। যা বদলে গেছে তা হল মানুষ এখন UIKit কোড লিখলেও সাধারণত Swift‑এ লেখে—অর্থাৎ নিচের ফ্রেমওয়ার্ক একই থাকলেও লেখার ভাষা বদলে গেছে।
বহু টিমের জন্য “UIKit অ্যাপ” আর Objective‑C নির্দেশ করে না। স্টোরিবোর্ড, nib, এবং প্রোগ্রাম্যাটিক ভিউগুলো রুটিনভাবে Swift ভিউ কন্ট্রোলার ও Swift মডেল দ্বারা চালিত হয়।
এই শিফটটি গুরুত্বপূর্ণ কারণ Apple ক্রমশে নতুন API‑গুলো Swift এর অনুকূল করে ডিজাইন করছে (পরিষ্কার নামকরণ, optionals, generics, result টাইপ)। এমনকি যখন কোনও API Objective‑C‑র জন্যও আছে, Swift overlay প্রায়ই “ইচ্ছাকৃত” সারফেস বলে অনুভূত হয়, যা নতুন ডেভেলপারদের UIKit কোডবেসে দ্রুত প্রোডাকটিভ করে তোলে।
SwiftUI কেবল বাটন ড্র করার নতুন উপায় ছিল না। এটি একটি ভিন্ন মানসিক মডেল ঠেলে দিল:
বাস্তবে, এটি অ্যাপ আর্কিটেকচার আলোচনায় বদল এনেছে। SwiftUI গ্রহণ করা টিমগুলো প্রায়ই আরো গুরুত্ব দেয় ইউনিডাইরেকশনাল ডেটা ফ্লো, ছোট ভিউ কম্পোনেন্ট, এবং ভিউ কোড থেকে সাইড‑ইফেক্ট (নেটওয়ার্কিং, পার্সিস্টেন্স) আলাদা করার উপর। যদিও আপনি সম্পূর্ণরূপে না গেলেও, SwiftUI ফর্ম, লিস্ট, এবং স্টেট‑ড্রিভেন লেআউটের জন্য বয়লারপ্লেট কমাতে সহায়ক।
শিপ করা অ্যাপগুলো প্রায়ই উভয় ফ্রেমওয়ার্ক মিশিয়ে ব্যবহার করে:
UIHostingController দিয়ে SwiftUI এমবেড করা।এই হাইব্রিড কৌশল টিমকে বিস্তৃত UIKit অবকাঠামো—নেভিগেশন স্ট্যাক, কোঅর্ডিনেটর, বিদ্যমান ডিজাইন সিস্টেম—রাখতে দেয়, আবার SwiftUI যেখানে সুবিধা দেয় সেখানে ধাপে ধাপে গ্রহণ করতে দেয়। ঝুঁকি নিয়ন্ত্রণও এমনই হয়: আপনি সীমাবদ্ধ এলাকায় SwiftUI পাইলট করে দেখতে পারেন পুরো UI রিরাইট না করে।
আজ যদি আপনি নতুন শুরু করেন, Apple‑এর সর্বশেষ UI গল্প হলো SwiftUI, এবং অনেক সংলগ্ন প্রযুক্তি (widgets, Live Activities, কিছু app extension) Swift-ওরিয়েন্টেড। UI ছাড়াও, Apple প্ল্যাটফর্মজুড়ে Swift-ফ্রেন্ডলি API‑গুলো ডিফল্ট শেপ করে: নতুন প্রজেক্টগুলো সাধারণত Swift-এ পরিকল্পিত হয়, এবং সিদ্ধান্ত হয় “আমরা কতটা UIKit লাগবে?” নয় “Objective‑C ব্যবহার করব কি?”
ফলাফল: এটি কেবল একটি ফ্রেমওয়ার্কের বদলে আরেকটির প্রতিস্থাপন নয়—Swift দুটোরই সাধারণ ভাষা হয়ে উঠেছে: পুরনো‑বান্ধব পথ (UIKit) ও নতুন, Swift‑নেটিভ পথ (SwiftUI) উভয়ের ওপর।
Concurrency হল কিভাবে একটি অ্যাপ একসঙ্গে একাধিক কাজ করে—ডেটা লোড করা, JSON ডিকোড করা, ও স্ক্রিন আপডেট করা—ইন্টারফেস আটকে না করে। Swift-এর আধুনিক পন্থা এটিকে সাধারণ কোডের মত অনুভব করাতে ডিজাইন করা হয়েছে, থ্রেড জাগলিং-এর চাইতে কম কষ্টসাধ্য।
async/await দিয়ে আপনি অ্যাসিনক্রোনাস কাজ (যেমন নেটওয়ার্ক রিকোয়েস্ট) টপ‑টু‑বটম স্টাইলে লিখতে পারেন:
async এমন ফাংশন চিহ্নিত করে যা অপেক্ষা করতে পারে।await হল “ফলাফল আসা পর্যন্ত এখানে থেমে যাও” পয়েন্ট।গভীর নেস্টেড completion হ্যান্ডলারগুলোর বদলে আপনি এটাকে একটি রেসিপির মত পড়েন: ডেটা ফেচ করুন, পার্স করুন, তারপর স্টেট আপডেট করুন।
Swift async/await‑এর সাথে structured concurrency দেয়, যার সারমর্ম: “ব্যাকগ্রাউন্ড কাজের একটি স্পষ্ট মালিক ও লাইফটাইম থাকা উচিত।” টাস্কগুলো একটি স্কোপে তৈরি হয়, এবং চাইল্ড টাস্কগুলো তাদের পেরেন্টের সাথে যুক্ত থাকে।
এটি গুরুত্বপূর্ণ কারণ এটি উন্নত করে:
দুই ধারণা একসঙ্গে “একচেটিয়া” ক্র্যাশগুলো কমাতে সাহায্য করে:
বেশিরভাগ টিম হঠাৎ করে সব কিছু পরিবর্তন করে না। পুরনো প্যাটার্ন—OperationQueue, GCD, delegate callbacks, এবং completion handlers—এর সাথে আধুনিক Swift concurrency মিশ্রিত হওয়া সাধারণ, বিশেষত যখন লিগ্যাসি লাইব্রেরি বা পুরনো UIKit ফ্লো আছে।
একটি বাস্তব iOS অ্যাপ মাইগ্রেট করা মানে “সব কিছুকে কনভার্ট করা” নয়—এটি একটি ঝুঁকি‑ব্যবস্থাপনা প্রকল্প। লক্ষ্য হল শিপিং রাখতে হয় আর একই সাথে Objective‑C রক্ষণাবেক্ষণের পরিমাণ ধীরে ধীরে কমানো।
একটি সাধারণ অ্যাপ্রোচ হলো ইনক্রিমেন্টাল মাইগ্রেশন:
এটি আপনাকে আত্মবিশ্বাস বাড়াতে দেয় এবং বিস্ফোরণ‑রেডিয়াস কম রাখে—বিশেষত যখন সময়সীমা ভাষা পরিবর্তনের জন্য অপেক্ষা করে না।
কয়েকটি Objective‑C প্যাটার্ন সরাসরি অনুবাদযোগ্য নয়:
objc_runtime‑ভিত্তিক কোডকে অনুবাদ না করে রিডিজাইন করতে হতে পারে।মাইগ্রেশনকে একটি ইমপ্লিমেন্টেশন বদল হিসেবে বিবেচনা করুন, ফিচার বদল হিসেবে নয়। প্রথমে ক্রিটিক্যাল ফ্লো (নেটওয়ার্কিং, ক্যাশিং, পেমেন্ট, auth) চারপাশে characterization tests যোগ করুন, তারপর পোর্ট করুন। UI‑রেজিস্টার পরিবর্তন ধরার জন্য snapshot tests সাহায্য করে।
টিমের জন্য অনুসরণীয় একটি হালকা মানদণ্ড তৈরি করুন: কোডিং কনভেনশন, linting (SwiftLint ইত্যাদি), মডিউল বাউন্ডারি, ব্রিজিং হেডার নিয়ম, এবং “নতুন Objective‑C লিখবেন না যদি যুক্তি না থাকে।” লিখে রাখলে কোডবেস ধাপে ধাপে অসঙ্গত হয়ে যাওয়া রোধ হয়।
Swift কেবল সিনট্যাক্স বদলায়নি—এটি iOS টিমে “স্বাভাবিক” কী তা বদলে দিয়েছে। আপনার প্রোডাক্ট যদি এখনও Objective‑C ধরে রাখে, তবুও দৈনন্দিন সিদ্ধান্তগুলো (লোক, প্রক্রিয়া, দীর্ঘমেয়াদি রক্ষণাবেক্ষণ) এখন Swift‑ফার্স্ট প্রত্যাশায় গড়ে উঠেছে।
অধিকাংশ নতুন iOS রোল Swift‑কে ডিফল্ট ধরে। প্রার্থীরা হয়ত পেশাদারভাবে Objective‑C কখনো শিপ করেনি, এবং মিশ্র কোডবেসে র্যাম্প‑আপ টাইম বাড়ে।
বাস্তব পরামর্শ: Objective‑C জ্ঞানকে “প্লাস” হিসেবে দেখুন, দরজা আটকে রাখবেন না; এবং অনবোর্ডিং মেটারিয়ালগুলোতে স্পষ্টভাবে দেখান কোথায় Objective‑C আছে এবং কেন আছে। একটি ছোট অভ্যন্তরীণ গাইড (bridging headers, ফাইল মালিকানা, “context ছাড়া স্পর্শ করবেন না” এলাকা) প্রথম দফায় ভুল আটকাতে সাহায্য করে।
Swift‑এর শক্ত টাইপিং ও স্পষ্ট optionals রিভিউ দ্রুত করতে পারে: রিভিউয়াররা কম সময় ব্যয় করেন অনুমান ভেবে যে একটি মান কি থাকতে পারে, এবং বেশি সময় ব্যয় করেন উদ্দেশ্য যাচাই করতে। প্রটোকল, জেনেরিকস, ও value types‑এর মতো প্যাটার্নগুলোও আরও ধারাবাহিক আর্কিটেকচার প্ররোচিত করে—যদি সংযম সহ ব্যবহৃত হয়।
ফ্লিপ সাইডে স্টাইল ড্রিফট একটি সমস্যা হতে পারে। টিমগুলো একটি শেয়ার্ড Swift স্টাইল গাইড ও স্বয়ংক্রিয় ফরম্যাটিং/লিন্টিং থেকে উপকৃত হয় যাতে রিভিউগুলো আচরণ নিয়ে হয়, না স্থানচিহ্ন নিয়ে। (আপনি যদি ইতিমধ্যে গাইডলাইন রাখেন, সেগুলো আপনার অভ্যন্তরীণ ডক হাবে লিংক করুন)।
আধুনিক API‑গুলোর ওপর আপনি সরাসরি নির্ভর করতে পারলে রক্ষণাবেক্ষণ সহজ হয়—পুরনো প্যাটার্নের উপরে কাস্টম র্যাপার বহন না করেই। কিন্তু Objective‑C এক ঝটকায় হারিয়ে যাবে না—বিশেষত প্রোডাক্ট‑বহু বছর ধরে স্থিতিশীল মডিউল সম্বলিত অ্যাপগুলোর ক্ষেত্রে।
মিশ্র কোডবেসের জন্য বাস্তবসম্মত বাজেট করুন: বিজনেস মাইলস্টোনের চারপাশে মাইগ্রেশন পরিকল্পনা করুন, অনন্ত “ক্লিনআপ” হিসেবে নয়। “ডান” কী তা সংজ্ঞায়িত করুন (উদাহরণ: সব নতুন কোড Swift‑এ, লিগ্যাসি মডিউলকে সুযোগ বুঝে স্পর্শ করা), এবং বড় রিফ্যাক্টরের সময় এই নিয়ম পুনর্বিবেচনা করুন।
নির্ধারণ নীতির জন্য, দেখুন /blog/migrating-objective-c-to-swift।
Swift বনাম Objective‑C বেছে নেওয়া সাধারণত দর্শনীয় বিতর্ক নয়—এটা খরচ, ঝুঁকি, এবং সময়রেখার প্রশ্ন। ভালো খবর: আপনাকে বছরের শেষে “সব বা কিছুই” বেছে নিতে হয় না। বেশিরভাগ টিম ইন-প্লেস উন্নতিকে অবলম্বন করে সেরা ফল পায়।
আপনি যদি নতুন শুরু করেন, Swift হওয়া উচিত আপনার ডিফল্ট। এটি Apple‑এর নতুন API‑গুলোর সাথে সামঞ্জস্যপূর্ণ, নিরাপদ ফিচার আছে, এবং async/await‑এর মতো আধুনিক প্যাটার্ন সহজ করে তোলে।
আপনার প্রথম সিদ্ধান্ত হবে UI কৌশল: SwiftUI, UIKit (Swift-এ), বা মিশ্র। যদি অনিশ্চিত হন, তুলনা দেখুন /blog/swiftui-vs-uikit।
একটি বিদ্যমান Objective‑C অ্যাপের জন্য, স্থিতিশীল, টেস্টকৃত মডিউলগুলো Objective‑C তেই রাখুন এবং Swift যোগ করুন যেখানে তাড়াতাড়ি লাভ পাবেন:
একটি ব্যবহারিক নিয়ম: যখন আপনি স্পষ্ট বাউন্ডারি (API সারফেস, মালিকানা, টেস্ট) নির্ধারণ করতে পারেন তখন একটি নতুন Swift মডিউল শুরু করুন। যখন কোড পরিণত এবং গভীরভাবে জড়িত থাকে তখন সেটাকে সুযোগ বুঝে স্পর্শ করুন।
পরিকল্পনার জন্য, দেখুন /blog/ios-migration-checklist।
বাক্তিগত ও টিম লেভেলে এই সিকোয়েন্সটি বাস্তবে ভাল মানায়:
iOS আধুনিকীকরণ প্রায়শই এমন অলঙ্কৃত কাজ উত্থাপন করে যা একই ইঞ্জিনিয়ারিং সময়ের জন্য প্রতিযোগিতা করে: অ্যাডমিন ড্যাশবোর্ড, অভ্যন্তরীণ টুল, ব্যাকএন্ড সার্ভিস যেগুলো iOS অ্যাপের ওপর নির্ভর করে। যদি আপনি চান আপনার iOS টিম Swift মাইগ্রেশনে মনোনিবেশ করে রেখে সামর্থ্য বজায় রাখবেন, Koder.ai আপনাকে চ্যাট-ড্রিভেন ওয়ার্কফ্লো দিয়ে ওয়েব অ্যাপ, Go ব্যাকএন্ড (PostgreSQL সহ), বা Flutter কম্পেনিয়ন অ্যাপ দ্রুত ঘুরিয়ে তুলতে সাহায্য করতে পারে—তারপর আপনি সোর্স কোড এক্সপোর্ট, ডেপ্লয়, এবং স্ন্যাপশট/রোলব্যাক ব্যবহার করে iteration নিরাপদে ম্যানেজ করতে পারবেন।
যদি আপনি চান বাইরে থেকে সাহায্য নিয়ে সবচেয়ে নিরাপদ পরবর্তী ধাপ (নতুন মডিউল, আংশিক মাইগ্রেশন, না স্পর্শ করা) স্কোপ করতে—দেখুন /pricing।
Swift তৈরি করা হয়েছিল সাধারণ iOS উন্নয়নের ঝুঁকি কমানোর জন্য (যেমন অননুমিত nil আচরণ ও ঢিলা টাইপিং), বড় কোডবেসে পাঠযোগ্যতা/রক্ষণযোগ্যতা বাড়াতে এবং সময়ের সাথে শক্তিশালী কম্পাইলার অপ্টিমাইজেশনের সুযোগ দিতে। এটা Objective‑C কে “খারাপ” বলার জন্য ছিল না—বরং নিরাপদ, আধুনিক ডিফল্টগুলো বড় পরিধিতে সহজে ব্যবহার করার উপায় তৈরি করার চেষ্টা।
Swift ধীরে ধীরে ডিফল্ট ভাষা হয়ে উঠেছে কয়েকটি কারণে:
এই সব মিলেই অধিকাংশ টিমের জন্য “নতুন কোড Swift-এ” লেখা সবচেয়ে কম বাধ্যতামূলক পথ হয়ে ওঠে।
Swift 5 Apple প্ল্যাটফর্মগুলিতে ABI স্থিতিশীলতা এনেছে, যার মানে কম্পাইল করা Swift কোড Swift 5.x রUNTIME সংস্করণগুলোর মধ্যে বাইনারি‑সামঞ্জস্য বজায় রাখতে পারে। বাস্তবে, এর ফলে অ্যাপগুলোতে Swift লাইব্রেরি বাণ্ডল করার প্রয়োজন কমল, অ্যাপ সাইজ এবং ডিপ্লয়মেন্ট নির্ভরযোগ্যতা উন্নত হল, এবং Swift দীর্ঘমেয়াদি প্রোডাকশন কোডবেস হিসেবে বেশি নিরাপদ মনে হলো।
একটি একই অ্যাপে উভয় ভাষা মিশিয়ে কাজ করা যায়:
YourModuleName-Swift.h) তৈরি করে যা Objective‑C-সামঞ্জস্যপূর্ণ Swift APIগুলো এক্সপোজ করে; সাধারণত @objc বা NSObject ইনহেরিট করে এসব ক্লাসকে näky করানো হয়।Optionals (T?) “অনুপস্থিত মান”কে স্পষ্ট করে এবং কম্পাইল টাইমে হ্যান্ডলিং বাধ্য করে (যেমন if let, guard, ??)। Objective‑C-তে nil-এ মেসেজ পাঠালে তা নীরবে কিছুই করে না এবং অনিশ্চিত নাল‑অ্যাবিলিটি রানটাইমে বাগ লুকিয়ে রাখতে পারে। ব্যবহারিক জেতা: কম ক্র্যাশ এবং কম “এই মানটা অনপেক্ষিতভাবে খালি ছিল” ধাঁচের লজিক ত্রুটি।
Swift-এ generics ও শক্ত টাইপিং কাস্টিং ও রানটাইম টাইপ চেক কমায় (যা Objective‑C-তে id এবং অ-টাইপেড কনটেইনারে কমন ছিল)। বাস্তবে আপনি পান:
[User] মতো নিরাপদ কলেকশন, “যাই খুশি” অ্যারে নয়হ্যাঁ—যখন আপনি সত্যিই রানটাইম ডায়নামিজমের প্রয়োজন অনুভব করেন তখন Objective‑C এখনো ভাল পছন্দ হতে পারে (যেমন ব্যাপক KVC/KVO ব্যবহার, মেথড সুইজলিং, সিলেক্টর-ভিত্তিক API, বা কিছু প্লাগইন‑স্টাইল আর্কিটেকচার)। Swift এগুলোকে ইন্টারঅপারেট করতে পারে, তবে সম্পূর্ণ Swift‑রূপান্তর প্রয়োজন হলে অনেক সময় রিডিজাইন দরকার হয়।
একটি বাস্তব উপায় হলো ধাপে ধাপে মাইগ্রেশন:
এটিকে ঝুঁকি ব্যবস্থাপনা হিসেবে বিবেচনা করুন: শিপিং বজায় রেখে দীর্ঘমেয়াদি রক্ষণযোগ্যতা কমান।
সাধারণ পিটফলগুলো হলো:
@objc, NSObject প্রয়োজন হতে পারে এবং কিছু ভাষা ফিচার সীমাবদ্ধ থাকবেঅ্যাপ্লিকেশন পরিবর্তনের আগে সীমানা পরিকল্পনা করুন এবং ব্যাবহারিক টেস্ট যোগ করুন।
একদম না। অনেক প্রোডাকশন অ্যাপই হাইব্রিড:
UIHostingController ব্যবহার করুন।এটি টিমকে SwiftUI যেখানে বেনিফিট দেয় সেখানে নেওয়ার সুযোগ দেয়, একেবারে সবকিছু রিরাইট না করে।
প্রতিটি Swift ফিচার Objective‑C‑তে দৃশ্যমান নাও হতে পারে, তাই সীমানা সচেতনভাবে পরিকল্পনা করা উচিত।