Docs
Mobile Apps for iOS and Android
How the Capacitor app shells work, building them, submitting under your own developer accounts, the push groundwork, and the app-store review reality.
Last updated
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.
What the App Shells Actually Are#
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.
- An installable app on iOS and Android with your icon, splash screen, and name
- Ready-to-open native projects - the iOS Xcode project and the Android Gradle project ship in the download, in
ios/andandroid/ - The full responsive web app running inside it, so every feature is present
- One codebase - a change to the web app is a change to the app
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.
Building the Apps#
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 requires a Mac with Xcode installed. You open the iOS project that ships in
ios/, set your bundle identifier and signing team, and build an archive for submission. - Android requires Android Studio and the Android SDK. You open the Android project that ships in
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.
Submitting Under Your Own Developer Accounts#
The apps go to the stores under your accounts, not Seedly's. That is part of owning the product.
- Apple - enroll in the Apple Developer Program (a paid annual membership) to get an App Store Connect account. You create the app listing, upload the build from Xcode, and submit for review.
- Google - register a Google Play Developer account (a one-time fee) to get access to the Play Console. You create the listing, upload the signed bundle, and submit.
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.
Push Notifications - the Honest Status#
The groundwork for push ships; the sender does not. Here is exactly where the line sits.
- What ships: the shells register device push tokens, the platform stores them per member and platform, and every notification type carries a per-member push preference toggle.
- What does not ship: a push sender. Nothing in the platform delivers to Apple's push service or Firebase Cloud Messaging, so no push notification arrives on a device out of the box.
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.
The App-Store Review Reality#
Setting expectations, because this is where first-time publishers lose a week.
- Review is real work and takes real time. Both stores review submissions by hand, and rejections on the first pass are common, especially on iOS. Budget days, not minutes.
- Apple scrutinizes wrapper apps. An app that is mostly a wrapped website can draw questions about whether it offers enough native value. A polished icon and splash and offline-friendly behavior help. Lead your listing with the community experience, not the fact that it is a web view.
- The accounts and the maintenance are yours. You hold the developer accounts, you respond to review feedback, and you resubmit when a store policy changes. Seedly ships the shell, and the store relationship is yours to run.
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.