Làm cách nào để quyết định giữa MonoTouch và Objective-C? [đóng cửa]

Sau khi ngồi qua một phiên hôm nay trên Mono tại một sự kiện .Net địa phương, việc sử dụng MonoTouch đã được 'chạm vào' như một cách thay thế để phát triển iPhone. Rất thoải mái trong C # và .Net, nó có vẻ như là một lựa chọn hấp dẫn, mặc dù có một số điểm khó hiểu của ngăn xếp Mono. Tuy nhiên, vì MonoTouch có giá 400 đô la, tôi hơi khó chịu nếu đây là cách để phát triển iPhone.

Bất cứ ai cũng có kinh nghiệm phát triển với MonoTouch và Objective-C, và nếu vậy thì việc phát triển với MonoTouch có đơn giản và nhanh chóng hơn nhiều so với việc học Objective-C, và lần lượt trị giá 400 đô la?

Gần đây tôi đã thấy câu hỏi này (và các biến thể của nó). Điều làm tôi ngạc nhiên là tần suất mọi người trả lời, nhưng có bao nhiêu câu trả lời .

Tôi có sở thích của mình (tôi thích cả hai ngăn xếp), nhưng đây là lúc hầu hết các "câu trả lời" bắt đầu sai. Nó không phải là về những gì tôi muốn (hoặc những gì người khác muốn).

Đây là cách tôi đi về việc xác định giá trị của MonoTouch - rõ ràng tôi không thể khách quan, nhưng tôi nghĩ rằng điều này khá nhiệt tình:

• Đây là cho vui hay kinh doanh? Nếu bạn muốn được tư vấn trong lĩnh vực này, bạn có thể kiếm lại $ 399 rất nhanh.

• Bạn có muốn tìm hiểu nền tảng từ trong ra ngoài, hoặc bạn "chỉ" muốn viết ứng dụng cho nó?

• Bạn có thích .Net đủ để sử dụng ngăn xếp dev khác nhau sẽ mang lại niềm vui cho bạn không? Một lần nữa, tôi thích cả hai ngăn xếp (Apple và Mono), nhưng đối với tôi MonoTouch làm cho trải nghiệm đó thú vị hơn nhiều. Tôi đã không ngừng sử dụng các công cụ của Apple, nhưng điều đó chủ yếu là vì tôi thực sự thích cả hai ngăn xếp . Tôi yêu iPhone, và tôi yêu .Net. Trong trường hợp đó, đối với tôi, MonoTouch là một người không có trí tuệ.

• Bạn có cảm thấy thoải mái khi làm việc với C không? Tôi không có nghĩa là Objective-C, nhưng C - nó quan trọng bởi vì Objective-C là C. Đây là một phiên bản OO đẹp, lạ mắt, thân thiện, nhưng nếu con trỏ cho bạn những con bò cái, MonoTouch là bạn của bạn. Và đừng lắng nghe những người không tán thành, những người nghĩ rằng bạn là một nhà phát triển nếu điều đó xảy ra rằng bạn không thích con trỏ (hoặc C, v.v.). Tôi đã từng đi bộ xung quanh với một bản sao Tài liệu tham khảo bỏ túi BIOS ROM của IBM và khi tôi đang viết lắp ráp và buộc máy tính của mình vào các chế độ video vui nhộn và viết các bit kết xuất phông chữ của riêng mình cho chúng và các hệ thống cửa sổ (phải thừa nhận là rác rưởi), tôi đã không Chúng tôi nghĩ rằng các nhà phát triển QuickBasic là những người ồn ào. Tôi đãmột dev QuickBasic (ngoài phần còn lại). Không bao giờ nhượng bộ cho mọt sách mọt sách. Nếu bạn không thích C, và nếu bạn không thích con trỏ, và nếu bạn muốn tránh xa việc quản lý bộ nhớ thủ công nhất có thể (và, công bằng mà nói, điều đó không tệ chút nào trong ObjC), sau đó. .. MonoTouch. Và đừng lấy bất kỳ guff nào cho nó.

• Bạn có muốn nhắm mục tiêu người dùng hoặc doanh nghiệp? Nó không quan trọng với tôi, nhưng vẫn có những người ở đó trên Edge và thực tế là: bạn có thể tạo gói tải xuống nhỏ hơn nhiều nếu bạn sử dụng ngăn xếp của Apple. Tôi đã chơi xung quanh với MonoTouch và tôi có một ứng dụng nhỏ khá hay, sau khi được nén, xuống còn khoảng 2,7 MB (khi gửi ứng dụng của bạn để phân phối, bạn nén nó - khi các ứng dụng được tải xuống từ cửa hàng, chúng ' được nén lại - vì vậy khi tìm hiểu xem ứng dụng của bạn có xuất hiện dưới giới hạn OTA 10 MB hay không, hãy nén trình hút trước - bạn sẽ ngạc nhiên với MonoTouch). Nhưng, hạnh phúc sang một bên, nửa meg so với gần ba (ví dụ) là điều có thể quan trọng với bạn nếu bạn nhắm mục tiêu người dùng cuối. Nếu bạn đang nghĩ về công việc doanh nghiệp, một vài MB sẽ không thành vấn đề. Và, chỉ cần rõ ràng - tôi sẽ sớm gửi một ứng dụng dựa trên MT đến cửa hàng và tôi không gặp vấn đề gì với kích thước. Không làm phiền tôi chút nào. Nhưng nếu đó là điều đáng quan tâmbạn , sau đó ngăn xếp của Apple thắng cái này

• Làm bất kỳ công việc XML? MonoTouch. Giai đoạn = Stage.

• Thao tác chuỗi? Ngày thao túng? Hàng triệu thứ nhỏ khác mà chúng ta đã quen với các khung công việc tất cả mọi thứ-VÀ-nhà bếp-bồn rửa của .Net? MonoTouch.

• Dịch vụ web? MonoTouch.

• Cú pháp, cả hai đều có lợi thế của họ. Mục tiêu-C có xu hướng dài dòng hơn khi bạn phải viết nó . Bạn sẽ thấy mình viết mã bằng C # bạn sẽ không phải viết bằng ObjC, nhưng nó đi cả hai chiều. Chủ đề đặc biệt này có thể lấp đầy một cuốn sách. Tôi thích cú pháp C #, nhưng sau khi vượt qua phản ứng ban đầu này là thế giới khác với Objective-C, tôi đã học cách tận hưởng nó khá nhiều. Tôi làm cho niềm vui của nó một chút trong cuộc đàm phán (nó là lạ cho devs người đang sử dụng để C # / Java / etc.), Nhưng sự thật là tôi có một Objective-C hình tại chỗ trong trái tim tôi mà làm cho tôi hạnh phúc.

• Bạn có kế hoạch sử dụng Interface Builder không? Bởi vì, ngay cả trong phiên bản đầu tiên này, tôi thấy mình làm việc ít hơn nhiều để xây dựng UI của mình với IB và sau đó sử dụng chúng trong mã. Có cảm giác như toàn bộ các bước bị thiếu trong cách thực hiện Mục tiêu-C / IB và tôi khá chắc chắn rằng vì toàn bộ các bước bị thiếu trong cách thực hiện Mục tiêu-C / IB. Cho đến nay, và tôi không nghĩ rằng mình đã thử nghiệm đầy đủ, nhưng cho đến nay , MonoTouch là người chiến thắng ở đây vì bạn phải làm ít hơn bao nhiêu công việc.

• Bạn có nghĩ thật thú vị khi học các ngôn ngữ và nền tảng mới không? Nếu vậy, iPhone có rất nhiều thứ để cung cấp và ngăn xếp của Apple có thể sẽ đưa bạn ra khỏi vùng thoải mái của bạn - điều mà đối với một số nhà phát triển là thú vị (Xin chào - Tôi là một trong những nhà phát triển đó - Tôi nói đùa về nó và cho Apple đã có một thời gian khó khăn, nhưng tôi đã có rất nhiều niềm vui khi học phát triển iPhone thông qua các công cụ của Apple).

Có rất nhiều điều để xem xét. Giá trị rất trừu tượng. Nếu chúng ta đang nói về chi phí và liệu nó có xứng đáng hay không, câu trả lời sẽ thuộc về mục đầu tiên của tôi: nếu đây là cho công việc và nếu bạn có thể có được công việc, bạn sẽ kiếm lại tiền ngay.

Vì vậy, ... đó là về khách quan như tôi có thể. Đây là một danh sách ngắn về những gì bạn có thể tự hỏi mình, nhưng nó là điểm khởi đầu.

Cá nhân (hãy bỏ sự khách quan trong giây lát), tôi yêu và sử dụng cả hai. Và tôi rất vui vì tôi đã học được Apple stack đầu tiên. Tôi dễ dàng hơn để đứng dậy và chạy với MonoTouch khi tôi đã biết đường đi khắp thế giới của Apple. Như những người khác đã nói, bạn vẫn sẽ làm việc với CocoaTouch - nó sẽ ở trong một môi trường bị đóng băng .Net.

Nhưng có nhiều hơn thế. Những người chưa sử dụng MonoTouch có xu hướng dừng lại ở đó - "Đó là một gói bọc blah blah blah" - đó không phải là MonoTouch.

MonoTouch cung cấp cho bạn quyền truy cập vào những gì mà Cốc Cốc cung cấp, đồng thời cho phép bạn truy cập vào những gì (một tập hợp con) .Net phải cung cấp, một số IDE cảm thấy thoải mái hơn (Tôi là một trong số họ), tích hợp tốt hơn với Trình tạo giao diện và mặc dù bạn không thể quên hoàn toàn việc quản lý bộ nhớ, bạn sẽ có được một mức độ chậm trễ.

Nếu bạn không chắc chắn, hãy lấy ngăn xếp của Apple (miễn phí) và lấy ngăn xếp của MonoTouch (miễn phí). Cho đến khi bạn tham gia chương trình phát triển của Apple, cả hai sẽ chỉ chạy với trình giả lập, nhưng điều đó đủ để giúp bạn biết liệu bạn có thích cái này hơn cái kia hay không, và liệu MonoTouch có, với bạn, trị giá 399 đô la hay không.

Và đừng nghe những người quá khích - họ có xu hướng là những người chưa sử dụng công nghệ mà họ đang chống lại :)

Có rất nhiều tin đồn trong bài đăng này từ các nhà phát triển chưa thử MonoTouch và Objective-C. Nó dường như chủ yếu là các nhà phát triển Objective-C chưa bao giờ thử MonoTouch.

Tôi rõ ràng là thiên vị, nhưng bạn có thể kiểm tra xem cộng đồng MonoTouch đã làm gì:

http://xamarin.com

Ở đó bạn sẽ tìm thấy một số bài viết từ các nhà phát triển đã phát triển trong cả Objective-C và C #.

Vì vậy, câu trả lời của tôi cho một câu hỏi tương tự trước đó là tìm hiểu Objective-C. (Ngoài ra, đừng quên hỗ trợ gỡ lỗi)

Điều này có thể sẽ xúc phạm một số nhưng thành thật mà nói, nếu bạn sẽ thực hiện bất kỳ sự phát triển nghiêm túc nào, bạn nên học Objective-C. Không biết Objective-C trong phát triển iPhone sẽ chỉ là một trở ngại. Bạn sẽ không thể hiểu nhiều ví dụ; bạn phải đối phó với những điều kỳ quặc của Mono trong khi nếu bạn có kiến ​​thức làm việc về Objective-C, bạn có thể nhận được nhiều hơn từ tài liệu nền tảng.

Cá nhân, tôi không hiểu vị trí nói tăng lượng thông tin bạn cần có lợi cho việc sử dụng Mono trên ngôn ngữ bản địa của nền tảng. Nó có vẻ hơi phản tác dụng với tôi. Tôi nghĩ rằng nếu đây là một đề xuất rất tốn kém (học một ngôn ngữ mới) thì có thể đáng để dành thời gian cho các khái niệm lập trình cơ bản để học ngôn ngữ mới là một đề xuất khá rẻ.

Một người dùng khác cũng đã viết điều này:

Monotouch là dễ dàng hơn cho bạn bây giờ. Nhưng khó hơn về sau.

Ví dụ, điều gì xảy ra khi hạt giống mới xuất hiện bạn cần kiểm tra nhưng phá vỡ MonoTouch vì một số lý do?

Bằng cách gắn bó với Mono, bất cứ khi nào bạn tìm kiếm tài nguyên cho các khung công tác, bạn phải dịch một cách tinh thần vào cách bạn sẽ sử dụng chúng với Mono. Các tệp nhị phân ứng dụng của bạn sẽ lớn hơn, thời gian phát triển của bạn không nhanh hơn sau vài tháng vào Objective-C và các nhà phát triển ứng dụng khác sẽ có lợi thế hơn nhiều so với bạn vì họ đang sử dụng nền tảng gốc.

Một cân nhắc khác là bạn đang muốn sử dụng C # vì bạn quen thuộc với ngôn ngữ hơn Objective-C. Nhưng phần lớn đường cong học tập cho iPhone không phải là Objective-C, đó là các khung - mà bạn cũng sẽ phải gọi bằng C #.

Đối với bất kỳ nền tảng nào, bạn nên sử dụng nền tảng thể hiện trực tiếp triết lý thiết kế của nền tảng đó - trên iPhone, đó là Objective-C. Hãy suy nghĩ về điều này từ góc độ ngược lại, nếu một nhà phát triển Linux đã từng lập trình trong GTK muốn viết các ứng dụng Windows, bạn có nghiêm túc khuyên họ không nên sử dụng C # và gắn bó với GTK không vì họ sẽ dễ dàng làm điều đó hơn?

Sử dụng Mono không phải là một cái nạng. Có rất nhiều thứ mà nó bổ sung cho HĐH iPhone. LINQ, WCF, mã có thể chia sẻ giữa ứng dụng Silverlight, trang ASP.NET, ứng dụng WPF, ứng dụng Windows Form và cũng có đơn âm cho Android và nó cũng sẽ hoạt động cho Windows Mobile.

Vì vậy, bạn có thể dành nhiều thời gian để viết Objective-C (Bạn sẽ thấy từ nhiều nghiên cứu trong đó mã mẫu chính xác trong C # ít hơn đáng kể để viết so với OC) và sau đó GIẢI QUYẾT tất cả cho các nền tảng khác. Đối với tôi, tôi đã chọn MonoTouch vì Ứng dụng đám mây tôi đang viết sẽ có nhiều giao diện, iPhone chỉ là một trong số đó. Truyền dữ liệu WCF từ đám mây sang ứng dụng MonoTouch cực kỳ đơn giản. Tôi có các thư viện cốt lõi được chia sẻ giữa các nền tảng khác nhau và sau đó chỉ cần viết một lớp trình bày đơn giản cho các triển khai iPhone / WinMobile / Android / SilverLight / WPF / ASP.NET. Tái tạo tất cả trong Objective-C sẽ là một sự lãng phí rất lớn thời gian cho cả nhà phát triển và bảo trì ban đầu khi sản phẩm tiếp tục tiến lên vì tất cả các chức năng sẽ phải được sao chép thay vì sử dụng lại.

Những người đang xúc phạm MonoTouch hoặc nói bóng gió rằng người dùng cần một cái nạng đang thiếu Bức tranh lớn về ý nghĩa của việc có khung .NET trong tầm tay của bạn và có thể không hiểu sự phân tách logic hợp lý khỏi cách trình bày được thực hiện theo cách mà có thể được tái sử dụng trên các nền tảng và thiết bị.

Mục tiêu-C là thú vị và rất khác với nhiều ngôn ngữ phổ biến. Tôi thích một thử thách và học các cách tiếp cận khác nhau ... nhưng không phải khi làm như vậy cản trở tiến trình của tôi hoặc tạo ra mã hóa lại không cần thiết. Có một số điều thực sự tuyệt vời về khung SDK iPhone, nhưng tất cả sự tuyệt vời đó đều được hỗ trợ đầy đủ với MonoTouch và cắt bỏ tất cả quản lý bộ nhớ thủ công, giảm số lượng mã cần thiết để thực hiện các tác vụ tương tự, cho phép tôi sử dụng lại các hội đồng của mình và giữ cho các tùy chọn của tôi mở để có thể di chuyển đến các thiết bị và nền tảng khác.

Tôi đã chuyển. Monotouch hãy để tôi viết ứng dụng nhanh nhất ít nhất 3-4 lần (4 ứng dụng mỗi tháng so với 1 cũ của tôi mỗi tháng trong Obj C)

Rất ít gõ.

Chỉ là kinh nghiệm của tôi.

Nếu đây là ứng dụng iPhone duy nhất bạn từng phát triển và bạn cũng không có hứng thú phát triển ứng dụng Mac, thì MonoTouch có lẽ đáng giá.

Nếu bạn nghĩ rằng bạn sẽ phát triển thêm nhiều ứng dụng cho iPhone hoặc sẽ muốn thực hiện một số phát triển riêng của Mac, thì có lẽ đáng để học Objective-C và các khung công tác liên quan. Thêm vào đó, nếu bạn là kiểu lập trình viên thích học hỏi những điều mới, thì đó là một mô hình mới thú vị để nghiên cứu.

Cá nhân tôi nghĩ rằng bạn sẽ có thời gian tốt hơn khi học Objective-C.

Nói ngắn gọn:

• "Mục tiêu học tập-C" không gây khó khăn như bạn nghĩ, thậm chí bạn có thể tận hưởng nó chỉ sau vài tuần đầu tiên
• Bạn đã quen thuộc với cú pháp "kiểu C" với rất nhiều * & () {}; mọi nơi
• Apple đã làm rất tốt việc ghi chép lại mọi thứ
• Bạn sẽ tương tác với iPhone theo cách Apple dự định, điều đó có nghĩa là bạn sẽ nhận được lợi ích trực tiếp từ nguồn không thông qua một số bộ lọc.

Tôi đã phát hiện ra rằng các dự án như Unity và MonoTouch có nhiệm vụ "tiết kiệm thời gian cho bạn" nhưng cuối cùng bạn sẽ cần học ngôn ngữ cụ thể theo tên miền của họ và đôi khi sẽ phải thực hiện các bước bên lề. Tất cả những điều đó có thể sẽ đưa bạn đến chừng nào nó còn học được ngôn ngữ mà bạn đang cố gắng tránh học (theo thời gian lịch). Cuối cùng, bạn đã không tiết kiệm được thời gian và bạn đã kết hợp chặt chẽ với một số sản phẩm.

EDIT: Tôi không bao giờ có ý ám chỉ bất cứ điều gì tiêu cực về .NET Tôi tình cờ là một fan hâm mộ lớn của nó. Quan điểm của tôi là việc thêm nhiều lớp phức tạp chỉ vì bạn chưa cảm thấy thoải mái với ký hiệu khung objc kỳ quặc không thực sự có ý nghĩa với tôi.

Cập nhật 2019: 7 năm sau. Tôi vẫn cảm thấy như vậy nếu không muốn nói là như vậy. Chắc chắn, 'ngôn ngữ cụ thể của tên miền' có thể là thuật ngữ sử dụng sai, nhưng tôi vẫn tin rằng viết trực tiếp cho nền tảng bạn đang làm việc và tránh các lớp tương thích và trừu tượng càng nhiều càng tốt. Nếu bạn lo lắng về việc tái sử dụng mã và làm việc lại, nói chung, bất kỳ chức năng nào mà ứng dụng đa nền tảng của bạn cần thực hiện có thể được thực hiện bằng các công nghệ web hiện đại.

Để thêm vào những gì người khác đã nói (tốt!): Cảm giác của tôi là về cơ bản bạn đang nhân đôi số lỗi bạn phải lo lắng, thêm các lỗi trong MonoTouch vào các lỗi đã có trong HĐH iPhone. Cập nhật cho các phiên bản HĐH mới sẽ còn đau đớn hơn bình thường. Yuck, tất cả xung quanh.

Trường hợp hấp dẫn duy nhất tôi có thể thấy cho MonoTouch là các tổ chức có rất nhiều lập trình viên C # và mã C # nằm xung quanh mà họ phải tận dụng trên iPhone. (Loại cửa hàng thậm chí sẽ không nhấp nháy ở mức $ 3500.)

Nhưng đối với bất cứ ai bắt đầu từ đầu, tôi thực sự không thể xem nó là đáng giá hay khôn ngoan.

Ba từ: Linq to SQL

Vâng, nó cũng có giá trị $.

Một cái gì đó tôi muốn thêm vào, mặc dù có một câu trả lời được chấp nhận - ai sẽ nói rằng Apple sẽ không từ chối các ứng dụng có dấu hiệu được xây dựng với Mono Touch?

Tôi sẽ đầu tư thời gian vào Objective-C chủ yếu vì tất cả sự giúp đỡ bạn có thể nhận được từ các trang web như thế này. Một trong những điểm mạnh của Objective-C là bạn có thể sử dụng mã C và C ++, và có rất nhiều dự án ngoài đó đã được thử nghiệm tốt .

Một điều nữa là mã của bạn (ngôn ngữ của sự lựa chọn) sẽ được hỗ trợ bởi apple. Ví dụ, iOS 5.x loại bỏ sự hỗ trợ cho giải pháp của bên thứ ba như MonoTouch? Bạn sẽ nói gì với khách hàng của bạn sau đó?

Có lẽ tốt hơn là sử dụng giải pháp độc lập nền tảng như HTML5 nếu bạn chưa sẵn sàng để chuyển sang Objective-C?

Tôi đã sử dụng MonoTouch được vài tháng rồi, tôi đã chuyển một nửa ứng dụng đã hoàn thành của mình từ ObjectiveC để tôi có thể hỗ trợ Android vào một lúc nào đó trong tương lai.

Đây là kinh nghiệm của tôi:

Các bit xấu:

• Xamarin Studio. Các nhà phát triển Indie như tôi buộc phải sử dụng Xamarin Studio. Nó đang trở nên tốt hơn mỗi tuần, các nhà phát triển rất tích cực trên các diễn đàn xác định và sửa lỗi, nhưng nó vẫn rất chậm, thường xuyên bị treo, có rất nhiều lỗi và việc gỡ lỗi cũng khá chậm.

• Xây dựng thời gian. Việc xây dựng ứng dụng lớn (được liên kết) của tôi để gỡ lỗi trên thiết bị có thể mất vài phút, điều này được so sánh với XCode, triển khai gần như ngay lập tức. Xây dựng cho trình giả lập (không liên kết) nhanh hơn một chút.

• Các vấn đề về MonoTouch. Tôi đã gặp phải sự cố rò rỉ bộ nhớ do xử lý sự kiện và phải đưa vào một số cách khắc phục khá xấu xí để ngăn chặn rò rỉ, chẳng hạn như đính kèm và tách các sự kiện khi vào và rời khỏi chế độ xem. Các nhà phát triển Xamarin đang tích cực xem xét các vấn đề như thế này.

• Thư viện bên thứ 3. Tôi đã dành khá nhiều thời gian để chuyển đổi / ràng buộc các thư viện ObjectiveC để sử dụng trong ứng dụng của mình, mặc dù điều này đang trở nên tốt hơn với phần mềm tự động như Objective Sharpie.

• Các nhị phân lớn hơn. Điều này không thực sự làm phiền tôi nhưng tôi nghĩ tôi sẽ đề cập đến nó. IMO một vài Mb thêm là không có gì những ngày này.

Bit tốt:

• Đa nền tảng. Bạn tôi đang vui vẻ tạo một phiên bản Android cho ứng dụng của tôi từ cơ sở mã lõi của mình, chúng tôi đang phát triển song song và đang cam kết với kho lưu trữ Git từ xa trên Dropbox, điều đó rất tốt.

• .Mạng lưới. Làm việc trong C # .Net đẹp hơn nhiều so với Mục tiêu C IMO.

• MonoTouch. Khá nhiều thứ trong iOS được nhân đôi trong .Net và khá đơn giản để mọi thứ hoạt động.

• Xamarin. Bạn có thể thấy rằng những kẻ này đang thực sự làm việc để cải thiện mọi thứ, làm cho sự phát triển mượt mà và dễ dàng hơn.

Tôi chắc chắn khuyên dùng Xamarin để phát triển đa nền tảng, đặc biệt nếu bạn có tiền để sử dụng các phiên bản Doanh nghiệp hoặc Doanh nghiệp hoạt động với Visual Studio.

Nếu bạn chỉ đang tạo một ứng dụng iPhone sẽ không bao giờ cần trên nền tảng khác và bạn là nhà phát triển Indie, tôi sẽ gắn bó với XCode và Objective C ngay bây giờ.

Là một người có kinh nghiệm với cả C # cũng như Objective-C, tôi muốn nói với hầu hết mọi người, Xamarin sẽ rất đáng đồng tiền bát gạo.

C # là một ngôn ngữ được thiết kế thực sự tốt và API của C # cũng được thiết kế tốt. Tất nhiên, API của Touch Touch (bao gồm cả UIKit) cũng có thiết kế tuyệt vời, tuy nhiên ngôn ngữ có thể được cải thiện theo nhiều cách. Khi viết bằng C #, bạn có thể sẽ có năng suất cao hơn so với viết cùng mã trong Objective-C. Điều này là do một số lý do, nhưng một số lý do sẽ là:

• C # có kiểu suy luận . Kiểu suy luận giúp viết mã nhanh hơn, vì bạn không phải "biết" loại ở phía bên trái của bài tập. Nó cũng làm cho tái cấu trúc dễ dàng hơn và tiết kiệm hơn.

• C # có tính tổng quát , sẽ giảm lỗi so với mã Objective-C tương đương (mặc dù có một số cách giải quyết trong Objective-C, trong hầu hết các tình huống, các nhà phát triển sẽ tránh chúng).

• Gần đây Xamarin đã thêm hỗ trợ cho Async / Await , điều này giúp việc viết mã không đồng bộ rất dễ dàng.

• Bạn sẽ có thể sử dụng lại một phần cơ sở mã trên iOS, Android và Windows Phone.

• MonoTouch phần lớn thực hiện API của Cốc Cốc theo cách rất đơn giản. Vd: NSData, v.v ...).

• Xamarin sẽ cung cấp cho người dùng trải nghiệm bản địa, không giống như các giải pháp như PhoneGap hoặc Titanium.

Bây giờ Objective-C có một số lợi thế so với C #, nhưng trong hầu hết các tình huống, việc viết ứng dụng bằng C # thường sẽ dẫn đến thời gian phát triển ít hơn và mã sạch hơn và ít làm việc hơn để chuyển cùng ứng dụng sang các nền tảng khác. Một ngoại lệ đáng chú ý có thể là các trò chơi hiệu năng cao dựa trên OpenGL.

Chi phí của thư viện MonoTouch hoàn toàn bên cạnh điểm. Lý do bạn không nên sử dụng Mono cho các ứng dụng iPhone của mình, đó là vì nó là một cái nạng. Nếu bạn không thể bận tâm tìm hiểu các công cụ bản địa, thì tôi không có lý do gì để tin rằng sản phẩm của bạn đáng để tải xuống.

Chỉnh sửa: 4/14/2010 Các ứng dụng được viết bằng MonoTouch không đủ điều kiện cho iTunes Store. Điều này là vì nó nên được. Apple đã thấy rất nhiều cổng nông trên Mac, sử dụng các bộ công cụ đa nền tảng như Qt hoặc triển khai lại một phần hộp công cụ System 7 của riêng Adobe, và dài và ngắn thì chúng không đủ tốt.