Tabris – iOS and Android apps written in Java

Industry experts have predicted that mobile computing is going to have a huge impact on the software industry. I agree. That’s why we asked ourselves if OSGi, RAP and Eclipse RT can help overcome some of the challenges in mobile app development.

Some of the most common problems involved in mobile development include dealing with multi-platform, security and maturity of the available platforms. But does multi-platform really matter with iOS breaking adoption records? I am sure that Google and Microsoft believe that their platforms will become breakthrough successes as well. While no one can make a definitive statement about their future success, I don’t think that anyone would bet a fortune on their failure either. This leaves us with three options for addressing multi-platform: HTML5, development for each platform or making a bet on which will be the most successful.

HTML5 is great technology – not only for mobile – but there is a growing body of lessons learned the hard way. Our own experience revealed that it is easy to get started with HTML5 and that the state-of-the-art JavaScript libraries look really great. But when it comes to running and using the apps the excitement mostly turned into disillusion. The other two options did not seem like good solutions for us, so we decided to add another option: Tabris (previously RAP Mobile).

Tabris gives us some key advantages over the alternatives. First, it allows multi-platform development in Java. It uses the iOS and Android native widget toolkits for rendering the user interface with optimal performance and native look and feel. And, it provides a mature and Open Source platform for writing and deploying business applications on standard JEE servers. It also provides a solution for common data security concerns with mobile devices.

If you are curious about how Tabris works and what it has to offer visit

15 Responses to “Tabris – iOS and Android apps written in Java”

  1. Mark says:

    Sounds very intriguing. How does it handle “transitions” and swiping? That is something that is expected of mobile platforms.

  2. Mark says:

    Obviously I did not watch the tree demo.

  3. Philipp says:

    I see that the native clients are only available on request as a developer preview. I didn’t find any information if they will be open source at a later time or if this will be a commercial offering. Could you shed some light on this?

  4. Jochen Krause says:

    Hi Philipp,

    The commercial model will not be entirely open source. The RAP server is and remains open source, the browser implementation of the client (which can also be used on mobile devices) is open source, but the native clients are not – at least at the moment. We are planning to open source parts of the native clients that are useful for native development, there will be announcements over the next couple of weeks. For adopters of RAP mobile we will have commerical offerings ranging from developer to enterprise.

  5. Dimos says:

    What about persistence and data cache on the client? In the demo it looks like the client always need a connection to the server.

    What about client usage if there is no connection to the server? (Caching, DataSync, logic programming)

  6. Zach Lendon says:

    “When it comes to running and using the apps the excitement mostly turned into disillusion”- what does that mean? Are you saying most mobile web apps aren’t well built, aren’t performant, what? And more importantly, why? Just because you are using Sencha Touch 2 or JQuery Mobile with HTML5 doesn’t eliminate the need for understanding those technologies to the degree necessary to be able to create a well-designed and well-built application. Mobile sites the quality of (for example) exhibit that non-native mobile apps can be *really* good – and are bound to only get better. And they are accessible via all phones browsers without the need to download an app. If the argument is that those quality of mobile apps are too challenging to build and RAP mobile makes it easier (and even produces results greater than existing solutions) – than that could be valid, but demonstrating it is better than making vague claims. Discussions of the trade-off of those purported claims would be much more valuable information to those of us who are at the ground level using these technologies to create compelling mobile websites for clients both today and into the future.

  7. Jochen Krause says:

    Hi Dimos,

    local event handling is on our roadmap. As we are targeting multiple platforms the least common denominator for writing the client side event handler is JavaScript. Accessing business logic will remain a call to the server, but user triggered events with a local scope can be executed on the client. Expect another blog post from us on this topic in the next few weeks.

    Access to device functions including local storage is currently under development. However, we do not think that complete offline usage is a good use case for RAP mobile.

  8. Jochen Krause says:

    Hi Zach,

    We have a strong relationship to HTML5 and JavaScript, we have been working with “Ajax” technlogies for a really long time – and continue to do so. RAP’s standard client technology is HTML5 and JavaScript. When we started to look into mobile clients we did several optimizations to our RAP client to perform better on devices. But we haven’t been able to achieve a level of usability that we saw with native apps. Thats when we turned to jQuery mobile to see if we could get satisfactory results with a different client technology. The initial results where really promising, but when the data volume grew bigger the apps started to become sluggish. So we started a proof of concept with a native iOS client rendering the user interface – and the out of the box performance was better by a multitude. Many developers in our team have been very sceptical about the necessity of clients not using HTML5, but after a few month they became convinced that it is the right choice for the type of applications (secure business apps) we develop with RAP.

    This does not mean at all that you cannot create very attractive and well performing applications with HTML5 technologies – you just need to know your way and put the necessary performance optimizations in place. I am sure that put a considerable amount of work into making their app snappy. And I would never have recommended RAP mobile to them, because they are building different types of applications than the ones that RAP is well suited for. Still, from my point of view there is one fundamental advantage to native widgets over (current) HTML5: Often you need multiple DOM elements to simulate one native widget. As computing resources are scarce on mobile devices (compared to desktops) this is a significant disadvantage because you have to layout, render and animate many more elements. This is not going to be mended soon. industry experts I have been talking to agree on this point.

    So our claim is not that RAP mobile is a superior technology to HTML5 or some particular framework, but that we have a very mature application framework building on OSGi, SWT and JFace which can make building business apps very productive.

  9. Aries McRae says:

    Can you blog about a side-by-side comparison with Phonegap?

  10. Zach Lendon says:

    Hi Jochen –

    Thank you for your reply. I do believe one key flaw we see in many mobile web-apps is this desire to “emulate” native apps – the desire to simulate a native widget whereas mobile web-apps should have their own look and feel – which can often provide the same functionality but not have the performance impact which you readily and correctly pointed out. If in the end you want to create a mobile webapp that looks, breathes and smells like a native app then well yes, a native app is going to obviously act better.

    One of the key decisions for businesses to make will be what technologies they wish to build their mobile solutions on. Does it make sense to leverage multiple native technologies (Obj-C, Java, Silverlight, etc)., use HTML5/Javascript (web-app or via Titanium/Phonegap type native solutions), or something like RAP. The earlier options are already on the table at most companies – if RAP proves itself I look forward to it having a seat at that table. Competition should only help to make the other solutions better as well.

  11. Mark says:

    Does “the browser implementation of the client (which can also be used on mobile devices)” function like a standard [desktop] RAP app in a mobile device? Or more like a “native” client?

    I mean does it look/work like this -
    Or like this –

  12. Jochen Krause says:


    It looks like (is) the first version:

    Our attempts to make it look like native apps revealed the performance issues described in comments above.

  13. Mark says:

    So if we want “mobile apps” that are not native apps but function like them, then we cannot use RAP. Correct? Just want to make sure. I am trying to figure out what path i should take. The mobile world is currently a mismash of choices. And people though the Java web-framework world was crazy.

    I really like the option of coding in Java and having it run on the mobile device (native or browser). But I have a shoe-string (well basically none) budget. So i guess I will see how much the license for RAP Mobile is.

    One other question. iOS is pretty restrictive. So how will the RAP Mobile apps work for Apple products – how will the client be delivered?

  14. Jochen Krause says:

    Our primary target for delivering the client is the Apple Enterprise account (owned by the provider of the app). The app store is another topic, however it seems many people fail to deliver apps that Apple accepts (no matter of the technology choice). We think that there is some more work involved in making RAP mobile apps ready for the app store (packaging the application core into the app, introducing local events), but with recent changes in Apple’s rules it is possible from our point of view. Similar to PhoneGap we are not trying circumvent Apple’s programming paradigm – we are creating a multi-platform solution.

  15. shyam says:

    Hai Jochen,

    Please can you answer my below questions ?

    Can you differentiate the performances of RAP with Native Android,IOS,JQueryMobile,Sencha.?
    Can we achieve all sort of native programming with RAP related to Android /IOS ?
    Is this similar to PhoneGap or how does it differentiate from the Phonegap?

15 responses so far

Written by . Published in Categories: EclipseSource News, Planet Eclipse

Looking for a job?

Karlsruhe / Remote
Karlsruhe / Victoria / Remote
Karlsruhe / Victoria / Remote