Skip to content

Update Your Mobile App

Most updates ship instantly when you publish. Only metadata or native shell changes need a new app store submission.

If you’ve wrapped your Proyecta app as a PWA and submitted it to an app store, updates work in two tiers depending on what you’re changing.

Tier 1: Content and functionality updates (instant)

Section titled “Tier 1: Content and functionality updates (instant)”

Because a wrapped PWA loads its actual content from your published Proyecta URL, most updates don’t require a new app store build:

  1. Make your changes in the Proyecta builder
  2. Click Publish in the builder toolbar
  3. Users see the changes the next time they open the app

Things in this tier:

  • New pages, features, layouts
  • Bug fixes
  • Copy and image changes
  • Backend logic changes
  • Database schema changes
  • Most styling tweaks

This is one of the biggest wins of the PWA-wrapper model — you’re not waiting on review queues for normal product work.

Tier 2: Native shell updates (new submission required)

Section titled “Tier 2: Native shell updates (new submission required)”

Some changes require regenerating the wrapper and submitting a new package:

  • App name as it appears under the icon
  • App icon itself
  • Splash screen
  • Manifest entries the wrapper bakes in (theme color, display mode, orientation lock)
  • Native permission declarations (camera, location, etc. that need new entries in Info.plist or AndroidManifest.xml)
  • Wrapper version bumps

For these:

  1. Regenerate the package at pwabuilder.com with your published URL
  2. Sign with the same signing key you used before (critical — see below)
  3. Submit through Google Play Console, App Store Connect, or Partner Center
  4. Wait for review

The single most important thing about updating an Android app: you must sign every update with the same key you signed the first version with. If you lose signing.keystore, Google Play won’t accept any further updates. You’d have to publish a brand-new app under a different package name and migrate users.

The same applies to iOS provisioning profiles. Back them up the moment you generate them.

Keep your app’s user-facing version number in sync with your Proyecta deploys when you do submit a new package. Otherwise users can’t tell whether their crash report is on the new build or an older one.

  • Update wizard in the builder that handles regeneration, signing, and submission for you
  • Version manifest tracking synced with Proyecta version history