Toni MaxxToni Maxx

Why a WordPress Site Needs a Real App, Not a Wrapper

story product

  • Built with
  • WordPress
  • React
  • Expo
  • PHP

Many "WordPress to app" products take your website and put it inside an app. It is quick to build. For NativePress I chose the other path: the app draws its own screens from your content. This note shows how each one loads, in plain words.

What a wrapper does

A wrapper app opens a WebView. A WebView is a browser inside the app. The app asks your site for a normal web page, and the page loads with its theme, its scripts and its menu. The reader gets your website inside an app shell.

That is a fast way to get an icon on a phone, and it reuses the site as it is. The trade is that the screen is still a web page, so it loads like one.

What a real app does

A real app draws its own screens with native components. The tabs, the header and the lists belong to the app. It only needs your content, not your page.

This is where WordPress gets in the way. The default WordPress REST output is heavy for a phone. It sends a lot of HTML and fields the app never uses. So the work is to give the app a lighter feed of the same content.

Try it

Pick a type of app and load one screen. The steps are a sample, not a measurement. No timings, no real requests.

Interactive · toy

Two ways to load the same WordPress screen.

  • Wrapper: the app opens a WebView, asks the site for the full page, the server sends HTML, CSS and scripts, and the WebView lays it out like a browser tab.
  • Real app: the app draws its own tabs and header, asks the plugin for light Markdown, and draws it with native components.
  • The steps are a sample, not a measurement.

What I built

NativePress has two parts, and I built both, plus the data format between them.

  • A WordPress plugin with its own REST namespace, nativepress/v1. It takes what authors write in Gutenberg, turns the HTML into light Markdown and serves that instead of the default wp/v2 output.
  • An app made with Expo and React Native. It reads the Markdown and draws it with native components. There is no WebView.

The Markdown is small and carries only the content. The app decides how it looks, so the tabs, header and lists are real app parts rather than a copy of the web page.

What stays the same for you

Authors keep writing in the editor they know. WordPress stays the source of truth, and the client keeps the site, the hosting and the domain. Nothing about the writing routine changes.

The app is a second way to read the same content. You publish once in WordPress, and the plugin serves the light version to the app. The full picture is on the NativePress case study and on the demo page.

What it is now

NativePress is a subscription: a monthly plan plus a one-time setup fee. Ask for a quote. I also prepare the app for store submission for clients. Apple and Google decide approval, so I do not promise it.

It suits WordPress site owners who want their readers to have an app and want their authors to keep working in WordPress.

Is a real app right for you?

Choose a real app when you want the app to feel like an app and your authors to keep working in WordPress. If you are not sure, tell me about your site and your readers and I will reply with a one-page recommendation.

Book the free consult

Related

What I checked / where this comes from

  • The public NativePress case study on this site and the demo page text. No customer names, store links or numbers are used.
  • The widget steps are a typical wrapper flow and the NativePress flow in simple words. They are a sample, not a benchmark.