I have an app that uses the ABAddressBook API and I am trying to convert my app to use ARC.
I know the AddressBook API is written in native C and its giving me a lot of errors when ARC is enabled.
Anybody knows how to do it or is it even worth to do it?
Thanks in Advance.
One possible solution is to set compiler flags for the code that is giving you trouble to convert to. Go to Build Settings for the particular target you are using and add the flag "-fno-objc-arc" to the files that are problematic. Also, any more info on the actual problems arising would be helpful.
bartender,
First, working code is working code. You can easily intermix both kinds of memory management mechanisms in the same app. I only convert classes to ARC as I open the code up for other purposes. This allows me to slowly move my app to ARC. Why do you want to change this code to use ARC?
Second, the interface between core foundation items and ARC can appear to be complex ... but it isn't. Most issues are handled by using the __bridge type qualifier. Typically, the compiler/fix-it tells you exactly what you need to do. (Working, non-leaking CF code doesn't need to change. It just needs to tell ARC to leave it alone.)
Andrew
Related
I'm looking to debug an app on a jailbroken iPod Touch 4, iOS (5.1.1) using. The only problem is GDB doesn't appear to have any knowledge of class/selector names for the app.
Attaching and setting address breakpoints work, but it cannot identify symbols when attempting to use objective-c names. For example, break -[Class Selector:] will fail. (I'm aware that + and - represent different class types.)
Also, I do not have the source for this app and will not be able to acquire it.
I'm looking to purely use GDB on the device without xcode or the source.
Has anyone successfully done this before? Thanks in advance for any answers.
Under the assumption that you're trying to debug an app from the store / a release build then your binary will have had the symbols stripped from it by the compiler. Only debug builds retain the symbols: there's no reason for release builds to keep them.
To find out the names you'll need to disassemble the binary manually and figure out what you need from there. This is a lengthy topic, too long to really type up in great detail here (O'Reilly's Hacking & Securing iOS Applications book has a good step by step tutorial).
Bear in mind that under the hood the Objective-C messaging framework is made up of C: if you're not familiar with things like the objc_msgSend series of functions you might find getting to know them better will help you along. Since every method invocation in Objective-C is sent using objc_msgSend you can effectively figure out class and method names by break-pointing every time it's called (or rather, breakpointing and automatically dumping the contents: it will be called so many times that to do it manually would take far too long).
However, this is only going to help you identify the symbol names: as the symbols are stripped from the binary you're still going to have to breakpoint on the addresses themselves.
Has anyone converted the Apple MVC Networking sample to ARC?
http://developer.apple.com/library/ios/#samplecode/MVCNetworking/Introduction/Intro.html
As a new iOS developer I am very interested in ARC and attempted the conversion w/o success, sent a few emails to Apple, no response.
During the conversion there were some CF functions that I couldn't bridge correctly and there were all kinds of memory issues and exceptions.
Currently I don't have an example, just wanted to see if anyone else has been though the conversion, Google didn't help me out this time :)
Thanks
Just curious but why are you trying to do this conversion? If you are integrating this example into a project that already runs with ARC, you can exclude the source files that aren't ARC explicitly in the Compile Source section of your build phases in the Target.
If you want to try this, select the sources that don't have ARC and hit enter. A dialog should appear where you can enter:
-fno-objc-arc
Hope this helps.
XCode 4.3.2 has a new feature to convert projects to ARC.
Edit->Refactor->Convert to Objective-C ARC
Should get you going in no time!
I'm about to start a new project and I'm wondering whether I should use ARC or not.
I don't know if it's recommended to use ARC when I know that the new project will have quite a lot of dependencies on older code and external libraries which have not been converted to ARC yet (three20, shareKit, ASIHTTPRequest,..) ?
Some of the libs are quite big so I think it'll be tedious to add the -fno-objc-arc flag for each separate file.
It seems that Apple has went the ARC way definitely for IOS and every IOS developer will have to convert sooner or later.
But is it maybe just too early to jump on the ARC bandwagon yet ?
Compiled libraries will work with ARC out of the box. All ARC does is add the memory management automatically. It'll add the retains, releases etc. If the code is already compiled, it'll contain the necessary memory management, regardless of whether it was compiled with ARC or not.
If you're adding 3rd party code directly to your application, then you'll need to make sure that code works with ARC, but you don't need to change anything for compiled libraries and frameworks.
Apple are pushing ARC as the way forward, so for a new project, I don't think there should be any problems with using it.
I have developed a number of frameworks that I want to ship with my application. I don't want others to be able to use the frameworks, but i've seen utilities such as class-dump which can get the headers back easily.
My question is, how can I make my frameworks more secure? I know that they'll never be 100% secure, but are there some good general tips to follow?
Thanks!
In short, don't bother. The very nature of the Objective-C runtime is that there is significant metadata available.
The reality is that it would be exceedingly rare for someone to pick up your framework and try to embed/use it.
Note that code obfuscators don't really work very well; there is still quite a bit of metadata that must be exposed. You can go that route, but -- generally -- it makes debugging/crash analysis significantly more difficult without actually solving a real problem.
I see others have pointed you down the path of obfuscation (though I suspect that the answer of #define someSelector mmmrrrggglll wasn't really tested much).
Some specific points to consider as you go down this path (I'm sure I've missed many):
if you use KVO/KVC, make sure you obfuscate all those calls to addObserver:* and the like
if you are targeting Mac OS X, don't forget about Bindings, too!
Interface Builder's xib files will often contain references to instance variables and/or properties and/or methods. Don't forget about those!
Anything that uses runtime introspection will need obfuscation, too.
make sure you don't obfuscate anything that the system frameworks are dependent; wouldn't want to subclass NSView, say, and then obfuscate drawRect: or initWithFrame:.
In some cases, the Info.plist can refer to class names and entry points. Don't mess with those, either!
Also, make sure every use of #selector() is also properly obfuscated; nothing like setting up an NSTimer firing against a method that no longer exists.
Make sure your obfuscation plans also includes the engineering work necessary to create an un-obfuscator for crash logs.
You'll also want to consider how you are going to debug a production binary; assume your stack traces will be obfuscated. b mmmrrrggglll ftw!
If your framework has symbol exports control, make sure to obfuscate 'em, too! Keep in mind that the way symbols are created differs between architecture and compiler, in some cases.
You can use static libraries to link with your application instead of frameworks. However, if you want to ship frameworks, you can use code obsfucators to make your library more difficult to use.
EDIT:
This SO post has a pretty simple description of a basic obsfucation.
How can objective C classes be encrypted
There are products on the market that do this, but they are expensive.
For the application I am writing, I need to access some other applications' items, for which Applescript seems the best way to go. I have been using the Appscript framework, which worked well, because it allowed me to thread it and not make my app lock up when an Applescript was taking a while. However, now I am attempting to make my application 64 bit compatible, and it seems like the Appscript framework does not support 64 bit. Is there a "good" way to use Applescript in Cocoa that will not lock up my application, but still give me the full control I need?
--firen
It seems like SBApplication should work, but I haven't used it before.
According to #cocoadevcentral:
SBApplication: use to make cross-application scripting calls with Objective-C instead of AppleScript. Ex: get current iTunes track.
Here is is the excerpt from the documentation:
The SBApplication class provides a mechanism enabling an Objective-C program to send Apple events to a scriptable application and receive Apple events in response. It thereby makes it possible for that program to control the application and exchange data with it. Scripting Bridge works by bridging data types between Apple event descriptors and Cocoa objects.
Although SBApplication includes methods that manually send and process Apple events, you should never have to call these methods directly. Instead, subclasses of SBApplication implement application-specific methods that handle the sending of Apple events automatically.
For example, if you wanted to get the current iTunes track, you can simply use the currentTrack method of the dynamically defined subclass for the iTunes application—which handles the details of sending the Apple event for you—rather than figuring out the more complicated, low-level alternative:
[iTunes propertyWithCode:'pTrk'];
If you do need to send Apple events manually, consider using the NSAppleEventDescriptor class.
Hope that helps!
As Blaenk mentioned Scripting Bridge may well be the way to go, although it can prove somewhat inefficient if you have to iterating through large arrays etc.
The simplest way to run an Applescript in Cocoa is using NSAppleScript.
Apple has some pretty good examples, which I found useful when I needed to do something similar. There are three articles you might want to take a look at. They all contain some sample code, which I always find very useful.
A Few Examples of using Scripting Bridge
Performance & Optimisation with Scripting Bridge
NSAppleScript Technote/Example
I created a gist with the full URLs as I can't post more than one link, what with being a newbie and all.
http://gist.github.com/130146
it seems like the Appscript framework does not support 64 bit.
Should work. Make sure you set the correct architectures and SDK (64-bit requires 10.5) in the Xcode project. File a bug report if you have a specific problem.