Titanium and iPhone OS 4

Fresk leaves invoking a happy mood.

Good news! After almost 2 weeks of trials and tribulations, we’ve finally figured out the magic combination to make Titanium work across iPhone OS 4 (every beta version to date) plus older iPhone OS 3 devices. While this should have been very easy, some major changes to the XCode toolchain, gcc, ABI compatibility and lots of other things made this very, very complicated. What would normally have been a simple recompile with backwards compatible APIs like normal, iPhone OS 4 is a big change. Not only in terms of cool new functionality like multi-tasking, but also at its core.

For your applications to be compatible across the various combination of operating system versions and the anticipated upcoming iPhone OS 4 release, you’ll need to follow a few of simple steps (below) and republish your application update to iTunes. I’m going to do my best to clearly explain what needs to be done and what doesn’t need to be done – but if this isn’t clear or I don’t do the best job, feel welcome to ask questions and we’ll do our best to help everyone out.

First, you do not need to upgrade to the latest release of Titanium (as long as you’re on 1.0+). While we recommend being on the latest release, we’ve taken great pains to ensure that you can run Titanium applications across different versions of the SDK. In fact, we’re going to recommend that you do not upgrade your application if it’s not on the latest already unless you have the time and energy to re-test your app thoroughly.

Second, the fix is going to be a simple drop-in onto the SDK(s) you used for your app(s). So, if you have 3 apps and each app uses a different version of our SDK, you’ll want to drop the fix into all 3 versions and re-test and re-publish all 3 of your apps. Get it?

Third, you’ll want to re-publish your application update(s) to iTunes (after testing, please!) as soon as you can. It takes time to get through the app approval process as you already know and we want to make sure you have plenty of time to get through the queue. Nobody knows when the iPhone 4 release will be made generally available, but in case that it’s at WWDC in June, the sooner you release, the better.

Fourth, you do not need to be on iPhone 4 SDK to apply this fix. This fix works across all known 3.1+ versions (including iPhone 4 beta 1-4) that are out. In fact, please don’t attempt to push your application using iPhone 4 as Apple has not yet approved the release of applications on the iPhone 4 SDK.

Forth, we suggest making this patch for both iPhone and iPad applications.

So — how to apply the patch? Good news is that it’s a simple download, uncompress and copy.

  1. Download the patched library. You can download directly from https://bit.ly/bGZSvq. Once downloaded, save this file off somewhere you can navigate to in console.
  2. Uncompress the downloaded file. Run the following command from console: gunzip libTiCore-7.a.gz. This should create a file named libTiCore.a. NOTE: If you’re using Safari, Safari will automatically uncompress this file after download for you. If that’s the case, you’ll see the file already in your Downloads directory uncompressed.

  3. The main SDK folder on OSX is either under /Library/Application Support/Titanium/mobilesdk/osx or ~/Library/Application Support/Titanium/mobilesdk/osx depending on your permissions when you installed Titanium. You’ll need to locate the version(s) of your SDK that your application uses from the Edit Project screen on Titanium Developer. Let’s assume you’re going to patch the 1.2.0 version of Titanium. You would copy the libTiCore.a file into the following directory: /Library/Application Support/Titanium/mobilesdk/osx/1.2.0/iphone. For 1.3.0, it would be /Library/Application Support/Titanium/mobilesdk/osx/1.3.0/iphone and so forth. You’ll probably want to make a backup of the existing libTiCore.a file in that directory. I’d suggest renaming it to something like libTiCore.a.orig.

At this point, you simply need to re-test your application both on Simulator and on Device. Assuming that works well, you can now build for distribution and submit to iTunes.

If you run into any problems or have questions, please comment on this thread for everyone’s benefit. We’ll monitor this post closely and try and provide timely help as necessary to everyone.

It’s worth noting, that this patch does not give you any iPhone 4 functionality. The upcoming 1.4.0 release of Titanium has the official 4.0 API support. It’s under development right now and we’re hoping to release it within the next 4 weeks (if not sooner).

Optional Techno Babble

For the intellectually inquisitive, what happened and how did we solve it?

First, it appears that iPhone OS 4 introduced some issues that as best we can tell are probably LLVM or GCC related problems. There’s a particular function that is used to create a set of pages in memory. This function effectively takes an address pointer, a block size for the page and several optional parameters for the memory access privileges, etc and returns a result code. This function prior to 4.0 worked great, as documented. The same function, when compiled on 4.0 worked great on a 4.0 device. However, when calling this function on a 3.2 built application on a 4.0 device, it returns an error code and an invalid address location. So, we had a catch-22. We could make it work on either 3.x or 4.0 both not both at the same time. After many various attempts to figure out why the same code produced 2 different results across 2 different SDKs, and coming up with all sorts of various ideas on how to work around it – we finally were able to trick the compiler into generating code that seemed to work on all scenarios. Everything looked great until we then tested under the Release build (during development, we generally test under the debugger in Debug build). Our fixes were being graciously optimized by GCC and removed, effectively removing our fix. Arg! OK, fine, we were able to force the compiler after some trickery into not optimize our fix.

Second, between iPhone OS 4 beta 2 and beta 3, Apple moved to a new ABI interface change which effectively changes the way symbols are handled by the GCC compiler. The original Objective C runtime, dating back to the NextStep era, had a flaw in it special issue, called the Fragile Base Class problem. Apple fixed this, but this new runtime is incompatible with the old runtime. So on the Mac, the 32-bit intel runtime is the old one for backwards compatibility, but the 64 bit intel and iPhone runtimes are the new one. With 4.0b3, Apple switched the simulator from the old runtime to the new one. So, symbols like NSObject and NSString (built-in Cocoa classes) no longer produced the same internal symbol names when building a library. If you built on the newer beta, the same symbol when produced by GCC produced a different symbol name. When then linking that library into an application built prior to 4.0, of course the linker couldn’t resolve the core Cocoa symbols. Luckily, this was a slightly easier fix. We were able to port a few of the Cocoa functions that were problematic to use the Core Foundation equivalents, which produced the correct symbols names both both 3.x and 4.0.

With the combination of all this fixes, we’re able to build a library which supports i386, x64, armv6 and armv7 and works on 3.x, 4.0 and the various versions of the current beta.

And aren’t you glad you’re not having to do all of this crazy work yourself?


  1. Very exciting news Jeff (and all at Appcelerator). And yes, basically thrilling not to have to figure this out on my own…

  2. Any way to be sure the new libTiCore.a was used?

    I carefully copied into the correct directories… but I’d still hate to resubmit an unchanged app.

    I see a ton of debug info when running on the simulator, maybe a lot more than before (I’m not 100% sure of this though), so maybe that’s enough of a clue?

  3. Unfortunately, no easy way outside of testing on 4.0 device or through simulator. Let me think if we can maybe grep a symbol in the final file, etc.

  4. Just a heads up, docs say:

    gunzip libTiCore-7.a.gz. This should create a file named libTiCore.a.

    But you end up with libTiCore-7.a, which needs to be renamed.

  5. Hello guys!
    Thank you very much for your efforts!
    I still didn’t have this clear, and sorry if I ask at the wrong time!
    Did Apple allowed the Titanium apps for the iPhone 4.0?
    Please I am so excited to here this as a “YES”!


  6. Great stuff. This allows me to try out your sdk for the iPad now. I was blocked up until now on this.

  7. Works great! Don’t forget to remove the “-7” from the file name.

    Also it might be a good idea to email everyone about this because not everyone checks here and when the time comes for the 4.0 official release, they’re going to be hit with their pre-4.0 apps not working!

  8. Install Error

    Build Failed (Missing app at /Users/michalg/Documents/xxx/build/iphone/build/Release-iphoneos/xxx.app/xxx). Please see output for more details

    i patched 1.3 but still got this error .. anyone?

  9. I have a few problems. I can’t no longer “Run on device”.
    The App works great in Simulator (both 3.2 and 4.0).

    But when i try to install the app, (both 3.2 and 4.0) i get an error:

    Install Error

    Build Failed (Missing app at /Users/Nick/iPhone : Docks/iPhone/Apps/R.E.P/R.E.P. iPhone/build/iphone/build/Release-iphoneos/R.E.P. iPhone.app/R.E.P. iPhone). Please see output for more details

    Any idea’s?

  10. It is not working on my setup.

    I installed the 4.0b4 SDK in a separate DeveloperBeta directory, and Titanium now finds it as the installed XCode, listing 3.2 and 4.0 only as SDK options.

    Question 1: is there a way to make Ti look at the other Xcode (in Developer) instead?

    Question 2: both Kitchen Sink and KS for iPad, in the 4.0b simulator, exit just after launch, with no apparent error:
    [INFO] Launched application in Simulator (1.37 seconds)
    [INFO] Application has exited from Simulator

    • there’s a command called xcode-select in /usr/bin that I believe will switch the current version of your SDK if you have more than one installed.

  11. Any word on 1.3.1? It was mentioned during the last webcast to address some of the 1.3.0 issues.

    Thanks Jeff, great work as always.

  12. Hi there,
    Great work. And indeed really innovative product you’re rolling out. I knew about it for long but tried it yesterday and I am pretty much convinced that its the way to go. Business logic on cloud while front-ends with Titanium desktop. I have a complaint and a question.

    Complaint is that the code snippets in documentation use dark red over black which is quit hard to read. Please do something about that.

    And question is that I am not able to understand the business model. What if I develop an application that is free and open source. How do I distribute it? From your App Store? Would you charge me for distribution?

    And what if the application itself happens to be closed source with commercial intentions?

    Hope you would address the questions raised.

    • Thank you Mohsin and we agree! 🙂 Good questions, let me see if i can address.

      1. Code snippets. We’ll look into how we can improve the readability. we have a lot of upcoming new documentation, video ,etc we’re rolling out soon.
      2. Business model. If you develop free and open source, you can distribute it on iPhone only through the iTunes marketplace (I know, we don’t necessarily like that either but that’s Apples way and we have to all play by that for that device). For Android, you have 2 options – go through their marketplace or distribute on your own or through another marketplace (getjar etc). For Blackberry, you’ll have to distribute through Blackberry World like iPhone. We don’t charge you for distribution. We will charge for additional support that you might need, training, some advanced functionality in the future, etc. All optional items where we think we can add value to your development. As far as the “closed source with commercial intentions” – probably most of our customers are in this spot and this is the norm. There’s no restrictions/limitations by Appcelerator on doing this at all. 🙂

      Hope that helps. Best of luck!

  13. For me it’s not working.
    With 4.0 beta 4 in simulator no problem, everything perfect. But in the iphone the application stops just after load the splash screen. I need to press home button to exit the application.

  14. Original libTiCore.a is about 207MB while the replacement is around 133MB, am i getting the right file?

  15. After updating none of my push notifications are working throughout urban airship. Even when using their p ush tester. It indicates that they went through okay without errors at ua but nothing on the devices

    Any ideas

  16. Disregard. Must have been a glitch with ua or the location I was in. All seems to be working now

Comments are closed.