30 thg 7, 2025·8 phút
Tại sao Swift ra đời: Cách nó thay thế Objective‑C trong iOS
Tìm hiểu vì sao Apple tạo Swift, cách nó dần thay thế Objective‑C trong app iOS, và ý nghĩa của chuyển dịch này cho tooling, tuyển dụng và codebase ngày nay.
Tìm hiểu vì sao Apple tạo Swift, cách nó dần thay thế Objective‑C trong app iOS, và ý nghĩa của chuyển dịch này cho tooling, tuyển dụng và codebase ngày nay.
Swift không xuất hiện chỉ vì Apple muốn một ngôn ngữ mới "vì vui." Nó là phản ứng trước những điểm đau thực tế trong phát triển iOS: vòng lặp chậm, các mẫu không an toàn dễ viết nhầm, và sự lệch ngày càng lớn giữa độ phức tạp ứng dụng hiện đại và thiết kế cũ của Objective‑C.
Bài này trả lời câu hỏi thực tế: tại sao Swift tồn tại, nó đã trở thành mặc định như thế nào, và lịch sử đó vẫn ảnh hưởng ra sao tới codebase và quyết định đội ngũ ngày nay.
Bạn sẽ có một timeline rõ ràng và ngắn gọn — từ các bản Swift đầu tiên đến một toolchain ổn định, được dùng rộng — mà không bị lạc trong các chi tiết tầm thường. Trên đường đi, chúng ta sẽ liên hệ lịch sử đó với hậu quả hàng ngày: cách dev viết mã an toàn hơn, cách API tiến hóa, điều gì thay đổi trong workflow Xcode, và "Swift hiện đại" nghĩa là gì với các tính năng như concurrency và SwiftUI.
Objective‑C vẫn hiện diện trong nhiều app thành công, đặc biệt là các codebase cũ và một số thư viện. Mục tiêu ở đây không phải kích động lo lắng — mà là làm rõ: Swift không xóa Objective‑C trong một đêm; nó dần chiếm ưu thế thông qua khả năng tương tác và chuyển dịch hệ sinh thái.
Objective‑C là nền tảng phát triển Apple trong nhiều thập kỷ. Khi SDK iPhone đầu tiên xuất hiện năm 2008, Objective‑C (cùng Cocoa Touch) là cách chính để xây app, như trước đó là Cocoa cho Mac OS X. Nếu bạn viết iOS app thời đầu, bạn thực ra học các quy ước nền tảng Apple qua Objective‑C.
Objective‑C có nhiều lợi thế — đặc biệt khi bạn theo phong cách "Cocoa way" để xây phần mềm.
Nó chạy trên runtime động mạnh: messaging, introspection, categories, và method swizzling cho phép các pattern linh hoạt và dễ cắm ghép. Các quy ước Cocoa như delegation, target–action, notifications, và KVC/KVO được tích hợp sâu và có tài liệu tốt.
Cũng quan trọng không kém là hệ sinh thái trưởng thành. Framework của Apple, thư viện bên thứ ba và vô số câu trả lời trên Stack Overflow đều giả định Objective‑C. Tooling và API được xây quanh nó, và đội ngũ có thể tuyển dev với kỹ năng dễ dự đoán.
Những điểm đau không phải triết lý — mà là ma sát hàng ngày.
Objective‑C có thể dài dòng, đặc biệt cho các việc "đơn giản". Chữ ký phương thức, ngoặc, và boilerplate làm code dài hơn và khó quét hơn. Nhiều API phơi bày các khái niệm nặng con trỏ làm tăng khả năng sai sót, đặc biệt trước khi ARC (Automatic Reference Counting) trở nên phổ biến.
Bộ nhớ và vấn đề an toàn luôn là mối quan tâm. Ngay cả với ARC, bạn vẫn cần hiểu ownership, reference cycles, và cách nullability có thể gây bất ngờ ở runtime.
Giao tiếp với API C cũng thường gặp — và không phải lúc nào cũng dễ chịu. Chuyển đổi kiểu C, xử lý Core Foundation, và quản lý "toll‑free bridging" tăng overhead tinh thần mà không giống việc viết mã app hiện đại.
Các codebase iOS kế thừa thường dựa trên Objective‑C vì chúng ổn định, đã được thử nghiệm, và tốn kém để viết lại. Nhiều app lâu đời bao gồm các lớp Objective‑C (hoặc dependency cũ) vẫn đang làm việc thực tế—và làm việc khá tốt.
Apple không tạo Swift vì Objective‑C "hỏng." Objective‑C đã hỗ trợ nhiều năm cho iPhone và Mac. Nhưng khi app lớn hơn, đội lớn hơn, và API mở rộng, chi phí từ một số mặc định của Objective‑C trở nên rõ hơn — đặc biệt khi nhân các rủi ro nhỏ trên hàng triệu dòng mã.
Mục tiêu lớn là làm cho sai lầm phổ biến khó viết hơn. Tính linh hoạt của Objective‑C mạnh mẽ, nhưng nó có thể che giấu vấn đề đến runtime: gửi message tới nil, loại id mơ hồ, hoặc quản lý nullability API sai. Nhiều vấn đề này có thể xử lý bằng kỷ luật, convention, và review tốt — nhưng vẫn tốn kém ở quy mô lớn.
Swift tích hợp các hàng rào: optionals buộc bạn nghĩ "cái này có thể thiếu không?", strong typing giảm sử dụng sai lầm vô ý, và các tính năng như guard, tính exhaustiveness của switch, và xử lý collection an toàn đẩy nhiều lỗi từ runtime lên thời điểm biên dịch.
Swift cũng hiện đại hóa trải nghiệm viết mã hàng ngày. Cú pháp ngắn gọn, suy diễn kiểu và thư viện chuẩn phong phú giúp nhiều tác vụ rõ ràng hơn với ít boilerplate so với pattern header/implementation, workaround generic dài dòng, hoặc sử dụng macro.
Về hiệu năng, Swift được thiết kế để cho phép trình biên dịch tối ưu mạnh mẽ (đặc biệt với value types và generics). Điều này không tự động làm mọi app Swift nhanh hơn mọi app Objective‑C, nhưng cung cấp một mô hình ngôn ngữ để Apple phát triển hướng tới tốc độ mà không phụ quá nhiều vào runtime động.
Apple cần làm cho phát triển iOS dễ tiếp cận cho dev mới và bền vững cho sản phẩm sống lâu. Quy ước đặt tên API của Swift, ý định rõ ràng tại call site, và nhấn mạnh kiểu biểu đạt nhằm giảm "kiến thức bộ tộc" và làm codebase dễ đọc sau vài tháng.
Kết quả: ít foot‑guns hơn, API sạch hơn, và một ngôn ngữ hỗ trợ nhóm lớn duy trì app nhiều năm — mà không phủ nhận Objective‑C có thể làm được việc.
Swift không "thắng" trong một đêm. Apple giới thiệu nó như một lựa chọn tốt hơn cho mã mới, rồi dành nhiều năm làm nó ổn định, nhanh hơn, và dễ áp dụng cùng với app Objective‑C hiện có.
ABI ổn định nghĩa là runtime Swift và thư viện chuẩn tương thích ở cấp nhị phân giữa các phiên bản Swift 5 trên nền tảng Apple. Trước Swift 5, nhiều app phải đóng gói thư viện Swift bên trong app, làm tăng kích thước và phức tạp phân phối. Với ABI ổn định, Swift trở nên giống Objective‑C hơn ở khía cạnh mã biên dịch chạy ổn định qua các bản OS update, giúp Swift cảm thấy "an toàn" cho codebase sản xuất lâu dài.
Nhiều năm, nhiều đội dùng Swift cho tính năng mới trong khi giữ các module lõi bằng Objective‑C. Con đường từng bước—thay vì rewrite toàn bộ—làm cho việc thịnh hành của Swift trở nên khả thi cho app thật và deadline thật.
Swift không thắng bằng cách ép mọi đội vứt bỏ Objective‑C hoạt động. Apple đảm bảo cả hai ngôn ngữ sống cùng nhau trong cùng target app. Khả năng tương thích này là lý do lớn khiến việc adopt Swift không đứt quãng ngay từ đầu.
Codebase hỗn hợp là bình thường trong iOS: bạn có thể giữ networking, analytics, hoặc component UI cũ bằng Objective‑C trong khi viết tính năng mới bằng Swift. Xcode hỗ trợ trực tiếp, nên "Swift thay Objective‑C" thường nghĩa là thay đổi dần dần, không phải một rewrite lớn.
Tương tác hoạt động qua hai cơ chế bổ sung:
YourModuleName-Swift.h) để phơi các class và method Swift tương thích Objective‑C. Thường bạn opt‑in bằng các attribute như @objc (hoặc kế thừa NSObject).Bạn không cần ghi nhớ mọi chi tiết kỹ thuật để hưởng lợi; nhưng hiểu có bước "phơi ra ngôn ngữ kia" giúp giải thích vì sao một số kiểu xuất hiện tự động và số khác thì không.
Hầu hết teams gặp vài điểm tích hợp lặp lại:
App thật sống lâu. Khả năng tương tác cho phép bạn di chuyển từng tính năng, tiếp tục phát hành, và giảm rủi ro—đặc biệt khi SDK bên thứ ba, component cũ, hoặc giới hạn thời gian làm cho việc chuyển đổi toàn bộ không thực tế.
Swift không chỉ hiện đại hóa cú pháp — nó thay đổi diện mạo code iOS hàng ngày. Nhiều pattern trước đây dựa trên convention (và review cẩn thận) trở thành thứ mà compiler có thể giúp áp dụng.
nil rõ ràngDev Objective‑C quen với việc gửi message tới nil mà không có lỗi. Swift làm sự vắng mặt rõ ràng bằng optionals (String?), buộc bạn xử lý giá trị thiếu trước với if let, guard, hoặc ??. Điều này giúp ngăn nhiều loại crash và lỗi logic “tại sao cái này rỗng?” — mà không tạo ảo tưởng là lỗi không thể xảy ra.
Swift có thể suy diễn kiểu ở nhiều chỗ, cắt bớt boilerplate nhưng vẫn giữ code dễ đọc:
let title = "Settings" // inferred as String
Quan trọng hơn, generics cho phép bạn viết code tái dùng, an toàn kiểu, mà không cần dựa vào id và kiểm tra runtime. So sánh “mảng của bất kỳ thứ gì” với “mảng đúng thứ tôi mong đợi” — ít đối tượng bất ngờ lọt vào và ít ép kiểu cưỡng bức.
throw/try/catch của Swift khuyến khích đường xử lý lỗi rõ ràng thay vì bỏ qua thất bại hoặc truyền NSError **. Collection có kiểu rõ ([User], [String: Int]), và String là kiểu Unicode‑correct String thay vì hỗn hợp C string, NSString, và quyết định mã hoá thủ công. Hệ quả là ít lỗi lệch chỉ số, ít giả định sai, và ít trường hợp “biên dịch được nhưng vỡ ở runtime”.
Runtime của Objective‑C vẫn có giá trị cho các pattern nặng runtime: method swizzling, dynamic message forwarding, một số cách dependency injection, và code dựa vào KVC/KVO. Swift có thể tương tác với chúng, nhưng khi bạn thực sự cần động tính runtime, Objective‑C vẫn là công cụ thực tế trong hộp.
Swift không chỉ thay đổi cú pháp — nó buộc hệ sinh thái iOS hiện đại hóa tooling và convention. Quá trình đó không phải lúc nào cũng mượt: các bản Swift đầu thường có build chậm hơn, autocomplete bấp bênh, và refactor cảm thấy rủi ro hơn. Theo thời gian, trải nghiệm dev trở thành một trong những lợi thế lớn nhất của Swift.
Hỗ trợ Swift trong Xcode cải tiến theo các cách thiết thực:
Nếu bạn dùng Swift thời 1.x/2.x, có lẽ còn nhớ nhiều cạnh sắc. Từ đó xu hướng nhất quán là: index tốt hơn, ổn định nguồn tốt hơn, và ít cảnh "Xcode bối rối" hơn.
Swift Package Manager (SPM) giảm nhu cầu các hệ thống dependency bên ngoài với nhiều đội. Cơ bản, bạn khai báo package và version, Xcode giải quyết, và build tích hợp mà không cần chỉnh file project phức tạp. Nó không hoàn hảo cho mọi cấu hình, nhưng với nhiều app nó đơn giản hóa onboarding và làm việc cập nhật dependency dễ đoán hơn.
Apple’s API Design Guidelines thúc đẩy framework theo hướng đặt tên rõ ràng, hành vi mặc định tốt hơn, và kiểu dữ liệu truyền đạt ý định. Ảnh hưởng đó lan tỏa: thư viện bên thứ ba ngày càng ưu tiên API viết cho Swift, làm codebase iOS hiện đại đồng nhất hơn — ngay cả khi vẫn bridge về Objective‑C phía dưới.
UIKit vẫn ở đó. Hầu hết app iOS sản xuất vẫn dựa nhiều vào nó, đặc biệt cho navigation phức tạp, cử chỉ tinh chỉnh, xử lý text nâng cao, và phần dài của component UI đã được kiểm chứng. Thay đổi là Swift giờ là cách mặc định để viết code UIKit — ngay cả khi framework nền vẫn như cũ.
Với nhiều đội, “app UIKit” không còn đồng nghĩa Objective‑C. Storyboards, nibs, và view programmatic thường được điều khiển bởi view controller Swift và model Swift.
Sự dịch chuyển này quan trọng vì Apple ngày càng thiết kế API mới với ergonomics hướng tới Swift (tên rõ ràng, optionals, generics, result types). Ngay cả khi API tồn tại cho Objective‑C, overlay Swift thường cảm giác như bề mặt "được dự định", ảnh hưởng cách dev mới trở nên hiệu quả trong codebase UIKit.
SwiftUI không chỉ là cách mới để vẽ nút. Nó thúc đẩy một mô hình tư duy khác:
Thực tế, điều này thay đổi cuộc thảo luận kiến trúc. Teams dùng SwiftUI thường nhấn mạnh hơn vào unidirectional data flow, component view nhỏ hơn, và tách side‑effect (networking, persistence) khỏi view code. Ngay cả khi không dùng hoàn toàn, SwiftUI giảm boilerplate cho màn hình chủ yếu là form, list, và layout điều khiển bởi state.
App đang vận hành thường kết hợp hai framework:
UIHostingController cho màn hình mới.Cách tiếp cận hybrid này cho phép teams giữ hạ tầng UIKit trưởng thành — navigation stack, coordinator, design system — trong khi áp dụng SwiftUI dần ở nơi có lợi rõ ràng. Nó cũng giữ rủi ro có thể quản lý: pilot SwiftUI ở vùng giới hạn mà không rewrite toàn bộ UI.
Nếu bạn bắt đầu mới hôm nay, câu chuyện UI mới nhất của Apple là SwiftUI, và nhiều công nghệ kề cận (widgets, Live Activities, một số app extension) hướng mạnh về Swift. Ngay cả ngoài UI, API thân thiện Swift trên các nền tảng Apple định hình mặc định: dự án mới thường được lên kế hoạch với Swift, quyết định trở thành “cần bao nhiêu UIKit?” thay vì “có nên dùng Objective‑C không?”
Kết quả là không phải framework này thay thế framework kia, mà Swift trở thành ngôn ngữ chung cho cả con đường thân thiện legacy (UIKit) và con đường Swift‑native mới (SwiftUI).
Concurrency là cách app làm nhiều việc "cùng lúc" — load data, decode JSON, và cập nhật giao diện — mà không làm đóng băng UI. Cách tiếp cận hiện đại của Swift thiết kế để làm công việc đó đọc giống mã tuần tự hơn là phiêu lưu với thread.
Với async/await, bạn có thể viết công việc bất đồng bộ (như network request) theo phong cách top‑to‑bottom:
async đánh dấu hàm có thể tạm dừng.await là điểm "dừng chờ kết quả".Thay vì callback lồng nhau, bạn đọc như một công thức: fetch data, parse, rồi update state.
Swift kết hợp async/await với structured concurrency, nghĩa là: “công việc nền nên có owner và lifetime rõ ràng.” Task được tạo trong một scope, và child task ràng buộc với parent.
Điều này cải thiện:
Hai khái niệm giúp giảm crash do truy cập đồng thời:
Phần lớn teams không bật công tắc qua đêm. Thường thấy mix concurrency hiện đại với pattern cũ — OperationQueue, GCD, delegate callback, và completion handler — nhất là khi tích hợp thư viện legacy hoặc luồng UIKit cũ.
Di chuyển một app iOS thật không phải dự án “chuyển hết”; nó là dự án quản lý rủi ro. Mục tiêu là tiếp tục phát hành trong khi giảm dần số Objective‑C bạn phải duy trì.
Chiến lược phổ biến là di chuyển từng phần:
Cách này giúp bạn xây sự tự tin trong khi giới hạn phạm vi thiệt hại—đặc biệt khi deadline không dừng để chuyển ngôn ngữ.
Một số pattern Objective‑C không dịch thẳng sang Swift:
objc_runtime mạnh có thể cần thiết kế lại chứ không thể dịch trực tiếp.Xem migration như swap implementation chứ không phải thay đổi tính năng. Thêm test đặc tính (characterization test) cho các luồng quan trọng (networking, caching, payment, auth) trước khi port. Snapshot test giúp bắt regressions UI khi di chuyển code UIKit sang Swift.
Tạo standard nhẹ cho teams theo: convention mã, linting (SwiftLint hoặc tương tự), ranh giới module, quy tắc bridging header, và "không thêm Objective‑C mới trừ khi có lý do." Viết ra tránh codebase trở nên song ngữ theo cách không nhất quán.
Swift không chỉ thay đổi cú pháp — nó thay đổi cái được xem là “bình thường” trong một đội iOS. Ngay cả khi sản phẩm vẫn có Objective‑C, quyết định hàng ngày về con người, quy trình, và duy trì dài hạn giờ bị định hình bởi kỳ vọng ưu tiên Swift.
Hầu hết vị trí iOS mới mặc định là Swift. Ứng viên có thể chưa từng ship Objective‑C chuyên nghiệp, ảnh hưởng tới thời gian ramp‑up nếu codebase mixed.
Kết luận thực tế: coi kiến thức Objective‑C là “ưu điểm”, không phải điều kiện bắt buộc, và làm tài liệu onboarding rõ nơi nào có Objective‑C và vì sao. Một hướng dẫn nội bộ ngắn về bridging header, ownership file, và "không sửa nếu không hiểu bối cảnh" sẽ tránh lỗi sớm.
Typing mạnh và optionals rõ ràng của Swift có thể làm review nhanh hơn: reviewer ít phải đoán giá trị có thể là gì, và dành thời gian nhiều hơn để kiểm tra ý định. Pattern như protocol, generics, và value types cũng khuyến khích kiến trúc nhất quán hơn — nếu dùng điều độ.
Mặt trái là drift style. Teams nên có style guide Swift chung và format/lint tự động để review tập trung vào hành vi, không phải whitespace.
Bảo trì dễ hơn khi bạn dùng API hiện đại trực tiếp thay vì mang theo wrapper tùy chỉnh quanh pattern cũ. Nhưng Objective‑C không biến mất trong một đêm — đặc biệt với app trưởng thành có module ổn định đã được thử nghiệm.
Lập ngân sách thực tế cho codebase hỗn hợp: lên kế hoạch di chuyển theo milestone kinh doanh, không phải như một "dọn dẹp vô tận." Xác định khi nào là "xong" (ví dụ: mọi mã mới bằng Swift, module legacy chỉ chạm opportunistically), và xem lại quy tắc đó khi refactor lớn.
For decision-making frameworks, see /blog/migrating-objective-c-to-swift.
Chọn giữa Swift và Objective‑C thường không phải tranh luận triết lý — mà là quyết định chi phí, rủi ro, và timeline. Tin tốt là bạn hiếm khi phải chọn "tất cả hoặc không." Hầu hết teams có kết quả tốt nhất bằng cách tiến hóa codebase tại chỗ.
Nếu bắt đầu từ đầu, Swift nên là mặc định. Nó tương thích với API mới nhất của Apple, có tính năng an toàn tốt hơn, và tiếp cận trực tiếp các pattern hiện đại như async/await.
Quyết định đầu tiên là chiến lược UI: UIKit bằng Swift, SwiftUI, hay trộn. Nếu chưa chắc, so sánh tradeoffs in /blog/swiftui-vs-uikit.
Với app Objective‑C hiện có, giữ module ổn định trong Objective‑C và đưa Swift vào nơi bạn thu lợi nhanh:
Quy tắc thực tế: bắt đầu module Swift mới khi bạn có ranh giới rõ (API surface, ownership, test). Giữ Objective‑C ổn khi mã mature, liên kết chặt, hoặc rủi ro khi chạm mà không có refactor lớn.
For planning, check /blog/ios-migration-checklist.
Trình tự sau phù hợp với phát triển iOS hàng ngày:
Hiện đại hóa iOS thường bộc lộ công việc hỗ trợ cạnh tranh cùng thời gian kỹ sư: dashboard admin, công cụ nội bộ, backend services, và API mà app iOS phụ thuộc. Nếu muốn đội iOS tập trung vào migration Swift trong khi vẫn phát hành phần hỗ trợ, Koder.ai có thể giúp bạn dựng web app, backend Go (với PostgreSQL), hoặc app companion Flutter thông qua workflow chat — rồi xuất mã nguồn, triển khai, và dùng snapshot/rollback để quản lý lặp an toàn.
Nếu bạn muốn trợ giúp ngoài để phác thảo bước an toàn tiếp theo — module mới, migration từng phần, hay "để nguyên" — xem /pricing.
Swift được tạo ra để giảm các rủi ro thường gặp trong phát triển iOS (như hành vi nil bất ngờ và kiểu dữ liệu lỏng lẻo), cải thiện khả năng đọc/duy trì cho các codebase lớn, và cho phép tối ưu hóa mạnh hơn từ trình biên dịch theo thời gian. Không phải vì Objective‑C “tệ” mà vì Apple muốn mặc định an toàn và hiện đại hơn cho quy mô lớn.
Swift trở thành ngôn ngữ mặc định nhờ một lộ trình từ tốn và thực tế:
Kết quả là “mã mới bằng Swift” trở thành con đường ít cản trở nhất cho hầu hết đội ngũ.
Swift 5 giới thiệu ABI ổn định trên nền tảng Apple, nghĩa là mã Swift đã biên dịch có thể tương thích nhị phân qua các phiên bản runtime Swift 5.x đi kèm hệ điều hành. Về thực tế, điều này giảm nhu cầu đóng gói thư viện Swift trong app, giúp giảm kích thước app và tăng độ tin cậy khi phân phối—làm cho Swift an toàn hơn cho các codebase chạy lâu dài.
Bạn có thể trộn cả hai trong cùng một target app:
YourModuleName-Swift.h) để phơi các API Swift tương thích Objective‑C, thường dùng @objc hoặc kế thừa NSObject.Không phải mọi tính năng Swift đều có thể nhìn thấy từ Objective‑C, nên cần chủ ý khi định ranh giới.
Optionals (T?) làm cho việc “giá trị thiếu” rõ ràng và buộc xử lý ở thời điểm biên dịch (ví dụ if let, guard, ??). Trong Objective‑C, gửi message tới nil và tính không rõ ràng về nullability có thể che giấu lỗi đến thời điểm runtime. Lợi ích thực tế là ít crash hơn và ít lỗi kiểu “giá trị này bất ngờ rỗng”.
Generic và kiểu mạnh của Swift giảm việc ép kiểu và kiểm tra kiểu lúc runtime (thường thấy với id và collection không kiểu trong Objective‑C). Trong thực tế, bạn có:
[User] thay vì “mảng bất kỳ”Objective‑C vẫn là lựa chọn tốt khi bạn thực sự cần tính năng động của runtime (ví dụ: KVC/KVO nặng, method swizzling, API dựa trên selector, hoặc kiến trúc dạng plugin). Swift có thể tương tác với những pattern này, nhưng các bản sao thuần Swift có thể đòi hỏi thiết kế lại hơn là chuyển dịch trực tiếp.
Chiến lược an toàn là di chuyển từng bước:
Xem việc di chuyển như quản lý rủi ro: tiếp tục phát hành trong khi giảm chi phí duy trì dài hạn.
Những lỗi phổ biến gồm:
@objc, NSObject và phải hạn chế một số tính năng ngôn ngữ.Lập ranh giới rõ và thêm test trước khi thay thế implementation sẽ giúp giảm rủi ro.
Hoàn toàn có thể mix:
UIHostingController để nhúng SwiftUI vào trong UIKit.Cách này cho phép đội áp dụng SwiftUI ở chỗ giảm boilerplate trong khi giữ lại navigation, hệ thống thiết kế, và component phức tạp đã được kiểm chứng trong UIKit.