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]

Your mobile site is a joke, and your web developers suck

I love when someone has the same issues I do, but takes the time to write about them.  Steve describes some of the different ways that sites detect mobile browsers, and then turn successful browser detection into instant hatred.

I'm not saying that Steve is verbose, but the post I've drafted a few hundred times in my head goes something like this: if you are going to sniff for mobile browsers, redirect me to the mobile version of the page I am loading, not your brokedick mobile homepage that doesn't provide me with any path to the story I actually want to read.

Steve's post clocks in at around 730 words (and 5 pictures), but it's worth the read.

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]

© 2007-2010, 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.