Say No to Universal Apps

If you build modern apps (especially in Meteor), you’ve probably heard of universal apps. In this article, I suggest that you stop building universal apps. Don’t panic. Read to the end. You will see why!

Edit: Earlier, I titled this post as “Say No to Isomorphic Apps”. But with the comments I got, it seems like Universal is a better word instead of Isomorphic in this context. So, I renamed it.

What’s an universal app?

In theory, an universal app is an app that you write once and it can be used everywhere, including the web and on iOS and Android devices.

With Meteor, this became trivial.

Before we dive into our main topic, let’s see what will happen in the web and mobile ecosystem in the future.

• The web will become super charged and it’ll get a lot of new features. Mobile web performance will increase a lot.
• Mobile user penetration will rise as usual.
• Web usage won’t die, but usage will be reduced.
• iOS and Android will get more native features and apps will utilize them (for example, iOS Force Touch).

Okay, now let’s talk about why it’s a bad to have isomorphic apps.

It’s all about the user experience

When building an app, you need to create a great user experience, which is hard. We always need to use platform-specific functionalities and we must consider the user expectations for each type of platform.

For example, iOS does not have a built-in back button but Android does. So, we need to design our apps taking that into account. This is just a single example, and there are many cases like this.

Although the web is getting better and better every day, it won’t be able to beat native mobile apps in performance and user experience. So, an isomorphic app does not add a considerable amount of value to your product.

For example, you can wrap a mobile web app as a Cordova app and publish it to a store. It’ll work for sure. But you will never be able to achieve an experience like that of a native app, no matter how hard you try.

And in doing so, the user experience will be bad and users won’t use it often. They may even write bad reviews.

Okay, I get your point. But our team doesn’t have the resources to build native mobile apps.

This is a valid point.

The answer is: don’t build mobile apps. Instead, improve your app’s mobile web experience. You can do this by applying some style changes and thinking about where to put things.

Once you do so correctly, mobile users will use it. The point is, now they know they are using a web app, but not an app. So, they don’t look for an app-like experience. Instead they look it as a mobile web app.

Because of this, you’ll have a lot of satisfied users, who will say things like:

Wow, this app works pretty awesomely in mobile. I love it.

One code base for all is a really bad idea

For isomorphic apps, we use a single code base targeting all these types of app.

This leads to a lot of hacks and a very hard to manage code base.

For example, let’s say you need to use some native functionality that is available on only one type of platform. Since it’s not available on the other platforms, you shouldn’t use it. If you do decide to implement it just for that platform, you will need to do some hacks to enable it just for that platform.

This all leads to a monolithic code base that will be very hard to manage in the long run. The solution is to build multiple apps for different platforms like web, iOS and Android.

Okay, this seems like a valid point too. But then, I need to duplicate the functionalities in all those apps.

Alright! This is where we are going to talk about isomorphic modules and concepts.

You can use React Native to build apps for both iOS and Android, following some isomorphic concepts.You learn how to do so with React Native once, and then you build different apps for different platforms.

On the other hand, you can wrap up your app’s client-side validation into an NPM module. Then you can use it on each of these platforms.

You can do the same for a lot of the things in your app and that’s how you can reduce the need to write the same code everywhere.

Here I mentioned two core ideas on why you should not build universal apps. That means we now need to build multiple apps for web, iOS and Android. Now I think you’ve got a question like this:

So, what about the server side?

Now we have multiple clients. But all of them need to talk to a single server. We can use a common API that can be invoked from all of our apps. That’s exactly something like GraphQL.

If you are using Meteor, you need to have clear separation between the client side and the server side. Do not mix server code and client code together. Always treat them separately.

This is the core concept behind Mantra

When we were designing Mantra, we always wanted to use isomorphic modules with a clear separation between the client and server.

Let me talk a bit about client and server separation.

All the interaction with the server will be done via a mediator on the client side. We should be able to swap it out(if needed) without re-architecting our app. You’ll be able to use Meteor’s LiveQuery, GraphQL, typical REST endpoints or anything you like without re-architecting your app.

Mantra modules will help you to distribute code via NPM. So in the future, we can easily move into different platforms. That’s why I said Mantra will support React Native even if we haven’t thought about how to do so yet.

For some apps, this may be a hard decision. But, try to stop building universal apps. You’ll see the benefit in the future.

If you are building a prototype, you can always ignore these suggestions. But keep in mind, it’s a prototype and not your final product (app).

In a nutshell, whether you use Mantra or not, stop building universal apps. Instead, use isomorphic modules and build multiple apps. This will lead to better products and a better user experience in the long run. That’s all we want to achieve at the end of the day.

Follow KADIRA VOICE for more articles like this.