[SIGN IN} PWAbuilderSettings.json to improve PWA workflow and consistency

[sanderkooger]

Tell us about your feature idea

Since I have been playing around with PWA builder, which I like very much, I keep running into something in my testing cycle that I really don't like. Every test, I have to type in all the platform specific settings again on store package generation. This invites for inconsistencies, and is a lot of extra work.

Do you have an implementation or a solution in mind?

If the PWA platform would be able to read a second JSON file with the settings we want to give PWA builder, this would greatly improve workflow and consistency.

PWAbuilder.json

  "microsoft": {
    "packageId": "ID",
    "publisherDisplayName": "Pubname",
    "publisherId": "pubid",
    "settings": {
      "appName": "App Name",
      "appVersion": "1.0.0",
      "classicAppVersion": "1.0.0",
      "iconUrl": "/path/to/iconx512.png",
      "language": ["EN/US", "FR/FR", "NL/NL"],
      "targetDevices": ["Desktop", "HoloLens"]
    }
  },
  "play": {
    "packageId": "ID",
    "appName": "App Name",
    "shortName": "Short name",
    "settings": {
      "appVersion": "1.0.0",
      "versionCode": 1,
      "host": "https://appdomain.com",
      "startUrl": "/",
      "themeColor": "colorValue",
      "backgroundColor": "colorValue",
      "navColor": "colorValue",
      "navDarkColor": "colorValue",
      "navdividerColor": "colorValue",
      "navDividerDarkColor": "colorValue",
      "iconUrl": "/path/to/iconx512.png",
      "maskableIconUrl": "/path/to/maskableIconx512.png",
      "monochromeIconUrl": "/path/to/monochromeIconx512.png",
      "splashScreenIcon": "Icon to use on splashscreen",
      "splashScreenDuration": 300,
      "fallbackBehaviour": "Custom Tabs",
      "displayMode": "StandAlone",
      "notificationDelegation": true,
      "locationDelegation": true,
      "googlePlayBiling": false,
      "settingsShortcut": true,
      "chromeOsOnly": false,
      "IncludeSourceCode": false,
      "signingKey": "new / prompt / none"
    }
  },
  "metaQuest": {
    "packageId": "ID",
    "appName": "App Name",
    "appVersion": "1.0.0",
    "appVersionCode": 1,
    "appManifestUrl": "/manifest.json",
    "signingKey": "new / prompt / none"
  },
  "ios": {
    "bundleId": "ext.domain",
    "appName":"App Name",
    "appUrl": "https://domain.ext",
    "settings" {
        "appIcon": "/path/to/appIcon.png",
        "splashScreenIcon":"Icon to use on splashscreen",
        "statusBarColor": "colorValue",
        "splashScreenColor": "colorValue",
        "progressBarColor": "colorValue",
        "permittedUrls": ["uri1","uri2"]
    }
  }
}

This way we can store all public data without having to retype it, it also gives us the option to experiment with more control and consistency.

Have you considered any alternatives?

I have thought about implementing this into a test script, that auto executes the commands for me in the browser and downloads the package. But this would not help others achieve the same.

[ghost]

Thanks for submitting a new feature request! I've automatically added a vote 👍 reaction to help get things started. Other community members can vote to help us prioritize this feature in the future.

[amrutha95]

This is a great suggestion @sanderkooger! Good news is that we are actively working on adding authentication and sign in to PWABuilder.com, which will enable us to save some of the user settings such as package info.

Did you have any ideas for how to implement this? Would love to hear more. We could consider also storing all these package options in local storage or indexedDB on the browser, but just curious if you already had some specific ideas.

[sanderkooger]

Hey @amrutha95,

Personally, I'm very much a single source of truth type of person, meaning if I make changes to my app code, I'd like this to be in the same place as my actual code. This way all changes are reflected in git and easy to check.

The only caveat is that storing secrets in a JSON file would be a bad practice, So maybe hybrid is the best option. This is why I added prompt in the signing key property.

This prompt could just as easily be a login prompt where after the data is fetched. I do not recommend using local storage because what happens with the data if we clear our caches. ;) We are devs, after all

[amrutha95]

Hey @sanderkooger , we have decided to add this feature as part of our sign in experience. Users who sign in will be able to store their package options so they won't need to enter them again.

[sanderkooger]

Hey @sanderkooger , we have decided to add this feature as part of our sign in experience. Users who sign in will be able to store their package options so they won't need to enter them again.

Thanks a bunch! And happy coding!