Build .net apps for your iphone | The Coffeehouse

harumscarum
out of memory

http://infoworld.com/d/developer-world/iphone-gets-net-app-development-194

Still need a mac (boo) but pretty neat to see .net here.

obrienslalom
(2 2 2 3) *3 | 3 3 3

"What's important here is that C# and .Net are considerably more productive development environments than the native iPhone language, which is Objective-C," -Miguel de Icaza

yup.

VB Man
Year of the Linux MCE.

"Why would anyone bother with non-native tools created by people who don't understand the native tools?" - Chris Hanson

stevo_
Human after all

That'll be a relief.

Minh
WOOH! WOOH!

In reply to VB Man

#Sep 15th @ 11:49 AM

All tools must be written in assembler?

Minh
WOOH! WOOH!

In reply to obrienslalom

#Sep 15th @ 11:42 AM

hellsyup!

PaoloM
Hypermediocrity

In reply to Minh

#Sep 15th @ 12:01 PM

Assembler is a mnemonic set (and modern ones are more macro based than instruction based). Binary is the way to go.

Minh
WOOH! WOOH!

In reply to PaoloM

#Sep 15th @ 12:35 PM

+/- 5V is really the way to go hahaha!

Bass
www.spreadfirefox.com/5years/

Sucks that you still need a Mac. Crying

figuerres
???

In reply to Minh

#Sep 15th @ 12:44 PM

Better yet +1V ( 1 and 0)

we have 3.3 volt in some parts already, and i think i have seen 2.2 or 1.2 V for some hardware....

dahat

In reply to Bass

#Sep 15th @ 12:48 PM

Agreed... and by design no less.

One wonders if their SDK requirements alone have helped to boost their PC sales (aside form what is claimed to have happend from happy iPod/iPhone users who wanted the full mac experiance).

W3bbo
The Master of Baiters

In reply to dahat

#Sep 15th @ 3:23 PM

The number of people buying Macs solely so they can build iPhone applications is in the minority, a drop in the ocean of total computer buyers. I imagine most of the hobbiests just bought Mac Minis so they could make use of their existing hardware, and Apple's profit margins on the Minis are nowhere near as high as on the Mac Pros or iMacs.

rhm

In reply to dahat

#Sep 15th @ 3:23 PM

It's funny when people complain about the fact that you need a Mac to build apps for iPhone OS, they never look at it from Apple's point of view: You're a company making a device and it needs an SDK; you also happen to make a line of computers and an OS. It isn't so much that building the SDK on Mac OS X is a cynical attempt to sell more Macs, it's more that building it on someone else's PC platform would be absolutely ****ing retarded.

Now I suppose you'd reply that, yeh, but they could make a Windows version of it too. And of course they could, but why would they? I'm sure Microsoft isn't rushing out Mac or Linux tools for developing Zune/XBox 360/Windows Mobile/Silverlight applications.

rhm

As for Mono Touch itself... apart from Miguel sounding like a typical 'know-nothing .NET developer' when he was talking about it recently on the Stackoverflow.com podcast, it could be a useful tool for some people. There's going to be a lot of disappointment though. Even if it's true that C# is a more productive environment than Objective-C, that's not why people are going to be attracted to Mono Touch - they're going to be attracted to it because they think it'll save them having to learn a lot of new stuff: Objective-C with it's smalltalk-like object model (which is more like Ruby or Javascript than C++/Java); countless 'frameworks' full of APIs; the XCode/Interface Builder development tools.

Of course they will have to learn all the APIs because Mono Touch isn't emulating some other UI toolkit that programmers from a .NET background already know - it's a bridge between the world of .NET objects and Cocoa Touch objects and frameworks. So they still have to do 90% of the learning that goes into learning to program an iPhone the proper way, except they are hamstrung because instead of having all of Apple's documentation and lots of third party books/websites/blogs in their chosen language, they have next to nothing to go on. At the same time they will be constantly annoyed that this or that API they've read about somewhere isn't wrapped and they have to PInvoke it like WinForms developers have had to on Windows since day 1.

CannotResolveSymbol
{insert caption here}

In reply to rhm

#Sep 15th @ 6:01 PM

At the same time they will be constantly annoyed that this or that API they've read about somewhere isn't wrapped and they have to PInvoke it like WinForms developers have had to on Windows since day 1.

As an iPhone developer myself (working entirely in native Obj-C), this would be my biggest concern. The iPhone development environment (especially lower-level stuff like graphics and networking) relies pretty heavily on a huge library of pure C code. I'm sure they have an automatic Obj-C to .NET bridge (so you can use Obj-C objects directly in C#), but are they providing the PInvoke "headers" (or providing a code generator for them) to give you access to the C APIs (CoreFoundation, CoreGraphics, CoreNetwork, SQLite, etc.)?

If they're not providing them, that's a dealbreaker for me. Having to get the PInvoke signature right for one or two Win32 functions is a pain-- having to do so for the dozens of C functions I use in a typical iPhone project would be a huge hit to my productivity.

There are other technical issues I'd be concerned about, too (toll-free bridging support, how seamless the integration is between Obj-C and .NET types, what happens if I need to access a C++ library (as in Obj-C++), etc.), but the level of integration they provide between C# and pure C APIs is my main concern.