Im a mobile developer and happy to get my hands dirty but would like to hear from anyone else who has already spent significant time thinking about the problem. Ideally brainstorming out an RFC and breaking up into tasks so a proof of concept can be constructed should be next steps.
I’ve thought about it a bit as I have an pretty big Redwood API which talks to a pretty complex Expo app. I put a bit of time into integrating Expo as a side once, before opting for a separate repo.
There’s quite a few sets of ‘parallel but different’ systems like the Redwood Router and RN Navigation’s navigation definitions or RNW vs the Redwood Web implementation which I am unsure if they can be reasonably reconciled without ceding too much control to make a quality app.
That said, the technique which has been knocking around in my head lately is that the redwood API could generate an npm module during builds, which the app can consume to get a manifest of all the important routes/queries/types/data models. This would act as the conduit for the ‘convention’ parts of Redwood.
Then a set of client-side components for bootstrapping consistent API clients etc can be added as something like @redwood/mobile lowering the barrier for communication between the different parts of the system.
Thanks for jumping in here @SeanDunford! This is outside my technical knowledge but hopefully I can connect some dots for folks here. Figuring out mobile integration is going to be a decent amount of upfront work.
But having multiple clients that can easily interact with your API has been a crucial part of the larger vision of Redwood from the very beginning. It was also perennially put off as a post-v1 feature and we’re already living in the future with Redwood v2.
Prior Art on a Redwood Mobile Package
There’s been occasional discussion around the topic, but mostly in regards to the concept of what is a side in Redwood. Aside from that, the GitHub issue you linked was the first attempt at implementing the functionality.
Since I have no experience with mobile, React Native, or Expo, I’m ensure of the feasibility or likelihood of any changes making it back upstream. Not sure if you’ve seen that discussion @orta, it’s over a year old, but you’d definitely have a better read on the room there than I would.
Next Steps and RFC
Either way, though, let us know Pedro if you’ve given any more thought to this or were still interested in contributing. I love @SeanDunford’s idea of an RFC and I encourage anyone else to share their thoughts here.
Right now the Redwood+Expo example Orta shared is the only other proof of concept that I’m aware of, so I would also be curious to hear from Pedro if he has any thoughts on Orta’s approach/suggestion of generating an npm module during builds.
I’ve got little to no experience with mobile app development. And even though I’m part of the RW core team, these are my own thoughts, and not representative of the Core team’s view on this.
When thinking about a mobile side, I’d focus on api+mobile and see how those two sides could work together. I wouldn’t worry about sharing routes between web and mobile for example. Basically approach this as if mobile and api were the two first sides we had. What would be the ideal DX be if that was our starting point?
Looks like there’s a project called Solito that worked on unifying navigation for web and React-native (with or without Expo). Might be worth investigating.
I listened to a talk at ReactSummit in Amsterdam a week ago where they mentioned GitHub - software-mansion-labs/react-native-url-router: A new way to create navigation in react-native as a way to have the same router for both web and mobile. But I think we’re pretty set on using our own router for React (web) now. So if anything the other points in that same talk about the challenges about building a router and handling navigation across both web and mobile can help us make Redwood Router work on mobile too, if that’s a path we want to explore.
If Redwood can do an integration between Redwood’s web side and RN like what he did, I really think that would be awesome! And also totally doable. I’ll bring it up with the core team and see what they say about it.
@Tobbe just watched the beginning of his about navigation. This already looks very similar to redwood router. This would be an awesome project to work on.
Had some more thoughts pop up related to this that I wanted to write down.
Let’s say you’re building something like Slack, or Spotify. You’d want a web-side that’s your marketing pages and maybe a pricing page with buttons that take you to some checkout form.
You’d also want a web-side that’s your logged in experience for paying (or free, I guess) customers.
Plus you want a mobile app for your customers.
And finally you might want an internal “admin” web side too, to manage users, subscriptions, content etc
Now, we’ve mostly talked about a “mobile side” as a separate thing. But is that really what we want? Is that the end goal?
What if the web-side for your logged in customer experience (e.g. the Slack or Spotify web interface) could also be your mobile app? Wouldn’t that be better? Maybe we shouldn’t look at this as a separate mobile side. Maybe it should just be another web side that can also compile to an app. This is the kind of the approach Ionic Capacitor takes.
Or, I guess, if you want to flip it around and say that RW’s mobile side can also be viewed/used on the web as a web app. (This is the React Native Web approach)
Or we do keep it all fully separated where “mobile” is totally its own separate thing for full flexibility.
I posted the above musings to the RW Core team chat as well.
The first question I got was “So, you’re asking PWA vs Native app?”
Any my reply was “Kind of, but not quite”.
It’s more like PWA + going the extra mile to make it a proper app that Apple will accept into the app store
vs
Making a mobile app + going the extra mile to make it work on the web as well
About PWAs: There are tools that simply take your PWA and bundle it into an app, like https://www.pwabuilder.com The problem is that only Google (and Microsoft) accept those kinds of apps into their app stores. Apple doesn’t.
Apple say
Your app should include features, content, and UI that elevate it beyond a repackaged website.
Basically what that means is you need to integrate with native things on the platform that are not available to PWAs. The simplest thing is usually notifications.
The sneaky thing here is that Apple might approve your app the first time you submit it, depending on what reviewer you get looking at your app. But for any future update you wish to publish they might change their mind, basically looking you out of the store until you’ve rebuilt your app.
Another thing to think about is the router. For our current web side we have our own router that’s very opinionated in that it’s not file-system based, and that it’s very flat, with all routes defined in a single file with minimal nesting.
Should we spend the time to write our own router for React Native too, to keep it similar (or even the same? ) as our web side router? Or should we use an off the shelf solution like React Navigation because it’ll be faster to get something working, and it’s something people are used to?
I’d just like to pop in as someone who is currently using Solito. It’s very heartening to see the Redwood core team actively considering this!
Right now I’m playing with Redwood’s API as a backend with for a Solito-powered front-end and native app. But if the entire thing could be in Redwood, that would be a dream come true!
The promise of not having to build completely separate apps for native and/or having to do tedious plumbing to set up shared components seems really aligned with the Redwood way of doing things.
Hey guys, creator of Solito here. Glad the talk was useful. @glowy sent this thread my way.
I wouldn’t, personally. React Navigation has worked through the many kinks of native navigation over the years. Unlike the Web, native is full of opinionated, platform-specific UI and challenging patterns. React Navigation’s implementation is very strong and well-maintained.
One place it lacks is, well, the API. Once you build a massive app with tons of routes, the many nested navigators can get hard to manage.
Luckily, there is a file-system router in development at Expo which will wrap React Navigation with a Next.js/Remix-style router. File-system routing is a useful step for enforcing a URL mental model in general. This new router will play nicely with Solito.
Long-story-short, I wouldn’t recommend building a new navigation library. If you guys are experts in routing, I highly recommend offering to help Evan Bacon in his quest to bring file-system routing and code-splitting to React Native. He’s already made big strides with Metro (React Native’s bundler). I spent some time with him in person working on the API and it got me excited for the future of RN’s routing.
I’m not too familiar with how Redwood works, but spinning something up like solito-redwood is one approach you could take to bridge the Redwood router with React Navigation. In addition to the Next.js talk linked to above, the Methodology and Gradual Adoption pages of the Solito docs may offer some help as you think through the best solution.
I found this cool repo that splits up a React Native app into a Redwood sides-esque setup. Thought it might help drive some ideas for the mobile side(s) addition.
Here’s a blog post explaining an approach to using a file system based routing approach for mobile apps. Very opinionated but might be useful to the discussion.
) as our web side router? Or should we use an off the shelf solution like React Navigation because it’ll be faster to get something working, and it’s something people are used to?
