I'm currently using BWToolkit, does anyone know if there are any steps that need to be taken before submitting to the app store (as far as licensing)? Do I need to put any disclaimers anywhere etc? I know it's BSD licensed but I don't want to have my app rejected because I missed a simple legal step.. Any help?
I don't think that NSGod is right.
You may want to read this and/or that.
You are not going to like this answer.
You will not be able to use the BWToolkit.framework as-is. Some of its classes rely on private APIs which Apple has strictly forbidden for apps that are submitted to the app store.
For example, the developer ran a tool called class-dump on the AppKit.framework Mach-O object and generated the .h files for 4 secret classes: NSTokenAttachment (an NSTextAttachment subclass), NSTokenAttachmentCell (an NSTextAttachmentCell subclass), NSWindow (NSTimeMachineSupport), some additional methods on NSWindow, and NSCustomView.
I'm not that familiar with the inner workings of the framework, but depending on what classes you've made use of, it may be possible to create a custom build of the framework from the source that doesn't include the private APIs. Or, you could just include the source files for the classes you use in your project (provided of course that they don't rely on private APIs).
What particular classes did you make use of? If you used BWSplitView, you might look into using RBSplitView. (I talked to Rainer and have confirmed that there's no private APIs used in it, so you'd be okay).
Related
I was wanting to make an app similar to something like TextExpander, but I am not sure how you would intercept the text. As far as I can tell, I need to start with NSAccessability. Could anyone share some snippets, or at least point me in the right direction?
First off, you should be aware that, because of the sandboxing requirement, this isn't possible at all if you want to sell your app in the App Store.
If you don't intend to sandbox your app, you can use the NSEvent class method addGlobalMonitorForEventsMatchingMask: to create a global key event handler that gets called when keys are pressed in other apps (but not your own app, use addLocalMonitor... for that).
To actually insert snippets, like TextExpander, there are several ways. You can use the accessibility APIs, but that requires that the app(s) you're targeting support accessibility, which isn't always the case.
Another option is to use the Quartz Event Services (CGEvent) APIs which provide (among other things) a low-level method to simulate key events.
Edit: Nevermind. You're asking about Mac OS. I thought you were asking about iOS.
You should look at how TextExpander is used by other apps. The target app has to build in support for TE by making an object provided by TE a delegate of the text field. You can't run your code in someone else's app. They have to compile your code into their app. That's why there's a TextExpander SDK.
Once the TextExpander code is in the target app, the text field delegate gets the shared snippets by looking for snippets put into a shared pasteboard.
Does anyone know how programs like iPhoneExplorer manage to list/add/remove files on an iDevice?
I would like to do something similar (but more basic) in a Cocoa Touch application.
It's technically not an Apple-approved™ method, so don't plan on putting this in the App Store. But it is possible. First, import the MobileDevice framework from /System/Library/PrivateFrameworks. Then use the reverse-engineered header for the MobileDevice framework:
http://code.google.com/p/ziphone/source/browse/trunk/ZiPhone/MobileDevice.h
It includes all the methods necessary to communicate with an attached iOS device.
There's also a C++ wrapper for it that's a bit easier to use, especially for detecting the device in the first place. It also includes methods specifically for jailbreaking, but they're not required.
http://code.google.com/p/independence/source/browse/trunk/libPhoneInteraction/PhoneInteraction.cpp?r=323
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.
I was wondering if there were a way to extract information from an objective-c app, static or dynamic library and/or framework?
Information such as an array of class names without instantiating or running the target.
I've checked google and the apple developer documentation and haven't found anything.
Frank
F-script appears to be able to do what you want, but I'm no expert. Check out www.fscript.org.
If you want to extract classes from an application/dynamic library, there is a handy tool called ClassDump.
It can even generate the header files in order to get an overview of the classes, protocols, etc.
If you want to do it at runtime, then take a look at the source code to learn how to load and parse the different mach-o segments.
This is an excellent starting point for reverse-engineering Cocoa apps:
http://culater.net/wiki/moin.cgi/CocoaReverseEngineering
It mentions F-Script, class-dump, and a few others.
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.