Hi, I'm the CTO for RAVN. When we decided to jump into the mobile dev game no one in our company had any experience with Object C or Android dev. We knew we wanted an iPhone app for sure, and probably an Android app eventually. I had taken a brief look at Objective C previously, and coming from Ruby/Rails, it looked less than trivial (memory management?! I hadn't done that in 10 years). I had heard about frameworks that would allow us to use JavaScript to write our app, and also allow for cross-platform development, so I started researching.
I looked at PhoneGap and Titanium primarily. We ended up going with Titanium for a few reasons:
- As you may or may not know, PhoneGap works by creating a sort of Safari "wrapper" that lets you write your app in HTML5 and JS. But the performance is crappy relative to native rendering. Titanium also used to work the same way, but more recently it actually compiles code written in JavaScript to native Obj C and Java. Clearly the benefit is speed.
- Even though Titanium only supports iOS and Android, we didn't really plan on ever developing for other platforms (e.g. Windows Phone, BlackBerry, webOS).
If you're looking into developing a mobile app, I would recommend taking a look at Titanium. To be fair, I had to write a little Obj C to hack geofencing functionality into Titanium (if you're interested in that: http://stevenou.com/post/17623116547/how-to-hack-geofencing-...).
There were lots of pros and cons to using Titanium and I'd be happy to answer any questions.
It's been 4 or 5 months since I switched from Titanium to writing native Objective C myself, so things may have changed since then (but I don't think they have). It's a misnomer to say that Titanium "compiles" Javascript to Objective C.
Titanium lets you write Javascript that executes using JavascriptCore (a Javascript processor that is part of iOS) on iOS, and I believe V8 on Android, but I could be wrong on that. Then, they have bindings in Objective C (and Java). So when you call in Javascript Titanium.window.create();, the relevant Objective C is executed by the bridge.
This is all fine and dandy until you start doing something more complicated than displaying a few windows. For example, our app needed to have some complicated TableViews with highly customized rows that needed to be re-generated on each draw. Executing the logic for that in Javascript has a huge penalty hit.
So while I would recommend Titanium over PhoneGap any day, it is not true that it is a "compiled to Objective C" sort of thing (again, at least it wasn't 4 months ago, and I was using at that time 1.80 which was the super-bleeding-edge-dev build, because I had a ton of issues with random crashes in the 1.7x series due to the Titanium Database module not being completely thread-safe at the time).
Sorry to hijack.
EDIT: Just to confirm, 1.81 is the current "stable" release, so what I was using 4 or 5 months ago is what is the standard now. So it does not compile Javascript to Obj. C.
A lot has been fixed in the 1.8x series, but at the end of the day you're still depending on someone else's middleware to behave and not crash your app for no reason.
In case anyone decides to go down the learning Objective C route, learning with the excellent "Programming iOS 4" book took me about 1 month from the first page I read to having the whole app re-written, so it's really not too terrible. You don't have to do any of the memory management stuff anymore with iOS 5 and ARC, either.
A lot has changed in the 1.8 release, and I'm sorry to hear you ran into problems with earlier versions. Our abstraction layer can be a bit "magical" sometimes, and we need to do a better job communicating the tips and best practices that we've learned from our major apps, such as the NBC flagship iPad and mobile apps, and the Jimmy Fallon apps. We've actually been releasing a lot of content on manual memory management and app structures lately, which we hope will be helpful in this. That content is on our dev blog and wiki.appcelerator.org
In terms of the bugs I am hearing about, that really sucks on our part. If youre using Titanium and run into an issue that's really giving you trouble, my team monitors messages to community@appcelerator.com - we're out in the dev forums as much as we can but questions do go unanswered sometimes. Please let us know if your question does.
All that said, we've had over 30k apps (that we know of) shipped to the stores, the best of which stack up very well against their native-only counterparts. We have work left to do to make Titanium bulletproof but we think we're headed in the right direction.
Titanium was a nightmare. The edit-compile-debug cycle is so slow. I ran back to ObjC after two weeks. Development is faster and the resulting apps are better.
It has good points too but for me it was a net negative. You couldn't insert rows into a table view without it crashing, you had to reload the entire thing (that was in May).
I'm amazed at the results some people get with Titanium. Maybe I was doing something wrong, but I'm very familiar with web dev and found it intolerable.
One trick that really helped with the edit-compile-debug cycle, especially on iOS, was to run the app from the command line instead of using Titanium Studio. I set up a Rake task that would run the app and then listen for a timestamp change to tmp/restart.txt, at which point it would restart the app within seconds. I already had a vim command for touching that file (it's used by Passenger for a similar purpose) so all I do while developing is press a key combination and wait for the simulator to pop back up. Very fast.
The patterns and frameworks I use in single-page javascript apps carried over well to developing with Titanium, including tools such as Backbone and CommonJS. Titanium supports CommonJS directly now but it wasn't available when I started so I used Stitch to combine the code into a single javascript file and have been happy with the result. One bonus of using this approach is that I've been able to share a large portion of the code with the mobile web version of the app currently in development (using Backbone and jQuery Mobile).
While we ran into some problems that were difficult to track down, the code for Titanium is on GitHub and is easy to fork if you need to. For example, one thing that's prevented me from posting a link to this app previously is that the Android version (also built with Titanium) is experiencing frequent crashes on certain devices. After several (ok, 20+) hours of debugging I discovered that the problem was in the 'click' event handler on table rows -- the handler was passing the whole table row object in the event handler and was causing occasional crashes due to the size of that object. I didn't need that data to be passed in the events so I just commented out that portion of Titanium code and everything's great now (we're releasing an update shortly). Sure, it was a brutal bug to find, but the source was available and not too difficult to follow.
The app also includes custom modules written in Objective C for iOS and Java for Android, but only for very specific functionality that wasn't already included in Titanium -- 99% of what we needed was already available.
If there's any interest I'm thinking of extracting my pattern into a basic application that I can share with others and perhaps build a bit of a framework around it. Here's a gist as an example of code used in the app: https://gist.github.com/1832639
That's true. It doesn't exactly "compile to Objective C." But it's an easy way for people to understand the basic concept. The performance is much closer to full native than full HTML5.
Yeah, I figured. Just wanted to say something since a person or two was saying that they were surprised it compiled to Objective C. Congrats on getting your app out the door -- at the end of the day, every product has different needs, and shipping a quality app that fits your customer's needs is the most important thing.
A friend recommended your app to me a few days back, and here's my impressions.
At first glance, the UI looks great, but it doesn't feel right. The big one for me was how I must start a swipe from the picture of the event, not the edge of the screen or the bottom portion with the profile pictures. The UI looks and acts almost like a scroll view, but not really.
Going into an event's View Details view, there are items in a table I can tap to view more details, such as See Full Description. Native iOS behavior is tapping will drill down immediately, and things can load slower if needed. It seems like there's a bit of a delay between a tap (when the table item flashes) and when the drill down happens. This time varies seemingly randomly, and can be up to a few seconds. It makes me wonder if the tap actually registered, even if it does flash.
The idea for the app is great, but I stopped using the app at that point because it's frustrating to have to change habits formed from using pretty much all the other apps on iOS. It's something to consider when thinking about using some non-native framework, especially for something like iOS where apps generally follow a set of human interface guidelines, as any difference in behavior can stand out like a sore thumb to users.
Is this something that you guys noticed or thought about internally during development?
I have to say I had not noticed the first issue. But now that you mention it I guess it's true.
The second issue is something I have noticed occasionally. I guess I'm always testing on WiFi so it tends to load quickly enough that I never considered it problematic. Definitely worth taking a look to improve the usability there.
We tried to follow iOS design conventions as much as we could, but I guess we haven't quite nailed it yet!
Been using Titanium for a little over a year on an app for our company. By all definitions our app is very simple - a login form, tableviews that drill down two levels and webview.
Our customers like the app and it works great, does exactly what it's supposed to do. iPhone development seems to go pretty smoothly. Debugging is fast. On Android it's a nightmare. The emulator is so slow to launch for one thing. It reminds me of developing a site and then when you're all done, testing it on IE6 and, surprise, nothing works! That's been my experience anyway.
The app seems to be great, but unfortunately I'm hesitant to find out since it requires Facebook to do anything. I really don't want an app to be posting my activities on my Facebook wall - Maybe there's a choice in the app, but I can't really tell.
So, until you guys figure out a way to make the app functional without me having to connect it to my Facebook account, I'll just have to give it a pass.
Do you guys realize that webOS apps are written in web languages (HTML, CSS, Javascript) so it would not be very difficult to port your app to webOS.
More than that, if you write it in webOS' Enyo framework and use Phonegap you could have your app ready for iOS, Android, webOS, Blackberry, Chrome Web App Store, and the MacOS app store very fast and easily.
Whoa, didn't know Titanium compiles javascript into native code. Cool! But Phonegap has a pretty rich set of plugins and its relatively painless to extend Phonegap's functionality with a plugin. Did you have to hack in your geofencing capability? There's no plugin framework?
No, Titanium doesn't compile to native code. He's using that as shorthand for "Titanium uses JavaScriptCore to implement a bridge that lets your JavaScript call native code". Your JavaScript remains interpreted (and will not be JIT compiled, as in Safari, since your app won't have the JIT entitlement) but in my testing of JSCore it's not generally a bottleneck.
There is a module framework, but since the Titanium framework already created a CLLocationManagerDelegate in their GeolocationModule, I didn't see a clean way of adding geofencing in a separate module. So I hacked it right into the existing GeolocationModule. Again, the performance difference between native code and rendering HTML5 is huge, and that's why we decided against PhoneGap. Personally, if HTML5 wrappers were the only option, I probably would've just sucked it up and went native Obj C. Like someone else mentioned, there are a lot of challenges to making an HTML5 app perform like a native one.
Speed is not the only benefit of Titanium. I recently submitted a phonegap app it was rejected on the basis that "It would be appropriate to add iOS specific UI and functionality". I am pretty pissed-off. You made the right choice.
Tiny feedback: Your homepage renders incorrectly for me on Chrome 17/OSX. The screenshots which are lined up to cycle on the phone display bleed through vertically all the way down the page.
To add to this (Chrome / OSX), clicking on the 4 buttons on the left side multiple times breaks the scrolling. The more you click it, the longer it breaks. I noticed this exact same bug on that stop SOPA banner (featured on HN about a month ago) which also caused a page scroll when clicked. I wonder if the issues are related?
The app looks great, thanks for sharing. Did you guys come across any issues with Titanium's memory management? I'd imagine debugging could be a nightmare.
I haven't used SimpleGEO so I couldn't really say. Appcelerator Titanium just provides API functions to access native geo features like GPS. It also provides reverse and forward geocode functions but I found those buggy so I implemented my own using Google. I know Appcelerator recently acquired Cocoafish, which I imagine will provide much more comprehensive geo features for future Appcelerator devs.
Top drawbacks:
- Bugs/memory leaks. Since Titanium does memory management for you, you will occasionally run into memory leaks or bugs that don't make any sense, and there's not much you can do about it. Appcelerator isn't the fastest at releasing fixes either.
- Using third-party SDKs is generally annoying. Want to integrate Tapjoy? Chances are you'll need to write a custom Titanium module. Same goes for just about every single SDK out there. You have to manually create the JS->Obj C interface (aka module). There is a Titanium marketplace where you can buy existing modules for relatively cheap, but it's only a handful of very popular SDKs, like TestFlight, Flurry, or Urban Airship.
- Need to manually integrate new iOS features. Like geofencing, for example, I had to manually hack into the framework, so you're always a step behind in terms of the latest iOS features. That's OK for most people but when you do need a feature that hasn't made it into the framework, it can be annoying.
We didn't specifically look at appMobi, but as far as I know Titanium is the only (relatively mature) framework that compiles to native Obj C, and is not just a wrapper for HTML5. The performance difference is enormous.
To be honest I've only built games and in that sense appMobi has an edge with their DirectCanvas technlogy which speeds up the canvas rendering on mobile devices by 500% (according to them). I guess you don't use any canvas though so not really relevant in your case.
Thanks for the reply anyway. I will definitely have a closer look at Titanium.
If you're making cross-platform games, you may want to take a look at playn, we have been using it for over 5 months, and it has been really easy to use and works really good, though some platforms are still a work in progress http://code.google.com/p/playn
When we started building it, Titanium was very very buggy. It has since improved, but still has a lot of really basic stuff that is broken. Their forums have a lot of questions that have been unanswered for over an year.
Our reason for picking Titanium was basically to have an app that is just like a native app on both iPhone and Android without writing the code twice.
We have found out that porting a Titanium app to Android is taking a ton of effort, lot more than we originally thought. I would be curious to hear what the RAVN team has to say regarding their Android version.
Its just not as cross-platform as we thought :(. I would be extremely careful before picking it in the future.
Basically, if you build native apps:
Native App: iPhone=1X, Android=1X. If you want both Android and iPhone: 2X
Titanium App: iPhone=2X,Porting to Android: 0.7X. Total effort: 2.7X
Exactly the same sentiment. That's the reason we did not launch with an Android version today. We will probably write it natively when the time comes. Titanium has proven to be a nightmare with Android.
Boy, do I feel you there. I've been working with Titanium since last March and I've yet to develop some semblance of a cross-platform application. It's a bloody mess in there.
Presumably it's a "single-page web app", where the HTML page is essentially empty except for JavaScript.
This JavaScript then performs the rendering by dynamically constructing an HTML page with the DOM, as well as fetching data from the back end, and so on.
It's a fairly common application model these days.
They probably use PhoneGap or something similar to glue into the mobile OS environment. (Edit: They use Titanium.)
My company is developing a very similar events app, also written entirely in JS (PhoneGap, Backbone, etc.). There are so many challenges in making it a smooth user experience comparable to a native app, but we've finally gotten there.
I'm pretty impressed with what you can achieve by running JS in a WebView, that said, it still is not as responsive as a native app. This is one of the better attempts I've seen though at bridging the gap between HTML5 and native, perhaps it just needs another year? keep up the good work!
The app looks great, congrats on that. The thing that bothers me though is that it posts stuff on my FB timeline without my approval first. This does not sound like a good practice.
they both have plugin systems that allow you to write normal objc code to do anything that wasn't available in their apis... so if you ever needed to call opencv code from javascript, you can do that.
I looked at PhoneGap and Titanium primarily. We ended up going with Titanium for a few reasons:
- As you may or may not know, PhoneGap works by creating a sort of Safari "wrapper" that lets you write your app in HTML5 and JS. But the performance is crappy relative to native rendering. Titanium also used to work the same way, but more recently it actually compiles code written in JavaScript to native Obj C and Java. Clearly the benefit is speed.
- Even though Titanium only supports iOS and Android, we didn't really plan on ever developing for other platforms (e.g. Windows Phone, BlackBerry, webOS).
If you're looking into developing a mobile app, I would recommend taking a look at Titanium. To be fair, I had to write a little Obj C to hack geofencing functionality into Titanium (if you're interested in that: http://stevenou.com/post/17623116547/how-to-hack-geofencing-...).
There were lots of pros and cons to using Titanium and I'd be happy to answer any questions.