Discourse forum owners: Are you interested in native mobile apps?

That’s interesting when you think about the number of wordpress wrapper apps out there.

@Aa7 I’m struggling to think of the advantages, but I’m open to hearing people’s ideas for sure. I like the fact that you mention the focus on user vs admin is smart.

Perhaps offering a whitelabel publishing service could be a gateway for this? Reason I say it is that the person that was doing it at one time (name escapes me) has stopped.

Or perhaps a build it from a UX teardown of the mobile theme. I have noticed a handful of folks disable the mobile theme and go full desktop on my forums… so that might be a clue.
Also google has at times complained about some touch areas being too small.

1 Like

Apple has definitely been inconsistent in enforcing its policies.

So first, you will be rebuilding the entire frontend in an app? I think you are grossly underestimating the complexity and amount of the work that needs to be done there.

And then, each time there is an incompatible Discourse update, you need to:

  • notice that
  • figure out what is happening
  • adapt your code
  • submit the app for review and go through an uncertain and possibly lenghty approval process
  • wait until the forum users find out there is an update, and they’ve updated the app on their phone

So how long would this take? Anything between a day and three weeks, I guess? Maybe five weeks, if you happen to be on vacation?

In the meanwhile, depending on your process, either

a) the forum cannot be updated, possibly exposing security issues
b) the forum cannot be used through the app

I don’t think this is going to work.

I think this is the main issue we need to solve - find the golden bullet functionality that will make Apple approve these wrapper apps, and then use the wrapper approach.


I know I said an app update would follow but the development for new releases happens in the open. Any adaptation can happen right alongside these changes. Besides Discourse is a mature code base. If it were anything as young as Talk (not an apples to apples comparison), where the API changes often I don’t think I’d consider it.

As for noticing changes and staying up to date goes, I submit that this is a full time job.

I haven’t really estimated the work. I’ve been in software development for about 13 years - I’m hoping I don’t make a gross error if I take concrete steps in working on this.

1 Like

Most sites run tests-passed, which means you will always be chasing compatibility not preparing for releases.


I would be interested in native Discourse app.

1 Like

Which is rather rich considering they don’t provide mobile Safari push …


Aren’t the “advantages” mostly for the people running the sites/services rather than for the users ? When you have an app, your users are a little more “captive”: They open the app and are in a closed environnement rather than in a web browser where they can go anywhere at any time. They have an icon leading directly to your app, rather than another bookmark to your site (if they have one, or maybe they will just forget your URL at one point). And there is usually the possibility of push notifications when an app has been installed even if the user didn’t open it for a while.

It’s subtle, and there are indeed arguments why this isn’t true or why you could do pretty much the same without an app. But at the beginning, isn’t it providers that pushed for their apps to be installed (even if they don’t really bring anything to users), rather than users asking for it ? (users went along with it and got used to this way of doing at one point, and maybe now they’re asking for apps, even if they don’t really know why. Maybe they find it convenient now)


I think so.

I currently use the official Discourse app and can’t think of anything that it’s missing (aside from push notifications for my site and a few others.) I like it.

The only other thing I really want is for it to have my community’s name and logo, for the reason…

They are in my case. People find single purpose devices pleasant to use. On a phone, you turn it into a single purpose device by opening an app.

Exactly. Infuriating.


So analytics. Not a bad thing.

Sorry I don’t follow. Can you please explain?

Out of curiosity, which forum do you run? Thanks.

Allow me to elaborate on what @Stephen has said.

As a plugin writer I can tell you keeping code up to date to be compatible with core is not a trivial task and requires careful strategy. Plugins are usually kept in step with the tests-passed branch. You could go for a slower branch but that means so will your clients. That’s ok though. But you will need a lead time to update your app after every stable release. That will be a lot of work and could lead to significant delay to client updates.

Like plugins, you always have an ongoing risk of something breaking in after a significant enough change in core.

You state Discourse core is stable. Perhaps more so than at the beginning but do take a look at the repo carefully, it does move (though a lot of that may be the web app). Just take a look at how many commits there are on a daily basis. Look at the number of open PRs. Take just one file, Topic.hbs for example, and consider how you will keep up with just that? Even forking the Discourse core base is warned against for exactly this challenge. And this will be a native rewrite?

Will you use only their API? Then fine but how will you implement any of the popular plugins? Some of them have significant visual changes most of which use monkey-patching with eg JQuery or plugin outlets which you won’t be able to re-use if you go native. You will reimplement those with native code?

Plugins are but the tip of the iceberg. What you are proposing is presumably the complete scope of all front end user functionality. All this will need testing. And test cases. Just wow.

And how big is your team? Again take a look at how many developers are committing to core. Add the in-scope plugin author population. That gives you another metric for the size of the challenge.

You will need a velocity that matches Discourse releases (!) or all your clients will start to feel like they are being held back from new features.

You will need to justify every hour you spend and recoup that in revenue (and that’s ok, you need to put food on the table like the rest of us)

But in any case I think you could have a go at implementing this with the aim of demo-ing it. I would start with ‘just’ the core app. That will quickly give you a feeling of how big the task is. Or just count up all the API calls you will need to support.

I’m sure you’ve thought about all this though. I don’t mean to put a downer on it but this is a serious amount of work you are proposing and on an ongoing, brutally relentless basis.

How about looking at the official app and seeing what you can do with that?


To be fair, I don’t think this would be an issue for an app that is native code instead of “just” a webview of a site.


That’s true and there are loads of examples of native implementations of web apps out there. Eg Facebook (although their web app is woeful)

A wholly native implementation probably isn’t at risk.

It’s the ‘wrapped’ apps they would target. Edited my post.


I have toyed with the idea of writing a fully native app as well (iOS developer by trade). I’d base it on the (public?) HTTP API of Discourse. Is there some guarantee how stable the API is or whether it is versioned in some way, to prevent old app versions from breaking unexpectedly?


Communities invested in the native app can follow our slow branch (aka “stable”). Also we don’t change APIs often, they are very stable.


The app could be based on Discourse REST API which should be fairly stable. Then it could have whatever UI/UX it desires, maybe even different from webapp (this might be better or might be worse). If app author chooses any other approach (I’m not sure if it’s even possible) he’ll hit the pain you describe.


Yeah. Looking different, but consistent could be viewed positively by some people, but probably only if it was one app you could add multiple instances to, like the official app. However, that’s not what a lot of people are interested in. Imagine your site’s custom app had completely different styling from your site. Not good.

And I can’t imagine anybody would be too pleased with an app that didn’t support all of the features on their site. So plugins begin to be a problem right away.


I agree, this could be the hairy part. A native app could end up looking worse than the web wrapper if plugins aren’t supported. A sensible first pass would support the most popular plugins, and over time, add support for more.