Native Where You Need It (Hybrid Mobile Apps)

What Does “Native Where You Need It” (NWYNI) Mean?

NWYNI refers to the practice of using native mobile components only in areas of your app where they’re essential and optimal. In all other instances, web components (web views) are utilized. AKA: Hybrid Mobile Apps. Part of the app is web, and maybe, parts of it are native mobile, when needed.

The application would “ship” as a native app that utilizes web views for the majority of its content, but then dives into native components where it is best suited for the given application. Based upon the route (URL) native components would be shown in some instances, while web would be shown in others.

The benefit of this is that you can ship new features to both platforms immediately, without app store approvals and then, when you’re ready, you can provide native implementations for various parts of your app, based upon the url structure.

A prime illustration of this approach could be imagined in media apps like Instagram. The core image editor and feed would optimally function as native components. On the other hand, features such as the profile field editor, subscription details, and the about page might be more suited as web views.

Another example might be a music player. The music player itself might be a native component, but the song search, playlist functionality/etc could all be web based.

Why would you consider using NWYNI?

When you built an iOS and Android app, you’re building the same exact thing twice.

• Once for iOS
• Once for Android

Each platform has different users and that requires usage of different programming languages and platforms for the same exact same use case. You’re writing the same app twice in two different frameworks and languages. If only there was a robust cross platform solution …

There is: HTML and the web.

Web apps already solve this problem – they are cross platform by default due to the nature of the web. You write HTML/CSS/JS once and then all platforms get to utilize it without custom programming for each platform.

Many businesses, business owners and startup founders have begun asking the question when it comes to developing multiple apps (iOS and Android):

Why would you create the same thing twice?

This is an oxymoron and doesn’t really make any sense from a business perspective. You create twice as many bugs (if not more), and grow your staff by 2-3x (or more) to support these two platforms that essentially do the same exact thing. Seems silly, doesn’t it?

When you build with a NWYNI approach, you will not abolish the need for native devs, but you will not need a huge team to do the same thing that previously would have required a large staff. You will need an iOS dev and an Android dev. Potentially they might even be part time depending on the features and how big they are. Remember, with NWYNI, all features are web based unless otherwise specified to be native. Only the native components would need native devs. The whole app is not going to be native, only small pieces of it.

Native Apps are Actually the 3rd & 4th Implementation of an App

When you’re building a native app, you’re mosts likely building the 3rd and 4th implementation of the app.

• Implementation 1 is the Web App
• Implementation 2 is the API
• Implementation 3 is the iOS App
• Implementation 4 is the Android app

It’s almost always like this in every single company I’ve worked with since starting Android development in 2008. Web comes first. Then they build the API (You need an API for the client apps). Then they build the iOS app first. Why? Most founders, VC’s, etc are all iOS users and its shown iOS users are more likely to spend money so this gets developed first. Finally, at the end, the Android app is developed.

The Web, iOS and Android apps have to be kept in sync going forward. As new features are developed, they need to be developed on all platforms. However, what often happens, and what most founders and businesses realize is that they can iterate on the web much faster. Therefore the web is almost always ahead on feature releases, bug fixes and more. That is, if the company has a web app, which most do. I know… there’s always special cases where this is not true, but 95% of the time they do have a web app/etc (in my experience).

Popular NYWNI Apps

Going NWYNI Hybrid is not something new. Tons of companies do it now. For example, there’s a laundry list of big apps that have quite a bit of web content in them.

• GMail
• Amazon
• Ebay
• American Express
• Starbucks
• Uber
• Southwest Airlines
• Untappd
• … and many many more

The list is simply to long to keep going.

The reason I tell you this is because this is something that many companies already do when they cannot afford to build native components for all their screens/etc. Sometimes they need to delegate to the web.

How to implement NWYNI

There’s two approaches for NWYNI hybrid apps.

Option 1: Web First, then NWYNI.

Option 2: Mobile First, web for everything else.

Option 2 is how most hybrid applications have been built. They’d build the core experience with native and then bolt on the other features with WebViews later on. I think this is fairly straightforward. You need to be able to authenticate your WebViews, and once you do that, you can be in a web context. However, with this approach you often lose the back button support and so much more, but it “works”. Ultimately this is a “mobile first” approach, and I’m advocating flipping this on its head to a “web first” approach. So we’re going to talk about option #1.

With Option #1 you start with the web app being web first, and then adding mobile components as needed by demand of the market. This is a “web first” approach. With this approach your not guessing if a user will like/need a particular native feature. They’ll let you know when they need/want it in native. Furthermore, you can always fall back to web if the native version breaks.

To go NWYNI you’re going to need a couple of things:

• A working web app that is mobile responsive
• An API for all the parts of the app that you want to go native
• A way to authenticate the user in a API session and web session

Now you’ll need to build out your respective platforms, but utilize web for everything. You’ll still need “two apps”, an iOS native app and a Android native app, but its only the shell of the app that will be native. You’ll have an installable file and users will be able to log in to a WebView to get their content. The benefit here is that with a native context you can now start to detect a login, and then interface with the mobile platform to do things like register for push notifications, gps sensors, health sensors, etc.

I’m not going to walk through everything needed to do this, but you will need to listen to the change of URL’s and then decide if you want to show a native view. For example, in Android you can use the WebViewClient.shouldOverrideUrlLoading method to determine if your app should intervene (and then take over and show a native component instead/etc).

Authentication with NWYNI

One of the fundamental things about NWYNI is authentication.

Authentication with NWYNI seems like its tricky because with mobile apps we often utilize OAuth or some type of token to represent logged in state after the user has authenticated. With the web, users are often authenticated with a cookie session store of sorts. This is how most apps do it.

This will mean you’ll need to authenticate:

• With an API with a token of sorts
• With the WebVIews with a cookie store/etc

How you do this, is completely up to you, but its fairly straightforward. You’ll want to authenticate your app with an API to get an API token, and then you’ll also want to either use that API token as a way to authenticate the WebView (maybe via custom headers or something), or when you authenticate with the API you’ll want to also receive a cookie that you can set on the WebView so that when the WebView loads it uses cookie session auth.

This also means you’ll need to do two other things:

• Know when the WebView or API returns an invalid auth
• You’ll need to log the user out of two locations at once when logout occurs

However, this is quite simple plumbing. In Android, you probably know how to auth with an token. You get it from your API, set it on each request in a header and your done. If your’e server returns back a cookie, you can save it an store it into the cookie manager that the WebViews use. For example, here’s how you’d do it in Android with OkHttp.

Now, when you log out, make sure you clear all the cookies and clear your auth token. Then your app would be logged out from the web and locally on the app client.

This is Great, but this is a Royal Pain in the Butt

I know what you’re thinking. Good god, this is a pain in the butt. Why would I do this?

Quite simply … if your web app exposes a new feature, its automatically available to both platforms, immediately.

Then, when you’ve built a new native mobile component to handle one particular part of your app, you can do so and ship it when you’re ready.

If you really want to be fancy, you can provide a URL mapping configuration via an API endpoint that says “Hey app, for this URL, load screen X and for this other URL load screen Y, but everything else let the web handle it”. This could be completely driven by the server and then if your native component happens to ship with an error in it, you can turn that native component off, and the app would revert back to its web implementation. This gives you ultimate flexibility for managing the stability of your app.

Now, again, this seems like a royal pain in the butt to build yourself. Thankfully there is some tech that helps with this.

Tech that helps enable NWYNI

Building all of this NWYNI plumbing can take some time. Thankfully there’s already some stuff built to help with this:

• Hotwire & Turbo
  • iOS Turbo
  • Android Turbo
• Strada
• Ruby on Rails

All of these tools together can help you simplify making a NWYNI application set up. Ruby on rails is the core, but you don’t need it. You can use turbo with any web stack, just check out the docs.

The core pieces are iOS Turbo and Android Turbo. I’ll speak on Android Turbo as I have the most experience with that.

With Android Turbo, you’ll load a remote configuration file that maps what URL’s will show native components. Then, along with the Google Jetpack Navigation Library, Android Turbo will take over when to show a native screen vs a web view. This is currently in production in many applications and one such application that uses this heavily is the Hey email app.

Ruby on Rails makes it easy to build web apps quickly and comes built in with Hotwire, Turbo and all the goodness of such. In my opinion, you’d be hard pressed to find a framework thats productive as Ruby on Rails. You’ll ship faster an get support for NWYNI applications right out of the box.

That said, there’s an even more fast track approach to building NWYNI applications, and that’s Jumpstart Rails Pro. This is a SaaS template that comes prebuilt with subscription management, plans, multi-account support, multi-tenancy and support for Turbo Native apps (NWYNI) and SOOO much more. See Jumpstart iOS and Jumpstart Android (disclaimer, I am the dev of Jumpstart Android). This is a commercial offering, but, in my opinion the time that it saves you is weeks, if not months, of development time. This is well worth the small investment.

Why Promote NWYNI When You’re A Native Dev?

You might be wondering why I’m promoting this heavily. Yes, I’m involved in Jumpstart Android, but thats not the reason why I’m such an advocate for this web first approach. So seeing that my personal background is heavily invested in native mobile android development (I’ve written books on it, have a podcast on it, and have done hundreds of hours of training videos on it online), it doesn’t make sense why I’d be promoting NWYNI.

The reason is simple: I believe the web will win.

I’ve been touting this on twitter/X for close to a decade now. Each time I talk about this I get run up the proverbial flag pole as a dismissive web elitist. Unfortunately, many don’t want to see this reality. May think native development will be the only way forward. This is what a lot of the mobile tech industry believes, even a lot of high level Android devs.

I was the person who touted Flutter quite heavily in this blog post, and in this video. I still think its a valid choice, but its not one I’ll make going forward (unless turbo and Hotwire are not available to me).

So when Chris from Jumpstart Pro came to me about the opportunity, it was a no brainer to me. Once I understood how it all worked my mind was blown. I even spoke to Jay Ohms (author of Turbo Android) about it here on the Fragmented Podcast. It was the best of both worlds – web first and then, if I absolutely needed it, I could dive down to the native level.

Unfortunately, this is often not enough to sway many into thinking that the web is a viable option.

Let me tell a story …

Be Pragmatic

In 2019, I was in Toronto for a Google Developer Expert (GDE) event. We went to a startup accelerator in town and met with a bunch of founders. They partnered with Google to have us come down and give them advice. We sat 2-3 GDE’s in each group. Usually the same type – meaning I was sitting with 2-3 other Android GDE’s at the time. The people that came to talk to us were startup founders who wanted to talk about Android apps or native apps in general. They wanted advice on their native app or building them.

We spoke to about 12 different people that day. Out of those 12 we told 10 of them that their business did not need a mobile app and that a web app would suffice. This would save them money, time and speed up time to market. If they needed “notifications” they could use Email or SMS until they hit product market fit and started to scale. Then they could go NWYNI.

This was a handful of Google sponsored Android Google Developer experts that had a combined experience of over 30 years (each of us had about 10 years experience) with Android, telling people “You don’t need an app, the web will do exactly what you need”.

In other words, we were all pragmatic about the use case of native mobile apps. They have their use cases and are very useful in those use cases. However, not all businesses need or require a mobile app. Most of the time the web will suffice. You have to be pragmatic about what you’re building.

Are you building an app to say “We have an app” or are you building an app because thats what is absolutely necessary for you business to succeed? These two are very far apart from each other. The key thing here is … to be pragmatic about it.

That’s what NWYNI is all about: Pragmatism.

Use what allows you to ship faster, get to market sooner, yet gives you the flexibility to add native components where it best suites your application.

NWYNI gives you that flexibility. You can ship faster, with a smaller and more nimble development team all while getting the benefits of native where you absolutely need it and a fast responsive web content via Hotwire and Turbo everywhere else.