18 ms·
Show HN: Red Goose – Convert your website to mobile app
Hi HN! I am Marvin Danig, a developer from Washington DC, and I am building Red Goose (https://goose.red https://goose.red). Red Goose is a web app to mobile app conversion engine that produces ready-to-publish apps for the app stores using GitHub repos.
There was a discussion on HN a few weeks ago about how a developer shaved off almost half of their native app's code without losing functionality [1]. Our launch today is a direct outcome of that thread and, moreso, in the context of this comment [2] and this one [3]. Paraphrasing the context below:
> "Fastmail is the only email/calendar app with a reasonable size (just 20MB)."
Followed by:
> "… EDIT: just realized the app is a web view. Sigh."
As someone who has been into mobile app development since 2010, the comments above read like a punch to the gut. We grew up believing that the native experience was better than the web!
It took a while to admit, but the web, it appears, has genuinely caught on. It has matured to a point where the four pillars of web development—HTML, CSS, JavaScript, and WebAssembly—are likely enough for universal distribution.
We already host compute-heavy environments for graphic designers [4], video editors [5], and rich document editing [6] on the web. And there is still more capability [7] in the works, if you will.
So the question we asked ourselves was: Could the modern web become the "native stack" of mobile app development?
With Red Goose, we want developers to be able to do just that. Create web applications that double up as mobile apps for the app stores. But this isn't always easy. Historically, native mobile apps have differed from (outdone?) the mobile web in three broad ways:
An app-specific design language,
Smooth and fancy screen transitions and,
Solving compute-heavy processes that scaled to millions of users.
However, at the same time, building and maintaining native mobile apps is super expensive, and it requires hiring separate teams of experienced developers whose sole job is to focus on mobile APIs.
Even with the newest alternatives like React Native, Flutter, Cordova, Xamarin, Ionic, or any other similar framework, there is a quantum increase in the amount of boilerplate code. Over time, as many of us have experienced in the industry, the web and native teams grow distant, leading to a less than optimum situation and bloat.
Red Goose puts the webview back in the ring. This step alone removes all the duplicated code from the equation. Red Goose then offers an alternate strategy [8], using the webview as the main leverage over your web app. And solve for native experience in the following three ways:
First—Intrinsic Design: we have built a new css framework called Toucaan [9] to tackle the gaps between mobile app design and mobile web. It allows the development of "app-like" interfaces using new css standards and the intrinsic qualities of the medium.
Second—Screen Transitions and Animations: Not all apps need this, but smooth transitions and performant animations are already possible with the new web APIs. With a strongly cached webpage using a service worker (PWA) and a better understanding of initial containing blocks (ICBs) pertaining to your front end, one can easily take steps to take the experience to the next level.
Third—Webassembly: The best thing about webassembly is that the wasm functions return immediately and synchronously. So one can easily offload compute-heavy transactions to a locally installed wasm utility and benefit from performance gains instantly on both web and mobile apps.
It appears that many apps wouldn't need to sprinkle webassembly into the mix to reach the level of performance expected of mobile apps, and just caching with a service worker and an app-like layout would do the trick.
Red Goose itself uses vanilla javascript and an experimental version of Toucaan for its frontend. Its backend is made with Node.js, Express, and MongoDB and is hosted on AWS within Docker. Our web-to-mobile app conversion pipeline uses NodeGit for app delivery, and the freshly minted mobile apps are written in Swift or Kotlin and shared directly over GitHub.
We believe that the opportunity to reduce app development and distribution cost using the newfangled powers of the web is massive—we've already helped a few teams to cut back on their expenses by as much as 80%.
At the same time, we're still early and would love to hear what you think about what we're building with Red Goose. We look forward to your comments and experiences, especially if you have been on this path before on your own. Thanks!
Relevant links:
HN Discussion:
[1] https://news.ycombinator.com/item?id=30442529 https://news.ycombinator.com/item?id=30442529
[2] https://news.ycombinator.com/item?id=30443310 https://news.ycombinator.com/item?id=30443310
[3] https://news.ycombinator.com/item?id=30444202 https://news.ycombinator.com/item?id=30444202
Leading web examples:
[4] https://www.figma.com/blog/webassembly-cut-figmas-load-time-by-3x/ https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
[5] https://web.dev/clipchamp/ https://web.dev/clipchamp/
[6] https://workspaceupdates.googleblog.com/2021/05/Google-Docs-Canvas-Based-Rendering-Update.html https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
[7] https://developer.chrome.com/blog/fugu-status/ https://developer.chrome.com/blog/fugu-status/
Tooling:
[8] https://www.toucaan.com/blog/mobile-apps-with-red-goose https://www.toucaan.com/blog/mobile-apps-with-red-goose
[9] https://toucaan.com https://toucaan.com
The end.
- gukov 4y agoThis wouldn't get past the app store review stage, would it (no webview apps)?
- g105b 4y agoI'm really interested in using this. Two questions: 1. Can I extend the functionality of my web app using native code where necessary (adding background GPS geofences, etc) 2. Do I have access to the real modern web stack in the compiled app? For example, does my iOS build support offline caching via my web app's service worker? Thanks!
- marvindanig 4y ago1. Can I extend the functionality of my web app using native code where necessary (adding background GPS geofences, etc) There doesn't appear a reason as to why not? This should be doable. 2. Do I have access to the real modern web stack in the compiled app? Yes. The webview Red Goose provides is basically the thinnest it could be. All your users get to see on the front end is your choice of web stack. 3. Does my iOS build support offline caching via my web app's service worker? Yes, it does! [1] Haha! And that's the main reason why I believe there is little value in coding up the whole business logic in native stack again. Although, I could be wrong here, and we are just starting to explore this vertical with the enormous power of PWAs. [1] https://www.toucaan.com/blog/mobile-apps-with-red-goose https://www.toucaan.com/blog/mobile-apps-with-red-goose
- aabajian 4y agoI put my website in and all it says is, " Is that site live yet?"
- satie 4y agoSorry to hear that. Please send me your website’s address on s@goose.red and I will take a look at what’s happening.
- bambax 4y agoSounds interesting. Two questions: 1. Is a new CSS framework really necessary? Smooth transitions have existed for a long time, it's unclear to me what is meant by "new css standards" and "take steps to take the experience to the next level". Corollary: can an existing webapp use Red Goose right away or does it need to be recoded? 2. There's this rumor that Apple fights webapps disguised as native apps with fury; yet Cordova & Ionic exist and prosper; what's true and what isn't, and what's your take on this? Is a Red Goose app at risk of being jacked from the appstore down the road for the sole reason that it's a web view?