Show HN: Our first iPhone app, built entirely in JavaScript

http://ravn.com/getapp

by yosho • 14 years ago

74 51 14 years ago

ravn.com

gpmcadam• 14 years ago

Care to expand on the "built entirely in JavaScript" part? Sounds interesting.

GigabyteCoin• 14 years ago

This is the only reason I clicked here. I too would love to hear more on that aspect.

lobster_johnson• 14 years ago

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.

d2ncal3• 14 years ago

They are using Appcelerator Titanium, which is a cross platform app SDK.

You write your code in Javascript, and Titanium actually generates native code that is then compiled into an app.

flixic• 14 years ago

What framework did you use?

stevenou8• 14 years ago

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.

Kiro2• 14 years ago

Did you ever consider appMobi?

stevenou8• 14 years ago

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.

fufulabs• 14 years ago

What plan did you get for Titanium?

How was Appcelerator's geo features, is it comparable to SimpleGEO?

Top 3 drawback vs going native pls.

Thanks for taking the time!

stevenou8• 14 years ago

We're on the Community (free) plan.

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.

jameshsi• 14 years ago

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.

doubleconfess• 14 years ago

Maybe a blog post on the pros and cons of using Titanium is in order.

blantonl• 14 years ago

I think we're seeing it play out right here?

mcrider• 14 years ago

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?

stevenou8• 14 years ago

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.

robterrell• 14 years ago

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.

silverlight2• 14 years ago

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.

Also, for an example of the random crashes we were seeing, see: http://www.juliusbuss.de/web/youatnotes/blog-jb.nsf/dx/quick...

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.

stevenou8• 14 years ago

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.

trabianmatt3• 14 years ago

I just released a native mobile banking app built using Titanium: http://itunes.apple.com/us/app/sf-fire-credit-union-mobile/i... and am happy to share my experiences with it.

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

Edit: accidentally used a private gist.

sjs• 14 years ago

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.

kwhinnery• 14 years ago

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.

apaprocki• 14 years ago

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.

stakecounter• 14 years ago

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?

vena• 14 years ago

the same issue is present in the current Firefox Aurora build.

LokiSnake• 14 years ago

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?

stevenou8• 14 years ago

Hey LokiSnake that's some good feedback, thanks!

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!

jakejake2• 14 years ago

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.

trabianmatt3• 14 years ago

With Android it's like testing 10 versions of IE6 -- every device/OS combo seems to behave differently.

Android development with Titanium was much easier when I started using a real device, but it's still much slower than iOS development.

JohnIdol• 14 years ago

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.

johnx123-up• 14 years ago

Can you please compare Titanium against PhoneGap? Are you sure that Titanium really compiles to native?

alphakappa• 14 years ago

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.

stevenou8• 14 years ago

Facebook is not required to use the app.

skat_et_dieu2• 14 years ago

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.

draggnar• 14 years ago

The landing page is fantastic. Super simple initially, more info if I want it. I wish the features section was more visual.

joezhou• 14 years ago

Though with titanium and phonegap you still cannot tap into the full capacity of the phone.

catch23• 14 years ago

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.

bwm• 14 years ago

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!

d2ncal3• 14 years ago

It's not a HTML app, but built using titanium which is a cross platform app sdk where u write the code in JavaScript.

One day we will be able to do this using just HTML... But that day is not here yet :(.

paisible• 14 years ago

Is there any way we can add our own events ?

hack_edu• 14 years ago

And, either way, what is the source of the events? Are you really doing them all by hand?

tejaswiy• 14 years ago

I'd like to know this too, considering you have stuff coming up in Orlando which none of the SV startups care about usually.

d2ncal3• 14 years ago

I am the founder of http://theicebreak.com

We have built our app ( Icebreak for Couples - http://itunes.apple.com/app/id476063944 ) using Titanium.

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

Native Wins.

stevenou8• 14 years ago

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.

grobolom• 14 years ago

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.

skat_et_dieu2• 14 years ago

Have you looked into the new Enyo framework to deploy apps?

romefort• 14 years ago

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.

Show HN: Our first iPhone app, built entirely in JavaScript

Related Stories