Improvements for WebApp published by AppGyver


It has been more than a year since I started using AppGyver, and I could say the app I created is 50:50 between native app and WebApp

WebApp will always have the advantage of not having to install anything. Many people try to minimize the apps they install as much as they can, especially if they are not going to use it frequently. That’s where WebApp comes in handy for businesses

However, until now there are a few apparent weaknesses in the WebApp published using AppGyver that is making the experience of developing the WebApp not so much fun. The below case is for launching the app in our own web hosting / domain

  1. Default favicon is still AppGyver’s even though we have changed in the configuration

And we will have to manually unzip the file, change the favicon, and zip it back again before uploading into the cPanel. Honestly I really don’t understand this, what’s the point the configuration allows us to upload our favicon but at the end it won’t even be used?

  1. The website title will always be AppGyver by default

And again, we will have to unzip the file, open the index html, and edit there. Then go to the folder _next - static - chunks - pages, and change the JavaScript source file named _app-xxxxxxxxx, then find the “AppGyver” to our own website title

Why can’t the website title be by default our own app’s name? It should be very easy to be done right…

  1. The pages will always be named page.Page1, page.Page2, etc

Frankly speaking, it looks very unprofessional. This makes WebApp published using AppGyver is not suitable for use by the mass public. As you have already make it so that page names are not allowed to be similar, why don’t you just make the page names as the page ID instead of making it page.Page1, page.Page2 by default?

That’s all. Seriously, if all of this is solved, the developer experience of developing the WebApp will be much better. And I do think it shouldn’t even be that hard…

Thank you. I really hope you will consider this request

I have also submitted a tracker feature request here, for those who have similar opinion as mine, please upvote it:

I agree. They need to implement the dynamic links next package and allow the urls paths and segments to be configured based on page name and data resource url handle. This is a standard next feature, and should not be difficult.