Developing for a jailbroken iPhone, A to Z (iPhone 3.0)

My obvious advice is to simply redo it and make a cert called “iPhone Developer”. That way you know everything will work as expected. That said, your other option is to look through each step carefully and change the name where it appears. There are two reasons I don’t recommend this: 1. it’s a pain – I may or may not be able to catch them all, and I wrote (or at least repeatedly tested in some cases) all these steps. 2. I have a couple more guides that are still in the works that generally revolve about this convention. You never know where codesigning will come up, but you do know that if you keep things consistent, it won’t be a problem.

That said, did you restart your computer and iPhone? It can sometimes be a problem if you don’t.

Zahangir: First, make sure you did step 3 under Procedure above, and Second, make sure you’ve restarted Xcode. Restarting often fixes the issue. A lot of people have been reporting that trouble, though, so I’ll try rerunning ALL my steps from scratch on a different install later today.

Alex: Same deal, I’ll try repeating all my steps to track down the source of the problem.

Alex: Wait, so the problem was that you tried to do all this using the SDK 3.0 beta? That’s weird, since it still should have worked. Did you update to the full release and test again?

Gotcha. Keep in mind that a dev account is free, you only have to pay once you want to do things like provision your phone, submit to app store, use push notifications, and so on.

There’s a new step at the bottom. You have to add a custom run script build phase which generates entitlements for the binary and uses them to psuedosign it before shipping to the phone. On a 2.2 device, this also manifests itself as the binary simply not launching. You could actually accomplish the same goal by signing the binary with ldid on the phone, or on the computer using the OSX binary before your app binary is loaded, but of course, this still has to be a build phase anyway or it won’t happen before the debugger needs it to.

Bottom line is, do that last step, and you should be good. Also note, the second part of it (actually adding the build phase) has to be done per every project.

Exactly correct. It used to be that we told Xcode that it didn’t need a provisioning profile – that didn’t break the fact that it still codesigned the binary before sending it to the phone. This new hack totally kills all codesigning functions, meaning it loads an unsigned binary to the device. On 3.0, apparently the Installd patch is comprehensive enough that that’s not a problem – it still launches, but debugging is broken. On 2.2, the binary simply cannot launch, springboard prevents it.

So yes, you need this step for both 3.0 devices and 2.2 devices. I haven’t tested it with 3.0 3GS, but I suspect it’s the same.

I think I know what the problem is, anyway: You tell Xcode to sign your code using the identity “iPhone Developer” It looks in your keychain for that. The problem is, you have two keychains – the system one, and the user one (one applies to all users, one only applies to you). I think the problem is that you’ve tried these or similar steps at least twice, once opting to put the certificate in your user keychain (default) and once opting to put it in the system keychain (non default). The answer should be to launch /Applications/Utilities/Keychain Access.app, find the cert in the system keychain, and delete it. If that doesn’t work, find and delete BOTH, then redo the first step 2 above, accepting defaults except where noted.

That should do the trick.

I haven’t got a clue! You’re running the release version of SDK 3.0 right? Some people have had issues.

If I had to make a guess as to why that’s happening, I’d wonder if maybe you’re using the same iPhone Developer codesigning identity this round that you used the first time you tried any of these procedures and I’d wonder if maybe, for some reason, it’s actually been long enough for it to expire.

My suggestion is to open Keychain Access (in /Applications/Utilities) and delete all the iPhone Developer certs you may have, then redo step 2 above where you make a new one.

Hopefully that should do it.

You remembered to install Installd Patch, right? That sounds like the error you’d get if you didn’t.

I’d google a bit first, and let me know if you figure it out, but you’ve got me stumped: The sure-fire (pain in the butt) way to fix it should be to completely uninstall Xcode, delete /Developer, and start over.

No, by all means, as long as the question gets answered eventually, it’s helpful to have posted it. For example, I’d never have expected you to get that error as a result of not installing Installd Patch, but now it’s here for anyone else who gets it to find via google 🙂

I think they’re only trying to illustrate the point, not that you’d ever practically have to do that.

I find, however, that I rarely need to deal with memory management concepts like that in Obj-C besides just making sure that I always balance retains and therefore don’t leak memory. You get pretty used pretty fast to the idea that you just always declare things as NSString *mystring = @”foo” (which is a pointer to an NSString object). I never really think about the fact that I’m passing around pointers and not actual objects, because you don’t really have to.

Retain is the conjugate of release. So, first of all, there’s never really any “malloc.” In Objective-C and cocoa, every object has an “alloc” method that handles all of the allocation for that object, and you never directly call “malloc” yourself.

Let’s say I have an object with an instance variable called “name”. In order to set name, I have to use my object’s setter method to pass in an NSString object. It might look something like this:

//I’m going to make my object!
MyClass *myClassInstance = [[MyClass alloc] init];
//I just created an object of type MyClass by telling the MyClass class to allocate some memory and initiate an instance of itself

//Now, to set its name!
NSString *nameString = @”Name”;
//We use NSStrings like candy, so apple built in a convenient syntactic way to make them: @”stuff” is a function that returns a fully allocated and initiated NSString with contents “stuff”. We didn’t even need to declare a new string, we could have just passed the next object the message @”Name” but that wouldn’t have been obvious

[myClassInstance setName:nameString];

Now here’s where it gets interesting. You can have different methods for your class to hold onto the string you just passed it. When you declare the Name property in MyClass.h, you can declare it as “copy” or “retain” (among other, less common things). How you declare this property is important, because it decides what you do next. Well, in these two cases, you do the same thing.

If you declared it as copy, your myClassInstance instance makes a NEW NSString object out of the NSString you pass it, nameString. It holds on to this elsewhere and you don’t need to worry about it.

If you declared it as retain, your myClassInstance instance calls [nameString retain]. This increments an integer value called the “retain count” for that object. When you [[myobject alloc] init] an object, its retain count starts at one, meaning that the runtime won’t call [myobject dealloc] on that object next time through the run loop.

However, you can call [myobject release], decrementing the retain count, and once the retain count hits zero, the object will be intelligently dealloc’d next time through the run loop.

So, in order to avoid memory leaks, the next thing we do is call

[nameString release];

In the first situation, the retain count goes from 1 to 0, meaning that the object will then be intelligently dealloc’d sometime soon. This is ok, because myClassInstance made a copy of the string and we don’t need the original anymore.

Similarly, in the second situation, the retain count goes from 2 to 1 (remember, myClassInstance retained it when we set the name property), meaning that when myClassInstance is done with it, the retain count will go to 0 and the memory will be freed.

NOTE: When does myClassInstance release this thing?! Every object has a dealloc method, and you need to make sure to call

[ivar release];

in that method for every instance variable you’ve defined for the object. If you look at example code with custom objects, you’ll always see this (or the code has memory leaks, which is bad).

Hopefully that makes more sense now, but I’m by no means an expert and I may have gotten some of that wrong. I STRONGLY recommend that you go to http://www.stanford.edu/class/cs193p/cgi-bin/index.php watch the videos and do the homework. I strongly recommend also that you download all the materials FAST, as that website will be erased in prep for next semester’s class.

1. rather, you [[UIWindow alloc] init], which IS creating a UI window object.
2 – 4. In reality, what you’re probably doing is subclassing UIView and editing its – drawrect method to draw the red square. Then you’re adding the instance of your subclass to the window with
[myWindow addSubView:myRedSquareView]
but yeah.
5. Right, because you’re either using the same object and its retain count is already upped by one, or you’ve copied it and you don’t need the original anymore.

Yes, your understanding is more or less correct at this point. Perhaps an NSString was a bad example object to use because NSStrings are autoreleased (if there’s nothing still using them at the end of the run loop, they’re dealloc’d automatically) but you can still explicitly manage them, which I usually find is good for the mind.

Correct, which is why you then [redview release]; and [blueview release];

That will bring the retain counts both to 1, which is good, since the window is still using them. Unless [window addSubView:redview/blueview]; makes copies of them, in which case it didn’t retain them and the retain counts both go to zero, removing them, which is ok since thie window is using a different copy.

Actually, you were right the first time. Your storage options on-phone (ignoring the internet) are .plist files and sqlight. Plists are super ultra easy – basically, objects can have methods built in to persist to disk, that is, save themselves as flat files. It basically means you can save an object for later and wake it up when you need it, like after app relaunch. It’s super convenient since many objects (dictionaries, for one) have this method built in and it’s literally one message to save it and one to read it back in.

The problem with plists is that it’s all or nothing – if you save a dictionary to a plist and want to read data from it again, you have to load the whole thing back in, which is bad if you’re storing a lot of data. Say I have a bunch of images, I wouldn’t want to save them in Plists (even though I could) because to read one would mean loading ALL of them back into memory (and with something like an image, that’s not always even technically possible).

Sqlight is the harder, but more memory-rewarding way to do things. If you have a bigass long list of strings, like 10k entries long, then it will pay highly to use sqlight. If you have, say, a couple of preferences, then you should be fine (in fact, NSUserDefaults exists for this exact reason, look it up in the documentation).