Matchbook Example "Game", 2x iOS and 2x Android clients

Matchbook is a lightweight and platform-agnostic matchmaking solution, intended for use in mobile applications (think games that require near-real-time, relatively-low-latency, persistent communications between two or more client devices).

At its core is a server component, which provides a JSON-based webservice allowing clients to find, create, and join matches. The server also acts as a proxy/relay when necessary, allowing client devices to tunnel through any firewalls that might exist between them.

In addition to the server component, Matchbook includes prebuilt SDK’s for both Java and Objective-C. These SDK’s are intended to support the development of native applications that make use of the Matchbook webservice on Android and iOS devices, respectively.

I could go on at length, but it’s simpler to just link to the project on Github (Matchbook is open-source, and permissively licensed, naturally):

https://github.com/adam-roth/matchbook

Note that Google is currently building comparable functionality into Google Play, although their realtime communications API is currently only available on Android (iOS support is under development).

And although Apple already has realtime and turn-based gaming API’s for iOS, they natually have no intention of inviting Android devices to the party. Ever.

So let the record show that Matchbook got there first.

https://github.com/kstenerud/iOS-Universal-Framework

This project provides a single installation shell script that will add a new Project Template to XCode, one that can be used to build universal iOS frameworks. Now this wouldn’t be a big deal (and in all rights, shouldn’t be a big deal), if not for the fact that for some unspecified and frustrating reason, XCode has no built-in ability to create such frameworks. This means that up until recently if you had an iOS library that you wanted to use across many projects, or that you wanted to distribute for other developers to use in their projects, you had only a few not-very-good options:

• Include your source code in every project that uses your library (increased compilation time, hooray!).
• Build two library versions, one for armv6/armv7 and one for x86.
• Screw with the linker to manually create a “fat” library.
• Use the Bundle Hack and hope that it works.

It’s worth noting here that the first three options listed above do nothing to help with the management of any shared header files needed to actually make use of the library code. The fourth option does allow you to include public headers in your build artifact, but the setup to do so is tedious, and the entire thing is basically a giant hack besides. None of these options are really very convenient or useful from the developer’s point of view.

What developers really need, what they should have access to, and what XCode should have supported at least since the release of iOS 4.0, is the ability to build true universal iOS frameworks that are “real” frameworks in the same sense that UIKit and CoreGraphics are real frameworks. And that’s exactly what the iOS-Universal-Framework project gives you. Just install it and you get a handy XCode Project Template that can be used to build a universal iOS framework. This lets you build real iOS frameworks that include libraries for both x86 and armv6/armv7 in a single package, automatically bundled with your public header files. You (or anyone else) can then use the generated framework inside of other projects in the same way as any other iOS framework; just add it to your “Link With Binary Libraries” build phase, and away you go.

All told, the iOS-Universal-Framework Project Template is great and works exactly as advertised. Just install it and you’re good to go. I’ve only come across one minor caveat worth mentioning, which is that although the template does correctly produce a universal iOS framework, the build product shown in XCode will actually point to an architecture-specific version of the framework. In order to find the correct, universal framework it is necessary to do a “Show in Finder” on the build product shown in XCode (or otherwise navigate to your project output directory), and then go up a level (or two) in the filesystem to find the folder that contains the universal version of the framework (edit: as per Karl’s comment below, this has now been fixed. Hooray!).

Apart from that minor annoyance this little XCode extension is really quite excellent, and I encourage you to give it a try. My personal thanks to Karl Stenerud for putting this together.