How the Capacitor app shells work, building them, submitting under your own developer accounts, the push groundwork, and the app-store review reality.
Loading the guide...
Help us make the guides more useful.
0 helpful · 0 not helpful
Seedly Communities ships with iOS and Android app shells so you can put your community in the App Store and on Google Play under your own name. This page is honest about what those shells are, what building and submitting them actually takes, and what stays your responsibility.
The mobile apps are Capacitor shells. A Capacitor shell is a thin native wrapper that loads your responsive web app inside a native container and gives it access to device features such as safe-area layout and push token registration.
Be clear-eyed about this. The shells are not a separate, hand-built native app with its own screens. They wrap the same responsive web experience your members already use in a browser, packaged so it can be installed from an app store and appear as an app with your icon and name. For a community platform this is the right trade - members get a real installable app on their home screen, and you get one codebase to maintain instead of three.
What you get, restated plainly.
ios/ and android/What it is not is a from-scratch native rewrite. If a reviewer or a member expects platform-native navigation gestures throughout, set that expectation up front.
The download includes the complete native projects, already wired to the app. Building the installable packages happens on your machine with the standard mobile toolchains.
ios/, set your bundle identifier and signing team, and build an archive for submission.android/, set your application id, and build a signed release bundle.Two things to do before your first build. First, change the placeholder bundle id in capacitor.config.ts to your own reverse-domain id and set your app name - a preflight check in the project refuses to build while the placeholder is still in place, on purpose, so a placeholder app can never reach a store. Second, run the sync commands from the setup documentation: a production build bundles the web app's static export directly into the shell, so the installed app carries your community's interface inside it rather than pointing at a URL.
One more honest note: a native in-call experience (CallKit style call handling) ships in the source as disabled reference scaffolding. Live video works through the wrapped web experience; wiring the native call path is an opt-in code change described in that package's README.
The apps go to the stores under your accounts, not Seedly's. That is part of owning the product.
Both stores need the usual listing assets from you - app name, description, screenshots at the required sizes, an icon, a privacy policy URL, and a support contact. Your community's own privacy and terms pages cover the policy requirement.
The groundwork for push ships; the sender does not. Here is exactly where the line sits.
If push matters to your community, wiring a sender against the stored tokens (APNs for iOS, FCM for Android) is buyer work - a well-scoped project for you or your coding agent, with the token storage and preference plumbing already in place. Until then, members are reached in-app and by email, which the notification system fully delivers. See the Features page.
Setting expectations, because this is where first-time publishers lose a week.
None of this is unusual - it is simply the cost of having your own app in the stores instead of renting a spot in someone else's. Plan for it and the first submission goes smoothly.