code signing
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.
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."
