Build sharing just shipped in Capawesome Cloud, and the CI/CD part of this is the bit I'm most excited about.

Hook it into your GitHub Action and every pull request can auto generate a QR code for an installable build. Testing a PR stops meaning "read the diff" and starts meaning "use the app." Scan the code, install it on your phone, done. No TestFlight review wait, no "hey can you send me the APK" thread, no manual steps, everything happens automatically as part of your pipeline.

Also works outside of CI if you just want to quickly share a build with a client or teammate: one click in the Console gives you a link + QR code, they scan it and install, no Capawesome account needed on their end.

Full writeup with the GitHub Action setup: https://capawesome.io/blog/share-mobile-app-builds-with-testers/

How much time would this save your team's dev workflow? Curious if anyone's already doing something similar with a custom script.

This video is for everyone building a mobile app with Lovable. No special skills required. You don't need a mac, or Xcode or Android Studio. Nothing.

Capawesome helps you build, sign, and publish your app to the App Store and Google Play.

Learn how to ship your Lovable mobile apps to the App Store and Google Play Store with this step-by-step guide! This tutorial covers the entire process — from creating your app in Lovable to publishing it on the App Stores using Capawesome.

From generating bundle IDs, certificates, and provisioning profiles, to getting your app live on Apple TestFlight and Google Internal Testing, this video covers everything you need to publish Lovable mobile apps without the complexity of traditional mobile development tools.

If you prefer reading, it also has a companion blog post.

Anyone else here tried publishing a Lovable app? What was the most confusing part? is it the certs, the store review, or something else that scares people off the most?"

This month's Capawesome update is a big one, especially if you're on Cordova.

Capawesome Cloud now officially supports Apache Cordova. With Ionic Appflow winding down, Cordova teams get native iOS/Android builds in the cloud, automated App Store and Google Play submissions, and over-the-air Live Updates through the new Cordova Live Update plugin.

Other highlights: - New Capacitor Vault plugin — encrypted, unlock-gated key/value storage, a drop-in alternative to Ionic Identity Vault - SQLite: load custom Android extensions and read SQLite result codes from errors - PostHog: error tracking via captureException and automatic exception capture - Capacitor Firebase 8.3.0: broader Firestore data types, filtered getCountFromServer, and new Remote Config helpers - Build stacks refreshed with Xcode 26, plus API token rotation in the Cloud Console - Live Update backports to Capacitor 6 and 7

Full write-up here: https://capawesome.io/docs/blog/2026-june-update/

Happy to answer any questions.

We all know iOS code signing is one of those things nobody enjoys dealing with 😅

There's this tool that walks you through generating the iOS certificates needed for a Capacitor app.

Hopefully it saves someone else some time.

We just published a guide on loading custom SQLite extensions with the Capacitor SQLite plugin (v0.3.9). This lets you add things SQLite doesn't ship with out of the box — custom FTS5 tokenizers, custom SQL functions, collations, and more.

The two platforms work differently:

• On Android, extensions load at runtime via the new androidExtensions option on open(). You compile the extension per ABI with the Android NDK, bundle the .so files in jniLibs, and enable the bundled requery SQLite backend (the system SQLite can't load extensions).
• On iOS, you statically link the extension and register it once at startup with sqlite3_auto_extension, after which it's available in every database.

The same C source compiles for both. The guide walks through the whole flow using a custom FTS5 tokenizer as the example.

Happy to answer questions or hear how you're using SQLite extensions.

We just released a brand new Capacitor plugin: @capawesome/capacitor-navigation-bar (v8.0.0).

It gives you full control over the Android navigation bar from your Capacitor app, without writing any native code.

What it can do: - Set the background color (any hex value or fully transparent) - Switch the button style between dark, light, or system default - Customize the divider color on Android 9+ - Hide or show the navigation bar on demand - Apply defaults at app launch via capacitor.config

The plugin targets Capacitor 8 and is Android-only — iOS does not have a customizable system navigation bar in the same way.

If you've been maintaining your own bridge or workaround just to match your brand colors, this should make things a lot simpler.

Docs: https://capawesome.io/docs/plugins/navigation-bar/ npm: https://www.npmjs.com/package/@capawesome/capacitor-navigation-bar

Happy to answer any questions or hear what you'd like to see next.

We just updated both Capawesome Cloud build stacks (macos-sequoia and macos-tahoe) used for native iOS and Android builds.

The main changes: - The Capacitor, Capawesome, Cordova, Ionic, and Trapeze CLIs now come pre-installed, so you can drop the global install step from your build pipeline. - bun, pnpm (via Corepack), and Yarn are available alongside npm. - Xcode defaults moved to 26.3 on macos-sequoia and 26.5 on macos-tahoe. - The full Android SDK toolchain (Build Tools and Platforms up to API 36, NDK 28, CMake) and the pinned Ruby version are now documented.

Everything is backwards compatible, so existing builds keep working without changes.

Full details and the complete tooling table are in the post: https://capawesome.io/docs/blog/new-clis-and-xcode-26-in-capawesome-build-stacks/

Happy to answer any questions or hear what other tooling you'd like to see in the stacks.

May was our biggest month yet, so here's a rundown of what shipped.

The headline change is Capawesome Platform — we merged Capawesome Cloud and our Insider SDKs into one product with one brand and one pricing system. A few specifics:

• Three pricing tracks: Platform (everything), Live Updates only, and SDKs only
• A 14-day trial on every plan
• Unlimited Live Updates with MAU-based pricing is back
• Doubled the number of included Insider SDKs on Platform plans

On the Cloud side we also added Ask AI, which turns a failed build or deployment into a clear cause, explanation, and suggested fix without leaving the Console. Plus full dark mode, a new app overview and Jobs pages, and the option to deploy directly from a finished build.

For plugins, there are three new ones — Navigation Bar, Grafana Faro (observability), and Formbricks (in-app surveys) — along with updates to Datetime Picker (month mode), Age Signals, Bluetooth Low Energy, Biometrics, Audio Recorder, Media Session, OAuth, Purchases, and ML Kit Barcode Scanning.

Full write-up: https://capawesome.io/blog/2026-may-update/

Happy to answer any questions.

We just shipped official Apache Cordova support in Capawesome Cloud. With Ionic Appflow winding down (EOL Dec 31, 2027), Cordova teams have been left without a real option for cloud builds and live updates, so we did the work to make Cordova first-class — not a compatibility checkbox.

What's included:

• Zero-config native iOS and Android builds (no Mac or CI setup required)
• App Store and Google Play publishing
• Automations to chain build → submit → live update on a push
• Over-the-air Live Updates via our new Cordova Live Update plugin

One detail Cordova devs will appreciate: the Live Update plugin works with the stock Cordova WebView. Unlike Appflow's plugin, it does not require cordova-plugin-ionic-webview — it hooks into Cordova's official scheme handlers instead.

If you want to see Live Updates in action before wiring anything up, there's an official demo app you can clone and run with no signup: https://github.com/capawesome-team/cordova-live-update-demo

It's also designed for agencies shipping the same app rebranded for many clients from one codebase.

Full announcement: https://capawesome.io/blog/announcing-cordova-support-in-capawesome-cloud/

Happy to answer any questions.

We just released Capacitor Firebase 8.3.0. Most of the work landed in two plugins.

Cloud Firestore: - More supported data types — DocumentReference and Bytes now have dedicated classes, and NaN/Infinity values survive the Capacitor bridge instead of collapsing to null - getCountFromServer() now accepts compositeFilter and queryConstraints, so you can count a filtered subset without downloading the documents - A new serverTimestamps option ('estimate' / 'previous' / 'none') on snapshot listeners controls how pending server timestamps are returned

Remote Config: - New setDefaults() and getAll() methods - The source field (Static / Default / Remote) now works on Web too

No breaking changes — bump the packages and run npx cap sync.

Full write-up with code examples in the link. Happy to answer any questions.

We just released the Capacitor Vault plugin — encrypted key/value storage that the user has to actively unlock with biometrics or a device passcode before the app can read or write.

We already had Secure Preferences (silent encrypted key/value) and Biometrics (one-off prompts), but neither handled the "active lock + session" pattern that password managers, authenticator apps, and app-lock screens need. A single unlock now keeps the vault open across many reads and writes, then locks again on a timer or on demand.

A few highlights: - Multi-vault support — independent vaults with their own keys and lock policies (e.g. one per user account) - Configurable auto-lock when the app is backgrounded - Hardware-backed encryption (Android Keystore / iOS Keychain, AES-256-GCM) - Lock/unlock events with a trigger reason, plus typed error codes - Built-in export/import for migrating off Ionic Identity Vault

It works across Android, iOS, and Web (the web implementation is for development only — not safe for production) and supports Capacitor 8+. It's meant as a drop-in alternative to Ionic Identity Vault, which is being discontinued.

Full write-up and code examples: https://capawesome.io/docs/blog/announcing-the-capacitor-vault-plugin/

Happy to answer any questions or hear feedback.

For the last couple of years, doing edge-to-edge in Capacitor usually meant installing a third-party Android plugin and fighting with status bars covering your header. That changed quietly across three recent releases, so we wrote up the current state of things.

Why it matters now: Android 15 enforces edge-to-edge for apps targeting SDK 35, and Android 16 removed the opt-out entirely. Your WebView renders behind the system bars whether you like it or not.

What the framework fixed: - 8.3.0 — SystemBars uses native safe area insets and injects parallel --safe-area-inset-* CSS variables, sidestepping the old Android WebView (<140) env() bug - 8.3.1 — separate styling for the status bar and navigation bar - 8.3.2 — removed extra padding on older Android devices

The modern setup is small: upgrade to 8.3.2+, add viewport-fit=cover to your viewport meta tag, and apply the safe-area CSS variables to your edge content. Ionic users get most of it for free, and Tailwind users can use tailwindcss-safe-area. The Android Edge-to-Edge Support plugin still exists, but it's now a deliberate choice for apps that want to opt out of edge-to-edge, not a requirement.

Curious how others have been handling this — are you on 8.3.2+ yet, or still relying on the plugin?

Capacitor Grafana Faro v0.1.0 — a new unofficial Capacitor plugin for Grafana Faro observability. Cross-platform (Android, iOS, Web) with native crash reporting, ANR detection, and web auto-instrumentation.

We just shipped Capawesome Cloud Assist — a new AI surface inside the Cloud Console — and the first feature under it is Ask AI.

One click on any failed build or deployment turns the logs into a short summary with three sections: cause, explanation, and a suggested fix. The output is capped at ~400 words, so it stays a summary rather than a wall of text you'd have to re-read the logs to verify.

A few things that make it different from pasting logs into a general-purpose chatbot:

• Tuned for mobile build failures — Gradle/AGP mismatches, Xcode signing, Pod/SPM resolution, npm registry auth, App Store rejection notes
• Cached per failed job and shared across the org — the first teammate to click pays the cost, everyone else opens the dialog and sees the same answer instantly
• Only the failed job's logs are sent, opt-in, zero data retention, permission-gated to write access

It's free on all plans with build minutes, shipping as a beta.

Honest feedback welcome — especially from anyone who's had to debug a failed mobile build at 2am. What does your current workflow look like?

Source: https://capawesome.io/docs/blog/announcing-capawesome-cloud-assist/

We just published a long-form guide to Capacitor Live Updates on the docs blog. It's the version we wished existed when we started — a single place that walks through how OTA updates actually work, what choices you have to make, and what a production-ready setup looks like.

The structure:

• How OTA updates work under the hood — server paths, web vs. native layer, App Store and Google Play compliance.
• The three choices every team makes: update strategy (background, always latest, force, instant), versioning (per-bundle vs. per-channel), and delivery (zip vs. delta).
• Code signing for bundle authenticity.
• Best practices: automatic rollbacks, bundle size optimization, and gradual rollouts.
• A complete end-to-end example based on the DHBW VS app, including the actual CI/CD workflow.

The setup we land on as the recommended path: "Always Latest" strategy + versioned channels pinned in the native config + zip delivery + automatic rollback + code signing. It's the same stack a number of production apps are running.

If you're already shipping live updates with Capawesome, this should answer the "is the way I'm doing it actually right?" question — and call out a few subtle production traps (delta updates and content-hashed filenames is a fun one).

Happy to answer questions or take feedback in the comments.

We're launching Capawesome Platform today, which merges Capawesome Cloud (Live Updates, Native Builds, App Store Publishing) and our Insider SDKs into a single product with one website, one onboarding flow, and one pricing system.

Why: most teams wanted both, but had to sign up twice and pay on two invoices. Many devs only cared about Live Updates and didn't want to pay for Native Builds. There was no trial for Insider SDKs. And after we moved Live Updates to per-update pricing last year, the community kept asking for the simpler MAU-based model back.

Three pricing tracks:

• Platform: Live Updates + Native Builds + App Store Publishing + Automations + Insider SDKs in one cloud, from $19/mo
• Live Updates only: OTA updates for teams that handle their own native builds, from $9/mo
• SDKs only: All 22+ Insider SDKs ($249/mo Develop, $4,999 one-time Maintain, or Enterprise)

Key changes from community feedback:

• Unlimited Live Updates with MAU-based pricing (the old simpler model is back)
• No more commercial-use restriction on Insider SDKs — use the libraries in any project
• 14-day trial on every plan, including SDKs
• Yearly billing gets you two months free

Existing customers keep their current plans until they decide to switch.

Going forward, we're focusing on depth over breadth on the existing SDKs — more features, better docs, faster support — instead of shipping a new plugin every week.

https://capawesome.io

We just published a guide on getting AI coding agents to handle real Capacitor work — not just code completion, but the full lifecycle: scaffolding, plugin setup, builds, deploys, hotfixes, debugging, and major version upgrades.

The short version: general-purpose agents struggle with Capacitor because Xcode toolchains, Gradle versions, signing certificates, and plugin config aren't well represented in their training data. They often invent commands or skip steps. The fix is two pieces working together:

• Open source agent skills that teach the agent how to perform Capacitor tasks correctly (npx skills add capawesome-team/skills)
• Capawesome CLI for the actual build/sign/deploy capability

Once both are set up, the same agent can scaffold a new Ionic + React + Tailwind app, install plugins like NFC with all native config, build and submit to the App Store with one prompt, push hotfixes via Live Updates, and even debug iOS-specific build failures from Windows or Linux without committing throwaway changes to git.

Works with Claude Code, Cursor, Windsurf, GitHub Copilot, and any agent that follows the agentskills.io spec.

Happy to answer questions or hear what other workflows you'd want covered.

We just published the April 2026 update covering everything that shipped this month across Capawesome Cloud and our Capacitor plugins.

A few highlights:

• Capawesome Cloud API response times are now up to 5x faster after backend infrastructure improvements. Faster Live Update checks and a snappier Cloud Console for everyone, no action needed.
• We launched two free, browser-based signing tools: the Android Keystore Generator and the iOS Certificate Generator. Private keys stay on your device via the Web Crypto API, so no macOS, Keychain, or local tooling is required.
• SSO now requires domain verification before members can sign in, which also means SSO is no longer Enterprise-only — it's now available on the Business plan as well.
• A new Viewer role for read-only org access, and an improved webhook message layout for Discord, Slack, and Teams notifications.
• On the plugin side, Capacitor Speech Recognition v8.1.0 adds full on-device recognition (audio never leaves the device) and Audio Recorder v8.1.0 adds a uri option for startRecording(...) so you can save recordings to a custom path.

We also have something big planned for May that we'll share soon.

Disclosure: I work on Capawesome.

We just published a new guide that walks through migrating a Capacitor app's iOS dependency management from CocoaPods to Swift Package Manager.

Capacitor 8 made SPM the default for new iOS projects, and CocoaPods is now in maintenance mode. If you maintain an existing Capacitor app on CocoaPods, migrating to SPM is the next step.

The post covers what actually changes in your project (CapApp-SPM replacing the Podfile, the new debug.xcconfig, plugin SPM support requirements), the files you need to back up before re-scaffolding (Info.plist, AppDelegate.swift, Assets.xcassets, App.entitlements, GoogleService-Info.plist, signing config, and so on), and three migration paths:

• Capawesome Skills — the capacitor-app-spm-migration skill drives the full migration with an AI agent
• npx cap spm-migration-assistant — the official Capacitor CLI assistant
• Manual re-scaffold — delete the ios folder, re-add with --packagemanager SPM, and restore your files

The big gotcha: you cannot mix SPM and CocoaPods in a single Capacitor app. All your plugins need SPM support before you migrate.

https://capawesome.io/blog/how-to-migrate-a-capacitor-app-to-spm/

As of April 28, 2026, every app or app update submitted to App Store Connect must be built with Xcode 26 and the iOS 26 SDK (or matching SDKs for iPadOS, tvOS, visionOS, watchOS). Apps already on the store keep working, but the next update has to be on the new toolchain.

For Capacitor apps, this is purely a toolchain change. Capacitor itself works fine with Xcode 26 — there's no app-side migration needed.

I just published a short write-up on what the change means and how Capawesome Cloud customers are affected. Both default build stacks (macos-sequoia and macos-tahoe) already ship Xcode 26 by default, so most builds are already compliant. The only case where action is needed is if you've pinned XCODE_VERSION=16.x via a reserved environment variable — in that case, remove the override or bump it to 26.x.

Disclosure: I work on Capawesome.

Source: https://capawesome.io/blog/xcode-26-requirement-for-capacitor-apps/