Crippled iPhone LGPL

I mentioned on the “latest Core Intuition”… that I no longer have any plans to release my own iPhone software. While that decision is mostly based on my unwillingness to give Apple so much control over my business, and frustrations with the App Store process in particular, there are a handful of technical reasons why iPhone development is not a good fit for me. Here’s one: open source.

“Daniel Jalkut’s essay on the GPL”… hits all the points about how the GPL can hurt developers by discouraging commercial participation. I’ve used LGPL projects in both “Clipstart”… and “Wii Transfer”… and I am careful to use them correctly. But iPhone development presents an interesting problem.

Can’t run command line tools. Separating the GPL code into a command line tool that is inside your application bundle is a common way to get around licensing issues. This is not allowed in the iPhone SDK.

Can’t replace dynamic libraries. The LGPL says that you can also link to libraries at runtime, but the catch is that the user must be able to replace an LGPL library with a newer version of their choosing. There is no way for normal users to do this on the iPhone.

Can’t use private frameworks. Oh, that point above about dynamic libraries? Actually it’s a moot point because Apple requires everything to be statically linked anyway. So you are blocked at every pass; you can’t ship an app that loads code dynamically even if the user could touch it.

The only solution I’ve seen so far is to release a special version of your Xcode project, with most of your application split into compiled libraries instead of source code, and allow developers with the iPhone SDK to relink your application with a different copy of whatever LGPL code you used. I stopped researching this when I put my own iPhone projects on hold, though. It’s just another example of how the closed nature of the platform creates an unnecessary burden in the software development process.

Manton Reece @manton