AKA : Self Code-Signing your OSX app without Apple’s developer certificate
(Tested with XCode 4.6 on OSX 10.8.2)

1. Open up ‘Keychain Access’
2. Go to ‘Certificate Assistance’ -> ‘Create a Certificate’
3. Type whatever name you’d like. Then go with ‘Self Signed Root’ and ‘Code Signing’ options.
   
4. Click ‘Create’
5. Check if a certificate is successfully created.
   
6. Open up an XCode project.
7. Override all of ‘Code Signing Identity’ with the sign-signed certificate, and off you go.

Update : This trick works like a charm on OSX applications. Unfortunately, it does not on iOS apps.

Reason being that, I suspect, your certificate and iOS devices registered to Apple should pair up. Otherwise, XCode says the certificate is expired.

^*Reference : Code Sign

I am an iOS developer with the background of building internet application since 1998. I am not an market analysts but I believe I have at least a despicable sense of seeing where things are heading.

As Siri starts making its way into the hands of millions of consumers, everyone starts taking a poke at it and glancing the future Siri might bring to us.

But no one seems to talk about what Siri might do to internet applications such as Google, Facebook, Youtube, and most importantly the ones I am working my ass off for. To make it short, it seems clear to me internet applications are now facing a very stiff challenge. May I dare to say Siri and its clones will end the internet applications as we know of. I am going to explain why I believe so.

Siri, the life delegate
After short period of poking, we will gradually converge our life into Siri. Firstly, we’ll probably start with simple questions such as a reminder for wife’s gift or rescheduling a meeting as they are shown in Apple’s Ad.

Then, we will start throwing more serious ones.

“Siri, find me a good romance book I can read during flight”
“Siri, what do you say about the new movie Matt Damen just shot?”
“Siri, find the most important person in this room I should talk to”
“Siri, do you believe my blind-date today is hot?”

All these question could be answered because Siri isn’t exactly a speech recognizer. Siri is an Artificial Intelligence that can learn, reflect, and extract the best information for the context you are in based on its service partners and experience with you. Siri could access Amazon, Itunes, Klout, and Foursquare. Even Facebook for that matter. Siri aggregates ratings, meta data, your location, your social graph, and, personal preferences. Thanks to its forever-getting-smarter A.I. engine, Siri will understand what you mean by ‘good’, ‘how about’, ‘important’, and ‘hot’, and then bring you the best choice for your context. Your previous complex tasks to find out the best Sushi restaurant for your date is now reduced to simply saying “I want #5″.

I have been wondering why this particularly interesting video doesn’t get more attention than it should. Tom Gruber at Semantic Web in 2008 demonstrated Siri.

KEYNOTE: The Game Changer: Siri, a Virtual Personal Assistant from Semantic Web on Vimeo.

Siri will eventually take vast majority of decision-making tasks for your day-to-day life, and it will soon to be very inconvenient to live without having Siri right besides you. I for one surely join the party.

Siri, the gatekeeper
So let us look at Siri from internet application developers’ view. We have lived up and developed applications with expectations of receiving ‘direct user interaction’ to help users getting answers for very subjective questions such as ‘how about the movie Matt Damen just shot’, or ‘who is the important person in twitter to follow’. We just barely start recognizing the value of user interaction, and start recommending venues, movies, and books to pay attention.

In the video above, Tom clearly explains that Siri is like a librarian. It reaches out all the applications, aggregates data, judges based on users’ historial preference and context, and comes up with the ‘best’ options.

Now ‘direct user interaction’ is all gone but Siri instead comes choose data based on its experience with what users want, and go away with what it grabs. Or more precisely to put, what users might want. Do you believe the data Siri takes represents true necessity of end users? Well, at least I don’t.

When Siri finally becomes a life delegate, the applications we pour our sweat and blood could turn into not much more than Siri’s mere library, a data container. If Siri does not want my application somehow, it is out of sight and out users’ mind. The awesome part is users don’t even know my application is gone.

I believe Siri will be the next gatekeeper of information flow, and, like it or not, our applications will need to be liked by Siri first, just like websites have to be liked by Google search engine. Internet applications as we know will have to transform tremendously in order to retain user loyalty by the the time I cannot sleep without telling Siri to set an alarm.

With impending iOS 5 release, Object-C memory management is going to change for good. With all the release/retain/autorelease gone, it will be even more of no-brainer than it is now. But just in case it might help some, I would like to lay out a particular experience I have had with my code.

I assume you are already familiar with Object-C memory management scheme; when to owe, when to release, and when to retain. When you are to, however, use Interface Builder heavily for fast paced projects, you often have to let IB handle all the initial construction of a complex view controller that contains a lot of sub-views and even child view controllers. These child view controllers are usually called “nested UIViewController” and one of 2011 WWDC session video explicitly talks about that. Nested UIViewControllers can have their own .nib/.xib file so that you can build very complex view hierarchy out of collection of simple view controllers. Not to mention that you can reuse the simple view controllers however you see fit.

In that case, the parent/host view controller might get retained in the shade. Eventually when you touch “Back” arrow button on top of screen, the parent view controller gets “popped” or “dismissed” from navigation controller, but it will never be deallocated. This is called “zombie” object. Especially when nested view controllers take the parent view controller as a delegate or some sort of referral in IB, it could be just so much pain in your private part if you are not careful.

Parent-Child view controller connection in IB example

The side effect of having deallocated but retained zombie UIViewController somewhere in your memory is really bad. It will get you all kinds of colorful pain; EXC_BAD_ACCESS will greet you, NSZombie sometimes won’t find you a clue, memory leak of course, even didRecieveMemoryWarning() gets called on supposedly dead objects. Your app crashes on your face.

I am going to demonstrate three cases where nested view controllers take their parent view controller as a delegate. Each case differs slightly in taking the delegate and the outcomes in the end are of course different.

1. A retain delegate property in interface of a nested view controller.

@interface RetainDelegateViewController : UIViewController
@property (nonatomic, retain) IBOutlet id delegate;
@end

Then I connect the delegate IBOutlet to its parent view controller in IB, and my parent view controller gets retained one more time. If I forget to release somehow, it never gets deallocated when it gets popped from navigation controller. So, it exists somewhere in memory as a zombie, does all the things a live object is supposed to, and crashes your app since it is flagged to be deallocated but not really deallocated because of the one extra retain.

This is just as obvious as a flying flag. I would highly discourage you if you are doing it.

2. An IBOutlet delegate of a nested view controller without being a property.

@interface PlainDelegateViewController : UIViewController
{
	IBOutlet id delegate;
}
@end

This is common for subviews and buttons. Simply because it does not send extra “retain” message to your subviews and buttons, you might have better chance of not leaking memory. When I connect the delegate to its parent view controller in IB, however, this does not go in the way I believe. This yields exactly the same result as a retain property does. This is really confusing so I browse through object-c documents but no use. If anyone could point me a right point to look, I would really appreciate.

3. An assign property in interface of a nested view controller.

@interface AssignDelegateViewController : UIViewController
@property (nonatomic, assign) IBOutlet id delegate;
@end

This clears all the issues I have with previous two, and deallocate the parent view controller as soon as it pops off navigation controller.

TL;DR
When you are to refer your parent view controller from a nested view controller, always use assign property. You can download IBDelegateRetainTest from Github to see how different the outcomes are.

IBDelegateRetainTest

*There are three view controllers. When they are popped from navigation controller, they are supposed to be deallocated. Take a look at console log and find out which one gets really deallocated.