CodeSigning
Latest
The right and wrong ways to run apps without dock icons
I recently downloaded an app that I wanted to run without a dock icon. There wasn't a preference to run that way, but I remembered that there was a way to edit a file within each app's "bundle" (.app "files" are actually folders or packages). Sure enough, a little time on Google brought me to information about adding or changing the "LSUIElement" key in the app's Info.plist file. It also led me to Dockless, which is an app that automatically sets that key for you when you drag the app to Dockless' window. That seemed much safer than editing the file myself, so I downloaded Dockless, dragged the app to it and restarted the app. It crashed immediately and every time afterwards. I'm no math whiz, but I can put two and two together. I emailed the developer, who confirmed my suspicion that editing the app that way had broken code signing, a feature that Apple introduced in 10.5 and which is now an essential part of most current apps, including apps from the Mac App Store. The solution was simple: delete the app and re-download a clean copy from the Mac App Store. (Running Dockless again to "undo" the change was not enough in my experience.) Just for the sake of completeness, I tried Dock Dodger, another application designed to do the same thing. To the developer's credit, there is a disclaimer on their website that "you may get some strange behavior or find some features inaccessible" after using it. I made a copy of iCal and ran Dock Dodger on the copy. It ran without a dock icon, but it also refused to store my MobileMe password, meaning that my calendars would not sync via MobileMe. Lesson learned. Being able to coerce apps to run without a dock icon might have been something we could get away with in the past, but it was never a very good idea, and like Lando's deal with Darth Vader, it's getting worse all the time. Fortunately I've noticed more and more applications that give users a preference setting to turn off the dock icon. If app developers build this into their apps, the feature doesn't break code signing, and the apps will continue to function normally. So what should you do if you find an app that you want to run "dockless" that doesn't have a preference setting for it? Well, if you want to try one of the above apps (which I do not recommend), be sure to make a copy of the app, and try the changes on the copy. That way, if it doesn't work, you can trash the copy and still have your "clean" original. My recommendation is to contact the developer and ask (nicely) for them to consider adding the feature in a future version. Developers weigh new feature requests based on a number of different things, but user requests are an important part of that decision process. It may not be feasible for all applications, but if you don't ask, they'll never know it was a feature you wanted.
SDK devsugar: Re-signing applications
TUAW's devsugar series helps introduce developers to tools and tricks that they might not yet be familiar with. Today's tip centers on signing already-compiled and already-signed applications with a new custom signature. A while back, I posted about a way to sign already-compiled applications with your personal credentials in order to better allow developer-to-developer distribution. By re-signing an application, it allows you to install it on any of the devices you have registered to your account at Apple without having to go through the fuss and bother of normal ad-hoc distribution. In addition, it makes it easier to develop applications on a contractor's machines, to ship them to a client, and then have them signed and shipped to App Store using the client's identity. A basic command-line solution is as follows. It calls codesign (found in /usr/bin) to sign the application, using the default keychain item that matches "iPhone Developer". It's a handy script, especially for informal beta distributions. #! /bin/bash export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/codesign_allocate codesign -f -s "iPhone Developer" $1 There are, however, several problems with this approach. First, it assumes you only want to sign with development (typically "Debug build") credentials. That's not going to work if you need to re-sign for distribution. (Solution? Change iPhone Developer to iPhone Distribution). Second, it assumes you only have one developer or distribution profile in your keychain. (Solution? Change iPhone Developer, for example, to iPhone Developer: Company Name to exactly match just one keychain entry.) Third, it assumes the person doing the re-signing knows how to use a command line. For that, the solution is a little more complicated. Recently, this topic came up on a developer e-mail list that I moderate: how do you make it easier for a non-technical client to re-sign an application, normally for distribution. As a solution, I put forth the proposal that one could embed the above shell script behavior into an AppleScript droplet. After consulting with a few colleagues, and gathering their requirements, I decided to give the project a try. I built an AppleScript application that signs any application dropped onto it. You can find a working copy of the application at my website. App Signer iterates through any apps dropped onto it, checks to ensure whether each file (or bundle, really) ends with an ".app" extension, and then attempts to sign those files using /usr/bin/codesign. Users can choose to sign with Developer credentials, Distribution credentials, or select Other to open a prompt and enter text for keychain disambiguation. (See the screen shot at the top of this post for an example of the disambiguation dialog.) The application displays results for each application, one at a time. Please note the following caveats: I make no attempt to guarantee that the app dropped onto this utility is actually an iPhone app (rather than, say a Macintosh application). When working with on-device keychains, the identity used to sign the application has to match the application id set forth in the Info.plist file for the application, otherwise keychain access will fail. This is a free application. It is offered under the BSD license. Use it at your own risk. Credit always appreciated. The open source github repository for App Signer can be found here. To create the application, open the AppleScript source in Script Editor and choose File > Save As > File Format: Application.
Dev Corner: Signing iPhone apps for informal distribution
At times, iPhone developers might like to test out applications without going through the formality (or challenges) of ad hoc distribution. Ad hoc distribution was introduced by Apple to allow software testing on up to 100 registered devices. It is, admittedly, a bit of a pain. Developers must collect device information (the "UDID", aka their unique device identifiers), register that device at the iPhone developer portal, create an special provisioning certificate, add a special entitlement, and build an ad-hoc only version of their software to distribute along with that certificate. If all that seems like a hassle, well, yes it is. It is, however, the proper, authorized, and recommended way to distribute pre-release software, whether for testing or reviews. But there is another way. If you know for sure that your target audience is another developer, the process becomes way easier. You can simply compile a normal development build of your application and send a copy of that build to another developer. That's because each registered developer has the ability to sign applications. Although the app was built to work with just the in-house devices you've registered for development, another developer can re-sign that application using the simple command-line script shown here. #! /bin/bash export CODESIGN_ALLOCATE=/Developer/Platforms/iPhoneOS.platform\/Developer/usr/bin/codesign_allocate codesign -f -s "iPhone Developer" $1.app This script uses Xcode's codesign utility to sign the already compiled version of the application. Once applied, you can then install the application through Xcode. So is this a general distribution solution? No. And thank heavens for that; free trading of app binaries would rapidly lead to piracy. This approach allows developer-to-developer testing and collaboration only. The development signing is limited to the units you have personally registered. If you want to try this out, follow the link at the start of this post. It leads to a testing folder I keep around and occasionally stock with software that I need tested. It also includes a copy of the script, which you must make executable (chmod 755 signit).
Rogue Amoeba on code signing, iPhone SDK
Mike Ash at Rogue Amoeba has published his fairly extensive thoughts on Apple's code signing policies and plans, as well as how they relate to the iPhone SDK. He makes some solid points and elaborates on thoughts that are being bandied about elsewhere on the 'net. In his critique of some points in the iPhone SDK announcement, his concerns regarding the "banned" iPhone apps are quite valid, in my opinion. Out of the list of apps to be denied (illegal, malicious, unforeseen, privacy, porn and bandwidth hog), he picks out a couple that are of concern. In regards to the issue of "porn", he notes that "...Apple is making moral judgements of the apps they sign." To me, it seems like Apple chose the safe option and just categorically denied materials that could sully their reputation, which I personally think was a good (if not obvious) choice. But the question arises, as it always does, about the definition of porn and obscenity... and who makes the call. Apple, as gatekeeper, gets to make those decisions for all of us. I can see some torrid debates arising in the future.Also of particular (and potentially more controversial) concern is the category "unforeseen," which provides a fairly broad scope for Apple to add to the list later. Again, it's likely a smart decision on Apple's part and a good way of sealing off loopholes without making the list read like a legal contract (see "License Agreement"), but leaves open the option for some heavy-handed control over what you can put on your iPhone.Of course, this initial list is incomplete, with restrictions outlined in the SDK license agreement (as pointed out in Rogue Amoeba's subsequent post). If you take an interest in this debate, be sure to check out Mike's post, "Code Signing and You."
