1 điểm bởi GN⁺ 2024-02-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Apple cung cấp cho khách hàng những thiết bị an toàn và ít gánh nặng quản trị, nhưng đi đến kết luận từ trải nghiệm rằng với nhà phát triển cá nhân thì họ không tạo ra cùng mức tính phụ thuộc lẫn nhau đó
  • Lỗi chế độ tối/sáng của Google Search được dùng như một ví dụ cho thấy những bất tiện không ảnh hưởng đến doanh thu có thể bị bỏ mặc rất lâu, hơn là do thiếu năng lực kỹ thuật
  • Giá trị cốt lõi của Apple không nằm ở hệ sinh thái ứng dụng mà ở máy tính và thiết bị mà người dùng có thể sử dụng mà không cần tự quản lý riêng; iPhone hay iPad được cho là vẫn có lý do để mua ngay cả khi không có ứng dụng
  • API Apple Music từng được kỳ vọng vào năm 2016 nhưng 8 năm sau vẫn còn lỗi và hạn chế truy cập, thậm chí chỉ để thử nghiệm đơn giản cũng cần tài khoản nhà phát triển 100 USD/năm
  • Nền tảng web không thuộc sở hữu của một công ty duy nhất thì không hoàn hảo và mong manh, nhưng vẫn là lựa chọn thực tế cho các nhà phát triển muốn bớt bị trói vào cấu trúc zero-sum của một doanh nghiệp cụ thể

Apple mạnh với khách hàng nhưng không phụ thuộc vào nhà phát triển

  • Trọng tâm là nhận thức rằng Apple rõ ràng mang lại giá trị cho từng khách hàng cá nhân, nhưng có rất ít lý do mang tính cấu trúc để họ phải quan tâm đến nhà phát triển cá nhân theo cùng cách đó
  • Quan hệ phụ thuộc chảy theo Developer -> Apple, Apple -> Consumer, và gần như không có chiều phụ thuộc ngược từ Apple sang nhà phát triển cá nhân
  • Ngay cả khi mọi nhà phát triển ngừng phát triển cho nền tảng Apple, Apple nhìn chung vẫn có thể tồn tại, vì đề xuất giá trị cốt lõi của họ không phụ thuộc vào từng nhà phát triển riêng lẻ
  • Việc hợp tác với các “đối tác” phát triển doanh nghiệp có thể là cần thiết, nhưng đó là vấn đề khác với việc phụ thuộc vào nhà phát triển cá nhân
  • Một số tập đoàn đa quốc gia xem nhà phát triển là trung tâm chiến lược, nhưng Apple bị cho là không thuộc kiểu đó
  • Sau khi chấp nhận sự phân biệt này, có thể tách riêng cảm giác yêu thích sản phẩm Apple với mong muốn phát triển cho Apple

Trường hợp Google: lỗi không ảnh hưởng doanh thu có thể tồn tại rất lâu

  • Google Search có vấn đề là trong môi trường hệ thống chuyển động giữa chế độ sáng/tối động, trang kết quả tìm kiếm đầu tiên có thể hiển thị với chủ đề ngược lại
    • Ban đêm, toàn bộ hệ thống đang ở trạng thái tối nhưng trang kết quả đầu tiên lại bật sáng làm đau mắt
    • Buổi sáng, sau khi laptop quay về chế độ sáng thì kết quả tìm kiếm lại hiển thị trên nền đen khó đọc
  • Lỗi này đã tồn tại nhiều năm và được cho là khó có khả năng được sửa trừ khi vô tình được khắc phục trong một đợt cải tổ lớn
  • Cách diễn giải là nguyên nhân không phải vì Google không có khả năng sửa, mà vì nó không ảnh hưởng đến doanh thu
  • Những người dùng công cụ tìm kiếm thay thế như DDG đã rời đi từ trước, còn đại đa số áp đảo vẫn bị giữ trong Google
  • DDG quảng bá tính thân thiện với quyền riêng tư, nhưng lý do sử dụng thực tế được cho là UX đơn giản gợi nhớ Google thời kỳ đầu, kết quả tìm kiếm chính xác chất lượng tốt và quảng cáo không gây cản trở
  • Google không xem người dùng như một mục tiêu trong trò chơi lý thuyết, và những tương tác có tính đối kháng với người dùng khi buộc phải dùng sản phẩm Google cũng được chấp nhận như hệ quả của cấu trúc đó

Giá trị cốt lõi của Apple: máy tính an toàn, ít gánh nặng quản trị

  • Khoảng năm 2009, khi chọn máy tính cho gia đình, Windows bị đánh giá là quá yếu về bảo mật vào thời điểm đó, còn Linux thì cần hỗ trợ kỹ thuật liên tục
  • Cuối cùng đã chuẩn bị một máy tính cài OpenBSD, Firefox và các game mặc định, nhưng đổi lại việc có được tính an toàn, quyền riêng tư và gánh nặng hỗ trợ thấp là khả năng sử dụng bị hạn chế đáng kể
  • Sau khi dùng Mac công việc tại một công ty làm ứng dụng iOS, đi đến kết luận: “đây chính là chiếc máy tính mình muốn cho mẹ”
  • Sau đó đã tiết kiệm tiền mua MacBook, và theo thời gian, kiểu thiết bị mà gia đình sử dụng chuyển từ laptop sang iPad, nhưng cùng một giá trị cốt lõi vẫn tiếp tục được đáp ứng
  • Ngay cả một chiếc iPhone không có ứng dụng cũng được cho là vẫn có khả năng mua cho bản thân, và gần như chắc chắn là thiết bị sẽ mua cho gia đình
  • Trong mô hình kinh doanh của Apple, nhà phát triển không phải yếu tố thiết yếu; nhà phát triển hạnh phúc thì tốt, nhưng không phải là điều bắt buộc về mặt cấu trúc
  • Bên trong Apple có những cá nhân quan tâm đến nhà phát triển và muốn cải thiện, nhưng hành động ở cấp công ty có thể không nhất quán

Kỳ vọng và thất vọng với Apple Music API

  • Khoảng năm 2016, khi Apple Music API được công bố tại WWDC, đã có kỳ vọng rất lớn, nhưng trên thực tế chuyện “mọi thứ thay đổi” đã không xảy ra
  • Trình phát nhạc của chính Apple vẫn bị cảm nhận là khó dùng, và những trình phát thay thế từng thử cũng được cho là hầu hết đi theo cách tiếp cận kiểu Spotify
  • Có kỳ vọng rằng có thể tái tạo lại trải nghiệm trình phát nhạc nhanh, mượt, liên tục bất tận nhưng mang tính cá nhân như thời Justin Frankel của Winamp
  • Nếu có catalog âm nhạc của Apple, người ta cho rằng có thể tái hiện trải nghiệm đó mà không cần dựa vào vi phạm bản quyền như trước đây
  • Khi có thời gian rảnh đã tạo một trình phát nhạc tên là Flowers, và cũng định viết hướng dẫn để người khác có thể tự tạo trình phát nhạc của riêng mình
  • Trong quá trình triển khai, đi đến nhận định rằng sau 8 năm API vẫn có lỗi và không công khai
    • Chỉ để thử API thôi cũng phải trả cho Apple 100 USD mỗi năm
    • Khoản phí này không phải phí sử dụng số lượng lớn mà cần ngay cả cho quyền truy cập thử nghiệm đơn giản
    • Ngay cả khi dùng tài khoản nhà phát triển trả phí thì cũng chỉ nhận được API bị hạn chế
  • Trong console trình duyệt của trình phát nhạc web Apple, nhập MusicKit.getInstance().developerToken có thể lấy miễn phí root token không hạn chế, nên quy trình dành cho nhà phát triển bị xem là vô lý

Web là nền tảng dùng chung không có một chủ sở hữu duy nhất

  • Kết luận dẫn đến hướng là hãy viết mã chạy trên web
  • Web là nền tảng dùng chung không do một chủ thể duy nhất sở hữu, và khác với nền tảng của một công ty cụ thể ở chỗ ngay cả thiện ý cũng có thể bị phá hỏng bởi sự bất lực
  • Nền tảng web đang ở trạng thái mong manh vì các yếu tố sau
    • Chính phủ can thiệp quá mức
    • Thế song mã trình duyệt
    • Hệ sinh thái nhà phát triển phức tạp
  • Không có gì đảm bảo web sẽ tiếp tục hưng thịnh, nhưng nó đã sống sót đến nay, và càng tồn tại lâu thì khả năng tiếp tục hưng thịnh trong tương lai càng lớn
  • Gần đây, đoạn mã workaround phải viết liên quan đến web được cho là do hành vi kỳ lạ của Safari
  • Đồng thời, Google cũng đang làm những việc tuyệt vời cho web, nên trong ngữ cảnh này được đánh giá là đang đóng vai trò tốt

Khó chia mối quan hệ với công ty thành thiện và ác cố định

  • Cũng như việc phân loại con người cố định thành người tốt và người xấu là không hữu ích, các công ty cũng bị cho là khó có thể bị phân loại vĩnh viễn thành công ty tốt và công ty xấu
  • Công ty chia sẻ những thuộc tính tương tự con người ở chỗ có trí năng, tính cách, sự sinh ra, lớn lên, tiêu vong và tư cách pháp nhân
  • Cũng như không thể sống mà không có con người, người ta cũng không thể sống mà không có công ty; dù có những đặc tính phi nhân tính thì dạng thức fractal của tổ chức con người vẫn tiếp tục tồn tại
  • Nếu không đặt công ty vào các phạm trù thiện ác cố định thì có thể xây dựng quan hệ linh hoạt hơn
    • Khi công ty đẩy mình vào trò chơi zero-sum thì giảm mức độ phụ thuộc
    • Khi họ cho phép một mối quan hệ cộng sinh hơn thì lại tiếp tục can dự
  • Steve Jobs từng nói vào năm 1996 rằng các doanh nghiệp lớn, vừa và nhỏ đều bắt đầu xem web là mạng lưới phân phối trực tiếp cuối cùng tới khách hàng, là con đường đi trực tiếp từ nhà cung cấp đến người tiêu dùng bằng cách bỏ qua trung gian

1 bình luận

 
GN⁺ 2024-02-05
Các ý kiến trên Hacker News
  • Ngay từ đầu tôi đã quyết định không học phát triển mobile native, dồn toàn bộ thời gian có hạn cho web, và riêng lần này tôi nghĩ đó là lựa chọn đúng
    Giờ đây có thể tạo ra những thứ đáng kinh ngạc ngay trong trình duyệt, và theo quan điểm rất cá nhân của tôi, ngoại trừ Uber, Google Drive và game, phần lớn ứng dụng lẽ ra nên là web app
    Tôi từng làm trong ngành truyền thông, và ở nước tôi, đầu thập niên 2010 là thời kỳ các cơ quan báo chí vốn không có nhiều tiền lại đổ ngân sách vào làm app di động; tôi là người đi ngược trào lưu đó
    Tôi biết phần lớn app khó mà có chất lượng tốt, và các công ty cũng sẽ không cập nhật phần frontend mobile đều đặn; rốt cuộc mọi chuyện đúng y như vậy
    Giờ họ bị mắc kẹt trong những app gần như không còn được bảo trì, phần lớn trông như di vật của một thời đã qua, và thực tế cũng đúng là vậy

    • Tôi hiểu vì sao Google Drive hoạt động tốt hơn dưới dạng app native. Vì nó phải cung cấp hệ thống tệp ảo cho hệ điều hành và làm những việc như đồng bộ nền
      Nhưng tôi không hiểu vì sao lại là Uber. Uber có, hoặc từng có, một website di động xử lý tốt việc gọi xe và gần như mọi việc app làm, và tôi không thấy app native đem lại thêm giá trị gì cho người dùng
      Phần lớn game di động cũng tương tự. Thường chỉ là đồ họa đơn giản mà trình duyệt đủ sức render với hiệu năng tốt, và họ thường tự làm lại các component UI dùng chung, nên việc không dùng được nút hệ thống native cũng không khác biệt nhiều
      PWA cũng có thể cung cấp đủ dung lượng lưu trữ cần thiết cho tệp lưu cục bộ và dữ liệu game. Tất nhiên, ngoại lệ là những game đẩy tới giới hạn của hệ thống
      Tôi không kỳ vọng những game như Death Stranding hay bản remake RE4 chạy tốt nếu không truy cập trực tiếp vào tăng tốc đồ họa native, và chúng cũng quá lớn để tải như một trang web đơn lẻ
      Nhưng phần lớn app di động, thậm chí cả những game free-to-play sinh lời cao có thể giữ thêm 30% doanh thu nếu chuyển sang web, đều không thuộc nhóm đó
      Vậy tại sao họ không nhắm tới web? Theo trực giác của tôi, người dùng di động đã được “huấn luyện” để tìm app và game trong app store, còn người dùng desktop thì kỳ vọng app sẽ được cung cấp qua trình duyệt, ngoại trừ một số công cụ chuyên dụng và game cấu hình cao
      Cuối cùng, phần lớn đây là vấn đề văn hóa, và việc Apple hỗ trợ PWA kém cũng chẳng giúp gì
    • Giá mà trải nghiệm phát triển web không bức bối đến vậy. Trong 10 năm qua nó đã cải thiện đáng kể, nhưng so với môi trường phát triển native thì tôi vẫn thấy chưa tối ưu
      Phần lớn sự bức bối đến từ công cụ, đặc biệt là TypeScript; khó diễn đạt ngắn gọn, nhưng tôi đã phải vật lộn với hệ thống kiểu của TypeScript nhiều hơn hẳn so với phía native
    • Đặc biệt, PWA được xây theo hướng offline-first đã gần với trải nghiệm native hơn rất nhiều so với 5 năm trước
      Tuy nhiên tôi lo liệu Google và Apple có động lực để giúp cải thiện PWA tới mức có thể cạnh tranh với app native hay không. Nếu đạt tới mức đó, doanh thu của họ có thể bị ảnh hưởng
    • Tại sao lại đầu tư thời gian vào những công nghệ theo trào lưu thay đổi hằng tháng?
      Tốt hơn là đầu tư thời gian vào các thành phần nền tảng của tech stack
    • Tôi quá mệt với việc điện thoại và tablet bị bừa bộn bởi đủ loại app linh tinh. Bãi đậu xe gần nhà cũng có app, máy photocopy ở thư viện cũng có app
      Tất cả đều là những thứ có thể xử lý bằng web
  • Lý do Apple không quan tâm đến lập trình viên là, như chính họ đã giải thích, họ đã tạo ra một thứ gần như là giáo phái khu vườn đóng kín ở phía người dùng
    Nếu lập trình viên không làm sản phẩm cho nền tảng đó, họ sẽ mất một nửa thị trường, hoặc hơn
    Trong công việc chính là làm game di động tại một studio nhỏ trong một tập đoàn lớn, chúng tôi phải liên tục đấu với Apple không chỉ về vấn đề kỹ thuật mà cả chính sách và phê duyệt
    Nhưng rất khó tưởng tượng việc phát hành một game di động mà không có cách chạy trên iOS, nên chúng tôi buộc phải tuân theo
    Ở nhiều khía cạnh, chiến lược PC ban đầu của Microsoft là hoàn toàn ngược lại. Họ chăm lo cho lập trình viên và cung cấp tài liệu, ví dụ, công cụ đồ sộ
    Các công ty nơi những lập trình viên đó làm việc có động lực tạo, quảng bá và bán phần mềm cho Microsoft; làn sóng lập trình viên cá nhân đổ ra phần mềm Windows đã tạo nên hệ điều hành desktop vẫn thống trị cho đến nay

    • Tôi đã viết phần mềm chuyên nghiệp trong 15 năm nhưng chưa từng viết một dòng code cho thiết bị Apple, và sau này cũng sẽ không làm
      Đóng góp cho hệ sinh thái Apple là một lựa chọn, không phải bắt buộc. Những lập trình viên đóng góp cho hệ sinh thái Apple đang chủ động tham gia vào tình trạng hiện nay
    • Tôi nghĩ đó là vì Apple là công ty phần cứng và dùng phần mềm để thu hút người tiêu dùng, trong khi Microsoft là công ty phần mềm và dùng phần cứng để thu hút người tiêu dùng
    • Apple không ép lập trình viên phải làm gì cả. Lý do lập trình viên làm app cho nền tảng đó là vì người tiêu dùng muốn tiêu tiền ở đó
      Apple đạt được điều này bằng cách đối xử tệ với lập trình viên, hay chính xác hơn là không cho lập trình viên đối xử tệ với khách hàng
      Nó cũng tương tự cách gây sức ép mạnh lên nhà cung cấp, nhưng cuối cùng đã tạo ra một hệ sinh thái lành mạnh và giàu có, và lập trình viên cùng nhà cung cấp vẫn tiếp tục đưa app lên đó
    • Tôi thấy chuyện này hơi khác với tình huống mà tác giả nói tới. Có vẻ tác giả tập trung vào những dịch vụ có ý nghĩa trong mọi hoàn cảnh, nơi mobile chỉ là một trong nhiều điểm truy cập
      Chẳng hạn mạng xã hội, app hẹn hò, Reddit, Stack Overflow. Không phải những dịch vụ phụ thuộc vào trải nghiệm mobile, như Uber cần theo dõi vị trí, hay game di động được thiết kế để chơi khi đang di chuyển
      Nếu doanh nghiệp không phụ thuộc vào trải nghiệm mobile, họ vẫn có thể cung cấp dịch vụ mà không cần app native
      Người dùng mobile vẫn có thể truy cập bằng trình duyệt di động; dù có thể không phải trải nghiệm lý tưởng, đó vẫn là một lựa chọn
      Tôi nghĩ điểm mấu chốt là: nếu nền tảng mobile không phải điều bắt buộc hoặc bạn không phụ thuộc vào nó, thì đừng làm riêng cho nền tảng đó
    • Tôi tò mò Apple đã chặn những gì liên quan đến game di động
  • Vài năm trước tôi đã đào sâu để học Swift và phát triển iOS native, nhưng thật sự không thể quen nổi với việc dùng Xcode.
    UI/UX của Xcode tệ đến mức khó diễn tả; tôi cứ phải mở rồi đóng các panel chỉ để bấm vào những biểu tượng thậm chí còn không được nhóm lại một cách trực quan.
    Mở một panel thì panel khác bị ép thu nhỏ, và cảm giác như một phần mười thời gian thực chất được dùng cho việc “lái panel”.
    Có vẻ các nhà thiết kế của Apple muốn tạo ra một IDE trông đẹp mắt và tối giản, chứ không phải một IDE ít ma sát cho lập trình viên.
    Nhưng IDE không cần phải tối giản; mỗi lập trình viên phải có thể tùy biến và để nó bừa bộn theo ý mình, tùy vào thứ họ đang muốn xây dựng.
    Hãy tưởng tượng một bàn làm việc trong gara ngoài đời: Visual Studio cho phép bạn làm bừa bộn và tùy biến không gian làm việc tùy thích, còn Apple thì giống như yêu cầu bạn bỏ công cụ trước đó vào hộp mỗi lần trước khi cầm công cụ tiếp theo.
    Ý tôi nói về việc lái panel là như vậy, và tôi tự hỏi các lập trình viên khác có cảm thấy thế không.

    • Câu này thật sự chạm đúng cảm giác của tôi, và lý do chính xác khiến tôi nhiều lần thử rồi dừng phát triển Mac/iOS native chính là IDE.
      Cách diễn đạt rằng họ ưu tiên hình thức hơn chức năng đã giúp tôi nói ra được mình ghét điều gì ở Xcode.
      Tôi đã ở trong hệ sinh thái JetBrains hơn 10 năm, nó cũng có nhược điểm, nhưng tôi chưa bao giờ cảm thấy JetBrains cố bắt IDE hoạt động theo cách họ muốn thay vì cách tôi muốn.
    • Tôi đồng ý rằng khả năng sử dụng của Xcode thật sự tệ. Nó chậm đến khó tin và crash quá thường xuyên, đến mức nếu đem qua quy trình duyệt App Store thì chắc không được thông qua.
      Nhưng điều thật sự khiến tôi quay lưng với việc làm app native cho nền tảng Apple là sự kết hợp giữa bug và thiếu tài liệu.
      Lần cuối tôi dùng cách đây một năm, SwiftUI chưa ở trạng thái phù hợp với mục đích sử dụng, và ngay cả những thư viện trưởng thành hơn cũng thường gần như không có tài liệu.
      Rất khó biết thứ gì đã bị loại bỏ.
      Trong công việc của tôi, lợi thế của app native từ góc nhìn người dùng vốn đã nhỏ, chủ yếu là phần lưu trữ cục bộ ổn định hơn.
      Nếu năng suất thấp hơn nhiều so với làm web app, thì khó biện minh cho chi phí và rủi ro bổ sung khi phải trông chờ vào lòng thương của một kiểu lãnh chúa độc quyền.
    • Tôi nghĩ điều này phụ thuộc khá nhiều vào phong cách phát triển và môi trường quen thuộc.
      Xcode không làm tôi khó chịu chút nào, nhưng Android Studio dựa trên IntelliJ được ca ngợi thì cứ liên tục khiến tôi bực mình.
      Visual Studio cũng gây khó chịu tương tự và có những hạn chế kỳ lạ. Ví dụ tôi không hiểu vì sao không thể dùng chữ nghiêng trong tô màu cú pháp.
      Trình soạn thảo cũng vậy. VS Code có những điểm nhỏ gây khó chịu, không như Sublime Text hay TextMate.
    • Đồng ý. Mỗi lần cố tìm những thứ như Build Output hay Project Settings, vốn có thể tìm thấy dễ dàng trong các IDE khác, tôi rất dễ bị lạc và phải Google xem mở panel đó như thế nào.
    • Cá nhân tôi thấy Xcode vừa tuyệt vừa tệ. Khi ở VS Code thì tôi nhớ nó, nhưng khi ở trong Xcode thì tôi lại ghét nó; không biết nói vậy có hợp lý không.
      Nó cho cảm giác như những IDE nặng nề ngày xưa, càng thuận theo nó thì càng thấy dễ chịu hơn, nhưng đồng thời vẫn có cảm giác mình không nắm quyền kiểm soát.
      Nếu Apple chịu quan tâm, chắc chắn họ đã có thể làm nó nhanh nhạy hơn, nếu không bằng VS Code thì cũng được một nửa, và chắc chắn nó có thể tốt hơn hiện tại.
      Chỉ riêng việc hỗ trợ key binding Vim tệ hại cũng đủ khiến tôi bực. Ví dụ phần lớn thao tác như c hay r không thể thực hiện lặp lại.
      Tôi không biết khi đó bạn dùng SwiftUI hay đang vật lộn với storyboard của UIKit, nhưng cái sau là trải nghiệm tệ nhất, tôi không muốn khuyên dùng kể cả với kẻ thù.
      SwiftUI tuy vẫn ở giai đoạn đầu và còn nhiều chỗ cần trau chuốt, nhưng so với nó thì cảm giác như tương lai.
  • Trước đây có lần tôi phải thiết lập tài khoản nhà phát triển Apple để đánh dấu một trong các app của chính quyền địa phương chúng tôi là thuộc sở hữu của chúng tôi.
    Tôi không biết vì sao các app khác không cần, nhưng dù sao cũng phải làm vậy, và đó là một trải nghiệm khá kinh khủng.
    Trước tiên cần có tài khoản Apple, và vì không muốn dùng tài khoản cá nhân nên tôi phải tạo một tài khoản công việc mới.
    Không thể tạo “tài khoản tổ chức” nên nó bị gắn với cá nhân tôi; may là tôi có một chiếc iPhone cũ sắp bỏ nên có thể dùng nó.
    Sau đó tôi chờ vài ngày để Apple xác minh danh tính, về cơ bản là Apple gọi cho người tôi ghi là sếp và người đó xác nhận đúng là tôi.
    Tôi hy vọng họ đã kiểm tra thêm, nhưng không chắc; tiếng Anh của những người gọi còn kém hơn cả chúng tôi, nên ít nhất tình huống đó cũng khá buồn cười.
    Tiếp theo phải thiết lập thanh toán, vì không hiểu sao muốn có tài khoản nhà phát triển Apple thì phải trả tiền.
    Số tiền đó có vẻ chẳng đáng kể trong toàn bộ ngân sách của một thành phố 60 nghìn dân, nhưng vì là đăng ký nước ngoài và Apple không cung cấp cách xử lý như một giao dịch B2B có thể dễ dàng đăng ký với cơ quan thuế địa phương, nên năm nào nó cũng bị đưa vào diện xem xét.
    Thanh toán cũng chỉ chấp nhận thẻ tín dụng, và thẻ tổ chức cũng gắn với một người thật, nên cần có người phụ trách gia hạn.
    Con người thì chuyển việc, còn muốn đổi chủ sở hữu thì Apple và người thật phải liên hệ với nhau, nên có thể tưởng tượng chuyện đó “vui” đến mức nào.
    Đây là chuyện vài năm trước nên có thể đã thay đổi, nhưng trong hơn 300 giải pháp IT doanh nghiệp tôi từng xử lý, không có gì tệ như Apple.
    Công bằng mà nói, tôi là lập trình viên nên cũng không biết vì sao việc này lại rơi vào tay mình, và có thể phía vận hành IT gặp những chuyện như vậy thường xuyên hơn.

    • Bây giờ có lẽ còn tệ hơn. Họ liên tục thêm rào cản để ngăn người ta đăng app lên “hệ sinh thái”.
      Ngoại trừ trường hợp là các tập đoàn lớn ở Mỹ có thể xử lý giấy tờ dễ dàng.
    • Giờ vẫn y như vậy. Khi thiết lập tài khoản nhà phát triển, tôi bị kẹt trong một vòng lặp lỗi trên iPhone, đội hỗ trợ thì không hiểu chuyện gì đang xảy ra, rồi khoảng 6 tháng sau tự nhiên nó hoạt động.
      Vẫn rất ngẫu nhiên. Có thể xong ngay, hoặc nếu không may gặp bug ngẫu nhiên trong quy trình này thì sẽ thất bại trong thời gian dài.
    • Theo tôi biết, chính phủ và tổ chức phi lợi nhuận có thể được miễn phí thành viên $99 Developer Program.
      Tôi không biết chương trình này bắt đầu từ khi nào, nhưng không phải mới gần đây.
    • Nếu làm bây giờ thì về mặt mua sắm doanh nghiệp có thể dễ hơn nhiều. Dạo này người ta thường phát hành số thẻ ảo dùng một lần cho từng dịch vụ.
  • Thỉnh thoảng tôi lại quên mất web/www ban đầu đã từng mở đến mức nào, và ngay cả bây giờ nhìn chung vẫn mở đến mức nào nếu so với “hệ sinh thái ứng dụng” do Apple và Google độc quyền
    Tất nhiên có “đám mây”, nhưng không có gì ngăn bạn thuê máy chủ rồi tự host thứ của mình
    Nếu không ổn thì rút ra khỏi đó và thuê máy chủ khác là được. Có hiệu ứng khóa chân và có thể không dễ, nhưng không phải là không thể
    Nhìn trên toàn bộ hệ sinh thái ứng dụng thì chỉ có 2 lựa chọn, và đúng nghĩa là phụ thuộc vào lòng nhân từ của họ
    Cá nhân tôi sẽ không bao giờ đặt cả doanh nghiệp vào một “app” duy nhất. Nếu khán giả thật sự yêu cầu thì có thể để app như một phương tiện phụ nhỏ, nhưng chỉ đến thế thôi
    Tôi ghét những sản phẩm ép tôi dùng app trên thiết bị di động. Thà quay lại kiểu m.website.com còn hơn, và tôi muốn tránh hẳn toàn bộ hệ sinh thái ứng dụng

    • Nếu 2 bên đó là những bên tôi đang nghĩ tới, thì một trong số đó là nơi có chiếc búa trục xuất dẫn vào hố đen hỗ trợ khách hàng
      Chỉ sau một đêm, vì bất kỳ lý do nào hoặc chẳng vì lý do gì, bạn có thể rơi vào cảnh “phải lên trang nhất HN để cầu cứu”
      Tôi cầu mong làn sóng sideloading mới ở EU sẽ khơi dậy các yêu cầu tương tự ở Mỹ, nhưng đồng thời cũng hiểu rõ rằng điều đó chỉ có thể xảy ra nếu có đủ nhiều người biết và quan tâm đến ý nghĩa của “khu vườn đóng” hay “sideloading”
  • Về lý thuyết web rất tuyệt, nhưng vì môi trường trình duyệt chỉ cung cấp quá cơ bản, nên nếu bạn đã quen với trải nghiệm phát triển kiểu “có sẵn pin” như trên nền tảng Apple, thì nó không hấp dẫn lắm với tư cách một nền tảng ứng dụng
    Trên macOS, ngay cả các ứng dụng mạnh mẽ và trau chuốt cũng chỉ có số dependency và dependency con đếm trên đầu ngón tay, và nếu chịu khó một chút thì thậm chí có thể phát triển mà không cần cái nào
    Ngược lại, một webapp tương đương sẽ có từ hàng chục đến hàng trăm dependency để lấp các khoảng trống chức năng
    Ví dụ, tôi không hiểu vì sao trình duyệt lại không thể cung cấp sẵn một list/table view cơ bản có khả năng tái sử dụng cell hiệu quả, với rất ít hoặc thậm chí không cần JavaScript
    Việc phải cuộn qua hàng trăm đến hàng nghìn mục mà không làm thiết bị giật lag hoặc cạn bộ nhớ không phải là chuyện hiếm
    AppKit, UIKit, SwiftUI, Android Framework, Compose, và có lẽ cả Flutter đều xử lý tốt việc này mặc định, nhưng trên trình duyệt thì chỉ vì tính năng rất cơ bản này mà bạn phải kéo thư viện vào hoặc tự viết code
    Cộng thêm vấn đề quản lý package và công cụ nói chung, thì trong khi các giải pháp đến rồi đi, cùng một vấn đề gốc rễ vẫn dai dẳng tồn tại

    • Tôi thấy trải nghiệm phát triển bằng Electron tốt hơn nhiều so với phát triển cho Apple UI
      Tôi cũng đã làm khá nhiều app iOS/iPad từ 15 năm trước
      Điểm hay của web là thường có thư viện hoặc framework phù hợp với yêu cầu. Electron là một ví dụ
      Phía Apple thì nhiều khi không có thư viện tốt, còn SwiftUI thì quá nhiều bug
      React đơn giản là hoạt động tốt và về mặt khái niệm cũng đơn giản hơn. Ràng buộc dữ liệu hai chiều là một ý tưởng tệ
      Apple có ý nghĩ rằng họ làm mọi thứ đơn giản hơn, nhưng thực tế thường là làm mọi thứ rườm rà và khó khăn hơn
    • Web được tạo ra với mục tiêu tài liệu, nên giả định là trong file HTML đã có sẵn toàn bộ dữ liệu cần hiển thị
      Bảng đã được server điền sẵn dữ liệu cần thiết và theo đúng thứ tự
      Vì vậy không cần tái sử dụng cell và row, và dù có hàng nghìn dòng thì dữ liệu cũng chỉ ở mức KB nên hoạt động nhanh nhạy
    • Flutter có engine render riêng nên API mặc định khá mạnh
      Nếu tính cả các lựa chọn thay thế như WebAssembly và Flutter, việc trình duyệt thiếu chức năng cơ bản lẽ ra không còn là vấn đề nữa
    • Tôi không hiểu JavaScript thì có vấn đề gì
  • Tôi không nghĩ nói rằng nhà phát triển chẳng mang lại gì cho Apple là đúng
    Nếu iPhone không có app bên thứ ba, Apple đã bán được ít điện thoại hơn rất nhiều
    Về lý thuyết, nhiều app có thể chuyển sang web, nhưng thực tế vẫn là app bên thứ ba khiến iPhone đáng sở hữu hơn rất nhiều
    Khi có cạnh tranh đúng nghĩa, nhà sản xuất hệ điều hành sẽ nỗ lực thu hút nhà phát triển. Cứ nhớ lại video “developers developers developers” của Ballmer ngày xưa là được
    Vì họ biết nhà phát triển làm tăng giá trị cho nền tảng và ảnh hưởng đến lựa chọn của người tiêu dùng
    Vấn đề ngày nay là không có cạnh tranh có ý nghĩa
    Dù quy định của Apple ra sao, nhà phát triển vẫn phải cung cấp thứ gì đó cho iPhone, và Apple có thể yên tâm rằng gần như không có khả năng một nền tảng di động thứ ba đứng vững
    Apple biết điều này, và bằng các chính sách nghiêm ngặt, họ đã lật ngược tình thế một cách tàn nhẫn
    Dù nhà phát triển đóng vai trò lớn trong việc khiến iPhone đáng sở hữu, Apple lại đánh thuế lên toàn bộ doanh thu như thể họ đang ban ơn khi cho phép nhà phát triển tiếp cận khách hàng iPhone
    Đây là lạm dụng vị thế thị trường, và như bài blog nói, ngoài việc phân phối qua web thì không có nhiều việc có thể làm
    Nó không hoàn hảo, nhưng ngoài quy định pháp lý ra thì đó là lựa chọn thay thế có ý nghĩa duy nhất, và Apple không có lý do gì để tự từ bỏ hàng chục tỷ đô la doanh thu kiếm được từ việc đánh thuế nhà phát triển app, nên họ sẽ làm đủ mọi cách để né quy định
    Tôi hy vọng web sẽ mạnh lên như một cách né các quy tắc phân phối app mang tính lạm dụng

  • Mỗi ngày tôi đều nghĩ web tuyệt vời đến mức nào, và thật đáng tiếc khi Apple đã cố làm hỏng web nhiều nhất có thể bằng cách khiến nhà phát triển tạo app iOS thay vì webapp
    Nếu không có App Store, web đã tốt hơn rất nhiều
    Đã có thể có nhiều sự đa dạng hơn trong tiêu thụ nội dung, nguồn gốc mạng xã hội, gợi ý thuật toán và trải nghiệm số
    Web chạy ở mọi nơi, và cũng có rất nhiều API tuyệt vời để tạo các ứng dụng nhập vai/thế hệ tiếp theo như WebXR
    Nhưng nếu ai đó tạo một app WebXR trên site của mình rồi bán có thu phí thì Apple không kiếm được tiền, nên Apple sẽ không bao giờ quảng bá những webapp như vậy
    Về dài hạn, web sẽ không chết. Các công ty sẽ bước vào, vắt kiệt lợi nhuận rồi biến mất, nhưng web không chết

  • Apple cung cấp hàng nghìn API giúp việc phát triển cho nền tảng trở nên dễ dàng, tạo ra ngôn ngữ lập trình riêng tích hợp tốt với nền tảng, và còn có một IDE tích hợp hoàn chỉnh hoạt động cùng cả hai
    Đúng vậy, “bạn” ạ. Họ không quan tâm đến bạn trừ khi bạn phát triển cho nền tảng của họ
    Mà ai trách được chứ? Những thứ trên là các khoản đầu tư cực kỳ tốn kém và mất rất nhiều thời gian

    • Bạn bỏ sót điểm là họ khóa chặt mọi thứ không thuộc các công cụ đó
      Tôi từng thử phát triển ứng dụng trực tiếp trên macOS mà không dùng Swift và công cụ của Apple, và đó là một cực hình
      Họ đã bỏ rơi và ghim phiên bản OpenGL đến mức khó giải thích nếu không phải để thúc đẩy công cụ của chính họ
      Ngay cả việc tải một DLL bên ngoài cũng gần như bất khả thi
      Bất cứ thứ gì cross-platform đều phải hạ xuống hệ công cụ của Apple, như việc chuyển Vulkan sang Metal
      macOS là một trường hợp còn dị biệt và đặc thù hơn mọi bản phân phối Linux
      Nhìn sang việc phát triển trên Windows dễ đến mức nào thì thật đáng kinh ngạc. Phía Microsoft thì hầu như mọi thứ đều cross-platform
      Trong những thứ của Apple được nhắc đến, không có thứ nào cho phép làm việc theo cách độc lập nền tảng
      Trong khi đó Windows vẫn hỗ trợ công nghệ riêng như DirectX, nhưng cũng cho phép chạy trực tiếp Vulkan, OpenGL, v.v.
    • Tôi cũng khá tích cực về việc phát triển cho Apple và cũng thích Xcode. Ít nhất là từ sau SwiftUI; còn Interface Builder thì tôi không tài nào học nổi
      Nhưng việc tác giả bắt đầu từ làm ứng dụng âm nhạc là một điểm rất có ý nghĩa. API âm thanh của Apple đúng là một mớ hỗn độn
      Media Player, AVPlayer, Core Audio, AVFoundation, AVAudioEngine, v.v. giống như các nhóm cạnh tranh từ tận thời NeXT mỗi nhóm dùng thư viện riêng, rồi bằng cách nào đó tất cả đều sống sót đến thời iPhone
      Trong thời gian phong tỏa vì COVID, tôi đã dành khoảng ba tháng để cố làm một trình phát Shoutcast/Icecast, và đó thật sự là đau khổ
    • Apple không phát triển các API đó vì thiện chí. Đó là chiến lược khóa chân
      Họ đã khiến việc viết mã native cross-platform chạy trên iOS gần như bất khả thi, và đã làm mọi thứ trong giới hạn chính trị cho phép để web app không thể cạnh tranh với ứng dụng native
    • Theo tiêu chí đó thì tôi e rằng Oracle sẽ dễ dàng chiến thắng với tư cách công ty chăm lo cho lập trình viên nhất. Vì họ cũng đã thực hiện những khoản đầu tư cực kỳ tốn kém và mất thời gian mà
    • Họ đâu cần phải tạo ra ngôn ngữ riêng. Đó cũng là một phần của hiệu ứng khóa chân
  • Tôi thích thái độ lành mạnh của tác giả khi đối diện với các tập đoàn lớn. Đó là kỹ năng sinh tồn cơ bản thời hiện đại
    Nếu được tự do, tôi muốn không phải cài bất kỳ ứng dụng nào trên iPhone hay iPad, nhưng vì các hạn chế nền tảng nên thực tế lại cần
    Tôi từng thấy web app X/Twitter trên Safari không phát video, dù đã tắt Lockdown Mode cho X
    Tôi muốn biết đây là lỗi của Apple vì tạo ra sự không nhất quán nền tảng, hay là chủ ý của X nhằm khiến người dùng cài ứng dụng
    Tôi chuyên về deep learning và LLM, nhưng cũng luôn thích phát triển web
    Điều cản trở là công cụ quá phức tạp
    Dù vậy, một người quen của tôi viết khá nhiều về ClojureScript + Dart, nên tôi đang nghĩ có thể thử xem
    Tôi muốn tìm một stack web app đơn giản, có thể học trong vài ngày và được hỗ trợ tốt; nếu có gợi ý thì rất hay

    • Tốt hơn là nên bỏ qua các bài viết đi tìm “stack hoàn hảo”. Stack hoàn hảo không tồn tại, và cũng không phải điều kiện thiết yếu để phát hành phần mềm tuyệt vời mà người dùng thực sự thấy có giá trị
      Một phần lớn của phát triển web là hiểu rõ trình duyệt, và web.dev là tài liệu rất tốt
      Sau đó thì học React + TypeScript là được. react.dev mới cũng tốt
      React không hoàn hảo, nhưng với tư cách một mô hình để xây dựng UI thì nó quá tốt, đến mức Apple cũng học theo khi tạo SwiftUI
      Cứ dùng Vite rồi bắt đầu code
      Điều tôi muốn khuyên nhất là hãy học nghiêm túc các tài liệu đó. Bắt đầu từ trang đầu của tài liệu và đi theo từng bước cho đến hết
      Tuy nhiên, không có nhiều thứ có thể học chỉ trong vài ngày. Công việc frontend khó là có lý do chính đáng