Using GDB’s ‘po’ command while a malloc lock is being held
Posted on April 23, 2010 by Brian Webster
Filed Under Cocoa, Programming, Tips & Tricks | 1 Comment
Starting in a recent version of Xcode (version 3.2 I think, but I’m not totally sure) a change was made in GDB where, if you try to print out the description of an Objective-C object, either using the ‘po’ command from the console or the “Print Description to Console” contextual menu command, you will sometimes get an error message saying something like “Cancelling call as the malloc lock is held so it isn’t safe to call the runtime” or “warning: Not safe to look up objc runtime data”.
The reason for this is that some other thread in your program is currently in the process of allocating some memory through malloc() or some other memory allocation routine. To print out your object, GDB will call the description method on the object being printed, which will return a plain NSString that it can easily print to the console. However, the description method almost always involves allocating some memory to create the new string containing the object’s description. Calling this while malloc is still being executed on another thread can lead to all sorts of crashes, memory corruption, or other weirdness.
However, while this change does prevent that sort of problem, it creates another problem in that when you hit a breakpoint, you can never be quite sure about whether you’ll actually be able to examine the content of your objects. In my experience, this seems to be even more of a problem in garbage collected applications, since there is always a collector thread running in the background which can often be the thread responsible for allocating some memory at the time your breakpoint gets hit.
This has become quite a pet peeve of mine, especially when I’ve spent quite a bit of time setting up a scenario to reproduce a bug, and I get to where I can break at the point in the code where the problem is, only to find that I can’t actually look at anything! Needless to say, this puts a cramp in my style, and I’ve been looking for a workaround for this for quit some time. I’ve found that sometime, stepping over a few statements will run the program enough that the thread that’s allocating memory will finish, but this is very hit-or-miss (more miss than hit) and I usually have to just restart my application and/or perform whatever setup steps were needed to get back to the same point, and hope that this time I can actually print out information.
So, this being the case, I was very intrigued by a tidbit I learned while watching one of the WWDC session videos from last year. The tidbit is in the form of a GDB flag called “scheduler-locking”. What this does, when enabled, is to cause GDB to only run the current thread when you click the “Continue” button or use the “continue” command from the GDB console, rather than running all threads at once. To enable this behavior, you can simply type “set scheduler-locking on” on the console.
The way I thought of using this to get around this malloc problem is as follows. Let’s say I get to this point where you’ve hit a breakpoint but can’t print anything out. What I’ll do is:
- First, I need to find out which thread is the one holding the malloc lock. The easiest way to do this is to type “info threads” in the GDB console. That will list all the threads running in your application, along with the topmost function call on the stack for each thread. Now, the exact function that’s responsible can be a number of different things, including
mallocobviously, but also any number of Cocoa, CoreFoundation, Core Graphics, or any number of other allocation related routines. So, you’ll have to do a little judging to figure out exactly which thread is the culprit in your particular case. - Switch to that thread to make it the current thread. You can do this either by typing “thread” followed by the thread number in the console, or by just selecting the appropriate thread from the pop-up menu in Xcode’s debugger window.
- Once you’ve done that, go and type “set scheduler-locking on” in the console.
- Then, just click the “Step Out” button in Xcode to make the current thread finish whatever allocation function it was in. It’s possible you’ll need to step out two or more levels in order to make sure you’re out of malloc-land. The trick here is that, since you enabled the scheduler-locking flag, only the thread that you selected will be run. This means that the thread your breakpoint is in (as well as all the other threads in your program) will not have budged at all, and once you’re out of the allocation routine, you can then switch back to that thread and print things out!
- Finally, after you’ve finished your debugging, make sure to go back and do a “set scheduler-locking off” before continuing with the rest of your program. Leaving it on could cause other problems such as deadlocks in further debugging, so you should only leave it on as long as necessary to get the job done.
I’ve only gotten the opportunity to try this technique a handful of times so far, but it’s worked like a charm each time I’ve tried it. It is a little involved, but in situations where you have a hard to reproduce bug you’re trying to figure out, it’s far less work than rolling the dice over and over, hoping you’ll hit your breakpoint in a state where you can actually examine your data. I’d be interested in hearing if anyone else tries using this technique and whether it works consistently, or if I’ve just been lucky so far.
Thoughts on the iPad
Posted on January 28, 2010 by Brian Webster
Filed Under Apple | 3 Comments
With the announcement of the iPad yesterday, everyone and their uncle has their take on who will want to use it, who won’t, and exactly what niche it will fill in the computing ecosystem. So of course, I can’t help but put in my two cents as well.
What is the iPad?
One of the main points of contention seems to be how to categorize the iPad. What is it, really? Is it just a big iPod Touch? Is it a type of personal computer, just a variation on the laptop form factor? Or is it something entirely new that doesn’t fit any existing category?
To start off with, at least in its current form, I definitely don’t think you can call it a personal computer. The main reason for this is that, while it has a lot of functionality that a PC (or Mac) has, you still need to have a PC in order to be able to use the iPad for most of the things it does. The primary way of getting content onto the iPad is by syncing it with your desktop or laptop machine, via iTunes. Without a PC to attach it to, you can’t put any of your music, photos, or videos onto it, and you can’t even update the software on it or back up your data. In order for the iPad to replace a PC, it has to be able to exist without requiring another PC. Could this happen in the future? Perhaps, but it’s definitely not the case right now. For now, the iPad is a secondary device, and will almost never be somebody’s sole computing device. (One exception to this would be a family that all shared a single PC, with each member of the family having their own iPad. You still need a PC, just not one per person )
In his presentation, Jobs did specifically pitch the iPad as bridging the gap between PCs and mobile devices such as phones and music players. Currently, the most common tool for this job is the netbook, which is basically a small, low powered, inexpensive laptop computer. The problem is, while a netbook is certainly more portable than a full sized laptop, it still comes with all the complexities and headaches of a full-fledged PC, such as figuring out how to install new applications, dealing with viruses, organizing your files on your hard drive, and so forth. The basic premise of the iPad is that personal computers, no matter their size, are not the right tool for the large number of users who just want to do fairly basic tasks with their machines, such as browse the web, do e-mail, listen to music, and view their photos. The iPad is designed from the ground up to fill that gap.
Further proof that Apple is moving aggressively to capture this market can be seen in their pricing. $499 is a very competitive price point, especially for Apple. Remember, this is the company that started out charging $400 for a music player and $500 for a cell phone.
It’s not quite at the $300 price point most netbooks are priced at, but I think it’s close enough, especially given the difference in quality between the iPad and a netbook. I predict that people will buy tons of these things at $499, then next year Apple will drop the price a hundred bucks or so, and then they’ll sell even more, just like they did with the iPod and the iPhone.
Open vs. closed platforms
One concern that many people (especially developers) have is the closed nature of the iPhone/iPad, both in terms of media content and software. It’s become pretty clear that Apple wants to have as much control as possible over the user experience on these devices. They act as sole arbiter of what software can and cannot be run on the device. If you want to write and sell software for the iPad or iPhone, you have to go through Apple. The downsides to this have been pretty well hashed over, and include arbitrary limitations on what is possible for your software to do, risk of rejection due to some reason not explicity stated in the SDK agreement, risk of rejection due to a simple error on Apple’s part, and the ability for Apple to stifle competition to their own apps.
What I think makes developers even more nervous though is not necessarily the current state of things, but rather the trend of where Apple appears to be headed. The iPhone has been a monster success, and presumably Apple will see at least some success with the iPad as well. As these platforms comprise more and more of Apple’s business, Apple could someday decide that they want to apply the same level of control to software written for the Mac, which does not currently have the kinds of restrictions that the iPhone OS platform has. For programmers such as myself who make their living on the Mac, the though of ceding that much control of my well being to Apple is certainly a scary thought.
Realistically speaking though, I personally don’t see this happening anytime in the near future. The primary (though not sole) reason for this is the huge difference in market share that Apple has in the smartphone and music player markets versus their share of the PC market. When it comes to phones, the iPhone is currently the 800 lb gorilla, and all the other phone companies are scrambling to retain their marketshare which is steadily being eroded by the iPhone. In the PC market though, even with the recent gains the Mac has made, Apple’s marketshare is still pretty low, much much lower than the iPhone.
Right now, for smartphone development, the iPhone is king, and everyone wants to develop for it, because that’s where the largest number of potential customers lie. This being the case, most developers are willing to concede to Apple’s terms in order to be able to sell their software to millions of iPhone users, and don’t have a lot of other viable options (though hopefully Android or some other platform will become good enough to compete well with the iPhone).
On the Mac, however, if Apple were to announce that all Mac applications needed to be approved by Apple in order to be sold, you would no doubt see developers desert the platform in droves. While developing for the Mac is nice, there are very viable alternatives for Mac developers when push comes to shove, including developing using .Net, Java, or any number of web based technologies. Simply put, Apple just doesn’t have the same leverage on the Mac platform the way that they do on the iPhone platform.
I also don’t give much credence to the theory that the desktop computer will eventually just go away entirely, meaning the Mac platform will be gone, and the iPhone/iPad platform will be all that’s left. I think the desktop will always be an the forefront of computing, and while mobile devices such as the iPhone or the iPad may take the place of some of what people formerly used laptops for, people will always want to be able to leverage the full power and flexibility that a true personal computing platform provides.
So basically, while I think it’s good to be wary about the openness of the Mac platform in the future, I don’t think this is something to worry about as long as the Mac’s market share stays relatively low. Apple currently only aims for the high end market, opting to make money off of high profit margins on fewer machines rather than selling more machines for less money per unit. Unless Apple changes this strategy drastically, I don’t see the Mac’s markeshare growing by leaps and bounds, certainly not enough to be anywhere comparable to Windows’ share of the PC market, or even iPhone’s share of the smartphone market.
Indie Relief: You get great software, proceeds go to Haiti
Posted on January 20, 2010 by Brian Webster
Filed Under News | Comments Off
Put together over the last week or so by Justin Williams of Second Gear Software, the Indie Relief promotion includes over 140 Mac and iPhone developers who have banded together and pledged to donate all of today’s (January 20th) proceeds from their software sales to various charities in order to help the victims of the Haiti earthquake.
I’m happy to announce that Fat Cat Software is participating, so the proceeds from any purchases of iPhoto Library Manager, PowerTunes, or PlistEdit Pro that happen today will be given to Doctors Without Borders to help Haiti in its recovery from this tragic crisis.
So, head over to www.indierelief.com, where you can browse through over 200 Mac and iPhone applications. Purchase any of them today, January 20th, and the proceeds will be donated to a charity of the developer’s choice. Or, if no software grabs your fancy, you can also donate directly to one of the charities listed on the page.
P.S. Because of the global nature of the companies involved, there has been a little confusion about time zones, what counts as January 20th, and so forth. Each developer will make their own decision on that, but what I’ve decided is to include all sales starting at midnight on Jan. 20th Eastern time through 11:59 PM Pacific time. So, it will actually be a range of 27 hours worth of purchases which will be given to charity.
Problems syncing photos with iPod, iPhone, or Apple TV and iPhoto 8.1
Posted on December 8, 2009 by Brian Webster
Filed Under Tips & Tricks, iPhoto, iPhoto Library Manager, iTunes | 4 Comments
Update: 3/30/10 According to Apple, this bug has been fixed with the iPhoto 8.1.2 update
A bug has recently cropped up in iPhoto (version 8.1 appears to be the first version with the bug, and the bug remains as of version 8.1.1) which can cause problems when attempting to sync your photos using iTunes to any device, such as an iPod, iPhone, or Apple TV. I’ve seen a whole bunch of reports of iPhoto Library Manager users encountering this bug, enough that I thought a blog post describing the problem and the solution would be helpful.
Symptoms
If you suffer from this bug, when you open iTunes and attempt to sync a device with your iPhoto library via iTunes, you’ll get an error reading “iTunes cannot sync photos to (whatever device you’re using) because of a problem on your computer. An unknown error occurred (-50)”.

When using iPhoto Library Manager to try to look at an affected library’s contents, you’ll get an error message reading “The album data file for this library is malformed. Encountered unknown ampersand-escape sequence at line X”.

Cause
The root cause of this problem is triggered by the following setup:
- You’ve created a custom slideshow in your iPhoto library
- You have used the “Music” button in iPhoto to assign a track from iTunes to play while the slideshow is being displayed
- The track you chose has an ampersand (&) character anywhere in the name of the song, the song’s artist name, or the song’s album name.
It’s actually the path to the song that’s relevant, but since iTunes organizes your music into subfolders based on these three fields, an ampersand existing in any one of them will result in the file’s path having an ampersand in it. An example is illustrated below, where a song by “Rob Thomas & Santana” is selected as the music for a slideshow

Solution
There are actually a couple different ways to work around this problem. I’ll list them here in order from simplest to most complicated.
- Delete the slideshow. Simple, but effective. But on the other hand, you lose your slideshow!
- Turn off music for the slideshow. Uncheck the “Play music during slideshow” checkbox and then click the “Apply” button to save your changes. But what if you still want to have music during your slideshow…?
- Choose a different song. Select a different song, one where no ampersand character occurs in either the song name, artist, or album title, then click “Apply”. But what if you really really want that specific song you spent hours and hours choosing from your vast music collection to find the perfect one?
- Remove all the ampersands. The only way to keep using the same song will be to remove any offending ampersands that occur in the path to the song file. For this, you’ll have to open up iTunes, find the song in question, and change the name, album, and/or artist to remove any ampersand characters in those fields. After you’ve done so, you’ll also need to go back into iPhoto and re-choose the song in the slideshow music settings, to make sure iPhoto is updated to point to the song’s new location.
One additional source of ampersands is if your entire media folder is located inside a folder or drive with an ampersand in the name. For example, if you store your iTunes media folder on an external hard drive and have named the drive “Music & Video”, then this will cause all your songs to have an ampersand character in their path. If this is the case, then you’ll need to rename the hard drive or folder to remove the ampersand.
Once you’ve done that, if you quit iPhoto, open up iTunes, and try syncing your device again, you should now be able to successfully sync your photos. If you still get an error, double check and make sure that the changes you made in iPhoto have “stuck” (click that “Apply” button!), and if you have multiple slideshows, that you’ve checked all of them for potential troublemaking music settings.
PowerTunes 1.1.1, now compatible with iTunes 9
Posted on September 18, 2009 by Brian Webster
Filed Under News, PowerTunes, Updates, iTunes | Comments Off
PowerTunes 1.1.1 was released today, which now provides full compatibility with iTunes 9, along with a couple other miscellaneous bug fixes. The main points of improvement in working with iTunes 9 are:
- The fix dead tracks, playlist/track copying, and merge functions now work with iTunes 9
- PowerTunes now understands the new layout of the iTunes media folder (formerly known as the iTunes music folder). The main place this affects things is to improve locating multiple tracks when using the Fix Dead Tracks command.
- PowerTunes now also recognizes the new default folder name of “iTunes Media” where applicable
So, if you have any older version of PowerTunes and have iTunes 9, I highly recommend using the “Check For Updates” menu item to update to the latest version.
PowerTunes compatibility with iTunes 9
Posted on September 9, 2009 by Brian Webster
Filed Under News, PowerTunes, iTunes | Comments Off
Apple released a new version of iTunes today, version 9.0, which adds several major new features to iTunes. Some of the changes in the new version will cause several features of PowerTunes not to work properly with iTunes 9.0 installed. The affected features are:
- Copying tracks and playlists between libraries: you will not even be allowed to drag and drop tracks or playlists on a library to attempt to copy them
- Merging libraries: an error message will be displayed almost immediately upon starting a merge
- Fixing dead tracks: no items will be displayed in the dead tracks list, even if dead tracks are present in the library
An update for PowerTunes will be published soon that will address the issues listed above. Preliminary testing indicates that all other features of PowerTunes work normally with iTunes 9, so you can continue to switch between your libraries, create new libraries, find orphaned tracks, and so forth using the current version of PowerTunes (1.1). If you do experience any problems with PowerTunes 1.1 and iTunes 9.0, please use the “Contact Support” menu item in the Help menu, or e-mail support@fatcatsoftware.com
You can check the “Automatically check for updates” checkbox in the PowerTunes preferences window to be notified when the update is made available, and/or keep an eye on this blog for further postings.
Preprocessing InfoPlist.strings files in Xcode
Posted on September 3, 2009 by Brian Webster
Filed Under Cocoa, Development | Comments Off
Xcode provides a handy feature called “Info.plist preprocessing” that allows you to specify placeholder values in your plist that are then automatically replaced by Xcode with values you specify in your build settings. The most common use of this is to place the current build’s version number in one or more appropriate places in the Info.plist file. This lets you change these kinds of values in one place, rather than having to track down every usage in the Info.plist and replacing them manually.
In addition to the Info.plist file itself, you can also have one or more localized InfoPlist.strings files included in your application bundle. There are some strings in the Info.plist (e.g. CFBundleGetInfoString) which are displayed directly to the user, and thus need to be localized. Putting these keys in InfoPlist.strings instead of directly into Info.plist allows you to have localized versions of these strings.
However, Xcode’s Info.plist preprocessing only covers the actual Info.plist file, and not the various InfoPlist.strings files you may have included in your application bundle. This means that if you have a version number or some such that you want to keep up to date in one of these strings, you have to resort to replacing them manually, which is both error prone and a pain in the ass. I was able to solve this problem for my own project, and thought I’d share the details here in case it came in useful to anyone (and in case I forgot how to set it up in a future project and needed some help from my past self
)
To get things working, I enlisted the help of a neat little tool called wincent-strings-util, courtesy of Wincent Colaiuta. It performs several tasks, but one of them is specifically geared towards doing this kind of substitution in a .strings file. In my setup, I simply include a copy of the tool in my project repository, so no installation is required and the build “just works” wherever you check out the project.
To get the substitution to be done when doing a build in Xcode, I defined a new build rule in my target to use a custom script to handle Info.plist files. To do this:
- Choose “Edit Active Target” from the Project menu, click on the “Rules” tab, then click the “+” button down at the bottom of the window to add a new build rule.
- From the “Process:” pop-up menu, select “Source files with names matching:” and then “*/InfoPlist.strings” in the field next to the pop-up. When I first tried this, I entered simply “InfoPlist.strings”, but that didn’t work because the match is against the whole path of the file, and not just the filename, so the * is necessary to match any file named “InfoPlist.strings”.
- From the “using:” pop-up menu, select “Custom script:”, then enter the following script text:
cd "${BUILT_PRODUCTS_DIR}" && ${SRCROOT}/DevFiles/wincent-strings-util --info "${INFOPLIST_PATH}" --strings ${INPUT_FILE_PATH} --output /tmp/${INPUT_FILE_NAME} --encode UTF-16LE - Where it says “With output files”, click the “+” button and enter “/tmp/${INPUT_FILE_NAME}” for the output filename
You can click here for a screenshot showing the completed build rule setup. A couple things to note:
- My major source of problems in getting this working was trying to deal with spaces in the various path names (my product name is “PlistEdit Pro”), and splicing together multiple build setting environment variables was not working well. That’s the main reason the script does a “cd” into the build directory, then works from there. That’s also the reason that I spit the output file into /tmp rather than somewhere inside the Xcode build folder, since trying to get it working there was more headache than it was worth.
- As I said, I keep a copy of wincent-strings-util inside my source repository. In my case, in lives in a subfolder named “DevFiles”. You should of course change this path in the script to the location where you choose to store tho wincent-strings-util executable
- The “With output files” section tells Xcode where to look for the result of the custom script. Xcode will then copy that result file into the appropriate location inside your built application bundle. If you do change where the –output argument of wincent-strings-util goes, make sure to change the output file to match.
Finally, to actually do a substitution, simply put a key from your Info.plist into the InfoPlist.strings file, enclosed in chevron brackets («»). For example, I have the following entry in my InfoPlist.strings file:
“CFBundleGetInfoString” = “PlistEdit Pro version «CFBundleShortVersionString», Copyright 2004-2009 Fat Cat Software.”;
This will replace the «CFBundleShortVersionString» placeholder with the value stored under CFBundleShortVersionString in the main Info.plist file. I have my Info.plist preprocessing already set up to include the version number of the build for CFBundleShortVersionString, so this will propagate that to the InfoPlist.strings files, and my version number will display correctly in the Get Info window for all localizations.
Snow Leopard compatibility
Posted on August 25, 2009 by Brian Webster
Filed Under News, PlistEdit Pro, PowerTunes, Updates, iPhoto Library Manager | Comments Off
Since Apple announced yesterday that they are releasing Snow Leopard on the 28th, I thought I’d post a quick note about the compatibility status of our products. I’ve run all of them through a thorough testing suite over the last few weeks to try and find any potential compatibility problems.
iPhoto Library Manager
Updated 9/16/09: A handful of users reported crashes when attempting to copy photos on Snow Leopard using iPhoto Library Manager 3.5.3. The cause of this bug has been found and fixed in iPhoto Library Manager 3.5.4.
PowerTunes
There are no known issues with Snow Leopard for the current version (1.1) of PowerTunes.
PlistEdit Pro
Only one issue was found in version 1.4.1 when running on Snow Leopard, but it was a fairly large one: plist files would not open in PlistEdit Pro when double clicking them from the Finder (the “Open” item in the File menu still worked properly). I just posted version 1.4.2 of PlistEdit Pro today, which fixes this problem, so if you encounter this issue, just use the “Check For Updates” menu item to update to 1.4.2.
I do my best to find any issues before an OS X update is released, but if you have any problems upon upgrading to Snow Leopard, please e-mail support@fatcatsoftware.com with a description of your problem, and we’ll try to get things figured out ASAP.
See iPhoto Library Manager in action at ScreenCastsOnline
Posted on August 18, 2009 by Brian Webster
Filed Under Tips & Tricks, iPhoto Library Manager | 1 Comment
ScreenCastsOnline.com is a website that features video tutorials on using various software on your Mac and instructions for performing handy tasks. This week, iPhoto Library Manager is included as part of a continuing series of video tutorials on how to manage your data among multiple Macs. The screencast shows you how to set things up so you can use one of your iPhoto libraries from multiple machines, and how to use iPhoto Library Manager to copy stuff back and forth between two or more computers. It’s a pretty slick video, and I highly recommend checking it out, along with the rest of the site (they have a very large catalog of videos already produced). There’s even a coupon code included with the screencast that will let you get 15% off a purchase of iPhoto Library Manager!
iPhoto Library Manager user stats
Posted on July 30, 2009 by Brian Webster
Filed Under iPhoto Library Manager | Comments Off
Starting with version 3.2.5 of iPhoto Library Manager, I started using the extremely useful Sparkle framework to handle automatic downloading and installation of updates from within the application. When users opt-in to automatically checking for updates, they can also choose to submit anonymous profile data when checking. This sends basic information such as what type of machine they have, what version of iPLM they have, their version of OS X, their version of iPhoto, and so forth. This info gets collected in a database where, until now, it has pretty much just been collecting virtual dust. I finally decided it was time to do a little data analysis and see if there were any interesting trends I could discern from the data. I’m posting in hopes that both developers and users might find some of this info useful.
First, however a couple things to note about the data:
- Information is transmitted every time iPLM checks for an update. This check occurs when the user opens iPLM, but no more than once a day. This means that users that use the program more frequently will have a larger representation in the sampled data that users who only open iPLM on occasion. So, all the numbers you see here are based on number of checks, not necessarily the number of users. However, I feel that this approximation is good enough for sussing out general trends.
- Apparently, when I changed webhosts over from Dreamhost to Slicehost, I neglected to transfer the data that had been collected thus for over to the new server. D’oh! As a result, the data starts at the beginning of 2008, rather than several months beforehand.
- Due to a build configuration mixup with iPLM 3.5.2, profile information was not being sent correctly by that version. Since it was released in early June, that means the data for the last two months is pretty much worthless. So, the data presented will range from 01/2008 through 05/2009.
iPhoto adoption rates
The first thing I was curious about is how quickly users of iPLM update to a major new version of iPhoto when one is released by Apple. The data I have only covers one such release, iPhoto ‘09 (version 8.0), which was released in January 2009. Here is a graph of the usage rates of different versions of iPhoto by iPLM users:
As you can see, it only took about two months for iPhoto 8 users to surpass iPhoto 7 users. Granted, people who use iPLM are probably more advanced users and thus more likely to upgrade, but I still found this to be pretty impressive. And yes, there are still a few people out there using iPhoto 1 and 2.
OS X adoption rates
Unfortunately, since my data doesn’t start until Jan. 2008, it doesn’t cover the release of Leopard, which came out in Oct. 2007, so this isn’t the most exciting graph in the world, but you can at least get a sense of how many people are using Leopard these days:
iPLM updates
I don’t know how useful this really is, but I figured it might be interesting to see how quickly people updated to a new version of iPLM once it was released.
So it looks like it typically takes about two months for ~80% people to get updated to a new version after it gets released. However, keep in mind that this is data that’s only coming from people with auto-updating enabled, so there’s no telling how many users there are out there that have it switched off and are still running old versions. Overall the adoption rate seems pretty good though.
Registration rates
iPLM’s method of enticing people to buy a full license for the program is to limit access to a handful of “power-user” features such as copying albums and merging libraries. People can use iPLM for basic stuff for free without any time limit, but they need to buy a copy if they want to be able to copy their photos around easily.
It has also been speculated by many in the Mac developer community that the same users who are likely to upgrade their version of OS X are more likely to purchase third party software. Let’s see what the numbers are for iPLM:
It’s not huge, but there is a noticeable increase in the percentage of registered users as you move up the OS X food chain. My next thought was how registration rates compared to the version of iPhoto being used:
Now that’s more like it! It looks like users of newer versions of iPhoto are much more likely to have a registered copy of iPLM than those using older versions of iPhoto. This makes some sense intuitively, since the more involved you are in taking and organizing your photos, it seems you would be more likely to need iPLM and to update to the latest version of iPhoto, but it’s always nice to have data back up your assumptions.
keep looking »



