Launching a web app also as mobile app?
Thomas Schranz ⛄️
Let's say you have a web app that is close to its initial launch. How are you thinking about whether to release it just as web app or whether to also release it in an app store? Especially interested in concrete recent examples. So if you have recently launched and had to make this decision: can you walk us through your thoughts and how you decided? (bonus points for linking to your app so we have the context)
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.
@mittermayr does the iOS AppStore also list PWAs or are they basically saying "sorry, not for the AppStore unless you add functionality"?
@__tosh I don't think they offer true PWAs in their listings (pretty sure they don't). But I've got two apps on the store that are essentially PWAs but encapsulated in a native wrapper (Cordova and Ionic). For both apps I've received a rejection on reviews (when submitting an update or first listing) that this could well be a PWA and not for the app store unless I am willing to add iPhone-specific features (that showcase the iPhone) and resubmit. I've gotten around this with arguing. You can read more about it here: https://love2dev.com/blog/apple-...
@mittermayr ty for the pointer!
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.
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.
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 🤫
(@simonmulser @molzer ty for sharing this!
@molzer @__tosh thanks for replying Georg. Just want to add: If you want to accept payments (especially if you want to offer subscriptions) budget time to integrate with App Store, Play Store and your web merchant of record. It's some work and there is a reason why companies are exactly solving this for their customers (Revenue Cat: https://www.producthunt.com/post..., Purchasely: https://www.producthunt.com/post..., ...).