क्या नेट पर मूल रूप से एक मैक पर .NET 4.0 एप्लिकेशन चलाने का एक समर्थित तरीका है?


11

क्या, यदि कोई हो, तो Microsoft मूल मैक पर नेट 4.0 कोड चलाने के लिए समर्थित विकल्प हैं? हां, मुझे मोनो के बारे में पता है, लेकिन अन्य चीजों के बीच, यह माइक्रोसॉफ्ट को पीछे छोड़ देता है। और सिल्वरलाइट केवल एक वेब ब्राउज़र में काम करता है। VMWare- प्रकार के समाधान में कटौती नहीं होगी।

क्या कोई अर्ध-आधिकारिक उत्तर है कि Microsoft केवल मैक पर .NET का समर्थन क्यों नहीं करता है? ऐसा लगता है कि वे सिल्वरलाइट और / या मोनो खरीद सकते हैं और जल्दी से वहाँ हो सकते हैं। देशी विज़ुअल स्टूडियो की कोई आवश्यकता नहीं; क्रॉस-संकलन और दूरस्थ डिबगिंग ठीक है।

कारण यह है कि जहां मैं काम करता हूं वहां भविष्य के बारे में अनिश्चितता की मात्रा बढ़ रही है जो C # के बजाय C ++ में बहुत अधिक विकास का कारण बन रहा है; C ++ का उपयोग करने के लिए ब्रांड नई परियोजनाएँ चुन रही हैं। कोई भी प्रबंधन को 18 से 24 महीने तक बताना चाहता है कि "माफ़" को मैक (या आईपैड) एक आवश्यकता बन जाना चाहिए। C ++ को सुरक्षित विकल्प के रूप में देखा जाता है, भले ही यह (यकीनन) आज उत्पादकता में नुकसान का मतलब है।


2
किसके सहारे है?

यदि MS इसका समर्थन करता है तो आप वास्तव में इसकी देखभाल क्यों करते हैं? अगर आप मैक को टारगेट करना चाहते हैं तो IMO को इससे ज्यादा फर्क पड़ता है।
वैकल्पिक

C ++ के साथ जाना कोई बुरा विचार नहीं है। आपके पास एक पोर्टेबल कोड बेस हो सकता है और प्रत्येक प्लेटफॉर्म पर देशी जीयूआई का उपयोग कर सकते हैं।
15:30 पर mike30

1
इस पोस्ट को अपडेट करने के लिए ऐसा लगता है कि एमएस ने नोटिस ले लिया है और वे अलग-अलग ओएस पर .NET का समर्थन करना शुरू कर देंगे, हालांकि यह स्पष्ट नहीं है कि यह कैसे किया जाएगा। आप NOV: nevron.com/products-open-vision.aspx (मैं इस कंपनी के लिए काम करता हूं) का उपयोग करके .NET के साथ क्रॉस प्लेटफॉर्म एप्लिकेशन बना सकता हूं। यह आम तौर पर आपको विंडोज़ पर सी # में कोड करने और फिर डब्ल्यूपीएफ, मैक, सिल्वरलाइट और जल्द ही आईओएस और एंड्रॉइड के लिए संकलन करने की अनुमति देता है। इस उत्पाद का एक नि: शुल्क (समुदाय) संस्करण है, इसलिए उत्पादकता और आर्कियन सी ++ के साथ छड़ी करने की आवश्यकता नहीं है।
बॉब मिलनोव

जवाबों:


17

क्या कोई अर्ध-आधिकारिक उत्तर है कि Microsoft केवल मैक पर .NET का समर्थन क्यों नहीं करता है?

सबसे अच्छा जवाब शायद यह है कि आप मैक पर "सिर्फ समर्थन" .NET नहीं करते हैं। आप करोड़ों डॉलर खर्च करते हैं और कई वर्षों तक मैक को .NET पोर्ट करते हैं।

जबकि कुछ चीजें पूरी तरह से प्रबंधित होती हैं और उन्हें पोर्टिंग की आवश्यकता नहीं होती है, ज्यादातर चीजें Win32 एपीआई (विंडोज़, नियंत्रण, जीडीआई +, क्रिप्टोग्राफी, सक्रिय निर्देशिका, COM, उद्यम सेवाओं, डिवाइस एक्सेस, ध्वनि, वीडियो, कोडेक्स, विनफॉर्म, आदि) के आसपास रैपर हैं। आदि)।

इनमें से हर एक को बैकएंड में अमूर्त करना होगा और OSX पर समान मूल पुस्तकालयों के लिए भेजना होगा। बेशक, एक अच्छा साफ-सुथरा मानचित्रण नहीं होने जा रहा है, इसलिए आपको इसे ठीक से काम करने के लिए हैक्स पर हैक भी लिखना होगा।

फिर यह समस्या है कि OSX पर ये API भंगुर हो सकते हैं और Apple बैकवर्ड कम्पैटिबिलिटी में बहुत अच्छा नहीं है, इसलिए आप अपने हैक्स को हर बड़ी रिलीज़ (और कभी-कभी मामूली रिलीज़ और हॉटफ़िक्स) के साथ पुनः प्राप्त करते हैं, जिससे एक उच्च रखरखाव लागत होती है।

मूल रूप से, यह एक जबरदस्त धन है और एक ऐसे प्लेटफॉर्म पर बहुत कम लाभ के लिए काम करता है, जिसका मालिक आपके खिलाफ इसे वैसे भी कर रहा हो। और आप वास्तव में पैसे खर्च नहीं करना चाहते हैं ताकि लोग अपने स्वयं के प्लेटफ़ॉर्म से किसी प्रतियोगी की ओर पलायन कर सकें।

तो आप पार-पार के प्लेटफ़ॉर्म विकल्पों में नहीं बचे हैं:

  • सी ++, जिसे अभी भी भविष्य में पोर्टिंग की आवश्यकता होगी
  • Microsoft समर्थन के लिए ब्राउज़र से बाहर चांदी की रोशनी
  • मोनो, जो .NET के एक स्वस्थ उपसमूह का समर्थन करने के लिए काम करता है, लेकिन Microsoft नहीं है

5
You spend hundreds of millions of dollars and several years porting .NET to the Mac.माफ़ कीजियेगा? यह संख्या थोड़ी अधिक है ... मुझे पूरा यकीन है कि मोनो-फ्रेमवर्क (कई और ओएस के लिए समर्थन के साथ) इतना खर्च नहीं हुआ।
बॉबी

1
@ बॉबी: यही तो मैं सोच रहा हूँ। मोनो + सिल्वरलाइट वहाँ सबसे अधिक लगता है। कम मुख्यधारा के सामान (क्रिप्टोग्राफी, AD, आदि) के लिए कुछ P / Invoke और / या C ++ / CLI में जोड़ें और मुझे लगता है कि आपके पास उचित लागत पर एक उचित समाधान होगा। मेरा तर्क यह है कि Microsoft OSES पर लोगों की मदद करने के लिए पैसा खर्च करना चाहता है; यदि वे नहीं करते हैं, तो लोग विंडोज पर C # /। NET का उपयोग करना बंद कर देंगे।
Ðаn

@ डान: बिल्कुल, माइक्रोसॉफ्ट दुनिया के साथ संगत नहीं करना चाहता है, अन्यथा दुनिया कुछ अलग उपयोग कर सकती है। ;)
बॉबी

15
मोनो फ्रेमवर्क भी पूर्ण, परीक्षणित, प्रलेखित, समर्थित समाधान नहीं है। खुले स्रोत के लिए "अच्छा पर्याप्त" में अंतर है और गुणवत्ता वाले लोग Microsoft से उम्मीद करते हैं। यह आसानी से उनके लिए करोड़ों डॉलर की लागत का होगा जो उपयोगकर्ताओं द्वारा मांग की गई स्तर पर करने के लिए होगा। वे निवेश को कम करने के लिए क्या कर सकते हैं। .NET फ्रेमवर्क के एक लोकप्रिय (और पोर्टेबल) सबसेट को चुनना होगा और बस करना होगा। यही उन्होंने चुना है, वे इसे "सिल्वरलाइट" कहते हैं।
jpobst

@jpobst लेकिन अभी तक ऐसा लग रहा है कि एमएस ने ऐसा ही किया है ... और भी बहुत कुछ?
Ðаn

14

नहीं, Silverlight OS X पर .net का एकमात्र Microsoft विकल्प है। मोनो उतना नहीं "पिछड़ता" है जितना आप सोचते हैं; यह उदाहरण के लिए .Net 4.0 और C # 4 का समर्थन करता है। हालांकि, OS X पर मोनो टूलकिट (WinForms और WPF) का अच्छी तरह से समर्थन नहीं किया गया है। पूरे रेंडरिंग इंजन को फिर से लिखे बिना न तो माइक्रोसॉफ्ट कर सकता था। यह शायद ठीक है, यद्यपि। यदि आप एक देशी मैक ऐप लिखना चाहते हैं, तो आपको एक देशी यूआई (शायद मोनोमाक का उपयोग करके) लिखना चाहिए।


प्रबंधन मोनो विकल्प के साथ जाने के लिए बहुत इच्छुक नहीं लगता है। और यह निश्चित रूप से विंडोज (या?) पर उसी दिन .NET 4.0 का समर्थन नहीं करता था।
Ðаn

क्या WPF (जैसे-जैसे) मोर्चे पर सिल्वरलाइट पहले से ही ज्यादातर नहीं है? हां, मैक लुक और फील पाने के लिए एक्सएएमएल को अलग होना जरूरी है।
19

2
@ डान: जिस तरह से मोनो इन दिनों चलता है, यदि आप Microsoft के रिलीज़ होने पर .NET के नवीनतम संस्करण के लिए एक ऐप विकसित करना शुरू करते हैं, तो मोनो उस समय तक उसी संस्करण का समर्थन करेगा, जब ऐप शिप करने के लिए तैयार है।
आनन।

कवर के तहत @Dan SL और WPF जितना संभव हो उतना विलय करने का प्रयास कर रहे हैं। तकनीकी अंतर हैं लेकिन मूलभूत अवधारणाएं पार मंच हैं।
एरोन मैकिवर

6
यदि आपकी कंपनी प्रबंधन मोनो का उपयोग करने के लिए तैयार नहीं है, तो आप पारंपरिक सी # 4.0 में लिखे गए डेस्कटॉप एप्लिकेशन को इसके साधारण रूप में असमर्थ नहीं बना पाएंगे।
रामहाउंड

5

नहीं, मोनो आपकी सबसे अच्छी शर्त है।

DotGNU जैसी अन्य ओपन सोर्स परियोजनाएं आपकी सेवा कर सकती हैं। http://www.gnu.org/software/dotgnu/ लेकिन इनमें से कोई भी MSFT समर्थित नहीं है।


4

सिल्वरलाइट केवल ब्राउज़र नहीं है । चूंकि संस्करण 3 OOB अस्तित्व में है और मैं एक Microsoft समर्थित प्लेटफ़ॉर्म होना आवश्यक है, तो वह मार्ग मैं ले जाऊंगा

हालांकि मोनो यह अंतराल कर सकता है कि यह .NET स्टैक से उतना दूर न हो जितना आप सोच सकते हैं और इसे एक व्यवहार्य विकल्प के रूप में एक तरफ नहीं डाला जाना चाहिए।

क्यों Microsoft पूरे .NET स्टैक को लागू नहीं करता है; लागत पर लाभ।


लेकिन ऐसा लगता है कि वे सिल्वरलाइट के साथ ओह-क्लोज़ हैं ... बस काम खत्म क्यों नहीं किया? मोनो-इंजीनियरिंग, सीएलआर, आदि की तुलना में हर किसी के लिए यह बहुत बेहतर प्रतीत होगा
15аn

1
SL संपूर्ण .NET स्टैक नहीं है। SL रनटाइम बनाम पूरे .NET स्टैक पूरी तरह से अलग जानवर हैं।
एरोन मैकाइवर

हां, लेकिन चूंकि आप SL के साथ सुझाव देते हुए OOB जैसी चीजें पहले ही कर सकते हैं, इसलिए .NET स्टैक के बाकी (1/3? 40%?) को पोर्ट क्यों नहीं करें ? या SL वास्तव में फ्लैश को मारने के प्रयास से ज्यादा कुछ नहीं है?
20

@ जब कंपनियां क्लाउड पर चीजों को आगे बढ़ा रही हैं ... आखिरी चीज जो आप करना चाहते हैं वह एक स्टैक को पोर्ट करना है जो क्लाउड में नहीं चल सकता है। SL ब्राउज़रों में चला सकता है। आप Google और अन्य लोगों की पसंद के साथ बहस कर सकते हैं कि ब्राउज़र के भीतर काम करने का धक्का वास्तविक है। इस समय आप इस दिन और उम्र में प्रचलित वर्चुअलाइजेशन के साथ <10% बाजार हिस्सेदारी के साथ ओएस पर एक पूरे स्टैक को पोर्ट करने का विकल्प क्यों चुनेंगे?
एरोन मैकिवर

Microsoft (यकीनन) आज C # और .NET के साथ सबसे अच्छा विकास वातावरण उपलब्ध है। लेकिन मैक / iPad / क्लाउड / आदि के आसपास अनिश्चितता के कारण खान जैसी कंपनियां इससे दूर भागेंगी। C ++ अधिक सुरक्षित लगता है।
Ðаn

3

Microsoft का अधिकांश लाभ दो उत्पादों - विंडोज और ऑफिस से आता है। क्रॉस प्लेटफॉर्म संगतता विंडोज को नुकसान पहुंचाएगी।

यदि आप वास्तव में एक ही कोड रनिंग प्लेटफॉर्म चाहते हैं, तो एक वेब ऐप लिखें। यह आप की तरह ध्वनि नहीं करता है, हालांकि। "बस के मामले में" एक अच्छा कारण नहीं है, यह गुंजाइश रेंगना है।

यहां तक ​​कि अगर आप अब से 16 महीनों में मैक ओएस एक्स या आईओएस को लक्षित करने का निर्णय लेते हैं, तो क्या आपको वास्तव में लगता है कि आप अपने मौजूदा सी ++ कोड को ले सकते हैं और इसे एक अच्छे (या कार्यात्मक) मूल एप्लिकेशन में बदल सकते हैं? जब तक आप एक फुल-स्क्रीन गेम पर काम नहीं कर रहे, तब तक जवाब नहीं।

C # के साथ समय बचाएं, और यदि आप Mac पर जाने का निर्णय लेते हैं, तो इसे Mac को ऑब्जेक्ट-सी और कोको के साथ फिर से लिखें - आपके उपयोगकर्ता आपको धन्यवाद देंगे।


1
"बस मामले में" वास्तविकता है; C ++ में सुरक्षित विकल्प होने पर कोई भी प्रबंधन को "उफ़" नहीं बताना चाहता।
Ðаn

1
मान लिया जाए कि इंटरफ़ेस कोड ठीक से अलग है, तो मैक पर C ++ कोड को स्थानांतरित करना आसान होगा। कोको का उपयोग करके उद्देश्य-सी में इंटरफ़ेस को फिर से लिखें, बाकी को लिंक करें, और आपको पूरी तरह से काम मिल गया है।
डेविड थॉर्नले

@ डेविड: और इसलिए इस प्रश्न के पीछे की समस्या: अधिक C ++, (बहुत) कम C #। मैं (वास्तव में) सी # की तरह!
20

ये क्रॉस-प्लेटफ़ॉर्म चिंताएं यहीं हैं कि हम में से बहुत सारे अभी भी जावा का उपयोग कर रहे हैं और सी # में नहीं जा रहे हैं।
ब्रायन नोब्लुक

1

क्या कोई अर्ध-आधिकारिक उत्तर है कि Microsoft केवल मैक पर .NET का समर्थन क्यों नहीं करता है?

वह बाज़ार कहाँ है जो एमएस को उस खजाने को कोडित करने में खर्च करता है? ऐसा करने के लिए, उन्हें वेतन में लाखों डॉलर की गंभीर नकदी छोड़नी होगी। फ़िक्सेस और अपडेट के साथ चल रही एक प्रक्रिया।

और किस लिए? डींग मारने का अधिकार? वे सभी इससे बाहर निकलते हैं, लोगों के लिए ऐप्पल के लिए विंडोज को खोदने और अभी भी अपने ऐप चलाने में सक्षम होने की क्षमता है।

अगर किसी को ऐसा करने से लाभ होगा, तो यह Apple होगा। लोगों के लिए अपने प्लेटफ़ॉर्म पर संक्रमण करना और डेवलपर्स (DEVELOPERS DEVELOPERS) को इस पर कोड करना आसान बना देता है। लेकिन क्या आपको लगता है कि SJ एक बकवास देता है? बल्कि मैं एक नई सामग्री का आविष्कार करने के लिए एक मैं के साथ रहना होगा । इसके अलावा, अधिकांश ढांचा ओएस है और सीएलआर चश्मा किसी को भी लागू करने के लिए स्वतंत्र हैं। आप इसमें से किसी पर भी गंदा एनडीए नहीं चिपका सकते।


"माइक्रोसॉफ्ट के लिए क्या है" का एक हिस्सा लोगों को विंडोज पर अपने शीर्ष पायदान उपकरणों का उपयोग करना है। जिस तरह से चीजें इधर-उधर हो रही हैं, C # /। NET को इन-हाउस ऐप्स में फिर से लाया जाएगा। जो डेवलपर्स वर्षों से C # का उपयोग कर रहे हैं वे फिर से C ++ लिख रहे हैं। लागत के रूप में; ऐसा लगता है जैसे वे 2/3 के बारे में वहाँ पहले से ही Silverlight और / या मोनो के साथ हैं।
Ðаn

मोनो एक खुला स्रोत मंच है, और जबकि .NET के लिए स्रोत जारी किया गया है, .NET फ्रेमवर्क खुला स्रोत नहीं है। Microsoft कई कारणों से मोनो खरीदने में असमर्थ होगा, प्रमुख यह है कि उनके पास एक भी 100% खुला स्रोत आवेदन नहीं है। क्या आप जानते हैं कि .NET के भीतर सिल्वरलाइट केवल एक ही भाषा है और इसका कारण बहु-मंच है क्योंकि Microsoft इसे फ्लैश के लिए एक प्रतिस्थापन के रूप में पसंद करेगा। मुझे यह भी जोड़ना चाहिए कि Apple ने अपने ऑपरेटिंग सिस्टम पर कुछ भी अनुमति नहीं देने की दिशा में हाथ बढ़ाया है।
रामहाउंड

1
@ आपकी आवाज़ के समाधान की तरह लगता है "उन सभी पर शासन करने के लिए एक भाषा नहीं है" लेकिन "हम एक मंच-अज्ञेय तरीके से कैसे तैनात करते हैं।" अधिकांश लोग तर्क से यूआई को तोड़कर, प्रति-प्लेटफ़ॉर्म आधार पर एक को एम्बेड कर रहे हैं और दूसरे को इनरट्यूब्स पर सेवा के रूप में पूरा कर रहे हैं।
बंद Ripped

1
@ मेरे पास इसके लिए एक समाधान है ... मैक के लिए कोड न करें। मेरे पास एक व्यक्तिगत गैर-विकास-एप्पल समझौता है, जिसे मैंने खुद लिखा और हस्ताक्षर किया था। मैं पूरी तरह से सी # कोड करने में सक्षम नहीं होने से नफरत करूंगा, और इसलिए ऐसा करने से बचें। लेकिन कभी-कभी आप वह करते हैं जो आप करना चाहते हैं, और अगर इच्छाएं मछलियां थीं, तो हमें उन कई चीजों का वर्णन करने के लिए कुछ अन्य गठजोड़ के बारे में सोचना होगा जो हम नहीं कर सकते।
बंद हुआ

1
@ दान दयालता। उन्होंने वास्तव में डेस्कटॉप (अभी तक) को नहीं छुआ है। लेकिन मैं इस बात से हैरान हूं कि पांच साल में क्या फर्क पड़ता है।
23:54 पर बंद

0

आपको मोनोमाक परियोजना उपयोगी हो सकती है - http://www.mono-project.com/MonoMac

यह कोको अनुप्रयोगों को मोनो शैली विकसित करने की अनुमति देता है, जिसे मैक ऐप स्टोर में तैनात किया जा सकता है।

मैं ऑब्जेक्टिव-सी के साथ अपरिचित एक डेवलपर के लिए इस दृष्टिकोण पर दृढ़ता से विचार करूंगा। लेकिन .NET / मोनो / जावा के साथ, जिसे एक समय पर रोक वाले परिदृश्य में एक आवेदन देना होगा।


0

कोई नहीं।

मैं या तो एक क्रॉस-कंपाइलेबल C ++ एप्लिकेशन लिखने की सलाह देता हूं - क्या आपको इसमें खुशी हो सकती है - या wxWidgets के साथ रूबी का उपयोग कर।

मैं क्रॉस-प्लेटफॉर्म विकास और दीर्घकालिक उत्पाद रखरखाव के लिए .NET को एक बुरा प्रस्ताव मानता हूं। हालाँकि, यार, तुम इसमें ऐप्स तेजी से निकाल सकते हो। : - /

विश डेल्फी अभी भी एक प्रमुख दावेदार था।


1
कभी लाजर के बारे में सुना है?
हैप्पी कोडर

इसके अलावा, कभी जावा के प्रमुख?
फर्नांडो गोंजालेज सांचेज़

0

यदि आप नेट पर मैक पर नेट चलाना चाहते हैं, तो आप इसे करने के लिए BootCamp का उपयोग कर सकते हैं (यानी आप मैक पर विंडोज चलाते हैं, और आपके .NET एप्लीकेशन विंडोज में हैं)।

यदि आपके पास मैक ओएस एक्स का मतलब सिर्फ हार्डवेयर के बजाय है, तो आप विंडोज़ एक्सपी एप्लिकेशन में ओएस एक्स में चलाने के लिए वीएमवेयर या समानताएं का उपयोग कर सकते हैं। ओएस एक्स में दोनों में विजुअल मोड्स होते हैं जो आपके एप्लिकेशन को ऐसा दिखाते हैं मानो यह केवल चल रहा हो। ओएस एक्स के भीतर (यह विंडोज एप्लिकेशन की तरह दिखेगा और व्यवहार करेगा, लेकिन यदि आप प्रत्येक ओएस के लिए कस्टम इंटरफ़ेस के बिना एक क्रॉस-प्लेटफॉर्म गैर-वेब एप्लिकेशन लिख रहे हैं तो आपको हमेशा यह समस्या होगी)।

ऐसा करने पर आपको "समर्थन" की एक ही राशि मिलेगी, क्योंकि आप ऐप को विंडोज में चला रहे हैं, हालांकि यह वर्चुअलाइज्ड है। बेशक, ऐप चलाने वाले को वर्चुअलाइज़ेशन सॉफ़्टवेयर और विंडोज की एक प्रति की आवश्यकता होगी, और एक ऐसे ऐप के साथ रखने के लिए तैयार रहें जो OS X ऐप की तरह व्यवहार नहीं करता है - लेकिन यह "मूल" होने का एकमात्र तरीका है .NET एक मैक पर चल रहा है।


0

दान, मुझे नहीं लगता कि आप ऐसा कर सकते हैं। हालांकि, एक संभावित समाधान (अभी भी vapourware) Embarcadero Rad Studio C ++ बिल्डर का उपयोग करना है, जिसके पास दृश्य अनुप्रयोगों को विकसित करने के लिए एक अच्छा VCL है (जिस पर बहुत से .net आधारित है), और वे क्रॉस-प्लेटफ़ॉर्म समर्थन से बाहर आने के लिए RUMORED हैं। अगली रिलीज में

यह विंडोज़, मैक या लिनक्स के लिए लक्ष्य पर विकसित किया जाएगा। या इसलिए उनका रोडमैप कहता है।

सी ++ पर्यावरण उचित है और यदि आप वीसीएल के खिलाफ विकसित होते हैं तो सिद्धांत रूप में आवेदन अन्य प्लेटफार्मों पर काम करेगा।

बेशक जब तक इसका वास्तव में भेज दिया गया है तब तक यह देखा जाना बाकी है कि यह वास्तव में कितना प्रभावी है।


-2

जवाब न है।

वास्तव में आपका मामला बहुत अच्छा उदाहरण लगता है जब .NET नहीं चुनना है।


कोई भी भविष्य का अनुमान नहीं लगा सकता है और कोई भी "अनुचित" जोखिम उठाना नहीं चाहता है।
Ðаn

@ दान: और बात है? लगता है आप मुझसे सहमत हैं ...?
गैब्रियल मैगना

-3

यदि आप ओएस के लिए विकसित करना चाहते हैं तो सही टूल का उपयोग करें। मैक के लिए मोनो में वास्तव में कोई पेशेवर ऐप नहीं लिखे गए हैं। दूसरी तरफ बहुत सारे गैर-पेशेवर डेवलपर्स हैं जो बहुत सारे कचरा पैदा करने वाले उपकरणों का उपयोग करते हैं। उन मोनो ऐप समीक्षाओं को देखें जो OSX के लिए लिखे गए हैं। डेवलपर्स OSX प्लेटफॉर्म से मिलान करने के लिए हैक किए गए अधूरे ढांचे का उपयोग करके लिख रहे हैं। लिखना शुरू करें - यदि आपने C # Objective C का उपयोग किया है तो यह एक त्वरित सीख है।

मैक के लिए व्यावसायिक डेवलपर्स C ++, ऑब्जेक्टिव C, कोको और Xcode का उपयोग करते हैं। मैं कई प्लेटफार्मों पर विकसित करता हूं और प्रत्येक के पास अपने स्वयं के सर्वश्रेष्ठ उपकरण हैं। Mac और iOS के लिए Xcode का उपयोग करें।

बस एक साइड नोट के रूप में एक्सकोड कोई विज़ुअल स्टूडियो नहीं है, यह उतना स्थिर नहीं है और तुलना में सेब के लिए एक अपमान है, लेकिन यह अच्छी तरह से काम करता है जब आपको इसकी आदत होती है। माइक्रोसॉफ़्ट टूल्स को हरा पाना बहुत मुश्किल है - लेकिन उन्हें विंडोज के लिए लिखा गया था न कि लिनक्स, आईओएस, ओएसएक्स, एआईएक्स आदि।


1
क्या आपके पास बैकअप स्टेटमेंट के लिए कोई तथ्य हैं जैसे "Xcode स्थिर नहीं है और Apple के लिए अपमानजनक है" क्योंकि मेरे अपने व्यक्तिगत अनुभव के आधार पर हर कोई जिसने Xcode का उपयोग किया है वह इसे प्यार करता है। इसके अलावा जब आप किसी विषय पर अपनी व्यक्तिगत राय व्यक्त करते हैं, तो ऐसा लगता है कि आपके साथ पारिवारिक संबंध नहीं हैं, आपको यह भी पता नहीं है कि 2013 में, वास्तव में एक समाधान है। बेशक समाधान वास्तव में है Monoऔर Xamarin.Macलेकिन यह एक समाधान है। मोनो का वर्तमान संस्करण .NET 4.0 का लगभग 100% पूर्ण कार्यान्वयन है, इसमें केवल कुछ प्रमुख विशेषताओं का अभाव है जिसकी संभावना कभी भी नहीं रखी जाएगी (यानी WPF)।
रामहाउंड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.