Hey guys,
I’m facing a bit of an architectural dilemma. I currently run traveljunky.in, a travel itinerary and package platform.
Current Stack: * Laravel (Backend)
Inertia.js (The bridge)
React (Frontend)
Server-Side Rendering (SSR) enabled via Node.js
The Dilemma: We are considering a move to React Native to provide a better mobile experience (offline access to vouchers, push notifications, etc.). However, SEO is our lifeblood. We rely heavily on organic search for package discovery and lead generation.
My concerns:
SEO Impact: If I "shift" to a decoupled React Native approach, I effectively lose my SSR benefits for the app content. How do you guys manage the SEO vs. Native App trade-off?
Maintenance Overhead: Is anyone successfully running a "hybrid" setup where the same Laravel controllers serve both Inertia (for the web) and a JSON API (for React Native)?
PWA vs. Native: For a high-intent, low-frequency industry like travel, does it even make sense to go Native, or should I double down on a PWA/optimized mobile web experience?
Specifically, I'd love to hear from anyone who has:
Refactored an Inertia monolith to support a mobile app.
Managed SEO-critical content alongside a native mobile app.
Used Capacitor or Turbo Native as a middle ground for Laravel apps.
Looking forward to your insights!
@bladeofgaladrial I don’t really understand why building apps using React Native, would affect SEO? React Native is for building native apps that runs on a user’s iOS or Android device. It would be completely separate from your “web” codebase, which means your web app would need to expose an API for your native apps to consume data.
But then I would be maintaining 2 repos one mono repo Laravel+React and another one for RN. Also I would have to maintain 2 endpoints for each action (one for web and another one for app).
The problem doesn't end here, the content on the website was not made keeping mobile apps in mind so there are a lot of interlinking through fully qualified URLs, wont they break in app?
You can try using NativePHP.
You code in Laravel / InertiaJS / ReactJS and you convert your web application into a mobile one.
This way you have only one repository to maintain.
@vincent15000 One repository? How would that work? Have you published a mobile app this way, either on Google Play or App Store?
To me, NativePHP sounds like a massive complication. You can't easily port an Inertia UI, which relies on server-side routing and props.
OP could probably get away with a PWA. I'd only consider separate mobile apps if they need some native APIs that are unavailable to PWAs.
But then I would be maintaining 2 repos one mono repo Laravel+React and another one for RN.
@bladeofgaladrial Yes? You would be doing that any way if you were building your mobile app(s) with something else like Flutter, or actual native technologies like Swift and Java/Kotlin.
Also I would have to maintain 2 endpoints for each action (one for web and another one for app).
Why? Both your web app and mobile app(s) can consume the same API endpoints if your web app is nothing more than a JavaScript client consuming an API.
The problem doesn't end here, the content on the website was not made keeping mobile apps in mind so there are a lot of interlinking through fully qualified URLs, wont they break in app?
What does this have to do with mobile apps? Your mobile app would request data from the relevant API endpoints. It doesn’t need to know anything about how the URL structure of the web app also using that API; it doesn’t even need to know if there is a web app—or any other client—using that API. Just like your website shouldn’t know or care about how your native apps are structured, how screens are presented, etc.
Stop conflating your web app and mobile apps. They are completely separate.
The OP is mentionning React Native which is to develop mobile applications.
So I thought about NativePHP which could be an alternative.
Please or to participate in this conversation.