Ionic capacitor some questions

I have some questions and I hope you can shed some light on all of those. Right now, I have a PWA written. No cordova or anything. Pure PWA with service worker, workbox and offline support.

Requirements:
a) I need to have a PWA website so that users can see my website via url.
b) I need my app to be on play store and app store.
c) I need the website and my apps to support push notifications.

Question 1) As you know, It’s possible to publish PWA on google play store and somehow app store(not sure yet). But if I do that, I won’t be able to have push notifications for IOS. so the only way if I want to provide push notifications for ios too is to use cordova or capacitor. Am I right?

Quesiton 2) If I use capacitor , then publishing PWA to playstore and appstore isn’t worth it because by using capacitor i already can publish them as almost native apps. Is that right? is this how you would do it?

Question 3) I tried to use capacitor for the first time today and here is the code I’ve written for push notifications.

import {
    Plugins
} from '@capacitor/core'
const { PushNotifications } = Plugins;
PushNotifications.register();
PushNotifications.addListener('registration', function(e){
    console.log("eee ", e);
})
PushNotifications.addListener('registrationError', function(e){
    console.log("err ", e);
});

the thing is, when building this through xcode after I use npx add ios and npx cap copy , I can see that push notifications work on ios now. The bad thing is that now, If I run this via my website url, let’s say chrome, it says that Uncaught (in promise) PushNotifications does not have web implementation.. So Now, I’m really stuck. Does this mean that I have use if else statements to first check what target user uses and if it’s web, I should use browser's PushAPI ? and if the target is ios or android , I’d use the above code. Because of the fact that I use service worker because my app is PWA, I can simply put push listener in service worker and now, I’d make push notifications for all platforms. Is this if else and checking platform and using PushAPI or capacitor's push notifications a great practice? or what other idea can you provide?

Question 4) It turns out that if I use capacitor i have to include @capacitor/core which will make the bundle size bigger for web. Now, the thing is if user goes to web version, My website size will be bigger, but the thing is size is bigger, but i don’t use capacitor's plugin at all. Is this unavoidable?

I’d really appreciate your sincere answers since there’s not many people who can help.

Hi @jordangio!
Welcome back to the comunity!
I suggest you to try FCM, Firebase Cloud Messaging in your push notifications.

How does firebase help me at all? It’s irrelevant mate.

  1. Yes
  2. Yes
  3. Yes
  4. No

Just going to answer question 4 since there are already answers for the rest.

The contents of capacitor/core do not really impact the over all size of your web app. Since most of the logic for each plugin on the web is just calling browser built in, the size is really negligible.

There are far more impactful things to worry about, like the kind of date formatting libraries you use, if you use lodash or not, etc etc.

TL;DR: cap/core is small. Nothing really to worry about.

  1. Any idea why service worker is undefined after running my code after capacitors’ npx cap add ios ? It doesn’t exist on navigator. So why?

  2. if the above question seems valid and it doesn’t exist and you don’t plan on bringing it, what should I do to support offline functionality and background sync? I should also use if else statements and if target is web , register service worker and continue using it as i had for my pwa and if target is ios/android, i should write new code which uses native plugins for that? No other workaround?

  1. Service worker is only available on websites deployed over https. So capacitor/cordova will not have service workers available. This is nothing to do with capacitor, it’s a browser specification.

  2. Really depends. You could do conditional logic to check if you’re on native ios/android.
    As for caching assets via http request, there’s some add-on libraries for Angular’s http service which will auto cache them (using localstorage/indexedDB).

The rest is up to you decide

Thanks Mike, so just to sum up:

  1. What happens for capacitor is that it wraps it into http connection so that’s why service worker is undefined . So at this stage , there’s nothing , nothing in the world that might make it work for me.

  2. So if user is on web, i’d use my current code, but if user is on ios/android , I’d have to do all those logic by myself. precaching assets, background sync and push notifications. Doesn’t capacitor have any plugin for that?

  3. i have read somewhere that service worker is still defined on android device after cordova wraps it. Am I mistaken?

  1. Correct
  2. Capacitor has plugins for push notifications, background sync is just handling request when the connect is spotty/not available. There are work-around you can do that are more client side
  3. on Android, it will be defined on the navigator object, but it will fail to register and basically be a noop.

Thanks for all the info. I got 2 questions and i think That will be all, mate.

  1. why does capacitor/cordova wrap it/intercept/change my https:// connections to http ? and if i make a request to https://api.com , does it mean capacitor is gonna make a request to http://api.com automatically? what if my api only allows https:// connections? then what?

  2. can you think of the best plugins for background sync and precache handling from capacitor?

  1. Capacitor serve all web assets through a local web server. It shouldn’t be modifying your requests directly. Meaning if you make a request to http://some.api, it will be done through https on the API side

  2. Again, background sync isn’t anything you really should worry about. It’s not about “handling things in the background”, it’s more todo with handling spotty connection. As for precaching, the browser/webview will provide a good experience here. Plus all the web assets that would need to be precached are local to the app. So nothing to worry about.