iPhone App Development questions

[padren]

Has anyone played with iPhone app development? I have an idea I really want to try and build and sell, I think it'll only take 20 hours of code or so (plus time to learn the UI libs) but I don't have a Mac - has anybody tried this or know of good alternative ways to build iPhone apps?

 

A friend of mine has a phone he can test stuff on, but I don't know much about the process and haven't seen too many ways to write code without a Mac (I'll get a cheap one if I have to) and I am curious about potential pitfalls and such.

 

TIA

[Comandante]

I'm wondering about the same thing. I have some good ideas to code but I need to know more about the whole development process, have put that sort of, on hold, but now that you've mentioned it I'll keep an eye on this thread.

 

Also, as there are tons of apps already out there, you really need to make sure that nobody has already made what you want to make, I figured that was the case with a few of my ideas

[padren]

Just an update, I did find this:

 

http://www.xmlvm.org/iphone/

 

Looks like an interesting way to develop iphone apps without working on a Mac, but I haven't tried it out yet. When I get the chance I'll comment on how it goes.

[bascule]

The main drawback of iPhone development is Objective C, in my opinion. It's a language that doesn't really have any value except programming for Apple (i.e. NeXT) properties like OS X and the iPhone. Granted that for what it does it's pretty cool, but outside of that scope it's practically worthless.

 

I wish Apple would support MacRuby on the iPhone, but they refuse to port the Objective C garbage collector over out of concerns for power or some silly rationale like that. But it's perfectly fine to have Safari for the iPhone execute garbage collected JavaScript?

[Pangloss]

Well I don't know, Objective C, C#, Java, it seems like six of one, half a dozen of the other to me. I always listen to what you say when it comes to programming because you seem to know a lot more about it than I do, but at the lighter level that I tend to work at what makes iPhone programming different is actually the IDE and tool set combined with the underlying iPhone operational philosophy, which is really unique and interesting.

 

I've been working on this off and on for a couple of months now, borrowing a Mini from my Dean, and I think it's great stuff. From purely a standpoint of mobile HCI it's really groundbreaking. A lot of the stuff about the iPhone that I saw as limitations suddenly became features, like the lack of multitasking. For example, if the iPhone runs out of memory, it doesn't give the user an error message -- it just reboots. It gives the PROGRAM several opportunities to recover, but at that point any sane desktop operating system will prompt the user for some sort of action before collapsing into dust, right? BUT this is a TELEPHONE -- you don't want users dealing with error messages while driving down the road at 60 mph. Better to just recover by the most expedient method available -- rebooting.

 

The iPhone OS is chock full of interesting little twists in HCI philosophy like that. And IMO you really should get to know it through the standard tools, known as the iPhone SDK, which includes IDE, Interface Builder (a cute way to do your forms -- a bit toylike, but pretty efficient and very easy to use), and the iPhone simulator (very clever -- works exactly like the real thing, even letting you tilt it, though of course it doesn't support all the hardware features such as GPS).

 

Apple controls this stuff pretty tightly. The SDK is free, but you have to join their developers program if you want to actually put one of your OWN applications on your OWN iPhone (yeesh). I believe that was $99 for a year. (I got our university into the program so I can get students on it for free; maybe you can talk to your school about that.)

[bascule]

Well I don't know, Objective C, C#, Java, it seems like six of one, half a dozen of the other to me.

 

The main difference between Objective C vs. C# or Java is the other two have a certain degree of ubiquity (thanks to the Mono project re: C#) whereas there's little you can do with Objective C outside of Apple platforms.

 

Also, Objective C isn't garbage collected by default (whereas C# and Java both are) and garbage collection isn't supported on the iPhone. I'm not sure why Apple made this decision. They were quite content for another garbage collected language (JavaScript) being the ONLY way developers could target the platform for over a year, but after shipping support for native apps they omitted the Objective C 2.0 garbage collector.

 

This is particularly frustrating as I would love to target the iPhone with Ruby (using MacRuby) but MacRuby relies on the Objective C garbage collector.

 

The garbage collector itself has been released as open source however the hooks into the runtime remain proprietary. This means that Objective C 2.0's garbage collection only works when using Apple's proprietary version of the compiler/runtime.

 

If you're content to target Apple's proprietary platforms exclusively, Objective C is pretty nice.

[Pangloss]

Well it's a tradeoff -- you get massively boosted productivity and true RAD in exchange for dependence on a specific vendor. On the other hand, look how they compete with one another on feature sets and even training methods. That may not lead us to platform independence, but it may not have to if everything about each "propriety" process is completely homogenous and predictable.

 

So all we have to do is teach kids what Polymorphism means. Then THEY can apply that knowledge to whatever platform they want to learn... and rinse and repeat as often as they want. Of course there is a risk that they won't understand the meaning behind the intellisense popups, but at least they'll know what to do with it, regardless of what "language" they're "learning".

 

It's a pretty slick place for the industry to have reached, you have to admit.

 

Regarding garbage collection not taking place on the iPhone, I believe that's one of the development choices I mentioned earlier that was consciously made in order to optimize the platform for mobile use. My dim recollection is it was sacrificed in order to minimize background task activity. Which means all iPhones inherently "leak" unless you remember to clean up your own resources. And if you run out of memory, well, the Home screen will be there for you shortly. (grin)

 

By the way, have you read the iPhone Application Programming Guide? It's available at Apple's developer center, and it's a pretty fascinating read, academically speaking. It's a radically different choice of direction and I one I don't think the HCI world has quite recognized yet. That's why, for example, no application allows "save" documents, and why they all seem to remember where they left off when you return to them. All that stuff's part of the design philosophy.

 

I'm probably just a bit too gaga over it, but having lived with a Windows SmartPhone for a year, I think I earned it. (shudder)