Manipulate a plist from the command line

Since OS X 10.5 a command called PlistBuddy has been available.

It's useful for things like extracting the version number out of your Info.plist during a Run Script Build Phase.

PlistBuddy wasn't in my existing path, I found it at /usr/libexec/PlistBuddy

Example Usage

/usr/libexec/PlistBuddy -c "Print :CFBundleVersion" Info.plist

Outputs: 0.14, or whatever the value of the CFBundleVersion key in Info.plist is.

iPhone complaints versus Android complaints

iPhone users complained about the lack of third-party apps, the lack of 3G, the lack of GPS, that the screen got greasy and that AT&T's network sucked.

Android users complain that they can't install the newest OS on their device, that Exchange sync doesn't work, that third-party applications crash, that Android Market is horrible, that core applications crash, that settings are obtuse and scattered, that it's awkward to use and uncomfortable to hold, and even though the browser uses WebKit, it sucks.

Two generations of phones later, and all of the current iPhones are capable of running the latest OS from Apple. Third-party apps exist, and for the most part don't crash. Except for hardware differences (GPS, speakerphone, camera), most applications run on any of the 6 iPhone and iPod Touch devices. Even the screen doesn't get greasy any more, and Apple introduced the word "oleophobic" into the vernacular. The major failure is still AT&T, who apparently uses frame-relay and microwave links for their backhaul.

Meanwhile the problem with Android devices lies much deeper. SDKs aren't released until weeks out after an OS release, resulting in masses of applications that aren't compatible with the new OS release (and with the newest device, as long as Google continues their new device, new OS trend). The Android Market is a mess – applications are being published that steal personal information, easily half of the apps are filled with comments to the tune of "doesn't work on device XXXX" or "crashes immediately!" because of the massive API changes occurring between OS releases and developers that lose interest after a single application.

Notification controls are non-existent – I have yet to find a way to shut my Droid up. Even if I go into every application and turn off all the sounds (and boy is that fun) and shut the phone off, for some reason the Motorola demon spawn will power itself back on and chirp at me.

And the browser. Oh the browser. Sure, it renders pages fine, but it's slow, and doesn't support multi-touch. The screen itself is capable of supporting multi-touch, just not the browser. The free Dolphin Browser has tabs and multi-touch gestures, but shares another flaw with the bundled browser – animation speed. Animations take much too long. Aim for about 200ms from start to finish. Any more than that and users will become impatient. And after waiting 600ms for a pinch-to-zoom, impatient is accurate.

Apple has demonstrated that they listen to user complaints, or at least that they plan ahead well. Most of the iPhone complaints were addressable with newer hardware, but the problem with Android is that Google seemed to want to take the exact opposite tact of Apple, and go for complete openness. That's great, but it looks like they started by attacking standard UI controls and behavior. Maybe they consider it a feature? ANDROID – where every app is so different it's like having 15 phones in one!

Google needs to tighten up the operating system and address the sprawl of OS releases and devices quickly before they fall into the same trap that RIM is in – a nasty pit one where a developer has to build multiple versions of a single application to overcome massive feature disparity between OS releases1.

  1. Although in RIM's defense they're addressing this with OS 5.0 which has a unified codebase. If only the carriers would get off their asses and approve the 5.0 updates. [back]

Apple treats all iPhone developers equally – like crap

Today Google released Google Latitude for the iPhone, something BlackBerry and Android users have been enjoying for quite some time.

One paragraph in particular jumped out at me, emphasis mine:

We worked closely with Apple to bring Latitude to the iPhone in a way Apple thought would be best for iPhone users. After we developed a Latitude application for the iPhone, Apple requested we release Latitude as a web application in order to avoid confusion with Maps on the iPhone, which uses Google to serve maps tiles.

So Google was working "closely" with Apple, built a native iPhone application1 for Latitude, and then Apple essentially rejected it and told them to build a web application. Isn't building an entire application only to have it wholly rejected one of the leading complaints about the nightmarish App Store approval process?

  1. I'd love to see a build of this leaked out so jailbreak users could run it [back]

Deploying tokens to the RSA SecurID iPhone Application

OK, so you've got the SecurID soft token app installed on your iPhone, but now what? Installing a token isn't as simple as it is on the BlackBerry.

One method is to use the RSA Authentication Manager to generate CT-KIP URLs which can be sent to the end-users. You can read more about this from the RSA iPhone page after downloading the documentation and device definition file.

My preference is to use the Compressed Token Format (CTF) which will compress a .sdtid soft token file into an 81-digit string.

Clarification

I don't want there to be any confusion about the intent of this post – I'm demonstrating one possible way to install a token on your device without involving an administrator.  In most cases your ACE administrator will probably be willing to assist you with the installation of a token, and none of this will be necessary.

Preparing the Token

You can use the Token Converter application from RSA, or the web-based token converter on my projects page. Paste the contents of your .sdtid file into the form, supply your password if it requires one and create the CTF link.

Distributing the CTF SecurID Token

You can email links to the CTF token file or link to an HTML page containing the link. Both work, although the current version (1.0.5) of the RSA SecurID iPhone Application is overly sensitive to malformed links.  Sending an HTML email from Outlook will generate a malformed link, but as Phil noted in the comments composing a message in RTF format containing the link will work.

Malformed Links

Correct: com.rsa.securid.iphone://ctf?...
Malformed: com.rsa.securid.iphone://ctf/?....

If you are going to email the link make sure that it doesn't append the extra trailing slash after ctf. Do not use Outlook to send the email in HTML format as it always appends the extra slash – compose a RTF message instead.

You may need to change your Outlook options to retain RTF emails when sending to internet recipients.  In Outlook open Options > Mail Format > Internet Format. Under "When sending Outlook Rich Text messages to Internet recipients, use this format:" change the option to "Send using Outlook Rich Text format".

Outlook - Send using RTF

Emailing the CTF Link

For iPhone users running OS 2.x you can compose a plain text message with the CTF link (com.rsa.securid.iphone://ctf?ctfData=<token>) between angle brackets.

<com.rsa.securid.iphone://ctf?ctfData=200010059123075173498074908439042057320570235870932850239850433809854092834893835>

This will only work with OS 2.x, and not with the GM release of OS 3.0.

For all users running OS 2.x and OS 3.x you can send an HTML-formatted email with a hyperlink to the CTF URL, like Click here to install Token.  As mentioned above this will NOT work with Outlook, which adds an extra forward slash that the SecurID application cannot understand.

Linking to a page containing a CTF Link

The third option is to use Mobile Safari to open a web page containing a hyperlink to the CTF URL.  You can put this page somewhere on your own servers, or use my RSA CTF Hyperlink Generator to dynamically build these links. Opening http://coreygilmore.com/rsa/<CTF> will automatically  display an iPhone-ready hyperlink  to install the token.  View a sample page.

Resources

Updated 6/18/09: Added information about composing Outlook RTF emails to successfully send token installation links, brief clarification about the intent of this post.


© 2007-2013, Corey Gilmore | Posts RSS Feed | Comments RSS Feed | Contact

 

The views expressed on these pages are mine alone and not those of any past or present employer. All information presented on this site was obtained lawfully and not through disclosure under the terms of an NDA.