Calling C Functions from Unity on Mac OS X/iOS

The Situation

At work I found myself needing to call previously written Objective-C code from Unity for an iOS app.  My options were to rewrite the code in C# or find a way to call the code from Unity.  I opted for not rewriting the code.

When looking around you’ll find ways to call C code from Unity on iOS apps using [DllImport(“__Internal”)]  This requires that when you build the app to device; the symbol you are referring is inside the executable somewhere.  Since on iOS dynamic libraries are verboten, this is your only option for iOS apps.  So just generate your xcodeproj, then edit it to link in your library that contains the C symbols you want to call from Unity.  This works but it will require that you build to device anytime you want to test your code that calls your C functions.  Unacceptable!  Especially since building to the iOS Simulator doesn’t work in my experience.

The other option is to make your library compile to a static library for iOS and a dynamic library for Mac OS X.  That way inside of the Unity editor we can load in the Mac OS X dynamic library to call the code without building to device, awesome!  There are a few gotchas though:

  • make sure your library is fat i386 and x86_64 (in my experience it only has to be i386 but I imagine this will change eventually)
  • you’ll need to have Unity Pro if you want to plop your library into the “Plugins” folder to have them magically distributed (if you are building for iOS this doesn’t matter anyways since you wont be distributing your dynamic library)
  • you’ll have to rename your library from “libfoo.dylib” to “foo.bundle”, the key part being the .bundle, it’s an error in the Mono runtime that they say will get fixed some day
  • if you aren’t using the Plugins directory you’ll have to put your library someplace where Mono can find it, like “~/lib”

The Code

The calling MonoBehaviour (NewBehaviourScript.cs):

The C code (foo.c):

The dylib Makefile:

shell command to put dylib in findable location:




Different Strokes: Process vs Product

Different people get into software for different reasons, and they get into it differently, like almost anything else.  For some people software engineering is a means to a end, for others it is the enjoyment.  In reality most people fall somewhere on that spectrum of enjoyment, process vs product.

I believe I can get along with anyone.  I’m not as good as my wife, she’s a meek sweetheart who everyone likes.  But some of the most challenging relationships in your software career will happen from dealing with people whose raison d’etre is different than yours.  One example is pacing: someone who loaves process but loves product might have a more sporadic schedule where they will avoid the work, psych themselves up, then finally take their medicine and cram.  A classic example of this is probably how most of us did our homework, because homework sucks.  Someone who enjoys software development won’t have an issue working at a more constant rate, until then end of development when the work becomes less interesting of course.

This is where a solid development system and scheduling comes into play, and scrum does a good job at this.  The product people need regular checkups to reduce the amplitude and period of their cram sessions.  The process people need regularly scheduled time to provide feedback on the target.  Small companies can run without a solid system and be productive, but it isn’t sustainable.  Like driving a car around in first gear, the wear on the engine will eventually catch up with you.

Coming Back to Unity After Pause

Screen Shot 2014-10-10 at 4.46.16 PMI’ve had a few side projects going on for a while.  One was a clone of Bump n’ Jump in Unity to get a feel for Unity development.  I set it aside to work on other things, but because of developments at work I’m going to have to start playing with Unity again so I picked it back up to get back into the groove.  Today I’ve written a Breakout clone and I’ll record a few observations about Unity.  You can find the Breakout code as of this article: Breakout or checkout HEAD in case I’ve decided to do more cool things with it: Breakout HEAD

  • It’s hard for me to be so removed from performance.  For instance there is no way to inline a method.  I guess .NET and mono have it now but it hasn’t made it’s way to Unity 4.6 yet.
  • It’s difficult to layout the code conceptually.  In the Breakout clone I put most of the logic for the game into the BallController.  He is the guy that knows the most and is the controlling factor for the game but it feels weird for him to be the arbitrator of the score and game state.  I think an empty GameObject for the game who listens to the balls events would feel cleaner to me.
  • The 4.6 UI tools are very nice.  It’s easy to get UI pixel perfect on screen.
  • On that note, I had a hard time getting the coordinate space to pretend to be 640×480.  Maybe I was fighting the system a bit but 640×480 seems convenient for me to think about when making a 4:3 game.
  • MonoDevelop is horrible.  I had to turn that off, it can’t even kill and yank correctly.  I’m now using a combo of Emacs/omnisharp-mode.  Maybe I’ll make a blog post about this setup later.
  • There is some magic that has to be done to get Unity to behave well with Git, this guy on StackOverflow laid it out nicely: How to use Git for Unity?
  • Breakout has such a well define physics, it was interesting to consider if I should use Unity’s 2D physics or to roll my own.  I eventually opted for rolling my own instead of trying to hack the physics engine.  It would have been nice to be able to use the Colliders by hand without the physics but I didn’t see a nice way to do that, so I had to throw them out as well.
  • Levels in Scenes or XML?  I just have one level right now but it was somewhat tedious to lay it out by hand in the editor (especially because of the coordinate system).  But it was convenient to be able to see the results and if I had 30 different levels to able to click through them and see them would be helpful.  It seems like I haven’t found a good answer in Unity about when to use Scenes and when to use XML.

Now I’m feeling a pang to post this for the Unity Web Plugin so we can all play with it.  Hopefully I’ll get around to that to spare you the trouble of loading up Unity.

Mike Acton’s Data Oriented Design

Mike Acton, the Engine Director at Insomniac Games, had a talk from CPPCon get posted on Gamasutra yesterday.  Here are some thoughts, if you missed the video you can check it out here:

Mike Acton’s Data Oriented Design

Mike has a very interesting job.  Many developers have the luxury of accepting inferior performance for ease and speed of development.  His job is at the extreme other end of needing to geek out as much performance as possible from a machine.  So looking from his point of view provides a very different take on what we do.  Some might think his talk is extremist, but remember his job is an extreme.

The thesis of his talk is that it isn’t wrong to write code that is designed for computers instead of humans.  He warns us of overcomplicating problems by translating reality to computers while trying to maintain human understanding of reality with real-world models.  To help us look outside of our ingrained real-world model thinking he gives us an alternative model of looking at software, its just transformations on data.  Data is the focus, not code.

This doctrine isn’t necessary for each software engineer to follow, but it definitely is a helpful lens to evaluate our software.  Looking at our software as data transformations is an aide we use all the time when we write unit-tests.  Over prescribing real-world models could be a problem in certain domains too, it’s hard to know when a tool is helpful if we don’t consider the merits of the alternative.