from Hacker News

Show HN: Red Goose – Convert your website to mobile app

by marvindanig on 9/30/22, 10:28 AM with 85 comments

Hi HN! I am Marvin Danig, a developer from Washington DC, and I am 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.

  • by StuckDuck on 9/30/22, 12:12 PM

    > 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 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.

  • by scottydelta on 9/30/22, 12:47 PM

    By default, webview in iOS doesn't persist the user session(android does). Does generating the app via Red Goose solves this problem?

    Currently when developing webView for iOS, you need to store the session before app is closed and reload it the next time so that user doesn't have to log in again.

  • by bambax on 9/30/22, 11:48 AM

    Sounds 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?

  • by WA on 9/30/22, 3:47 PM

    What is the difference between your product and Capacitor as a WebView wrapper (which supports most PhoneGap plugins) plus Ionic as a UI framework?

    I’m trying to be positive here, but your post sends off an incredible odd vibe. You drop names of successful web companies and make it sound like you just invented "mobile apps based on WebViews", which is a thing since, well forever.

    Also, you claim Ionic comes with a lot of boilerplate, which is simply not true. Ionic 6 is web-components only with zero overhead. You can use them in vanilla JS no problem.

    I don’t see what this brings to the table.

  • by pwillia7 on 9/30/22, 1:04 PM

    Your tools sound like a really good base for a PWA framework too -- have you considered that? I know there are 1 zillion web/ecomm agencies of all sizes that know they need to push into PWA/headless in the next ~5 years and only those with strong tech chops can really do that well and without risk today.

    I can see a really strong prop at replatform to say hey just build a PWA with this and for phase 2 click this button and it's in the app store. That plays nicely with all the composable stuff going on and the want to not have 20 systems that do 20 different, overlapping things.

    In ecommerce, there's a few people that have built headless/composable 'low-code' PWA offerings and I haven't really seen anything I think will win the lower end of the market as all that matures, but I'm confident SOMEONE will appear to mop that up in the near future.

  • by Meph504 on 9/30/22, 4:07 PM

    I'm sorry the pricing here is offputting to say the least, you think that pinch controls is worth an additional $400. and push notifications another $200 and your fastlane deployment $1000

    I think you are drastically over estimating your value add.

  • by memorable on 9/30/22, 2:40 PM

    The website UI is broken on mobile.

    https://postimg.cc/gn3X2K1W

  • by thrownaway561 on 9/30/22, 12:42 PM

    Good luck with it... I put in my site and it didn't give me a preview, but wanted me to pay the $189 anyways. I'm not going to pay for something I can see. Honestly... instead of a preview, you might want just want to pull up the rendered mobile app in a simulator from browserstack or something so the customer can actually interact with it. Having people pay for something only to ask for refunds later is going to kill your credit rating.

  • by boxed on 9/30/22, 11:54 AM

    You are missing a ton of screenshots to show what the result would be on mobile platforms.

  • by wazoox on 9/30/22, 3:55 PM

    On the https://goose.red/pricing page, it tells me that " Your app is expected to be ready by 04:05PM today." But it's 17:55 where I am, what does it means exactly? Is this server time? Will I get my app in 10 minutes, 70 minutes, tomorrow afternoon?

  • by rglover on 9/30/22, 3:38 PM

    Do you have any docs for how an app would talk to native/OS-level functionality? I saw push notifications mentioned in the order form...would that just use the web notifications API?

  • by manmal on 9/30/22, 6:05 PM

    I‘m surprised to see the claim that the App Store approval rate is high for this sort of app. From the review guidelines:

    > 4.2 Minimum Functionality

    > Your app should include features, content, and UI that elevate it beyond a repackaged website. If your app is not particularly useful, unique, or “app-like,” it doesn’t belong on the App Store. If your App doesn’t provide some sort of lasting entertainment value or adequate utility, it may not be accepted.

  • by scarface74 on 9/30/22, 12:44 PM

    Now you can have all of the fun of the clusterfuck of modern web development in app form!

    (Not criticizing your effort. Red Goose isn’t the problem.)

  • by wingerlang on 9/30/22, 2:03 PM

    This service does not seem like something that needs pressure tactics. Naming it "fomo" is a bit on the nose as well. And I assume they are all BS as well, unless google ordered one 1 hour ago (or was it 33 minutes ago? who knows... it's randomized).

    https://goose.red/fomo

  • by danpalmer on 9/30/22, 6:21 PM

    Do you have any example app repos?

    As an engineer, I'd probably want to see what the generated code looks like before paying. I'm also probably not the target market, but as someone who is regularly asked by non-engineers for tech advice about websites and apps, it would be great to be able to recommend with confidence.

  • by teddy85 on 9/30/22, 3:00 PM

    Website doesn't have any CSS on Android after 2 secs?

  • by numlock86 on 9/30/22, 12:08 PM

    Hug of death?

    Edit: Yes, application seems down/hugged. Getting 504 from their nginx.

  • by turnsout on 9/30/22, 2:10 PM

    Honest question, but what is the advantage of having your website as an app? Isn't it easier for people to just go to the mobile site if it's exactly the same?

  • by xigoi on 9/30/22, 12:37 PM

    What's the advantage of a webview app over a bookmark?

  • by g105b on 9/30/22, 11:07 PM

    I'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!

  • by AndrewVos on 9/30/22, 3:31 PM

    When I focus the text input on your website all your CSS disappears. Chrome on Android.

    Not even sure how that's possible.

  • by niblettc on 9/30/22, 1:09 PM

    Very interested in using this as a short term solution for launching on Android. Is there a way to see a preview of the app, interact with it, etc. before we pay? Want to verify everything works.

  • by hbcondo714 on 9/30/22, 5:09 PM

    This reminds me of manifold.js from a few years ago:

    https://news.ycombinator.com/item?id=9487941

  • by andybak on 9/30/22, 1:50 PM

    Completely broken for me in Firefox. Tried disabling uBlock.

  • by gukov on 9/30/22, 7:20 PM

    This wouldn't get past the app store review stage, would it (no webview apps)?

  • by aabajian on 9/30/22, 11:40 AM

    I put my website in and all it says is, " Is that site live yet?"

  • by z3t4 on 9/30/22, 5:58 PM

    Nothing seem to happen when I click "preview my app!"

  • by masukomi on 9/30/22, 4:11 PM

    obligatory PWA comment:

    Progressive Web Apps bypass the need for tools like this BUT Apple's support of PWAs has been suboptimal (hobbling). Of course, you can't get a PWA on the app store (or Google Play store?), but you can get it on your home screen.

    If your site is fairly simple and you just don't want to deal with the app store, a PWA may be a decent solution for you. They're not hard to make.