Launching a web app also as mobile app?

The AppStore drives a lot of unexpected traffic! I have done zero marketing on the App Store but always received quite a bit of sign-ups through it, so if the hurdle of getting through approval (which can take a lot of time) isn't too much, it definitely makes sense to go through that. Only caveat is that Apple has been pushing people to rather release as PWA instead of AppStore if the reviewer notices (feels) that the app isn't using any unique features of the iPhone itself. I've seen that twice now, where the review was declined and essentially said: please release as web app (PWA) instead or try and incorporate some iPhone-specific features to release this on the AppStore. Mileage may vary.

Great topic! For Outdone’s V1 launch (www.outdone.io), we felt strictly launching as a web app made the most sense. To us, a web app seemed like a much more efficient way to test the gift recommendation value prop with users. We didn’t think we’d be able to get users to download an app before our engine’s effectiveness was proven in their mind. That said, one thing we found to be pretty interesting is that countless people we described the business to just automatically assumed that we built a downloadable app. It seems like most people naturally assume consumer-facing tech launches happen in the form of App Store apps.

AppStore SEO is almost negligible - but that probably depends on domain / keywords. The real download numbers come from category charts or Apple picks. So if you launch within AppStore be sure that you're app meets certain quality standards. Also if you're low quality you'll accumulate 1-star ratings. These will never go away. I would only consider if you can strongly leverage push notifications for engagement or if you have a forgiving community of power users who crave for an inferior web tech based mobile app.

We started out with WebApp only but wanted to include a few features that required a native mobile app over time. (A QuickScan feature to easily scan documents to a patient record and TouchID/FaceID to make it easier to securely log in to your account). We looked into building the entire mobile experience from scratch, but as a tiny team, it was just not feasible at the time. We now follow a basecamp-like approach and added the features mentioned above natively, while offering the rest of the app in a web-wrapper. It somewhat works but is nowhere near as polished as I would like it to be. 😐 In hindsight, I wouldn't invest time and resources in a native app nowadays as you can achieve so much on the web already. Plus, it's a hassle to maintain, especially if you outsource the native implementation as we do. (bug fixes, tiny improvements,... everything takes forever) It was also meant as an experiment to see if we can create signups through that channel, but honestly, that did not work out so far. So long story short from my POV: Either invest in a proper native mobile implementation or stick with building a great (mobile) web experience for all devices.

Great question Thomas! Kickresume was a 100% web app for more than 7 years. We have more than 1.5M users worldwide. Last November we decided to launch Kickresume mobile resume app (Android & iOS). We feel mobile platforms are just different acquisition channels so we can simply get new users. We acquired more than 30K mobile users in the first 6 months without any marketing campaigns. So I think it works! On the other hand, there are also some drawbacks. In our case it was pricing. It's pretty difficult to have two different pricing structures for web and mobile because the mobile app is just 1/3 of the web app so it is cheaper. Our apps: https://www.kickresume.com/en/mo...

app.shadowmap.org started as a web app and we seriously just dropped the whole thing into a web view and submitted it to the App Store and … it got approved! We don't have a single native view (beside the IAP overlay). We do have some calls to native APIs (share sheet, geolocation etc. though. Pros: We get more visibility. Users have the app on their home screens (yeah too many people don't know how to add a PWA). We have another sales channel which drives up revenue. IAP checkout on iOS works super fast/smooth – less of a hurdle than Paddle on the web app. No browser chrome, Shadowmap looks just beautiful on iPads and iPhones! More map space = better UX. A single code base spanning >1 platform. We believe it pushes recurring usage. Cons: Syncing up iOS IAPs and Paddle web-app accounts was much more work to set up than anticipated (@simonmulser can tell you more 😜). I.e., a Web-App user can sign in on iOS and access their paid features and vice versa. Some app changes require re-submission of the native container – might lead to inconsistencies between native versions (e.g., iOS users didn't upgrade yet, etc.). Decision process towards it: Many users reached out to us and demanded it. Some even said that "the app doesn't really exist unless it's in the store". While this is a little dramatic, it has its truth. Also, it was a personal "dream" to have Shadowmap in the store. I completely underestimated the effort to get it there and thought: Let's just do it. It turned out to be more complicated but … I'd still do it. Get Shadowmap in the App Store here: https://apps.apple.com/us/app/sh... Android coming soon 🤫

No such experiences, so pure guts. I would make a decision based on how much resource + experiences that my team had. If we could only work on web launch really well, and if launching the app could turn our web launch from excellent to good, then I would simply just focus on web. If my team are strong enough to handle both, and probably both could mutually benefit from each other (traffic, recommendations, social, etc.), then... So, decide from inside. :-)

Depends on the app. Do you think the time put into developing it for mobile is worth it.

I'm thinking of wrapping my web application to mobile application using basecamp approach.