Setting Up a Mobile Project with Capacitor


Capacitor is an open source project that runs modern Web Apps natively on iOS, Android, Electron, and Web while providing a powerful and easy-to-use interface for accessing native SDKs and native APIs on each platform. As an alternative to Cordova, Capacitor delivers the same cross-platform benefits, but with a more modern approach to app development, taking advantage of the latest Web APIs and native platform capabilities.

It might be helpful to think of Capacitor as a powerful new browser for modern Web Apps that unlocks the full native functionality of each platform through consistent cross-platform APIs. Using Capacitor, developers can build one app and target one set of APIs regardless of the platform the app is running on, as opposed to managing multiple APIs for each target platform.

This means that, for example, accessing the Camera uses the same code on iOS/Android as it does on Electron and on the web. This makes it easy to build one web app that runs natively on mobile, desktop, and the web.

At the end of the day, Capacitor apps are native apps. They can incorporate native UI controls and access any native SDK or API available on the platform. But unlike more traditional native apps, Capacitor apps will likely have the bulk of the app running in an embedded WebView control that unlocks desired cross-platform benefits and efficiencies.

Learn more at:

Mobile Project Setup

Wappler makes it easy to build mobile apps using Capacitor, with just a few clicks. The first thing we need to do is to create a mobile project, based on Capacitor.

Click the new project button:

Select Mobile and select one of the available frameworks - Bootstrap or Framework 7. For this example we select Framework 7:

Add a name for your mobile project and select a folder for it:

Then make sure to select Capacitor in the Runtime dropdown:

Click Save:

Your project has been created. A system check prompt will appear, click Yes in order to perform a system check:

The required components will be installed. You can check the progress in the terminal at the bottom of the screen. A success notification will appear once the required components are installed:

Adding a Mobile Platform

After the project is set up, we can install the mobile platform(s) which we want to use - Android and iOS. For building iOS apps, you need a mac computer with xCode installed. For Android apps you need Android Studio installed.

Open the Platforms menu:

And select the Platform you need:

A platform installation and a system check prompts will appear - click yes in both dialogs to install the selected platform in your project:

You can check the progress in the bottom panel. A success message will appear when all the required components are installed and the platform is added to your project:

Android Requirements

As of 20 Jan, 2022 Capacitor does not support the Android SDK 32, which is installed by default with Android Studio.

Android SDK 31

You need to do is to install Android SDK 31.
Open Android Studio and select More Actions:

Open the SDK Manager:

Select Android SDK 31 (Android 12) and click OK:

Confirm the download of the required components:

Agree with the License Terms and click Next:

You can see the progress of the installer:

Once it’s finished, click the Finish button and you are done. Android SDK 31 is now installed.

Android Emulator Setup

Now as we have Android SDK 31 installed, we need to setup an emulator using it.
Open Android Studio and click More Actions, then select AVD Manager:

Click the Create Virtual Device button:

Select a device from the list, we select Pixel XL and then click Next:

Click the download button for the SDK 31 (Android 12):

Follow the installation process. Click Next, when the emulator finishes downloading and installing:

Then Click Finish:

Android SDK Command Line Tools

The last thing you need is to install the Android SDK Command Line Tools.

Open the SDK Manager:

Select SDK Tools and check the Android SDK Command Line Tools. Click OK:

Confirm the download:

And follow the installation process. Click Finish when it’s done:

You have everything you need to add Android and use an Android Emulator in your project now.

Running Apps in Emulator

You can easily run your apps in the selected platform’s emulators. Open the emulator dropdown and select an emulator:

Then click the Run In Emulator button:

And you can see the results in the emulator:


Is this leading to one project having the Server Connect API, web and mobile elements all in one rather than having to build separate web and mobile/desktop projects? (obviously the API for mobile/desktop would only work if published to web)

This is just the native runtime integration of Capacitor instead of Cordova and and much better cooperation with the native tools like XCode for iOS and Android Studio for Android apps.

You still have to have a separate Wappler project for the server side API indeed. We are looking for ways to improve that integration as well.

It would be utterly incredible if you could click a publish to capacitor IOS button, or capacitor Android from a web project to update Server Connect links to absolute URLs and produce the necessary IOS/Android files.


Actually we will be improving more the Server Connect integration by using a global App Connect variable instead of hard coded url, so you can switch the development targets as you wish and the correct url will be used. Something that @mebeingken suggested a while ago.

We just need a way to manage such App Connect Global variables, appoint external API projects and have them running as well specially for development, probably in a separate main Wappler window so you can have one Wappler window for the mobile app and one for the server side API project.


This is necessary as Android nor IOS has any capacity to execute PHP. It has to be a secondary Project hosted accordingly and can not reside within the mobile application itself.

I think it would be great if within the Mobile Project you could pick the data API for the Project, ie, a simple select Project button would suffice (for now). As someone who has built multiple Mobile applications this would save on selecting from the drop down to pick the Project and then the Server Connect Actions. Could then just have the data Project set and instantly select from the Server Connect Actions within the data Project.

1 Like

AND! May I just say, to all the Team. THANK YOU for the mobile love!!

Really gentleman, amazing implementation! Will open up building mobile applications to all (a lot suffered trying to set-up the environment), this integration makes it so much easier for those Users!


1 Like

I think I would qualify as one of those users. I only have one mobile app (iOS and Android). This is no doubt a big update. But in dummy speak, should I update my app and what exactly will this allow me to do that I couldn’t do before. Will this lead to more Wappler integration using Plugins? (push notifications specifically)

Great to see mobile get some love. I’d love to dive more into it but really all you can build without being a scientist is a mobile version of a web app. Can’t make use of any actual mobile capabilities … yet.

Thanks again for such a huge update! :beers:


Does Capacitor enable to build full fledged PWAs as well?

You could do this with Cordova and plugins but nothing is straight out of the box it all takes configuration.

Yep, so I guess my question is, will updating to Capacitor make this easier to do (in Wappler eventually). I have looked over the docs for the push notifications plugin for Capacitor and you pretty much have to be a scientist to figure it out.

Ya, I still use dynamic URL’s for everything in a mobile project using a base url to control domain and then an api path to control versioning. Works great, but tighter integration would be fantastic.

Thanks for the mobile update!


Capacitor is most correctly considered an alternative to Cordova. These technologies are used to wrap your web resources (html, css, js) in a native shell, to install the application on android, ios or windows. This is not required to create a PWA.

For PWA, you only need to create Service Workers and use the advanced Browser API. Are looking forward to the implementation of Workbox from the Wappler team for advanced work with Service Workers. This will not only allow you to quickly create a PWA in a Wappler, but will also greatly improve the performance of your web applications that work with a large amount of data.

In fact, the introduction of advanced Service Workers management in the Wappler will give a huge leap in development and will solve one of the most unpleasant problems of ordinary web applications - with a large amount of data in the request, the user interface is frozen. Because of this problem, websites seem to be slow, and Cordova/Capacitor-based applications are very inferior to native mobile applications and applications created on the basis of Flutter. Service Workers can solve this problem and make web applications as efficient and fast as native ones.


I would love to see a Workbox integration in wappler too.

I am trying to follow the instructions here on a M1 Mac and getting the following error.

Has anybody come across this before?

While I agree with almost everything in your post, I completely disagree with you on this.
I am working within hybrid app development for years now in very large environments / with bigger installation bases, and performance was never ever an issue. Ionic’s UI Framework, for example, runs at 60 FPS and comes with a Lighthouse Score of 100% OOB.



The same happens to me

For some reason, you took my words out of context, which is why they are not perceived correctly. The context was as follows:

If your application uses complex queries with a large amount of data or server computing, without using service workers, applications based on Capacitor/Cardova will greatly lose performance to native and Flutter-based applications, since they will use additional threads (kotlin/swift) or isolates (flutter) to process complex queries./calculations. This frees up the main thread, which is responsible for rendering the interface.

If you do not agree with my thesis and think that applications based on Capacitor/Cardova will always work on a par with native/flutter applications, even if you do not use the workers service, I would be extremely grateful if you would show an example. It would be extremely interesting for me to get acquainted with a solution in which, for example, a request is made to a database, the total processing time of which takes 20-30 seconds, and the received data takes 10-20 megabytes. Or complex calculations on the client side. My experience in such cases is unambiguous - if you do not shift the calculation data / queries to another thread, but basically perform it will kill the performance of the interface and the user will face a freeze. If you have another practice, I will be grateful to get acquainted with it.

Well described! This would be a complete Integrated Suite for Mobile applications.

While still playing around with Wappler, it actually works quite good with two projects, one for data/api/backend/platform (you name it) and one for the frontend (app).

I personally would keep doing it with two (or three) different project, just for the sake of maintenance,versioning and building - they all have different life cycles.


1 Like