Frequently asked questions

An app with five to ten screens and a straightforward data model is usually ready to submit within two to three weeks at a comfortable pace. Building it in the visual editor takes a few days; the rest goes into content, testing on real devices and store review. Apps with multiple user roles, payments or external integrations typically land at four to six weeks.

No. You assemble screens in a visual editor: pick components, bind them to your data collections and define what happens on each action, without writing code. The skill you need is structuring information, not mobile programming. If you do have a developer, they can extend the app through the REST API and webhooks.

The platform is built for business apps: bookings and appointments for customers, internal apps with forms and approvals, loyalty and community apps, service catalogues, and field apps for mobile teams. They all rest on the same building blocks — screens, data collections, forms, user roles and notifications. It is not meant for games or for apps that need exotic hardware access.

One project produces both: a native app for iOS and Android, and an installable PWA that runs from the browser. The native build goes to the App Store and Google Play and can use push notifications, the camera and offline data. The PWA is shared as a plain link with no store review — handy for internal teams or for a fast pilot.

Choose native when you want a presence in the App Store and Google Play, push notifications on iOS, and a real home-screen app. Choose a PWA when you want to launch the same day, distribute internally, or avoid review cycles altogether. You can start with the PWA and publish the native build later from the same project, without rebuilding any screen.

You start from screen templates grouped by app type and adapt them: colours, typography, icons, navigation structure and the fields of every form. An empty project is available too if your flow is already well defined. Templates stay fully editable, so the starting structure never locks you in.

Yes. Data collections can be filled by importing CSV files or spreadsheets, or synced through an external API when the information lives in another system. Every collection uses typed fields — text, number, date, image, reference — so screens know how to render the content. Imports can be repeated at any time without rebuilding the app.

The platform produces signed iOS and Android builds and prepares everything the stores ask for: icons, screenshots, description, privacy policy and content rating. Submission is driven step by step from your panel. Google Play usually answers within one to three days, Apple within one to seven days on a first submission.

Yes, and that is the recommended setup: the app is listed under your own company identity and you stay the owner of the listing. An Apple Developer account costs 99 USD per year and a Google Play Console account has a one-time 25 USD fee, both paid directly to Apple and Google, outside your 4myapp subscription. We walk you through creating the accounts and handling signing certificates.

We keep the app runtime and the native libraries current with Apple and Google releases, including when the stores raise the minimum SDK level. For you that means a new build and a resubmission — no development cost and no screens to redo. Published apps therefore keep working on new devices and recent OS versions.

Rejections are common on a first submission and are almost always resolved within days. The usual causes are thin content, a permission requested without explanation, a missing privacy policy, or no test account for the reviewer. You get the exact message from Apple or Google along with what to change, and you resubmit from the same panel.

You edit the screens, generate a new build and submit it from the panel; the previous version stays live until the new one clears review. Content and data changes, however, reach installed apps immediately, with no new version at all. In practice you only go back to the stores when the structure of the app changes, not every time you fix a sentence.

Yes. Push notifications can be sent manually, scheduled, or triggered automatically by an event in the app — a confirmed booking, a status change, a reminder the day before an appointment. Recipients can be segmented by role, city or recent activity so you are not broadcasting to everyone. On iOS and recent Android versions the user must opt in first, so when you ask matters.

The app supports email and password, a one-time code by email, or Apple and Google sign-in — note that Apple requires "Sign in with Apple" whenever you offer social login. Each user carries a role, and the role decides which screens they see and what data they may change. You can also keep public screens that need no account at all.

Yes. The app can read and write data over a REST API and can fire webhooks to other systems when something happens inside it. There are direct connectors to the other services in the 4b2b ecosystem, and a generic API or an automation service covers the rest. Integrations are configured from the panel, not in code.

Yes. The app can take card payments for services delivered outside the app and can manage recurring subscriptions for access to content. Mind the store rules: for digital content consumed inside the app, Apple and Google require their own in-app purchase systems and take their commission. We help you pick the right model while the app is still being built.

The native app keeps the last loaded data on the device, so screens the user already visited still render with no signal. Actions that change data — a submitted form, a booking — sync as soon as the connection returns. For field teams this can be extended to any collection you explicitly mark for offline use.

The app and the data are yours. The App Store and Google Play listings live on your own developer accounts, and everything entered into your collections remains your company property. 4myapp processes that data as a processor under GDPR and can export your collections as CSV or through the API at any time.

On cancellation we stop producing new builds and stop the services that feed the app with data, so installed copies no longer show fresh content. The store listing stays on your developer account and you can remove it whenever you want. Your data stays available for export for an announced period before deletion, so export it before you cancel.

The cost is a monthly or yearly subscription depending on the plan you choose; the full grid is on the pricing page. The subscription covers the visual editor, data hosting, iOS and Android builds and an allowance of push notifications. The only fees outside it are the developer accounts, paid directly to Apple and Google.

Support runs through the channel in your account panel, with hands-on help for the first build and the first store submission, where most projects get stuck. The documentation covers screens, data collections, notifications and publishing. Apps with complex integrations get dedicated assistance, included in the higher plans.

Yes. You can run several projects from one account and hand each one over to the client together with editor access, while keeping your administrator role. Publishing happens on the client's own developer accounts, which avoids ownership disputes later on. Agency arrangements are discussed through the contact page.