Noel

Independent game designer and programmer. Created Subterfuge, Casey's Contraptions, Flower Garden. Runner. Cyclist. Nature enthusiast. Magic addict. @noel_llopis.

Adding New Development Devices

Today I join the ranks of proud iPhone owners (maybe not so much in Japan though). Yes, it an extra expense I can barely afford, but my previous cell phone contract was pretty much over and it made sense. So far I had been doing all my development on an iPod Touch, but I could really use a real iPhone for beta testing Flower Garden with all the reports of significant performance differences between the iPod Touch 2nd gen and iPhone. Besides, with 360iDev and GDC coming up, being able to have constant internet access for email and Twitter is a huge bonus.

Or maybe I just had gadget envy. Whatever.

But I’m not writing to rub in what a cool gadget I have now. I had a couple interesting experiences adding new devices to XCode and I figured I would share them with other iPhone devs.

SDK and firmware compatibility

This is something I noticed a few weeks ago, but I was able to confirm it with my new iPhone. Each new version of the iPhone SDK warns you to upgrade your device firmware to that version before you attempt to run any programs on it with the new SDK. I always took that literally, but I realized it’s not as restrictive as it sounds.

With each version of the SDK, you have the option to target your build to that version or any of the previous ones. I discovered quite by accident that is perfectly fine to use a certain SDK (like 2.2.1) to build for an earlier version (2.0) and run it on a device with older firmware matching that version. It really makes a lot of sense, because otherwise the only way you could test your app on older firmware would be by reinstalling an old SDK. So maybe this is old news to most people, but it was certainly nice to first upgrade the SDK, and only later the firmware to minimize potential for problems.

Updating provisioning profile

So with my new shiny iPhone in hand (actually, it was a $99 refurbished model, but it shines like new and has that new car smell… oh wait), I set to run Flower Garden on it. The process involved the following steps:

  • Add a new device with the UDID of my iPhone to the Apple Developer Program account. I made the mistake of having to type it manually from iTunes–didn’t realize that XCode allows you to copy and paste it, doh!. Check.
  • Add the new device to the development provisioning profile I was using. Check.
  • Download the updated provisioning profile and add it to XCode and my iPhone. Since the iPhone was plugged, all I had to do was drag it onto XCode. Check.
  • Clean all, build, run. And….

Yeah, you guessed it, I got an error. Otherwise I wouldn’t be writing this if it had behaved as expected, would I? The error kindly informed me that the provisioning profile I was using to build the app wasn’t available on my device. But I could see it in the organizer window of XCode. I double checked it was the correct one and that Flower Garden was being built with that one. Check. Check.

What was going on?

Here’s the fun part, which took me a few minutes of digging through the docs. When I added the updated provisioning profile, XCode decided that it was a different one from the one I was trying to replace. But, here’s the kicker, they both had the same name and description. So XCode was still building my app with the old one, but it was the new one that was installed on the iPhone.

I discovered this by going to the source. XCode stores all the provisioning profiles in the folder ~/Library/MobileDevice/Provisioning Profiles. You can’t tell much of anything by looking at the filenames since they’re a bunch of UIDS, but you can crack the files open with a good text editor and you’ll see they’re a mix of text and binary data. From there, you can see which file corresponds to which profile by looking at the text between the <Name> tags. All I had to do was delete the two development provisioning profiles, re-add the new one to XCode and the iPhone and I was back in business.

I had heard so many horror stories of upgrades to 2.2.1 that I was afraid I was hitting one of those. Fortunately it was quite simple. Next time I’ll know where to look right away.

Now it’s back to work for me. I still need to finish the slides for 360iDev and then I need to fix a couple of things in Flower Garden and get it ready for the first round of beta testing. Sleep? What’s that?

The Cat’s Out of The Bag

Or is that the flowers out of the bag? In any case, I finally get to announce the project that has been keeping me up at night for the last few months: Flower Garden for the iPhone and iPod Touch.

flowergardenlogo-14-02-22

In the next few days I’m going to start beta testing, so if you’re interested in participating, let me know.

More info coming soon…

Presenting at GDC 2009 on iPhone Development

gdc09It seems like GDC was just the other day, but GDC 2009 is around the corner! And this year, I’m going to be giving a presentation titled iPhone Development: Exploring The New Frontier I’m sorry about reverting to the cliched format of having a colon in the presentation title. It was too hard to resist :-).

I’ll be sharing my experiences transitioning from traditional AAA console game development, with teams of 100+ people, multi-million budgets, and several years of development, to indie iPhone development. There are a surprising amount of things that carry over from “big game development”, and quite a few that are totally different. I’ll go into what’s involved making games for the iPhone, and what game developers can expect when making the transition.

Apart from my talk, I’m particularly excited about this year’s GDC. It seems that the amount of content on indie game development and iPhone game development has shot through the roof. On Monday and Tuesday we’re treated to not just one, but two great summits: The Independent Games Summit and GDC Mobile! Last year, the Independent Games Summit was the best part of the show. Meeting all the other indie game developers out there and hearing their experiences was great. This year I’m hoping for more of the same plus all the iPhone-specific content.

Of course, the main conference is packed with great content too, but I haven’t had time to go through all of it and pick the sessions I want to attend yet. Too busy wrapping up my current project.

So if you see me around the show, stop by and say hi. I’m always glad to meet other fellow developers, and it’s always nice to put a face with a name for those of you that I know know through Twitter or online blogs.

San Diego iPhone Developers Gathering This Wednesday

We had so much fun the first time, that we decided to do it again. Last time we had a great turnout and we had a great time comparing ninja UIKit techniques, giving exclusive worldwide previews of apps in the works, and sharing voodoo spells to to make your app show up in the front page of the App Store (amazing what a few beers will do).

So we’re back at it again. Anybody involved in iPhone development or interested in learning more about it is welcome to come.

When: Wednesday Feb 11th from 8PM until whenever.
Where O’Sullivan’s Pub in Carlsbad (home of the Appy Entertainment Secret World Headquarters)

If you’re interested, you might also want to join the San Diego iPhone Developers group to keep up to date with any future announcements.

See you all there!

Last Objective-C Annoyance: Fixed!

I’ve gone on and on before about how much I like Objective-C and especially, how well it plays with C++. Mixing the two is a pleasure, and it’s often hard to remember where one stops and the other one starts. So much so that sometimes I catch myself calling C++ member functions like this [self myFunction:param];. Oops.

It is true that Objective-C can be a bit more verbose than plain C++, but it more than makes up for it with named parameters (which increase readability a huge amount), and not having to duplicate many things between header and implementation files.

Yet, even though I like Objective-C so much, there was one last, really annoying feature that was preventing perfect interop between C++ and Objective-C. Something so simple, yet so fundamental, that it really got in the way. Something that wouldn’t allow me to write something as simple as this:

@interface MyView : UIView
{
    // ...
    SingleTouchEvent m_singleTouchEvent;
}

SingleTouchEvent is a custom C++ class. There’s nothing wrong with that right? There shouldn’t. But if you try and compile it, you’ll get this warning:

warning: type `SingleTouchEvent' has a user-defined constructor
warning: C++ constructors and destructors will not be invoked for Objective-C fields

Some of you might be saying, no big deal, you can dynamically allocate objects and have their constructors called as usual. That’s true, but I hate allocating objects on the heap just because of something like this. My preference is always to make them member variables if I can. It’s faster, more efficient, less error prone, and easier to read. Needless to say, this was bugging the hell out of me.

I looked all over the build options in case there was some setting I could toggle to enable C++ constructors to be called, but no luck. I did a bit more research, and lo and behold, it turns out there is a custom setting you can pass directly to gcc to do exactly that! It’s nowhere in the XCode settings GUI, so you have to enter it by hand. Go to Project | Info, and in the Custom Settings section, enter the following: GCC_OBJC_CALL_CXX_CDTORS = YES

setting

With that setting enabled, Objective-C and C++ now play together better than ever!

Without any barriers to writing new code in Objective-C, I expect it will slowly (or maybe not so slowly) replace C++ as my main language of choice for future projects.