We are getting close to an app release, and the part worth explaining is not the app. It is that the thing we are shipping is not a separate product.

The usual arrangement, when a platform offers you a mobile app, is that the app is theirs. Their design, their branding with your logo tucked in a corner, their feature set, their release schedule. You are a tenant in somebody else’s application, and the members using it are theirs to see.

What we have been building instead is the other thing. Your site, rendered natively. Same members, same content, same login, your name on it, your colours throughout. The app is not a product you commission. It is your website with a different front end.

This post is where that stands, what landed in the last two days that moved it forward, and honestly what is still missing. We are close. We are not done, and the difference matters if you are planning around it.

What “your site becomes the app” actually means

The concrete mechanism is a single call the app makes when it connects to a site.

That call returns the site’s own name, its logo, its login background, and an accent colour. From that one accent colour the app derives its entire palette, light mode and dark mode, before a single screen is drawn. It also returns which features that particular site has switched on, what its legal documents are, and the minimum app version the site expects.

The consequence is the thing worth understanding. Two different customers running the same app build get two different apps. One opens to a community in their brand colours with forums and media tabs. The other opens to a job board in different colours entirely. Neither is a custom build, and neither needed us to compile anything for them.

That is why we describe it as your site becoming the app rather than you getting an app. The branding is not a setting we apply for you at build time. It is something your site tells the app at connect time, every time.

The decision that made this week possible

Two days ago four of our products added the ability to sign into a mobile app. Eventonomy on Saturday, then BuddyNext, Listora and WP Sell Services yesterday morning.

Four products, roughly forty-eight hours. That pace is not a story about working fast, and we wrote separately about what actually makes the cycle quick. It is a story about a decision made a long time earlier to refuse to build something.

The tempting path when you put a plugin on mobile is to build an authentication system for it. Issue tokens, manage refresh, store secrets, handle expiry. Every plugin gets one, and every one is subtly different. It feels like the professional choice because it looks like what large apps do.

We refused it. Authentication is WordPress core Application Passwords, and nothing else. The app opens the authorisation screen that ships with WordPress itself, the member approves it there, and the credential comes back and is stored in the device keychain. There is no token endpoint of ours anywhere in that flow, because WordPress already solved this and duplicating it would only mean owning the bugs.

The payoff arrived this week. Adding app sign-in to a fourth product was not a project. The identity layer already existed, in core, shared by everything.

Listora’s version of it is the detail that shows the design is holding. Its app learns which sign-in doors a site offers before it draws the login screen, so a member never sees a button that will not work on their site. And when somebody signs in again, the credential is replaced rather than stacked, so members do not accumulate a growing list of app passwords they never asked for and cannot interpret.

BuddyNext went further and added Sign in with Apple, along with the bridge that connects a native app session, and QR-code enrolment for two-factor. All of it sits on the same core credential rather than beside it.

What actually landed, and what it lets you do

Set aside the version numbers. Here is what a site owner can do now that they could not last week.

Members sign into your app with the password they already have. No app account, no second registration, no separate password reset that generates support tickets. The credential they use on your website is the credential the app uses.

You can reach people through push. BuddyNext Pro added native push, and WP Sell Services added device listing so you can see what is registered. Push runs through each plugin’s own notification system out to Expo’s transport. There is no third-party push service in the middle holding your member list.

Your branding travels. The site sends its name, logo, login background and accent colour, and the app dresses itself accordingly before the member sees anything.

The app only shows what your site runs. Feature flags come from that same call, aggregated across every active plugin. A member never sees a tab for something you have not enabled.

None of that is a changelog line. All of it is the difference between a website that has a companion app and a website that is available as an app.

Two ways your members will open it

There are two shapes this takes, and they are the same codebase.

Inside the unified app. One app in the stores, into which a member connects your site. They get your branding, your colours, and the tabs your site has enabled. If they belong to three communities running our plugins, they can connect all three and switch between them. For most site owners this is the sensible option, because it costs nothing, requires no store account, and needs no submission process.

As your own branded app. Your name in the App Store, your icon on the home screen, one product’s module enabled and your branding baked in. This is not a fork or a separate build we maintain for you. It is the same application compiled with a different profile: one module switched on instead of all of them, branding fixed rather than fetched.

The reason that distinction matters is maintenance. A forked app for each customer would mean every fix has to be applied and resubmitted many times over, which is exactly how white-label mobile products end up abandoned two years in. A build profile means a fix lands once and every profile inherits it at the next build.

What a branded build costs you is not development. It is the ongoing obligations of being an app publisher: a developer account, review cycles, and responding when a platform changes its rules. That is a real commitment and worth being clear-eyed about before choosing it over the unified app.

Why App Store review is the long pole

The work left is mostly not features. It is compliance, and compliance is where mobile projects go to sit for three months.

Four things block submission regardless of how good the app is.

It cannot crash on a reviewer’s device. Obvious, and harder than it sounds, because reviewers use the app in ways nobody on the team would.

Anything with user content needs reporting and blocking. Apple requires that a member can report content and block another member, and that reports go somewhere. This is why our plugins added moderation queues and member blocking on the web side first. A block has to hide that member’s content on every read surface, not just the one screen where the button lives.

Account deletion has to work from inside the app. Not a support email. A path in the app that deletes the account and the data behind it. This is also why the privacy erasure work matters so much: an incomplete erasure is a failed requirement, not a rough edge.

Legal documents have to be reachable in the app. Which is why the config call carries a legal block rather than expecting somebody to remember to add links.

None of that shows up in a feature list, and all of it is mandatory. We took one product all the way through to a proven submittable state specifically so the remaining ones do not each have to discover these separately.

The order, and why it is that order

The sequence is deliberate rather than by product popularity.

Jetonomy went first because it was the proving ground, and everything about auth, theming, networking and push was learned there. WPMediaVerse went second because it is the product with the most user-generated content, which made it the right place to work out App Store compliance properly rather than theoretically.

Career Board, Listora and Learnomy follow, each needing the contract work rather than new APIs. BuddyNext, the unified shell, comes last, because it is the thing everything else folds into and there is no sense finalising the container before knowing what has to fit in it.

If you are waiting on a particular product, that ordering is the honest answer to when. Not a date, but a position in a queue whose earlier items are largely finished.

Where each product actually stands

Being specific here, because vague progress claims are how people end up planning around something that is not there.

The REST surfaces are mature and have been for a while. Learnomy carries roughly 195 registered routes. WPMediaVerse is around 145 across its free and Pro namespaces. Listora is near 69, WP Career Board around 43. That work is done, and it is the part people assume is the bottleneck.

It is not the bottleneck. The per-plugin work that remains is bringing each one to the mobile contract, which is a narrower and more specific list: the single bootstrap call, permission callbacks that hold up when a credential bypasses the normal login path, push fan-out, viewer-relative fields on reads, and pagination that survives real data.

Jetonomy is the reference implementation. Its app is the proven one, and every pattern described here was learned there first.

WPMediaVerse is the compliance reference, taken all the way to a submittable state on simulator. That matters because App Store review has hard requirements that have nothing to do with whether your app works: reporting and blocking, account deletion, legal documents reachable in the app, and no crash on a reviewer’s device.

The rest are in the queue behind those two, and each release closes named gaps.

What is not done, said plainly

Three things, because a post about being close should be specific about the distance.

Most plugins are not yet at the full mobile contract. Their REST APIs are rich, which is not the same thing. The contract asks for particular behaviour in particular places, and each product is at a different point against it.

A feature existing in code is not a feature that works. We learned this expensively. On one product, a check of the codebase suggested reporting and blocking were present and privacy erasure was complete. In practice the reporting endpoint returned a permission error to every caller, and the erasure routine missed nine database tables. Both looked fine from the outside. Neither was. So when we say a product is ready, it means somebody exercised it at runtime, not that the functions exist.

The app is a Pro benefit with a licence check. It is gated at connect time, before credentials are entered, and it fails closed. If you are on a free plugin, the mobile app is not part of that. The plugin’s own web features stay entirely independent of any licence, and always will, but the app is not free.

What it is not

Three clarifications, because “your site becomes an app” invites some wrong pictures.

It is not your website in a frame. A wrapper that loads your site in a hidden browser is the cheap version of this and it always feels wrong: scroll behaves oddly, navigation is web navigation, and push either does not work or works badly. What we are building talks to your site over its API and draws native screens. The difference is obvious within about four seconds of using it.

It is not a progressive web app. A PWA is a reasonable thing and it is not this. This installs from the store, gets real push notifications, and can use platform sign-in like Sign in with Apple.

It is not a reduced version of your site. The intention is that everything a member can do on the web, they can do in the app. We hold each product to a coverage matrix that maps every member-facing capability the plugin has to a screen in the app, and the release bar is zero capabilities missing. Where something is genuinely absent, it gets written down rather than quietly dropped, because the failure mode we most want to avoid is a member downloading the app and finding half their site is not in it.

That last one is also the most expensive commitment we have made, and it is the reason this is taking as long as it is.

For developers

This section is the technical half. If you are reading as a site owner, the closing thoughts are below it.

The auth decision has one consequence that is easy to miss and expensive to get wrong. Application Passwords are minted by WordPress core, which means they bypass any login gate a plugin has added. A member you have banned, or one who never verified their email, can still hold a perfectly valid credential.

So the ban check cannot live at login. It has to live in the REST permission callback for every write, on every route. The contract test we hold products to is blunt: a banned user holding a valid app password gets a 403 on every write path, posts, replies, votes, messages, without exception. Any product where that is enforced only at the login screen has a hole in it.

The second thing worth knowing is that mobile makes list performance non-optional. Enrichment fields, whether the viewer bookmarked something, how they voted, what their membership is, cannot be resolved per row. On a web page an N+1 is slow. In an app fetching a feed over mobile data it is a product that feels broken. Everything is server-paginated and enrichment is batch-fetched, and the bar we test against is a 2000-post feed and a 400-reply thread. This is the same big-site readiness checklist we apply to every list view on the web, applied somewhere the consequences are less forgiving.

Third, the module architecture. Roughly seventy percent of any of these apps is a shared shell: auth, theming, networking, navigation, push, and the config loader. What differs per product is a module that declares its navigation entries, routes, API client, feature-flag key and deep links. A module never assumes its plugin is active. It mounts only when the site’s config says that flag is true, which is what lets one build serve sites running entirely different combinations.

The stack, for anyone who wants to build against it: Expo with file-based routing, React Query for caching and offline persistence, Zustand for auth and push state, Nativewind for styling, SecureStore for the credential, and Expo Notifications for push.

What this means if you run a site

If you are running one of these plugins, the practical implication is that you do not need to plan an app project.

The thing that usually makes a mobile app expensive is not the app. It is that your data lives in a system that was never designed to be read by one, so the first six months go into building an API before anyone sees a screen. That work is already done here, and it was done as a normal part of the products rather than as a mobile initiative. It is also the clearest return on building the whole stack in-house, because an API that has to be negotiated across five vendors is an API that never quite arrives.

What you will need to decide is smaller: whether you want your own branded build or your members inside the unified app, and whether the Pro licence makes sense for you.

What you should not do yet is promise your members a date. We are close, and close is not shipped. The remaining work is the contract gaps and App Store compliance, and compliance in particular is the kind of thing that takes exactly as long as it takes.

There is one thing worth doing now, though, and it costs nothing. If your members are going to open your site on a phone in an app, the data they meet there is the data you already have. Profiles that are half filled in, categories nobody maintains, a member directory with no useful fields to search: none of that improves by being rendered natively. It gets more obvious, because a phone screen is less forgiving than a desktop one.

The sites that will feel best in the app are the ones whose content and member data were already in decent shape. That work is available to you today and it is not blocked on us.

The short version

We are getting close to an app release, and the reason it is close is a series of decisions that each looked conservative at the time.

Refusing to build our own authentication and using what WordPress core already provides. Putting branding in a runtime call instead of a build step. Building one shell with modules instead of five apps. Treating list performance as a day-one requirement rather than a scaling problem.

None of those were exciting choices. Together they are why four products could add app sign-in in two days, and why the app your members eventually open will be your site rather than ours with your logo on it.

We will say it is ready when somebody has exercised every part of it at runtime, not when the code exists. That standard is why this post contains a list of what is missing rather than a launch date, and we would rather publish it in that shape than the other one.

Until then, close is the honest word.