What tech stack should I use to build an app?(as a web developer entrepreneur)
You(Web dev entrepreneur): Hey Kyle, remember last time you mentioned I should avoid building an app unless absolutely necessary? Well, so I've just tested some mvp only using web and gained some insights, but users keep asking for mobile apps. I'm thinking about finally taking the plunge, but I'm stuck on which tech stack to use. Any thoughts?
Kyle: Great. Let's talk about your options for app development. Here's the TL;DR upfront – I'd recommend three options, in order of preference: Next2app > Capacitor > RN+WebView. Let me break down why.
next2app
First up, next2app. I'm recommending this first because it's specifically designed with web developers in mind. Actually, this is the framework that I built because I kept running into roadblocks while developing apps myself. As a web dev turned founder, I tried pretty much everything out there to build apps fast, but kept hitting the same wall – processes that just don't make sense to web developers. Look, we can pick up new languages and frameworks pretty quickly, right? The real headache comes from the completely different conceptual concepts that I had to know due to the nature of the apps.
For example, take running a dev server – on web, you just fire up npm run dev and you're good to go. Not so simple with apps. You've got to check if native functions are added, figure out if you need to build... it's a whole thing. And don't even get me started on building. Web? npm run build and you're done. Apps? You're dealing with provisioning profiles, certificates, App Signing keys... It's a massive time sink just wrapping your head around concepts that don't exist in web development.
That's exactly why I built next2app – to make app development feel as familiar as web dev. If you want to skip the painful learning curve I went through, and you're using Next.js, next2app is your best bet. (Quick note: it's Next.js only, so check out the other options if you're using a different framework.)
Capacitor
Second choice: Capacitor. It's a framework that generates Android and iOS native code webviews automatically. Super straightforward, comes with basic app libraries out of the box, and has been around long enough to be stable. I put this above RN because there's less to learn. For a startup where speed is crucial, I think Capacitor can be a better choice than other, since it will take less time to learn.
BUT – and this is a big but – if you need lots of custom native functionality, you might want to jump straight to React Native. Capacitor can be a pain when it comes to custom features, and its library ecosystem isn't great – lots of abandoned packages. Custom native functions in Capacitor mean writing separate iOS and Android code, which is... not fun. So if you need custom app code (like payment modules or third-party services), think twice. With RN, you can usually write once for both platforms, which is way more manageable and faster.
React Native + Web View
Finally, RN+WebView. This isn't as common, but I've had good results with it. Basically, you use React Native to build a shell app that's mostly WebViews, then load your React app inside(via URL). It gives you tons of flexibility with ok performance. Plus, you can build a container app(webview app) for iOS, Android all at once with RN code. The massive RN library ecosystem is another big plus.
The downside? Steeper learning curve. Not many tutorials out there, debugging can be tricky, and you need to get comfortable with both RN and Expo(a lot to learn, I know). It might be overkill for simple apps, but the flexibility, RN ecosystem makes it worth considering.
You(Web dev entrepreneur): Thanks Kyle, but my brain's fried. Can I get an even simpler TLDR? Just tell me what to pick!
Kyle: Haha, fair enough. Just go with next2app. I built it specifically for web devs like us. It's open source and free – so there's really no reason not to use it.
You(Web dev entrepreneur): lol thanks... But since this is my first time building an app, could you walk me through the whole development process?
Kyle: Okay, we'll cover that next time.