Basically, yes, wrap it in a WebView. I'd need to see your mobile website to judge it better, but if it looks like a website, Apple might reject it. Your website really needs to look like an app to have some certainty of getting it through if your app only consists of a WebView.

At webtoapp.design we usually include some native components in the apps. Although they might not add functionality (just replaces some website components), they help get the app published.

I guess you'll have to decide based on your hourly rate whether it's worth it to tinker with some self-built solution or if you are also open to going with a finished product. I don't want this to sound too much like an ad, just expanding on the time save (because often you don't think about all the things in advance): - If your client decides he wants push notifications: A finished solution should already have support for that - For Apple, you'll also need to set up your Xcode developer environment and manage all the certificates and provisioning profiles (personally, I found that complicated when I started out). With webtoapp.design we handle all of that automatically (we upload a finished build to your developer account) - not sure if some competitors do that too.

It can be very frustrating, since I help my customers through the entire app creation and publishing process, so that includes dealing with Google and Apple.

I keep working on it because it's growing slowly but steadily and it provides me a lot of flexibility. I don't know which marketing channels to focus on to speed up growth though, at the moment it's pretty much all SEO.

This will make it nearly impossible to get an app published as a small business, since who the hell has 20 users just waiting for your app? It's already a huge struggle to help people with publishing their app.

The road to hell is truly paved with good intentions. All the scam apps will have no problem cheating this system, but honest devs will struggle. I can only hope Google reconsiders this requirement, otherwise it might be worth it to push my users more towards alternative app stores. We already support the Amazon App Store and the Huawei App Gallery (which are a lot easier to publish apps in), but the user base is just not there unfortunately.

Either way, the article seems mostly fine to me.

It happens quite often that I need to wait for something which doesn't have a builtin alert.

Currently I'm for example using it to get an alert when a flutter package has been updated on pub.dev

After 0 days: New Android version comes out After 1 year: App Updates need to target the latest Android version After 2 years: Apps can't be downloaded on devices with the "new" Android version anymore unless they target the "new" Android version

So normally there should be plebty of time to prepare. However, if you're an indie developer or not actively maintaining the app, then it definitely is annoying, since usually the apps would work perfectly fine on the new Android version without updating the targetSdk version.