What is RemoteUI and how does it work?

The RemoteUI Framework is a Java Library that allows you to build mobile applications for iOS and Android that run on the server. A RemoteUI app runs in a Java Web Container environment either bundled (Apache Tomcat) or installed as WAR into a JEE7 compliant runtime.

RemoteUI Clients on iOS and Android connect to such an app via a WebSocket connection. They render its user interface that they retrieve as binary layout descriptions. As the native SDKs on each platform are used for rendering, the apps look & feel like native applications.

During development and integration, you typically use the generic RemoteUI Clients, that allow connecting to every URL and have RemoteUI branding (splash screen, logo). As license holder, you typically customize the clients with a fixed URL, custom logo and splash screen for distribution via play store, app store or other means.

Can I use other JVM languages than Java?

Yes. You can use all JVM languages available. Maybe you could try Pizza?

Which features of Java, Kotlin and Groovy are supported?


Can I use 3rd party libraries with RemoteUI?

Yes. You can use all 9.7 Million artifacts available via Maven Central and other repositories.

Do I need a Mac or a cloud service to build iOS applications?


As your app runs on the server, you never need to compile a mobile app package. You will compile a JAR or WAR and run it, which works on every platform. For the client, you use our Maven plugin to customize a RemoteUI Client package (IPA for iOS and APK for Android) with your logo, package and splash screen. This process can run locally on Linux, Windows and macOS.

Will an app, that was built with the RemoteUI Framework, have offline capabilities?

No, you need at least a 2G internet connection. You may present a static layout in offline-mode.

The software architecture of the RemoteUI Framework provides some kind of a thin-client environment where the logic of an app runs on the server. This has many advantages over traditional mobile app approaches: The apps are cross-platform enabled, have super-fast startup and development times, offer direct backend integration, great tooling (debugging, performance analysis, runtime reload and preview) and a full JVM environment with the latest language features (JDK 8, 9, 10 …). A RemoteUI app can easily be deployed and updated. Java, Kotlin and Groovy developers do not need to learn new tooling and can work on every desktop platform, they prefer. These great features come at the cost of reduced offline capabilities.

There are two possibilities to offer offline capabilities for certain distinct use cases:

  1. You can provide a single layout that will be displayed by the client when it is in offline mode. This layout can be updated at runtime, so you can use this functionality to provide an important set of information (e.g. shopping cart contents) when the user is offline.
  2. RemoteUI is available as client-side library. It is possible to build a hybrid app that only partially uses RemoteUI to realize its functionality. With this approach, you can realize an app that offers offline-capabilities for certain use cases (including logic). At the moment, this functionality is only part of our enterprise licensing program.

Will a RemoteUI app work with a slow network connection?


The RemoteUI Protocol has been designed to work with minimal bandwidth requirements. It uses a persistent connection, resource variant reduction, persistent layout caching, binary encoding, continuous compression and advanced image codecs to reduce the size of all transferred content to a minimum. Therefore, a RemoteUI app works in a 2G environment with bitrates from 150Kbit/s on. Our experience shows, that many other applications with backend access e.g. via JSON-based APIs already stop working, when RemoteUI apps are still running without problems. Our research has also shown, that the initial load of a RemoteUI app requires 5 to 150 times less traffic than loading a mobile web app.

How much resources do RemoteUI apps require on the server?

You can run about 5000 simultaneous RemoteUI sessions per Gigabyte RAM.

RemoteUI apps run their logic and keep their state on a server. The state of an app is held in a traditional HTTP session. Therefore, it is possible for the RemoteUI client to reconnect to an existing session for the case of connection-loss or the app going into background because of an incoming phone call or other disruptions.

Holding state on the server means, that the main requirement for most RemoteUI apps is RAM. However, the RAM requirements are relatively small for the RemoteUI technology itself. The RemoteUI Framework never holds GUI-related object trees in memory like other UI technologies do (e.g. JavaServer Faces). Instead, only the Activity objects of an application and their dependent objects (typically your data), are held in memory. Additionally, memory is used for a shared LRU cache of compiled UI bindings and adapted layouts.

In a test with a productive app that used JPA/Hibernate to access a MySQL database and consisted of about 10 screens, we observed a data requirement per started session (that included a Hibernate Session in this case) of ca. 200KB. This means, this app could serve about 5000 simultaneous and active user sessions per Gigabyte RAM. We expect significantly better numbers for apps that use session-less persistence APIs as alternative.

What happens, when the RemoteUI Client has a bad connection or loses the latter?

It will detect it, inform the user adequately and realize session-continuation when being reconnected.

We have invested a considerable amount of effort to make the RemoteUI Client’s network library a super-robust piece of software, that can handle all kinds of network conditions gracefully. The library automatically measures round-trip times on the fly and triggers appropriate callbacks for user feedback. It uses message correlation with a piggy-backing approach to keep data requirements for this measurement at a minimum.

During user interaction, a 1.5 second delay is pre-configured for the detection of short time-outs, meaning, the server does not respond on user interaction within this time span. When such a time-out is reached, the RemoteUI Client automatically shows a spinning progress bar on top of the user interface to inform the user, that her input has been accepted but needs time for processing.

If the server response takes longer than 10 seconds, the library triggers the long time-out and the RemoteUI Client supposes, that the connection has been lost. It switches to a reconnect dialog to let the user decide on whether to try a new connection or close the application.

Short and long time out mechanisms apply during user-interaction with the app. Additionally, keep-alive messaging is applied during times of no interaction. Every 25 seconds, the client sends a WebSocket keep alive message, expecting the server to respond within the short and long time-out periods respectively. If no adequate response is retrieved, progress spinner and reconnect dialog are applied as described above.

Of course, the library reacts on a gracefully closed TCP-connection, e.g. triggered by a server-shutdown or the user switching off Wifi or cellular networking on the mobile device. In all cases, the connect dialog is automatically displayed.

During reconnection, a session cookie is transferred as part of the WebSocket request. If the session on the server is still alive, which is typically the case for 20 minutes, the app is opened where it was last seen. The user can continue where she left.

Can I use JavaScript to implement my app?

Only for certain logic of your app. Typically not for the RemoteUI Activities.

Sure, you can run JavaScript as part of every Java application. The same is true for your RemoteUI app on the server. You can use Java’s built-in Nashorn engine or V8 Java bindings to realize this. It will however be a bit tricky to use npm, if you plan for this. You could have a look on GraalVM to find a way of mixing RemoteUI’s Java implementation with your npm-related workflow. Please let us know, if you made it ;-).

Why don’t you use HTML to realize your UI implementations?

Two reasons: Poor performance on mobile devices and reduced longevity.

We have conducted extensive research on the performance of different cross platform frameworks for app development. HTML-based solutions have several disadvantages:

  • The rendering performance is worse than that of native UI elements. Especially animations and transitions produce a lot of jank. This results in stuttering, juddering or freezing of the UI as HTML rendering oftentimes cannot be realized with 60fps.
  • Special UI elements are not available in HTML. Examples are maps with 3D support, zoomable charts and more.
  • There are limited possiblities to reduce the download size of layout descriptions with HTML. As an example, RemoteUI uses the WebP image codec to provide images with alpha channel on all platforms. If you use HTML with a WebView, you cannot use WebP on iOS.
  • If you compare the download size of HTML with CSS and JS with RemoteUI’s protocol, you end up with 5 – 150 times the traffic. In our tests, an app made with Ionic required 40 times the download size (~500kB vs. 12kB) of RemoteUI.
  • A hybrid app made with HTML requires significantly more RAM on the mobile device than RemoteUI with its native rendering engine.

An app that relies on HTML and the underlying WebView uses the system’s browser engine. On Android, this engine is updated every six weeks. If you want to ensure compatibility with every release version of the engine, you have immense effort. In the past, there were many problems that rendered existing HTML apps useless. You may google “Sencha Touch Chrome 65 or Chrome 43” to find some of them.

In comparison: The RemoteUI Client required the last update as of incompatiblity in March 2016. A minor change had to be made to make the RemoteUI Client on Android compatible with the newly introduced OpenJDK-based Android Runtime.

Which IDEs are best for developing a RemoteUI apps?

Eclipse (with Spring Tools) or IntelliJ IDEA Ultimate

RemoteUI Layouts use XML with an XML schema. With Eclipse and IntelliJ IDEA Ultimate, you have automatic code assist from the schema. Both IDEs have been optimized for Java development and allow out-of-the box debugging and refactoring. If you want to work with Kotlin, we made the best experiences with IDEA. Jetbrains has developed this language and obviously offers the best tool for it.

With Spring Tools and the Ultimate Edition of IDEA, you also have Spring Boot project wizards that function with the NeverNull starter, a web service that generates RemoteUI app projects. While this feature is optional, it is quite neat and fastens project setup.

I am editing in Live Preview mode. How can I add example data?

You can use the testObject element in your layout file. Every variable you declare with MVEL within this element can be used in binding expressions below. With this approach, you can realize rapid prototyping by skipping business logic implementation as a first step.

Is RemoteUI open source?

No, our business model is the sale of commercial licenses for RemoteUI. You can however use the free version to get started at no costs.

What are the restrictions of the free version?

The free version of RemoteUI is meant for trying out the technology without any qualitative restrictions. As you know, our main concern is simplicity and speed for developers, giving you the best tools to realize a fast time-to-market. Giving the free version to you without asking for time-consuming registration or payment processes and without any trial period restricting your evaluation phase is one of the approaches to make your life easier. At the end, we know, that the RemoteUI Framework will save you a lot of time and money, when you are going productive. For the latter case, we like you to get a paid license. Therefore, the following restrictions have been imposed on the free version:

  • The free variant of the RemoteUI Client does not support transport encryption (TLS).
  • The free version of the RemoteUI Framework restricts the number of concurrent simultaneous connections to 5.
  • Without a paid account, you cannot build your own installable app packages with logo, package name and branding.
  • You retrieve basic community support only.

With this approach, you have no restrictions when developing an app and demonstrating it to possible customers. If you are going in production and want to publish your app in the play store or app store, a paid license is required.

How many licenses do I need?

You need one license per developer.

Will my app still work after my license has expired?


Your app will work as long as OS updates don’t enforce updates for client or server components. Typically, Apple and Google provide major upgrades for their mobile OSs once a year. You should be prepared to test your app with them and possibly update to the latest RemoteUI version, if anything does not work. For the update, a license is required.

What’s the answer to life, the universe and everything?


Are there still some open questions? Feel free to