automatic-ref-counting

Possible Duplicate: using ARC, lifetime qualifier assign and unsafe_unretained What's the difference between the two? @property(unsafe_unretained) MyClass *delegate; @property(assign) MyClass *delegate; Both are non-zeroing weak references, right? So is there any reason why I should write the longer and harder to read unsafe_unretained instead of assign ? Note: I know there is weak which is a zeroing reference. But it's only iOS >= 5. In a property accessor, yes those are the same. assign properties will map to unsafe_unretained for this case. But consider writing the ivar manually rather than

I know that I am suppose to use: ObjectClass *tmpObject = [[ObjectClass alloc] init]; realObject = tmpObject; [tmpObject release] to initialise realObject (where realObject is an object within a class) But now with ARC mode, releasing is automatic, do i still need to use this technique? Can I simply use realObject = [[ObjectClass alloc] init]; ? If not is there any specific reason why it would leak? Thanks As Spencer said, if you compile with ARC enabled, you cannot call release at all. It is an error to do so and the compiler takes care of it for you. However: ObjectClass *tmpObject = [

I'm making an interactive book for the iPad and am using UINavigationController to implement the navigation between a page and the next. When a user turns the page, the next page is pushed on top of the navigation stack. I'm now 15 pages into the app, and the app crashes when I try to go from page 14 to page 15. No error message in the console, nothing in the device's crash logs neither. Each view controller's scene in the storyboard has UIImageViews displaying images that are between 5MB and 20MB. The view controllers' viewDidLoad method is called just once. The total size of all the app's

I'm considering dropping 32-bit support for in favor for Automatic Reference Counting (which is only supported for 64 bit binaries). I'd like to avoid these two scenarios with the Mac App Store: For a user of an old 32-bit Mac : who did purchase the previous version with 32-bit support: Will they see an update message for the app in the Mac App Store? If so, the (now 64 bit only) update would not work for him/her. who has not purchased the app before: will they be able to purchase the app although it will not run on their system? ARC 64 bit only: http://developer.apple.com/library/mac/

The code below returns the following error when I log/request values from the History Core Data object: -[CFNumber release]: message sent to deallocated instance 0x17ea2a90 I originally thought there was an issue elsewhere and have spent countless hours attempting to debug this to no luck. After further testing, I have pinpointed the crash to requesting certain values from the History Core Data object. Can anyone see any issues to why the object values are being deallocated? [[DocumentHandler sharedDocumentHandler] performWithDocument:^(UIManagedDocument *document) { if(!self.document) { self

I have a property that I do not synthesize, instead I create a getter and setter myself. Therefore, the ARC keywords (strong or weak) have no meaning, I assume, so I eliminate them. This works fine on Xcode 4.3, but when my coworker opens them on XCode 4.2 the compiler complains that there is no strong/weak keyword, so I instructed him to meaninglessly enter the keyword back in again. Which is correct (with or without keywords)? To be clear: I have a property like this @property (nonatomic) NSString *foo and in the .m file I implement -(NSString *)foo and -(void)setFoo:(NSString *)foo and do