- Trong Swift 6 và phát triển ứng dụng iOS mới nhất, mức độ tận dụng các công cụ dựa trên LLM thấp rõ rệt, khiến khoảng cách năng suất so với Android (Kotlin, Compose, dùng Cursor) ngày càng lớn
- Nhóm Android có thể phát triển nhanh và hỗ trợ tính năng mới trên cả các phiên bản OS cũ, trong khi nhóm iOS gặp suy giảm năng suất và gánh nặng chuyển đổi codebase do cú pháp Swift 6 mới nhất, các ràng buộc tính năng và thiếu hỗ trợ framework
- Vì LLM không hiểu mô hình đồng thời mới (concurrency) và các pattern phức tạp của Swift 6, nên khả năng tự động hóa/tăng tốc viết mã của LLM bị hạn chế
- Bản thân việc áp dụng Swift 6 được một số lập trình viên đánh giá tích cực, nhưng thiếu khả năng tương thích với các công cụ LLM được chỉ ra là vấn đề
- Khả năng tương thích ngược và cách tiếp cận thân thiện với lập trình viên của hệ sinh thái Google như Android, Compose, Cursor trở nên nổi bật, trong khi sự bất mãn với tốc độ cập nhật framework và API của phía Swift/Apple vẫn tiếp diễn
Năng suất phát triển trong thời đại Swift 6 và LLM
Cảm nhận về năng suất phát triển iOS vs Android
- Tác giả đang phát triển một ứng dụng mới bằng Swift 6 trong một nhóm iOS nhỏ, đồng thời phát triển song song với một nhóm Android quy mô nhỏ
- Nhóm Android có thể đạt tốc độ cao và hỗ trợ tính năng mới nhờ sử dụng Kotlin, Compose, Cursor, đồng thời hỗ trợ rộng tới Android 10 ra mắt năm 2019
- Nhóm iOS chỉ có thể hỗ trợ từ iOS 16 (2022) trở lên; việc áp dụng Swift 6 mới nhất khiến họ gặp nhiều ràng buộc với các tính năng như Observable, generic parameter packs
Sự lệch pha giữa Swift 6 và LLM
- Những thay đổi lớn về cú pháp và framework trong Swift 6 trùng với thời điểm LLM (mô hình ngôn ngữ lớn) bắt đầu được hỗ trợ rộng rãi, nhưng LLM lại không xử lý tốt hệ thống concurrency mới của Swift 6
- Các công cụ LLM tạo hoặc gợi ý mã tự động (ví dụ: ChatGPT, Claude, Cursor) chưa học đủ dữ liệu và pattern liên quan đến Swift 6 nên bị hạn chế trong việc sinh mã chính xác
- Lập trình viên phải tự bổ sung các phần mà LLM chưa hiểu đúng, như giải thích ngữ cảnh và thêm quy tắc thủ công → gây giảm năng suất và phát sinh công việc lặp lại
Ý kiến và trải nghiệm từ cộng đồng
- Một số lập trình viên iOS bày tỏ sự ganh tị với khả năng tương thích ngược của API Android, độ hoàn thiện của Compose UI và công cụ Cursor
- Cũng có ý kiến cho rằng việc áp dụng Swift 6 là lựa chọn sai lầm, nhưng trên thực tế vẫn có đánh giá tích cực rằng dù phải chấp nhận các pattern mới và nhu cầu học thêm, khả năng biểu đạt và chất lượng mã đã được nâng lên
- Các framework chủ chốt của Apple vẫn chưa được cập nhật đầy đủ để phù hợp với hệ thống concurrency của Swift 6, nên việc phải dùng lẫn với GCD khiến nhiều người chia sẻ trải nghiệm về độ phức tạp mã và suy giảm năng suất
- Một số nhóm đang trì hoãn việc áp dụng Swift 6 và ưu tiên giải quyết các vấn đề tương thích với codebase hiện có
Khác biệt giữa hệ sinh thái Android và Apple
- Android tăng cường năng suất cho lập trình viên nhờ chính sách backport cho API mới, đồng thời đang khắc phục các nhược điểm kéo dài như phân mảnh và lỗi theo từng thiết bị
- Ngược lại, Apple duy trì API riêng tư/hạn chế cùng chính sách cập nhật chậm, khiến lập trình viên phải nhiều lần tự triển khai các tính năng tương tự
- Năng suất phát triển Android còn cải thiện nhanh hơn nhờ việc áp dụng các công cụ AI/tự động hóa như Compose, Cursor
- Trong bối cảnh khó tận dụng LLM, nhiều lập trình viên iOS/Swift ngày càng cảm thấy bất an về sự thay đổi của xu hướng phát triển và vị thế nghề nghiệp
Kết luận và hàm ý thực tiễn
- Bản thân Swift 6 được đánh giá cao về tính đổi mới và khả năng biểu đạt mã, nhưng do giới hạn của các công cụ coding LLM/AI, trong thời gian tới vẫn khó tránh khỏi làm thủ công và giải thích lặp đi lặp lại
- Với các dự án cần phát triển nhanh và tận dụng tính năng mới, tổ hợp Android + Compose + Cursor cho thấy năng suất vượt trội
- Chừng nào Apple chưa nhanh chóng cập nhật hệ sinh thái framework và công cụ, các nhóm áp dụng Swift 6 trong thực tế sẽ vẫn phải chấp nhận suy giảm năng suất và giới hạn khi tận dụng LLM
3 bình luận
Nhìn chung thì đây là nhận định đúng, nhưng từ góc độ một người đã thử chạy tạm các mô hình cục bộ bằng MLX trên thiết bị Apple Silicon, tôi khó mà đồng ý 100%.
Tham khảo thêm, khi phát triển mô hình còn có gánh nặng phải port sang
mlx, và dù đã bậtmpsthì cảm nhận thực tế cũng chỉ là tính toán nhanh hơn CPU một chút, nên hiện tại vẫn khá bất tiện.A... đau thật, bị nói trúng tim đen rồi...