To compile Lua for use on iPhone and iPad, I’ve grabbed the original source code for 5.1.4, and I have grabbed build_for_iphoneos.sh shell script by Christopher Stawarz. Both were slightly modified since Lua does not use autoconf, and build_for_iphoneos.sh is slightly dated. Read more to see what did I do.
Continue reading
Apple’s example code for Game Center does something strange — in fact, we can simply go out and call those things bugs. Keep reading to see what I’m talking about.
Continue reading
You’re a budding developer. You’re writing a program. FSF has its lengthy explanations about many licenses, as does OSI. Yet, you want a short and concise answer.
Here’s an overview of some of the licenses I consider for my projects, their major differences, and why I pick each of them. I’ll also describe how to apply them.
Note: I Am Not A Lawyer, and applying these is at your own risk. Don’t apply them blindly, and talk to your employer; you might not be able to decide licensing for your own work. Also, don’t use these notes as info on what you may or may not do with code you know to be GPL’d, LGPL’d or BSD-licensed. Read the licenses themselves; these are notes indended only to help in quick decision, not to explain the licenses in great detail.
This is also largely done from memory, without doing proper research right now; it should be pretty correct, though.
Corrections and questions? Put them in the comments section, please 🙂
Continue reading
I figured out I had to have an automated check prior to Mac App Store submission because I managed to miss some stuff a few times.
So here’s a beginning of a simple unofficial test suite for Mac App Store submissions: CheckRelease on BitBucket
It currently checks only if you have some external dependencies. I’ll try to write a validation for checking if you have added all the frameworks you depend on into the app, and I hope to extend it with some additional tests.
It’s under BSD license, and contributions are very welcome!
Also, hopefully, Apple will extend their own validator built into Application Loader and Xcode. Currently we have to wait a few days for rejections from the App Store team that are as trivial as “forgot to put in a framework” and “forgot to get rid of an external dependency” (or, at least, a reference to an external dependency that you actually don’t depend on, and that you never actually use).
To get Dropbox with Nautilus extension to run under Debian:
1. Download .tar.bz2 from Dropbox’s site.
2. sudo apt-get install libnautilus-extension-dev python-docutils
3. tar xvvfj nautilus-dropbox-0.6.7.tar.bz2
4. cd nautilus-dropbox-0.6.7
5. ./configure
6. make
7. sudo make install
Apple’s very strict: you can reference frameworks in /System/Library/Frameworks and in your own app. That’s all fine, but there’s another unexpected obstacle. App can be self-contained (the library executable paths patched using install_name_tool) but the install path still references /Library/Frameworks. See “otool -L”; the first reference is a self-reference, and it looks like you can’t easily update it after the library is built. (Or I didn’t look hard enough). And yup, leaving that an absolute path referencing into /Library/Frameworks, that’s enough for rejection.
Untested theory is that updating “Dynamic Library Install Name” (LC_ID_DYLIB) is enough to fix this. I’ve set it to:
@executable_path/../Frameworks/$(EXECUTABLE_PATH)
in place of
$(DYLIB_INSTALL_NAME_BASE:standardizepath)/$(EXECUTABLE_PATH)