After almost 10 years of research and 1.5 years of development, our team is proud to announce our first public release of MobileUI (0.4.1), a new software framework for cross-platform app development. πΎπΎπΎ
At NeverNull, we have more than 20 years experience as app developers, software engineers, consultants, software lecturers and trainers. During this time, we have learned a lot about the good and the bad parts of cross-platform app development with a huge variety of frameworks and programming languages.
We think, the time has come to take these findings and build a product that combines the good parts leaving out the bad ones. Our vision for MobileUI is to become the number one solution for cross-platform app development with Java and/or Kotlin. One codebase, a unique developer experience, a great toolchain and the full native app experience.
We are very excited about the outcome - and hope you are too! The following article gives you some details about the product. Get your own copy here: www.mobileui.dev
What is MobileUI?
Java-Based Cross-Platform Apps with Native Experience
MobileUI is a Java-based cross-platform framework that offers a native UI component library and unique layout system for iOS and Android.
MobileUI allows you to write fully native apps in Java and Kotlin, without touching languages like Objective-C or Swift. Why Java? Java is a great way to combine easy development and a huge ecosystem of libraries and tools with fulfilling maybe the number one requirements on mobile: Performance. With MobileUI's system, all Java code is ahead-of-time compiled which brings huge benefits in regard to execution time and memory consumption.
While you can rely on Java's cross-platform APIs, you can also access all native SDKs for Android and iOS from the same codebase. This is thanks to the availability of the Android Runtime SDK and the RoboVM Native Bridge (Bro). It is great for all cases, where our cross-platform framework does not (yet) contain an abstraction or plugin for a platform-specific function. You don't have to switch IDEs, tools or programming language to add a new feature. In our experience, the latter happens a lot with cross-platform frameworks like React Native, Flutter or Ionic, that only give you SDK access through native plugins.
Layouting and Styling with Ease
MobileUI uses Android's Layout System to arrange platform-native widgets on the screen. We have ported Android Views to iOS from Android's original source code (Following a hint by Chuck Norris, who already ran Android apps on iOS in 2005. Thanks Chuck! πͺ). And with a big smile, we recognized that this approach is amazingly πfast π! Because Android layouts have been optimized to support devices with many different form factors, building iOS apps with it works like a charm.
Have you ever understood Android's style system in depth? No? We neither π¬! That's why
MobileUI XML layout files are styled with CSS. Just as in HTML, you can include .css files or write style directly to the layout. Checkout this code snippet. It should be very familiar to everyone who has ever built an HTML page:
<Layout xmlns="urn:nevernull:mobileui:layout">
<style href="style.css"/>
<style>
.CustomButton {
textColor: white;
backgroundColor: #6111B1;
}
</style>
<LinearLayout width="fill_parent"
height="fill_parent"
orientation="vertical">
<Button class="CustomButton"
onClick="#{onOpenUrlClicked()}"
text="Yeah, take me to the candy shop"
/>
</LinearLayout>
</Layout>
There is also the possibility of using dynamic CSS and variables through MobileUI's super-fast template engine. You can implement rich design systems and custom themes - from dark to light to super-awesome!
And did we mention MobileUI's Data Binding? Glue Java code and layout together with expressions #{justLikeThis}. Or simply start with your layout and later add the bindings. With this separation of concerns when building your apps, you can present high-fidelity prototypes early in the development process. This is super-valuable when talking to customers and product owners π.
Extensibility is key
Since you have access to all native SDKs, you are not constrained to the components we offer. Build, share and reuse your own abstractions and improve your developer experience.
We know that it is a good idea to use component systems as soon as your apps become more complex. That is, why we ship MobileUI's Purple Edition with a dependency injection framework that is a perfect fit for mobile. It is based on Micronaut and makes extending your app with platform-specific components super-easy. MobileUI Inject is used as the basis for our Plugin System which allows you to integrate plugins into your app with a few lines of code. Read more on this in coming blog posts.
Instant Live Preview
Let's face it: Slow build cycles thwart you when developing your apps β. One of the most stressful things is restarting the whole app only to see a few pixels more padding in your layout or the UI being rendered on a second device.
While we cannot completely eliminate build cycles β especially for Java compilation on iOS β we do our best to make them unnecessary or much faster.
That is why we provide you with the Live Preview feature that comes with the MobileUI Plugin for Android Studio. The Live Preview pushes layout changes to your app in real-time. With this approach, you can modify the layout while the app is running (and keeping state). This allows fast iteration cycles, increases productivity and safes a lot of time. Don't believe it works? Watch and try!
Extensive Documentation & Support
Diving into app development with a new framework is difficult without an excellent documentation. One of our main goals is to bring you high quality tutorials, how-tos and references for all MobileUI features on docs.mobileui.dev. And if you are stuck, we assist you on our Spectrum Channel.
It is great that MobileUI apps are actually native apps with full SDK access. You find a huge amount of examples for solutions on Android and iOS on the Internet. You can easily apply them in your MobileUI apps without reinventing wheels. We help you, if something should not work out as expected.
Try it out with our MobileUI Gallery
That's it for now. Are you curious, if this works? Try MobileUI today and find out! Get MobileUI Free at
... and let us know what you think! We appreciate your feedback!
Top comments (7)
Iβm really impressed about MobileUI, interesting one. But I have the same question but directly to Flutter.
So, why should I choose MobileUI over Flutter, and specifically when your framework work is closed and Flutter is Open Source?
Understanding Dart programming language is not difficult for a Java Developer.
Just to know.
Thanks.
Hi Aneudys,
thanks for the question. Let's start with Dart: I think, Dart's syntax is similar to Java like it's similar to C#, Typescript or JavaScript and many other C-like languages. No problem for a Java-dev! But when you are considering similarity, you must also compare the ecosystem. For me as a Java developer, it is super-important, that the given runtime has most of the standard APIs that are defined by the JDK. Why? I know how to fetch a file from a server, I know how to manipulate Strings, I know how to start a Thread pool. I have to learn all these approaches from scratch, if I am switching languages and SDKs. And that is happening when switching from Java to Dart.
But the problem even applies to technologies, that support Java or Kotlin as programming languages and don't have the Java SDK. Examples are GWT or Kotlin Native. As a result, you cannot reuse existing libraries. And you are cut from the 17 Mio. libraries that are available in Maven repos today - most of them open source!
Another thing about Dart: As of today, it's not feasible to use Dart on the server. One advantage of Java and Kotlin is, that with our approach, they become full-stack technologies. You can reuse libraries between backend and frontend. We have productive projects, where we reuse data models (ORM), components and DI-containers (Micronaut) on mobile and the corresponding backend 1:1. It's amazing as it saves a lot of development and maintenance effort.
How about open source? So, we currently are not open source with our product. That's true. But huge parts of the system we are running on are. The Android native SDK is open source. RoboVM is open source and we are contributing to the project.
I think, the question is: Why are we not cost-free? And the answer is: We give support to our customers. And we need some kind of revenue so that we can further improve and extend our software. It's a pitty, but we don't have a well running search engine or cloud business model in the back that pays the bills π€·.
But when considering your cost of the product, please also consider your time β±. Flutter and other technologies are only free, if your learning and practice time does not cost anything. With MobileUI, as a Java or Android developer you save so much of it. And if that counts, we are confident that you will love MobileUI π!
P.S.: I forgot to mention: I personally don't like Flutter's cross-platform approach with switching between Material and Cupertino widgets. It's quite complicated as can be seen in this video about building iOS apps with Flutter (Comments below show, that I am not the only one with this opinion). Rock on!
Really interesting and amazing product, congratulations!
I have to ask, in lamest terms, could you explain why would someone choose your product over Ionic/Angular Native and similar? What are some of the advantages?
There surely will be some more articles coming up, explaining certain aspects of the framework and how they compare to other frameworks.
That being said, I'd say some of the biggest advantages are:
Obviously it's a difficult market to compete, but we are confident in the developer experience of our product. We enjoy building apps with it a lot.
Hope you give it a try and have us some feedback. Always happy to improve things.
Hey Kristijan,
that's a great question. Surely, there are a ton of pros and cons when we are talking about cross-platform today. With MobileUI, our main goals are:
Enable developers to build apps with great quality. This typically means: The framework must support native UI as this typically resembles the great look and feel your users love from all the competing apps on their phones. Users get the full FPS from the UI (e.g. for animations), super-fast response times and they can use the gestures they love (e.g. for navigation).
Save time and effort by going cross-platform. While the above is all great, one could achieve this with dual-development for Android and iOS as well. This is okay, if you have the budget. But going cross-platform typically brings significant savings. That's why MobileUI is a cross-platform approach. But with an important addition: You can also break out of the "single codebase" whenever needed. With MobileUI running on Android Runtime and RoboVM, you have the possibility to directly access native SDKs from Java and Kotlin. And that's a main difference to Ionic, React Native or Flutter, where you need to switch languages, tools and IDEs to implement native extensions.
But for sure, we are also big fans of the Java and Kotlin ecosystem. And with us are about 9 million Java developers and millions of Android devs. MobileUI enables them to build amazing cross platform apps. Especially for Android developers, we give our best to flatten the learning curve π. And that's what makes it easy for agencies and companies that have Android developers to go cross-platform!
Why this framework still uses XML to build UI? Like SwiftUI, Flutter and Jetpack compose, they use DSL to build UI and this is a trend.
Yes, we watch the UI-DSL developments and have discussed these trends internally. Our conclusions so far were that XML - although being 22 years old - has several advantages when being used as UI declaration language. Why? Well-designed XML languages (like MobileUI Layouts) are:
<TextView text="Hello World!"/>andOn the other hand, we find that XML is not a one-size-fits-all approach. There are cases, where XML just does not fit and produces a lot of verbosity. Examples: XAML Styles and Android Styles π. When it comes to styling, our opinion is that DSLs are a better fit. Therefore, we use a well-known and standardized DSL for the latter: CSS.
Also for UI data binding, we use a DSL: MVEL. With the Java-like expression language, you can super-concisely combine XML with Java and Kotlin code.
While we think XML is great for UI trees, we are watching the development of UI-DSLs, waiting for a good to come. With MobileUI's stack, it would technically be possible to bring Jetpack Compose to iOS just like we did it with Android Layouts before. Maybe one day, we will walk that way. But first, we wait until Google and IntelliJ have fixed the Kotlin Compiler so that all Jetpack features are supported π.
But be aware! When this happens, your boss might ask you: "What does this code do?" And you would have to explain (Flutter in this case) π:
(see github.com/nisrulz/flutter-example...)
So what do you think? What are the pros of UI-DSLs? What are the cons?