ionic-team

Google Play DEX Code Optimization in Capacitor Apps If Play Console shows a "DEX code optimization" finding for your Capacitor app, the Android project template is the cause. From February 2027, Google Play requires at least 25% obfuscation, optimization and shrinking for every app with more than 10 MB of DEX code, and the Capacitor Android template ships with R8 turned off. In this post, we walk through the fix: two lines in build.gradle, a short proguard-rules.pro, and one check before you upload. Prerequisites You'll need: - A Capacitor 8 Android app - Android Gradle Plugin (AGP) 8.x Everything below comes from our own production app at Capawesome, which uses about 40 plugins and runs on Capacitor 8.5.0 with AGP 8.13.2. Play's DEX optimization requirement Google Play measures three percentages for every app bundle you upload: obfuscation, optimization and shrinking. A Capacitor app built from the default template scores close to zero on all three. The Android project that npx cap add android generates sets minifyEnabled false in the release build type, so R8 never touches your DEX code. For our app, Play Console reported 1% obfuscation. The Play Console technical quality requirements say that from February 2027, apps need at least 25% in each category, and that "not meeting a requirement can affect an app's visibility and publishing capabilities on Google Play". The thresholds apply to apps with more than 10 MB of DEX code and to games with more than 50 MB. Capacitor, Firebase and Play Services dependencies put a plugin-heavy app over the 10 MB line. The Android vitals page on DEX code optimization explains that for apps built with AGP 8.10 or higher, Play reads them from the r8.json file inside the bundle. Any shrinker counts, and R8 is the one every Android project already has. Enable R8 Open android/app/build.gradle, set minifyEnabled true in the release build type and switch the default rules file to the optimizing variant: android { buildTypes { release { minifyEnabled true proguardFiles getDefaultProguardFile('proguard-android-optimize.txt'), 'proguard-rules.pro' } } } The template points to proguard-android.txt. That file contains -dontoptimize, which blocks most of what R8 could do, and AGP 9 no longer accepts it by default. We covered that build failure in How to Fix Capacitor Plugin Build Errors with AGP 9, so switching now avoids it later. R8 has run in full mode by default since AGP 8.0. That detail is behind the keep rule in the next section. Rules you need On top of the rules that Capacitor, AGP and the large SDKs contribute on their own, a Capacitor app needs these lines in android/app/proguard-rules.pro: # Capacitor annotations: required in R8 full mode (ionic-team/capacitor#8589) -keep @interface com.getcapacitor.** { *; } # Plugin-specific rules from each plugin's README -keep class io.capawesome.capacitorjs.plugins.** { *; } # Optional backends that plugins probe for at runtime (see missing_rules.txt) -dontwarn io.requery.android.database.** -dontwarn net.zetetic.database.** The first rule is the one every Capacitor app needs, and we'll explain it below. The second line is an example of a plugin-specific rule. Most Capacitor plugins ship no consumer rules, and a plugin that relies on reflection or serialization documents its rule in its README. The Capacitor SQLite plugin does exactly that for the io.capawesome.capacitorjs.plugins package. The -dontwarn lines depend on which plugins you use; the "Missing class errors" section shows how to find yours. The rest is already handled for you: - Capacitor's consumer rules: @capacitor/android declares its own proguard-rules.pro as consumer rules. They keep every class annotated with @CapacitorPlugin, its public @PluginMethod methods, and its @PermissionCallback and @ActivityCallback methods, even private ones. Capacitor resolves those callbacks by method name at runtime, so permission requests and activity results survive R8 without any rule of yours. - AGP's defaults: they keep @JavascriptInterface methods, which is how Capacitor's MessageHandler receives calls from JavaScript. - Large SDKs: Firebase and Play Billing ship consumer rules of their own. Why the keep rule Without the @interface rule, the build passes and the app crashes on startup. Capacitor's consumer rules keep the classes annotated with @CapacitorPlugin, but not the annotation types themselves. Here is what the first launch of our minified build looked like in logcat: FATAL EXCEPTION: CapacitorPlugins java.lang.RuntimeException: java.lang.reflect.InvocationTargetException Caused by: java.lang.NullPointerException at com.getcapacitor.Plugin.getPermissionStates at com.getcapacitor.Plugin.checkPermissions at ...FirebaseMessagingPlugin.checkPermissions According to the Android documentation on R8 full mode, R8 strips annotations from classes that are not explicitly kept. Once the CapacitorPlugin annotation is gone, getAnnotation(CapacitorPlugin.class) can only return null. R8 then removes the pluginAnnotation field from PluginHandle, and Bridge.getPermissionStates() dereferences null the first time any plugin checks its permissions. All plugins still register, because registration only needs the class. The -keep @interface com.getcapacitor.** { *; } rule keeps every annotation type in the package. That covers @CapacitorPlugin, @Permission, @PermissionCallback, @ActivityCallback, @PluginMethod and the legacy @NativePlugin. Capacitor does not ship this rule in its consumer rules yet. Issue #8589 describes the same behavior with the same workaround and is open as of this writing. Capacitor 8.5.2 merged a null check in getPermissionStates(), so on 8.5.2 the app no longer crashes. Instead, checkPermissions() returns an empty permission map. You still need the keep rule on 8.5.2, because the null check only hides the symptom. You could also avoid the crash by disabling full mode with android.enableR8.fullMode=false in gradle.properties. That costs you optimization across the whole app and all its dependencies, which is the exact number Play measures. The keep rule is the cheaper fix. Missing class errors R8 fails the build with "Missing class" errors when a plugin was compiled against a library your app does not bundle. Some Capacitor plugins do this on purpose. The Capacitor SQLite plugin compiles against both SQLCipher (net.zetetic.database.**) and requery's sqlite-android (io.requery.android.database.**) as compileOnly dependencies, and bundles only the one you select in variables.gradle. At runtime it probes for them with Class.forName. The missing classes are expected, but R8 can't know that, so the two -dontwarn lines above tell it. Whenever R8 reports missing classes, it writes a ready-to-paste file to android/app/build/outputs/mapping/release/missing_rules.txt. Read each entry before you paste it: - A -dontwarn for an optional backend that the plugin checks for at runtime is correct. - A -dontwarn for a class a plugin calls unconditionally hides a real NoClassDefFoundError until a user hits it. The right fix there is to add the dependency. Verify locally Debug builds never run R8 with this configuration, so the release build is the only one that tells you whether your rules are complete. It also has to be signed before you can install it. The signing properties that Android Studio injects into Gradle let you sign a local release build with the debug keystore, without touching build.gradle: cd android ./gradlew assembleRelease \ -Pandroid.injected.signing.store.file=$HOME/.android/debug.keystore \ -Pandroid.injected.signing.store.password=android \ -Pandroid.injected.signing.key.alias=androiddebugkey \ -Pandroid.injected.signing.key.password=android adb install -r app/build/outputs/apk/release/app-release.apk With the build installed, run three checks: 1. Watch logcat for FATAL EXCEPTION, ClassNotFoundException and NoSuchMethodException while the app starts. Then run every flow that requests a permission or waits for another activity, such as the camera, a file picker or a settings screen. The annotation crash shows up within the first second. 2. Open mapping.txt in android/app/build/outputs/mapping/release/ and confirm that your plugin classes still appear under their original names. A renamed plugin class means a keep rule is missing. Archive this file with every release, because you'll need it for production stack traces. 3. Read the Play numbers from the bundle before you upload it. Build it with ./gradlew bundleRelease and run unzip -p app/build/outputs/bundle/release/app-release.aab BUNDLE-METADATA/com.android.tools/r8.json. Play Console shows the same percentages for that upload in the app bundle explorer. Conclusion Our advice: enable R8 now, not when the February 2027 deadline arrives. The first minified build of a plugin-heavy Capacitor app surfaces every missing rule at once, and you want that to happen on an emulator, not in a Play release. Treat the release build as a standing test target. Run your permission and activity-result flows on it before every upload, and check missing_rules.txt again whenever you add a plugin. For the other Android build pitfalls Capacitor apps run into, see The Android Troubleshooting Guide for Capacitor. The full post on the Capawesome blog also has an FAQ on mapping files for Play and Crashlytics and on resource shrinking, and if you have questions, drop them in the comments below.

Comparing Ionic, NativeScript & React Native When it comes to creating apps with JavaScript, there are multiple approaches, and none is more popular than React Native. Some of the biggest apps on both the App Store & Play Store rely on React Native, Ionic is quite popular as well, and NativeScript is behind the two. We also use Meta's framework for creating cross-platform native apps. Curious why? React Native React Native is currently the most popular JavaScript framework for creating mobile apps. Neither Ionic nor NativeScript can match its popularity. Its popularity comes from the fact that it was tied to React from the start, while both Ionic and NativeScript were Angular-first (the bet did not pay off for the two). The framework allows developers to build mobile apps using JavaScript & TypeScript and React's JSX syntax, so you can build rich user interfaces that feel native. You may even reuse the same libraries you are used to from web React, such as Formik, Redux, react-query or even tailwind (provided you install an additional plugin for handling utility classes). When to Use It In our view, if you're choosing between those three, you can't go wrong with React Native. It's flexible, the community support is great, and there are a ton of libraries and resources available. If the bare workflow does not suit you, you have Expo at your disposal - a great project that extends Meta's framework and adds many indispensable goodies. What's becoming more important is that the number of React Native projects is huge, which means tools such as GitHub Copilot, Cursor, and others have more repositories to scrape, so suggestions for your code should be better. Ionic Ionic allows the creation of hybrid applications using web technologies like HTML, CSS, and JavaScript. The framework wraps the web application in a native container using Capacitor, thanks to which you may access native APIs from the comfort of the DOM. Because of that, however, apps will be much slower. Of the 3 frameworks, Ionic will be the easiest to switch to for a web developer, because React Native and NativeScript have some gotchas you need to keep in mind. How many you hit depends on how deep you go, but there are definitely some. When to Use It Ionic is great if you want to create quick prototypes or a quick mobile app version of your website, and don't need a performance beast. It's also great for reusing as much code as you can between your web and mobile app. If your company is primarily a Vue.js or Angular development company, you're effectively choosing between Ionic and NativeScript. NativeScript NativeScript (originally called Telerik NativeScript) enables developers to create truly native mobile applications using JavaScript or TypeScript. Unlike Ionic, it does not use WebView but accesses native APIs directly. If you know you will need plenty of third-party libraries, NativeScript isn't for you. The community isn't huge, and it likely won't grow; at least nothing indicates it will. A huge pro is that it has first-party integration with many frameworks. When to Use It NativeScript is the least popular of the 3, but it's still not a bad option. You will have significantly fewer third-party plugins and libraries at your disposal, but maybe you won't mind. Furthermore, it offers integrations with 6 different web frameworks, not counting the option of vanilla JavaScript & TypeScript. If your company primarily uses Vue.js, Angular, Svelte, or Solid, go for it. If you know ahead of time that you won't be using many third-party UI components and such, it's safe to pick. If you do expect to use them, consider a different framework. React Native vs Ionic vs NativeScript While choosing the tool matters less than other business decisions, it's still an important decision that could make or break your project. Depending on the type of your app, it can have a big impact on the user experience you deliver. User Experience React Native provides a truly native look and feel, as it uses native components for rendering. This results in smoother animations and transitions, making it ideal for performance-sensitive applications. NativeScript also offers a native experience, allowing direct access to native APIs, which can enhance the app's responsiveness and overall user satisfaction. Ionic, while capable of creating visually appealing applications, often resembles mobile websites more than native apps because it relies on WebView. This can limit performance in complex applications, and the user interfaces look similar to native ones but feel slightly off. Development Speed Ionic is generally faster in development for developers familiar with web technologies (HTML, CSS, JavaScript), making it a preferred choice for rapid prototyping and simpler applications that aren't performance critical. React Native and NativeScript may require more time to master due to their more complex setups and the need for understanding native mobile development concepts. Performance React Native and NativeScript are designed for high performance close to that of native applications. If you're developing graphics-intensive, complex applications, choose one of these two. You should also choose one of them if smooth 60 frames per second is a priority. Ionic, while effective for simpler apps, can struggle with performance under heavy loads or when utilizing extensive animations. Community and Ecosystem Both React Native and Ionic have large communities with plenty of resources, libraries, and third-party plugins that can speed up development. NativeScript has a smaller community but still offers useful resources and support, particularly for developers who want to use native capabilities. In the 2024 Stack Overflow Developer Survey, 9% of professional developers declared they're using React Native, 2.8% declared they are using Ionic, and... NativeScript wasn't there. According to the same survey, 56.5% of professional developers "admired" React Native, while 39.6% "admired" Ionic. When it comes to popularity on GitHub, React Native's repository has 119k stars, NativeScript's repo has 24.2k stars, while Ionic's has more than double that with 51.1k. Cross-Platform Compatibility All three frameworks allow for cross-platform development, but the extent of code reuse varies. React Native and NativeScript can share a significant portion of code between iOS and Android. Meta's mobile app framework has one significant pro: you may also create desktop apps for macOS & Windows. Ionic allows broader code reuse across web, mobile, and desktop platforms but may require additional adjustments for optimal performance on mobile phones. Keep in mind that desktop apps created with Ionic are based on Electron, which is great for development speed but uses too many resources. For example, Slack, a popular messaging app, will easily use 500 MB of your RAM without breaking a sweat. !React Native Summary The three frameworks approach mobile app development differently, each catering to different developer groups and companies. React Native focuses on creating high-performance, native-like applications using React only. It's ideal for teams & companies familiar with React that want to use native capabilities. Ionic uses web technologies (HTML, CSS, JavaScript) to build hybrid applications that run in a WebView. It's best for rapid prototyping and simpler applications where development speed matters more than native performance, and it's great for web developers moving to mobile. Performance can be a limitation for more complex apps, but it is very accessible for web developers. Lastly, NativeScript provides a way to create truly native apps using JavaScript or TypeScript, accessing native APIs directly. It's suitable for applications that make extensive use of native features, and while it offers a good balance between performance and flexibility, it may not have as large a community or ecosystem as React Native or Ionic. The choice among React Native, Ionic, and NativeScript should depend on your project requirements, team expertise, and desired user experience. Each framework has its own strengths and weaknesses and its own ratio of development time to UX, so understanding your goals will help you make the best decision for your mobile app. For us, as well as for a large portion of other companies, there is no better choice than React Native. We love React, and we have created apps using both the native version and the web one. If you need an experienced React & React Native development company, feel free to contact us. You can also see our Expo setup on GitHub. --- Originally published at ordergroup.co.

The Road to Capacitor 9 Hey r/capacitor — I wrote up our latest Capacitor update over on the Ionic blog and figured folks here might be interested. Quick rundown: CocoaPods goes read-only Dec 2, 2026 — trunk freezes permanently, no new podspecs or version bumps. This won't break Capacitor directly, but it'll stop updates flowing to CocoaPods-hosted native deps your plugins depend on (Firebase, Stripe, etc). We've supported Swift Package Manager since Capacitor 6 and made it default in 8, so if you haven't migrated yet, now's the time: capacitorjs.com We're exploring a Capacitor MCP server so agents can pull real project info instead of guessing from training data. If you've had AI confidently get something wrong about Capacitor (the more specific the example, the better), I'd genuinely love to hear it in our GitHub discussion: capacitor#8555 Three plugins are now fully open to the community: Contacts, Calendar, and Health & Fitness (HealthKit/Health Connect). These started as OutSystems-exclusive and have been running in production for a while — now everyone gets them. What's actually landing in Capacitor 9: - Cordova Optionality — you can finally exclude the Cordova compatibility layer from your builds - iOS internals modernized: remaining Objective-C converted to Swift, and we're dropping XCFramework distribution (plugin authors will need to run migration tooling) - Early groundwork for multi-instance/windowed apps for foldables and large screens - Ongoing work to make Capacitor itself easier for AI agents to understand (docs, API annotations) Full post with more detail: ionic.io

The format, before and after: sarunw.com The silent failure: capacitor#8607 Apple's open-source model of the format: apple/xcode-project-format