Anyway to develop iPhone/iTouch apps without investing in a Mac?

December 31, 2008 3:16 PM

I'm interested in developing iPhone/iPod Touch applications, however my understanding is the SDK only works in OSX. I have a XP desktop and a Vista notebook with an AMD Athlon and Turion (both dual core) respectively, both pretty good machines. Is there any way to avoid spending serious cash buying a Mac just to get into iPhone development?
posted by nmaster64 to computers & internet (27 comments total)

You're going to need to run OS X somehow.

Mac Mini
Buy used/refurbished.

And of dubious legality...
Hackintosh (various guides out there)
There are also VMWare images of OS X floating around.
posted by wongcorgi at 3:33 PM on December 31, 2008

No. You need a mac, the SDK and X Code (which is free). You also need to learn Objective C, which is horrifying.
posted by Artw at 3:36 PM on December 31, 2008

Lots of mac users upgrading at the moment, and a second hand one will definately do the job.
posted by Artw at 3:37 PM on December 31, 2008 [1 favorite]

Other things you might need: A spare iPhone or touch, unless you're willing to sacrifice the one you use personally.
posted by Artw at 3:38 PM on December 31, 2008

You can use your own iPhone without "sacrificing" it. Sheesh.
posted by Blazecock Pileon at 3:49 PM on December 31, 2008 [1 favorite]

Other things you might need: A spare iPhone or touch,

The iPhone SDK includes an emulator that should serve for about 95% of your testing, including making physical movements of the device. At the point you put your app on your iPhone/iTouch to test, your app should already be well-behaved enough that you don't need to worry.
posted by fatbird at 3:55 PM on December 31, 2008 [1 favorite]

Just doing this myself:

1. Do not get too old a Mac. The developer stuff only runs on Intel processors.

2. If you know C, you can learn Objective C in no time. It is not hard--it uses the smalltalk [objectptr function:argument] for objectptr->function(argument).
However, it (and Apples 'extensions' to it) is/are horrifying on many levels.

3. Documentation is poor compared to VC. Also poor compared to Java. It's poor.

4. Interface Builder (the part of the IDE that lets you drop a little picture of a button onto a window (er, view) changed radically in the new (XCode 3) version, so almost all the examples on the internet are pretty useless. It's a real horse, too. The three-click 'create an empty window project' generates an Interface Builder file (.xib, the new xml version of the formerly binary .nib file) over 3000 lines long.

5. Unlike the Microsoft products of the last 10 years, the IDE is a little flakey. Sometimes it seems necessary to clean, close, and reopen a project to get it compiling again.
posted by hexatron at 4:07 PM on December 31, 2008

You absolutely need an Intel Mac of some description.

The entire iPhone build process is too deeply ingrained in XCode to build elsewhere; and the only other Objective-C compiler I know is gcc, which doesn't support any Apple's additions to the language (nor their libraries).

And, in direct opposition to what people are saying above, Objective-C is absolutely my favorite native, compiled language. Elegant, small (only a few changes from C), late-binding, dynamic, straightforward. It's what C++ should have been.
posted by Netzapper at 4:18 PM on December 31, 2008 [2 favorites]

How crucial is it to actually code in Objective C? You'll be referencing ObjC libraries, but can't you code it in C++? Do wrappers exist? I thought that the libraries had a pretty decent selection of language bindings, including some scripting languages like Python.
posted by fatbird at 4:42 PM on December 31, 2008

If you are serious about this, you shouldn't spend your time in getting non-Mac non-Objective-C non-Cocoa environment up and running, and making sure your development environment survive through various Xcode and OS X upgrades. Rather, invest in a Mac and invest in learning Cocoa, so that your time can be better spend perfecting your applications.
posted by applesurf at 5:51 PM on December 31, 2008

Sell one of your computers, get a used Mac. You can run Linux/Windows on if it need-be, but you'll probably end up liking OS X enough to use it fulltime.

I bought a Mac Pro in 2007 due to the fact Apple had an insane $650 discount available to me as a student developer through their ADC thing. I planned to go back to Linux after toying with OS X for a week, but that never happened. It really is a happy unicorn land for coding, honestly.
posted by floam at 6:28 PM on December 31, 2008

Hackintosh osx86 lets you run OSX on typical PC hardware.
posted by damn dirty ape at 6:30 PM on December 31, 2008

The iPhone SDK includes an emulator that should serve for about 95% of your testing, including making physical movements of the device

The emulator doesn't emulate accelerometer data and runs OpenGL renderings much faster than the iPhone and iPod Touch. It also doesn't work with Apple's keychain framework. It'll be best to do preliminary design on the emulator and then testing on the device.
posted by Blazecock Pileon at 6:32 PM on December 31, 2008

Depending on the hardware of your desktop/laptop, you can also download an iATKOS or Kalyway ISO from various websites, that will install on your computer. I've heard that Pirates offer it, and that they hang out in a Bay of sorts.
Good Luck.
posted by dunkadunc at 7:57 PM on December 31, 2008

How crucial is it to actually code in Objective C? You'll be referencing ObjC libraries, but can't you code it in C++? Do wrappers exist? I thought that the libraries had a pretty decent selection of language bindings, including some scripting languages like Python.

Crucial. None of those bridges exist on the phone, they're only on the desktop. You could flit around with C, but you're going to need the Mac anyway -- apps are hard enough to sign and provision to the device on a tickety-boo Mac as it is, so don't make life harder for yourself.
posted by bonaldi at 8:35 PM on December 31, 2008

Get a used Intel Mac Mini so you're not paying for components you're not going to use like a screen. Around here I wouldn't have to pay more than $400 for one off Craigslist, and then use it as a file server server or whatever. I use mine as a media PC. (And $400 isn't bad for a new development platform. I've paid many time that for a development kit.)

Note that you will also need the latest version of OS X 10.5 to do iPhone dev which might be an extra expense with a use Mac.

And you can install Windows on these things. Works very well. In fact I now prefer to do development in a virtualized Windows box.

And Objective C is much easier if you don't listen to the people who scream "oh noes!" when they hear it. It's just another language. Relax and let it happen. Worrying about how bad you imagine it will be will only make it worse.
posted by Ookseer at 9:22 PM on December 31, 2008

Pierre Chatelier's Objective-C guide for C++ programmers is an excellent resource for C++ programmers who want to learn ObjC and — importantly — what aspects are different.

In addition, with "Objective-C++", you can automatically implement C++ libraries, routines and syntax in an iPhone application by simply renaming the class file extension from .m to .mm.
posted by Blazecock Pileon at 10:03 PM on December 31, 2008

I'm bemused that people seem averse to learning ObjC — it's a much simpler (and, IMHO, better designed) language than C++.
posted by hattifattener at 10:51 PM on December 31, 2008

I don't know why those two are freaking out about Objective-C. It's amazingly simple and insanely powerful.

You'll need to learn Obj-C and the Cocoa frameworks, yeah. Obj-C, as said, isn't difficult to learn if you already know C. (It is a strict superset of C that adds Smalltalk-like messaging, a few bits of syntactic sugar, reflection/polymorphism, garbage collection, and a couple other small pieces.) It may take a little time to "get into" the Cocoa mindset, but once it starts snapping into place, you're going to go crazy with joy.
posted by Mikey-San at 3:26 AM on January 1

You have to do your own garbage collection for iPhone apps. Quite a pain if you're not used to it - the POC I produced probably has memory leaks all over it.
posted by Artw at 7:54 PM on January 1

> the only other Objective-C compiler I know is gcc, which doesn't support any Apple's additions to the language (nor their libraries).

GCC supports Cocoa, if that is what you are referring to.

I wouldn't even consider GCC for iPhone development, as other people have pointed out, but I would use it to get a good feel for Objective-C, its syntax, its OOP, and so forth before investing in a Mac Mini (cheapest legal way, I think) or a refurbished Mac.
posted by shadytrees at 7:57 PM on January 1

Hows that work with ib?
posted by Artw at 9:12 PM on January 1

You have to do your own garbage collection for iPhone apps. Quite a pain if you're not used to it - the POC I produced probably has memory leaks all over it.

The term you're seeking is "reference counting". I mentioned GC because it's part of the language spec, even though the collector is not available in iPhone OS.

The memory management rules for non-GC applications in Cocoa are pretty simple, as long as you don't listen to anyone who tries to reformulate them. Just read the memory management guide on the ADC site, stick to the contracts, and use the myriad tools available to make sure you aren't leaking. But just like in GC environments, you must be aware of how you are allocating and managing memory, because a collector cannot solve all of your performance problems (and can easily cause you more).
posted by Mikey-San at 11:55 PM on January 1

But just like in GC environments,

should be

"Even in GC environments,"

and then let's add

"Good memory management (and thus performance) is more than simply making sure you aren't leaking, and that problem exists whether you've got a collector or are rocking retain/release."
posted by Mikey-San at 11:58 PM on January 1

shadytrees: er, gcc is the system compiler on Macs, including for iphone development (both cross-compiling to ARM and compiling to x86 for simulation). Rumor has it they're moving to something LLVM-based someday, but at the moment, it's all gcc. Of course, it has some Apple tweaks (like for Mach-O support), and you need to be able to link against the Apple libraries if you want to do anything.

Artw: IB just writes out a data file describing the GUI. The application reads it in and creates the widgets and connects them as specified. (This is a one-line call into the gui library.) There's no compiler magic, no (ugh) code generation, or anything else.
posted by hattifattener at 12:48 AM on January 2

If you don't want to go the Hackintosh route like I suggested before, the Mac Mini is probably the best way, like Ookseer said.
Yes, it means investing in a Mac, but they're SO cheap. Just make sure you've got enough RAM: Mine came with 512MB and it wasn't nearly enough.
posted by dunkadunc at 3:58 AM on January 2

Artw: IB just writes out a data file describing the GUI. The application reads it in and creates the widgets and connects them as specified. (This is a one-line call into the gui library.) There's no compiler magic, no (ugh) code generation, or anything else.

A very, very good point. There's a common misconception that Interface Builder performs some kind of voodoo magic that is entirely opaque, generating code behind your back. This isn't the case at all. Your nib/xib files are simply descriptions of objects and their relationships to each other. It's a good example of the General Rule of Cocoa: "Whatever you're doing is probably less complex than you think."
posted by Mikey-San at 9:56 AM on January 2