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?