পাঠ ০২ · ৫৭-এর মধ্যে · মডিউল ১
Home / Courses / Mobile App Development / ফাউন্ডেশন

নেটিভ বনাম ক্রস-প্ল্যাটফর্ম বনাম হাইব্রিড — একটি আর্কিটেকচার ম্যাপ

Native vs cross-platform vs hybrid — an architecture map
৯ মিনিট পড়া শুরু · Beginner Python কোডসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • নেটিভ, ক্রস-প্ল্যাটফর্ম ও হাইব্রিড অ্যাপ্রোচের সংজ্ঞা এবং প্রতিটির আর্কিটেকচার কেমন দেখতে
  • প্রতিটি অ্যাপ্রোচে ভাষা/SDK, পারফরম্যান্স, ডিভাইস API অ্যাক্সেস ও কোডবেস সংখ্যার তুলনা
  • একটি ফিচারের জন্য প্রতিটি অ্যাপ্রোচে বাস্তবে কত কোড শেয়ার হয় তা গাণিতিকভাবে যাচাই করা
  • কেন "সবচেয়ে বেশি কোড শেয়ারিং" মানেই "সেরা পছন্দ" নয়

১ · তিনটি আর্কিটেকচারাল অ্যাপ্রোচ

একটি মোবাইল ফিচার — ধরা যাক, ক্যামেরা দিয়ে প্রোফাইল ছবি তুলে আপলোড করার ফিচার — তৈরি করার সময় প্রথম সিদ্ধান্তই হলো: কোন আর্কিটেকচারাল অ্যাপ্রোচে এটি বানানো হবে। তিনটি প্রধান রাস্তা আছে:

নেটিভপ্রতিটি প্ল্যাটফর্মের নিজস্ব ভাষা ও SDK দিয়ে সম্পূর্ণ আলাদা কোডবেস — iOS-এর জন্য Swift/UIKit/SwiftUI, Android-এর জন্য Kotlin/Jetpack Compose।
প্রতিটি প্ল্যাটফর্মের নিজস্ব ভাষা ও SDK ব্যবহার করে সম্পূর্ণ আলাদা কোডবেস — সর্বোচ্চ পারফরম্যান্স ও সম্পূর্ণ ডিভাইস API অ্যাক্সেস, কিন্তু দুইবার (বা ততোধিক) কাজ।
ক্রস-প্ল্যাটফর্মএকটি শেয়ার্ড কোডবেস (JavaScript/TypeScript বা Dart) যা কম্পাইল বা ব্রিজের মাধ্যমে আসল নেটিভ UI কম্পোনেন্টে রূপান্তরিত হয় — যেমন React Native, Flutter।
একটি শেয়ার্ড কোডবেস যা কম্পাইল/ব্রিজের মাধ্যমে নেটিভ ভিউয়ে রূপান্তরিত হয় — বেশিরভাগ কোড শেয়ার্ড, কিছু ফিচারের জন্য ছোট নেটিভ ব্রিজ মডিউল লাগে।
হাইব্রিডএকটি সাধারণ ওয়েবসাইট (HTML/CSS/JS) একটি নেটিভ "শেল"-এর ভেতরে একটি WebView-তে চালানো হয় — যেমন Cordova/Capacitor-স্টাইল অ্যাপ।
একটি ওয়েব কোডবেস একটি নেটিভ শেলের ভেতরে WebView-তে wrap করা — সবচেয়ে বেশি কোড শেয়ারিং, কিন্তু সবচেয়ে দুর্বল ও সবচেয়ে কম পারফরম্যান্সের ডিভাইস API অ্যাক্সেস।
একটি মোবাইল ফিচার নেটিভ Swift/Kotlin · প্রতি প্ল্যাটফর্মে আলাদা ক্রস-প্ল্যাটফর্ম React Native/Flutter · শেয়ার্ড কোড হাইব্রিড WebView · একক ওয়েব কোডবেস সরাসরি, সম্পূর্ণ ডিভাইস API অ্যাক্সেস bridge/plugin দিয়ে প্রায়-সম্পূর্ণ অ্যাক্সেস WebView plugin API দিয়ে সবচেয়ে সীমিত অ্যাক্সেস
একই ফিচার তিনটি ভিন্ন আর্কিটেকচারাল পথ দিয়ে বাস্তবায়িত হতে পারে — যত ওপরের সারিতে আলাদা কোড, তত নিচের সারিতে বেশি ডিভাইস অ্যাক্সেস।

২ · তুলনা টেবিল

নিচের টেবিলে তিনটি অ্যাপ্রোচের সুপরিচিত, ব্যাপকভাবে-স্বীকৃত বৈশিষ্ট্য তুলে ধরা হয়েছে — এখানে কোনো নির্দিষ্ট ফ্রেমওয়ার্ক API সিনট্যাক্স দাবি করা হয়নি, শুধু আর্কিটেকচারাল বৈশিষ্ট্য।

অ্যাপ্রোচ ভাষা/SDK পারফরম্যান্স ডিভাইস API অ্যাক্সেস কোডবেস সংখ্যা
নেটিভ Swift/UIKit/SwiftUI (iOS), Kotlin/Jetpack Compose (Android) সর্বোচ্চ — প্ল্যাটফর্ম-অপটিমাইজড সরাসরি, সম্পূর্ণ প্রতি প্ল্যাটফর্মে আলাদা (২টি বা বেশি)
ক্রস-প্ল্যাটফর্ম JavaScript/TypeScript (React Native), Dart (Flutter) নেটিভের কাছাকাছি — bridge/compile করা bridge/plugin দিয়ে প্রায়-সম্পূর্ণ একটি শেয়ার্ড + ছোট নেটিভ মডিউল
হাইব্রিড HTML/CSS/JS (WebView-তে wrap করা) সবচেয়ে কম — WebView লেয়ারের ওভারহেড WebView plugin API দিয়ে সীমিত একটি শেয়ার্ড ওয়েব কোডবেস

৩ · একটি ফিচারের প্ল্যাটফর্ম-নির্দিষ্ট কোড খরচ হিসাব

উপরের টেবিলটি স্থির বিবরণ — নিচের কোড সেলে একই তুলনা গণনা করে দেখা যাক। ধরা যাক ফিচারটি হলো "ক্যামেরা দিয়ে প্রোফাইল ছবি আপলোড করা", এবং আমরা iOS ও Android — এই দুটি প্ল্যাটফর্মের জন্য এটি তৈরি করছি। প্রতিটি অ্যাপ্রোচে বাস্তবে কত লাইন প্ল্যাটফর্ম-নির্দিষ্ট কোড লাগে এবং কত শতাংশ কোড শেয়ার্ড থাকে তা হিসাব করা হয়েছে।

Python
# ফিচার: "ক্যামেরা দিয়ে প্রোফাইল ছবি আপলোড" -- তিনটি অ্যাপ্রোচে কোড খরচ হিসাব
# এটি সত্যিকারের Python হিসাব -- হার্ডকোড করা আউটপুট নয়

PLATFORMS = ["iOS", "Android"]

def native_cost(platforms, per_platform_lines):
    # প্রতিটি প্ল্যাটফর্মের জন্য সম্পূর্ণ আলাদা ইমপ্লিমেন্টেশন -- ০% শেয়ার্ড
    breakdown = {p: per_platform_lines for p in platforms}
    total = sum(breakdown.values())
    shared_pct = 0.0
    codebases = len(platforms)  # প্রতিটি প্ল্যাটফর্মে আলাদা কোডবেস বজায় রাখতে হয়
    return breakdown, total, shared_pct, codebases

def cross_platform_cost(platforms, shared_lines, bridge_lines_per_platform):
    # শেয়ার্ড কোড + প্রতি প্ল্যাটফর্মে ছোট নেটিভ ব্রিজ মডিউল (যেমন ক্যামেরা অ্যাক্সেস)
    breakdown = {p: bridge_lines_per_platform for p in platforms}
    total = shared_lines + sum(breakdown.values())
    shared_pct = round(shared_lines / total * 100, 1)
    codebases = 1
    return breakdown, total, shared_pct, codebases

def hybrid_cost(platforms, shared_web_lines):
    # কোনো নেটিভ কোড লাগে না -- একটিই ওয়েব কোডবেস দুই প্ল্যাটফর্মেই WebView-তে চলে
    breakdown = {p: 0 for p in platforms}
    total = shared_web_lines
    shared_pct = 100.0
    codebases = 1
    return breakdown, total, shared_pct, codebases

native_b, native_t, native_s, native_c = native_cost(PLATFORMS, 220)
cross_b, cross_t, cross_s, cross_c = cross_platform_cost(PLATFORMS, 300, 40)
hybrid_b, hybrid_t, hybrid_s, hybrid_c = hybrid_cost(PLATFORMS, 260)

rows = [
    ("নেটিভ",           native_b, native_t, native_s, native_c),
    ("ক্রস-প্ল্যাটফর্ম", cross_b, cross_t, cross_s, cross_c),
    ("হাইব্রিড",         hybrid_b, hybrid_t, hybrid_s, hybrid_c),
]

print(f"{'অ্যাপ্রোচ':16s} | {'iOS লাইন':9s} | {'Android লাইন':13s} | {'মোট লাইন':9s} | শেয়ার্ড % | কোডবেস")
for name, breakdown, total, shared_pct, codebases in rows:
    print(f"{name:16s} | {breakdown['iOS']:9d} | {breakdown['Android']:13d} | {total:9d} | {shared_pct:8.1f}% | {codebases}")

ranked = sorted(rows, key=lambda r: r[3], reverse=True)
print("\nশেয়ার্ড % অনুযায়ী ক্রম (সর্বোচ্চ প্রথমে):")
for name, breakdown, total, shared_pct, codebases in ranked:
    print(f"  {name}: {shared_pct:.1f}% শেয়ার্ড, {codebases}টি কোডবেস বজায় রাখতে হয়")

    
হিসাব করে দেখুন: নেটিভে 440 লাইন মোট (২২০+২২০), 0% শেয়ার্ড, 2টি কোডবেস। ক্রস-প্ল্যাটফর্মে 380 লাইন মোট (৩০০ শেয়ার্ড + ৪০+৪০ ব্রিজ), ৭৮.৯% শেয়ার্ড, 1টি কোডবেস। হাইব্রিডে 260 লাইন মোট, 100% শেয়ার্ড, 1টি কোডবেস — কিন্তু মনে রাখবেন, এই হিসাবে "ডিভাইস অ্যাক্সেসের গভীরতা" ধরা হয়নি, শুধু কোড-শেয়ারিং।
মূল কথা · Key takeaway

হাইব্রিড অ্যাপ্রোচে কোড শেয়ারিং সবচেয়ে বেশি হলেও এটি স্বয়ংক্রিয়ভাবে "সেরা" পছন্দ নয় — কারণ কোড শেয়ারিং শুধু একটি মাত্রা; ডিভাইস API অ্যাক্সেসের গভীরতা ও পারফরম্যান্স আরেকটি মাত্রা, যেখানে হাইব্রিড সবচেয়ে দুর্বল। সঠিক অ্যাপ্রোচ বেছে নেওয়া মানে এই ট্রেড-অফগুলো প্রকল্পের নির্দিষ্ট চাহিদার সাথে মিলিয়ে দেখা — পরবর্তী পাঠে (L03) আমরা PWA-কে চতুর্থ অপশন হিসেবে যোগ করে এই তুলনাকে আরও বিস্তৃত করব।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ ক্রস-প্ল্যাটফর্ম অ্যাপ্রোচে ছোট নেটিভ ব্রিজ মডিউল কেন লাগে — সম্পূর্ণ ০ নেটিভ কোড কেন সম্ভব নয়?

ক্যামেরা, GPS, বায়োমেট্রিক সেন্সরের মতো কিছু ফিচারের জন্য মাঝে মাঝে এমন প্ল্যাটফর্ম API দরকার হয় যা ক্রস-প্ল্যাটফর্ম ফ্রেমওয়ার্ক নিজে থেকে কভার করে না, বা করলেও প্ল্যাটফর্ম-নির্দিষ্ট আচরণ ঠিক করতে ছোট নেটিভ মডিউল লেখা লাগে। এ কারণেই কোড সেলে cross_platform_cost-এ bridge_lines_per_platform সম্পূর্ণ ০ না রেখে একটি ছোট ধনাত্মক সংখ্যা রাখা হয়েছে।

প্র ০২ হাইব্রিড অ্যাপ্রোচে কোড শেয়ারিং আমাদের হিসাবে ১০০% — তাহলে এটি কেন সবসময় সেরা পছন্দ নয়?

কারণ কোড শেয়ারিং শুধু একটি মাত্রা। হাইব্রিড অ্যাপ WebView-এর ভেতর দিয়ে চলে বলে ডিভাইস API অ্যাক্সেস সবচেয়ে সীমিত এবং পারফরম্যান্স সবচেয়ে কম — একটি অ্যাপের কোন মাত্রাটি বেশি গুরুত্বপূর্ণ তার ওপর নির্ভর করে সিদ্ধান্ত নিতে হয়, শুধু কোড-শেয়ারিং সংখ্যা দেখে নয়।

প্র ০৩ কোড সেলে native_cost-এ shared_pct সরাসরি 0.0 লেখা, কিন্তু বাকি দুটোতে ভাগ করে হিসাব করা হয়েছে — কেন?

নেটিভ অ্যাপ্রোচের সংজ্ঞা অনুযায়ীই প্রতিটি প্ল্যাটফর্মের কোড সম্পূর্ণ আলাদা — তাই গাণিতিকভাবে শেয়ারিং সবসময় ঠিক ০, এটি ইনপুটের ওপর নির্ভর করে না। কিন্তু ক্রস-প্ল্যাটফর্ম ও হাইব্রিডে শেয়ার্ড লাইনের সংখ্যা পরিবর্তিত হতে পারে, তাই shared_lines / total দিয়ে সত্যিকারের হিসাব করা হয়েছে।

অনুশীলন

  1. চিন্তা করুন: মনে করুন আপনার টিমের সবার JavaScript/React অভিজ্ঞতা আছে, কিন্তু কারো Swift বা Kotlin অভিজ্ঞতা নেই। কোন অ্যাপ্রোচ প্রাথমিকভাবে বেশি ব্যবহারিক মনে হয়, এবং কেন?

    ক্রস-প্ল্যাটফর্ম (বিশেষত React Native) বেশি ব্যবহারিক মনে হয়, কারণ এটি টিমের বিদ্যমান JavaScript দক্ষতা পুনরায় ব্যবহার করতে দেয়। নেটিভ অ্যাপ্রোচে টিমকে দুটি সম্পূর্ণ নতুন ভাষা (Swift ও Kotlin) শিখতে হতো এবং দুটি আলাদা কোডবেস বজায় রাখতে হতো — সময় ও খরচ দুটোই বাড়ে।

  2. পরীক্ষা করুন: উপরের কোড সেলে cross_platform_cost(PLATFORMS, 300, 40) কলে bridge_lines_per_platform মান 40 থেকে 100-এ পরিবর্তন করে দেখুন total ও shared_pct কীভাবে বদলায়।

    নতুন breakdown হবে {'iOS': 100, 'Android': 100}, তাই total = 300 + 100 + 100 = 500। shared_pct = round(300 / 500 * 100, 1) = 60.0 — অর্থাৎ প্রতি প্ল্যাটফর্মে বেশি নেটিভ ব্রিজ কোড লাগলে শেয়ার্ড শতাংশ কমে যায়, ঠিক যেমন বাস্তবে জটিল ডিভাইস-ইন্টিগ্রেশন ফিচার বেশি হলে ক্রস-প্ল্যাটফর্ম অ্যাপেও নেটিভ কোডের ভাগ বেড়ে যায়।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

  • কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ অ্যাপ লাইফসাইকেল, মোবাইল UI/UX, MVVM/MVI আর্কিটেকচার, নেটিভ বনাম ক্রস-প্ল্যাটফর্ম, নেভিগেশন, স্টেট ম্যানেজমেন্ট, লোকাল স্টোরেজ, ডিভাইস ফিচার ও ডিপ্লয়মেন্ট — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
  • Full-Stack Web Frameworks কোর্স সহোদর কোর্স MVC/MVVM, স্টেট ম্যানেজমেন্ট, টেস্টিং ও CI/CD-র সাধারণ আর্কিটেকচারাল ভিত্তি সেই কোর্সেই তৈরি হয়েছে — এই কোর্স মোবাইল-নির্দিষ্ট পার্থক্য শেখায়।
  • সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Programming Languages & Compiler Design, Software Engineering & Git, Theory of Computation, Engineering Economics, Full-Stack Web Frameworks ও Mobile App Development — সব এক জায়গায়।
আগের পাঠ
মোবাইল অ্যাপ ডেভেলপমেন্ট কী ও ওয়েব থেকে কীভাবে আলাদা