Live data from Hacker News

Native iOS development made simple [video]

smore.com

21–27 of 27 posts

Re: Native iOS development made simple [video]

#24
post #17
post #3

From all the app code generators I've seen and used, the experience is absolutely horrendous. Memory leaks, does not five you full access into the API etc... It's a lot easier to suck it up and learn Objective-C than having to deal with these tools.

Out of curiosity have you used or seen Xamarin? I've heard a lot of hype and talked to fairly experienced people who say it doesn't add too much in size or performance cost.

I like Xamarin's products. I am currently involved in a Xamarin.Mac project and I definitely prefer coding with C# over Obj-C. It's a very nice combo of having things like LINQ, nullables, properties, etc and yet you're still truly coding against/with Cocoa. You can't use Xamarin's products without first having at least a working knowledge of Apple's tech.

My reservation is the cost. I bought MonoTouch when it was first released and wrote a game for the iPad with it[1]. If I wanted to release that game now though, I'd have to re-buy MonoTouch, which doesn't sit well with me. But if you're not a hobbyest then the cost is pretty irrelevant IMO.

[1]https://github.com/city41/optix

Re: Native iOS development made simple [video]

#26
post #3

From all the app code generators I've seen and used, the experience is absolutely horrendous. Memory leaks, does not five you full access into the API etc... It's a lot easier to suck it up and learn Objective-C than having to deal with these tools.

The thing I find funny about their example is that alot of it is easily achived by storyboards anyway. I find that people choose these solutions thinking it will help them with complex requierments or ideas they have where in fact the application should or can only be used for applications for simple ideas and requierments.

Re: Native iOS development made simple [video]

#27
post #7

Nice idea, but the sample code they show in the screenshot uses "FALSE" instead of NO (the Obj-C standard boolean literal). I'm not sure how they did that (#define?) but stay far, far away. Imagine if you opened up a Ruby codebase and found out I had aliased NO to be the same as the language builtin false... yeesh. Also, setting boolean instance variables to NO in init is silly since Obj-C objects are calloc'd, so al…

CFBase.h defines TRUE as 1 and FALSE as 0. There's no reason to think that they defined it themselves (and indeed, I believe this would error unless they explicitly checked for a previous definition).

Correct.
Post reply on HN