Swift vốn luôn được định sẵn sẽ trở thành một phần của OS

• Trên diễn đàn Swift có ý kiến phàn nàn rằng việc đưa Swift vào OS đã tạo ra tình huống tệ hơn cho các nhà phát triển
• Đáp lại điều này, cũng có ý kiến mỉa mai kiểu “chào mừng đến với thế giới của các thư viện được phát hành cùng OS”
• Bài viết này dựa trên trải nghiệm phát triển Swift tại Apple để giải thích bối cảnh Swift trở thành một phần của OS và những vấn đề phát sinh

Phụ thuộc vào OS

• Trước đây, máy tính cá nhân cho phép tiến trình đang chạy kiểm soát toàn bộ máy, nhưng ngày nay nhân hệ điều hành luôn chạy và cung cấp các dịch vụ OS cơ bản
• Hầu hết các OS hiện đại cho phép tạo chương trình có thể yêu cầu thực hiện một số tác vụ đặc quyền thông qua giao diện system call.
• Các OS của Apple ngày nay có giao diện system call không ổn định theo từng phiên bản OS, vì vậy phải dùng thư viện chuẩn C/POSIX và các phần mở rộng của nó để thực hiện những tác vụ cơ bản.

Mô hình của Apple (trước Swift)

• Trước Swift, phần lớn API công khai của Apple được viết bằng C hoặc Objective-C và được cung cấp dưới dạng native code.
• Phiên bản OS mới sẽ bao gồm các phiên bản tương thích nhị phân mới của thư viện hiện có, tạo thành một tập siêu của các API từ các phiên bản trước.
• Nhược điểm chính của mô hình này là tính năng và API mới bị gắn chặt với phiên bản OS mới.

Swift "beta" 1 ~ 5

• Từ Swift 1 đến Swift 5 đã có rất nhiều thay đổi, và tính ổn định ABI luôn là mục tiêu của Swift.
• Khi chuyển sang Swift 5, phần lớn vấn đề đã được giải quyết, và cần phải tìm cách để khi Swift được đưa vào OS thì các ứng dụng và dự án hiện có không bị ảnh hưởng.

Chuyển đổi

• Trong quá trình đưa Swift vào OS, cần phải tìm cách để không phá vỡ các ứng dụng và dự án đã được xây dựng trước đó.
• Sử dụng tính năng gọi là rpath để file thực thi có thể tìm thư viện động bằng cách dò qua một loạt thư mục thay vì một đường dẫn được hardcode.

Những gì đã mất

• Khi Swift được đưa vào OS, ứng dụng không còn cần phải tự đóng gói Swift nữa, và việc Swift runtime cùng Objective-C runtime được cung cấp sẵn giúp cải thiện hiệu năng.
• Tuy nhiên, các cộng tác viên Swift bên ngoài phải đối mặt với vấn đề rằng API mới chỉ tồn tại trên OS mới.

Các lựa chọn thay thế

• Có một vài cách hợp lý mà Apple có thể thực hiện để mang lại tình huống tốt hơn cho các nhà phát triển, nhưng chưa rõ Apple có làm vậy hay không.

Kết luận

• Việc Swift được đưa vào OS có thể là một thỏa thuận không tốt cho các nhà phát triển ứng dụng, nhưng Apple không thể từ bỏ lựa chọn viết các system library bằng Swift.

Đây không phải điều mới mẻ chỉ liên quan đến Swift

• Nhiều vấn đề liên quan đến Swift thực chất là hệ quả của các thư viện được phát hành cùng OS.
• Cả những thay đổi kỹ thuật lẫn thay đổi về mặt xã hội của Swift đều ảnh hưởng đến các vấn đề này.

Ý kiến của GN⁺

• Việc Swift trở thành một phần của OS tạo ra nhiều ràng buộc hơn cho các nhà phát triển, nhưng đó là hệ quả tất yếu của mô hình phân phối thư viện của Apple.
• Bài viết này nhấn mạnh sự phức tạp của phát triển phần mềm và tầm quan trọng của quản lý thư viện bằng cách khám phá những thách thức kỹ thuật, vận hành phát sinh trong quá trình tích hợp Swift vào OS và các cách giải quyết cho chúng.
• Việc tích hợp Swift vào OS mang đến kích thước tệp lớn hơn và vấn đề tương thích cho các nhà phát triển ứng dụng, nhưng đồng thời cũng giúp Apple có thể viết và cập nhật các system library bằng Swift, qua đó hỗ trợ duy trì tính nhất quán và bảo mật của toàn hệ thống.