# Objective-C or C++ for iOS games?

I'm pretty confident programming in Objective-C and C++, but I find Objective-C to be somewhat easier to use and more flexible and dynamic in nature.

What would be the pros and cons when using C++ instead of Obj-C for writing games in iOS? Or rather, are there any known problems with using Obj-C as compared to C++?

For instance, I suspect there might be performance issues with Obj-C compared to code written in C/C++.

One big upside to C++: If you decide to do so, it'll be relatively easy to port to Android/PC/DS/PSP/(insert platform of choice here). Objective-C will lock you into iOS until you decide to rewrite the entire game.

• I disagree with the word "easy." "Possible" may be a better choice. – 3Dave Apr 13 '11 at 21:11
• Yeah, for many smaller games (eg. most iPhone games) it's better to simply re-write everything from scratch for the new platform rather than attempting to adapt the code from one platform to work on another. A solid MVC architecture would minimize this pain, but who would bother with that for a match-3 game? – jhocking Apr 13 '11 at 22:01
• Relatively easy! If the alternative is impossible, then "extremely difficult" is relatively easy ;) – ZorbaTHut Apr 22 '11 at 6:57
• blog.vucica.net/2011/06/… he talks about building Objective C apps for android. It's just Linux and Linux can run Objc as easily as an iPhone. – Feloneous Cat Aug 26 '12 at 0:49
• Using objective c won't lock you in. Using functions specific to the XNU kernel will. Gclang is there for a reason. – user20618 Dec 12 '12 at 18:49

There are no real pros or cons here, at least none that should force a programmer comfortable in one language to have to use the other.

Performance shouldn't be an issue. It's unlikely that you'd write any heavy lifting with lots of messaging in the inner loops if you're a good Obj-C programmer, which means you'll really be writing those inner loops in C. If you're not a low level programmer, chances are the heavy lifting will be done by whatever libraries you chose to defer that too, and you'll be at the mercy of whatever they've chosen to do.

Portability is a real issue, if you care about it. If not, then meh. Being cross platform isn't the end all be all. Being successful on one first would be nice :) You can always port later. If you're not carefully planning to be cross platform from day 1 anyway, just being in the same language won't get you very far: there are plenty of further real differences between platforms that need addressing.

Finishing the project is more important that fretting about the tech, and if you're more productive in Obj-C then stay in Obj-C.

My preference? I'm a C++ guy. I like Obj-C just fine, but I'm happy in C++, and I do write cross platform code.

• I very much concur with the advice to focus on finishing the project with whatever tools you are most productive with. Avoiding premature optimization doesn't only apply to writing code, it's a good way to approach life. – jhocking Apr 13 '11 at 22:04

There are no performance issues with Obj-C over C++. Both are compiled code, and recall that Obj-C is a superset of C, and Obj-C++ is a superset of C++, which is great when you want to mix Obj-C and C++ in the same program (easy to do and XCode has nice support for the C++ side). All language combinations support OpenGL, so any serious graphics work is fine and the library support is ok with Apple regardless of language.

That said, what is the purpose of your game?

• If you are solely writing for IOS, then don't worry and write in whatever language or combination you feel more comfortable in. For me, this happens to be Obj-C++ with STL since that's my favorite part of C++. Since I prefer Obj-C slightly over C++, I tend to use this option.

• If you are writing with the goal of porting to another device, write in C++ with a translation layer to Obj-C to deal with any device-specific stuff (graphics, input, camera, ...), where the calls are made to entry-points in your application.

• If you are a purest and want just one language, write in Obj-C.

Others have talked about other libraries (physics and such). There are absolutely no problems with accessing any of that from any of the language choices you are talking about (Obj-C, C++, or Obj-C++). You will also not have any performance issues with those libraries in any language.

A caveat: There is a pointer indirection call with message passing. I'm not sure how much you can interpret that as overhead, since I'm pretty sure that's exactly the same as an inherited C++ method call. Can anyone clarify this?

Hope that helps,

Lee.

• Good points, but would you really want to write your Vector3D class in Obj-C? My gut feeling tells me that could lead to bad performance. – Martin Wickman Apr 16 '11 at 9:52
• That's just it. Obj-C is C. Not a performance issue. If you go to the standard header files with XCode, you will find the underlying types are just C structs. – Lee Apr 16 '11 at 20:46
• The message overhead with Obj-C is quite a bit higher than C++ because it's more dynamic. It's certainly NOT "exactly the same". eg: see developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/… – Andy Dent Mar 23 '12 at 5:10

It depends on exactly what you are programming. If it's mainly game logic using existing physics and graphics engines, i can safely say i don't see any reason to use c or c++ if you're more comfortable with obj-c. If you are going to be rolling out rendering or physics classes i would probably write those using c or c++. Cocos2d - which is a wonderful and one of the most popular iOS game libraries is written in obj-c.

Check out this read - the relevant part is "division of labor", might help you to decide when to code in a higher level language and when to use lower level: Managed code in games

While objective-c overhead should be no where near C# and isn't even managed (on iOS), i believe the logic still applies, and devices running iOS are also no where near as strong as the PC that would be interpreting MSIL :)

• Obj-C isn't managed code on iOS. For example (and in particular) Obj-C has a garbage collector when programming for OSX, but it doesn't have a garbage collector on iOS. – jhocking Apr 13 '11 at 20:08
• @jhocking i never said it was managed, isn't there still overhead when using obj-c as opposed to c++? I did mention c# vs c++ it was no where near obj-c vs c++ – Zaky German Apr 13 '11 at 20:11
• When you post a link called "Managed Code in Games" while talking about Obj-C then I take that to mean you think Obj-C is managed code. Which it is on OSX, just not on iOS. Kind of goofy that, as if Java compiled to machine code on some platforms but ran in JVM on others. – jhocking Apr 13 '11 at 20:14
• oh and I don't know if Obj-C has any overhead compared to C++. That's why I'm not posting an answer myself. – jhocking Apr 13 '11 at 20:14
• @jhocking no sir :) "The thing is, the retain/release model in Objective-C is roughly a middle ground from no memory management to a basic GC so you are already ahead of the curve." interfacelab.com/objective-c-memory-management-for-lazy-people – Zaky German Apr 13 '11 at 21:57

This study says to really get the performance in a CPU intensive game, you have to use C. The linked article is complete with a XCode project that you can run.

I believe the bottom line is: Use Objective-C where you must interact with the iPhone's functions (after all, putting trampolines everywhere can't be good for anyone), but when it comes to loops, things like vector object classes, or intensive array access, stick with C++ STL or C arrays to get good performance.

I mean it would be totally silly to see position = [[Vector3 alloc] init] ;. You're just asking for a performance hit if you use references counts on basic objects like a position vector.