Hi HN! We're Sonica, Marvin, and Satie, and we are building Red Goose (
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
[2] https://news.ycombinator.com/item?id=30443310
[3] https://news.ycombinator.com/item?id=30444202
Leading web examples:
[4] https://www.figma.com/blog/webassembly-cut-figmas-load-time-...
[5] https://web.dev/clipchamp/
[6] https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
[7] https://developer.chrome.com/blog/fugu-status/
Tooling:
[8] https://www.toucaan.com/blog/mobile-apps-with-red-goose
[9] https://toucaan.com
The end.
It is
With the transition to web apps, we have lost some excellent quality standards, integration, and availablity. 10 years ago you could have productively used your computer and software without ever needing to touch an internet connection. Nowadays it's either: - the browser is the portal to everything - apps are just slow, unresponsive, ugly looking WebViews
It's sad that the bar is so low these days that VSCode is considered acceptable. That takes 30 seconds to start up on my i5-8250U with MX150 graphics.
Notepad++ launches instantly on a 10 year old 32 bit computer with a *low end CPU.
Not criticizing your service btw, I'm sure it's well developed. I hate the general concept at the base tho.