Docs
Mobile Apps for iOS and Android
How the Capacitor app shells work, building them, submitting under your own developer accounts, push setup, 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 a few device features such as push notifications and safe-area layout.
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 push notifications, 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
- Push notifications to members' devices
- 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 Capacitor configuration already wired to your app. Building the installable packages happens on your machine with the standard mobile toolchains.
- iOS requires a Mac with Xcode installed. You open the generated iOS project in Xcode, set your bundle identifier and signing team, and build an archive for submission.
- Android requires Android Studio and the Android SDK. You open the generated Android project, set your application id, and build a signed release bundle.
The setup documentation in your download walks the exact commands to sync the web build into the native projects. Point the shell at your production domain first (see Custom Domain and Branding) so the installed app loads your live community and not a local build.
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#
Push is the main reason to ship a native shell rather than tell members to bookmark the site. Wiring it up is a per-store setup you do once.
- iOS push runs through Apple's push service. You create a push key or certificate in your Apple Developer account and register it so the app can receive notifications.
- Android push runs through Firebase Cloud Messaging. You create a Firebase project, add the app, and drop its configuration into the Android project.
Once configured, the platform's notification system delivers to the device the same way it delivers in-app and email notifications - members choose per-type which notifications reach them, across in-app, email, and push. See the notification coverage on 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. Push notifications, 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.