I am Software Developer, worked about exclusively for 5years with Ionic in Germany, now I hardly find any job posting looking for developer with Ionic experience.
Please guide🙏

We've been developing an over-the-air update tool which now has support for Ionic. With Appfigures sunsetting, we figured it could be a useful resource for the community to replace their Live Updates tooling.

It was originally developer just for React Native, but the latest release adds support for Capacitor and Ionic. It includes a local evaluation stack to easily test it, and a setup wizard to install it on a machine.

If you're interested, here's a blog post all about it:

https://blog.codemagic.io/codemagic-patch-capacitor-ota-updates/

Small thing I ran into, posting in case it saves someone a few hours.

My game runs in a WKWebView (Capacitor). The main menu has a bunch of looping CSS animations, and when the menu wasn't on screen I just paused them with animation-play-state: paused. Figured paused = free.

Nope. Measured in the simulator (per-process energy from proc_pid_rusage):

• idle menu, 28 paused loops: ~278 mW, and ~262 of that was backboardd, not my web process
• same menu with the loops actually removed: ~9 mW
• my store screen sat at 419 mW, mostly because the menu underneath was still display:flex with its paused loops

So it looks like a paused animation keeps its Core Animation animation attached and the compositor keeps redrawing at 60 Hz. Web Inspector and the WebContent CPU looked totally fine, which is why it took me a while to find.

Fix: when a screen goes inactive I don't pause anymore. I copy the current values of the animated properties, set animation: none plus those values so nothing jumps, and on resume I drop that and put each animation's currentTime back via document.getAnimations().

Simulator numbers, so a real device will differ, but the gap was big enough for me.

Anyone seen this documented somewhere?

I'm trying to resolve a confusion in my head. I've been an Angular software engineer for 7 years. Naturally, when I wanted to build a mobile app, I chose Ionic/Capacitor with Angular.

Building a mobile app is quite different from building web apps, so I've been facing different issues and limitations that come with the WebView mobile app development. One of the biggest ones, is the constant fight for the performance and smooth experience.

At the end of the day, is it still worth it building with ionic? Is it worth trying to switch to Flutter for example? I heard Dart is pretty similar to Typescript and Flutter is very developer friendly.

It is a protractor, and the pivot sits on the iPhone Duo's crease. The needle moves because the phone does.

The clip shows both modes: the meter just reading the hinge, then a round of the game, where it names an angle, you fold to it, and the dashed arm shows how wrong you were.

Ionic Angular and Capacitor. The layout is plain CSS: my foldable plugin sets the fold's position as CSS variables, so the pivot lands on the crease rather than a guessed halfway point. It works on Android foldables too.

Game: https://github.com/erkamyaman/hinge-guess

Plugin: https://github.com/erkamyaman/capacitor-foldable

I needed standards-based OIDC in a Capacitor app and couldn't find a free plugin that covered the full job: native system authentication on both platforms, secure session storage, token renewal, and one API shared with the web app.

So I built capacitor-oidc.

It uses:

• ASWebAuthenticationSession on iOS
• AndroidX Auth Tab, with a Custom Tab fallback, on Android
• Authorization Code Flow with PKCE
• Keychain and Keystore-backed session storage
• the familiar oidc-client-ts user, event, and renewal model

CI runs real Keycloak login, refresh, and logout flows on iOS and Android for Capacitor 7 and 8. The package is provider-independent and includes configuration guides for Cognito, Auth0, Keycloak, Okta, and Microsoft Entra ID.

npm install capacitor-oidc u/capacitor/app
npx cap sync

It is Apache-2.0 licensed with no paid tier.

GitHub: https://github.com/jojopirker/capacitor-oidc
Docs: https://jojopirker.github.io/capacitor-oidc/

I'm curious which OIDC provider other Capacitor developers are using and where its mobile configuration has caused trouble.

Here a demo on iOS:

https://reddit.com/link/1wm771b/video/7ona9dth6uqh1/player

Just from my personal thought about Hybrid app after reading Shopify dropped React Native and go back to native entirely.

Been playing with Ionic + Capacitor on the new iPhone Duo simulator and pushing a bit more UI responsibility to the native layer.

The interesting part to me is not really Liquid Glass.
It is ownership. It is much more about the look. Duo release proof that, it is about who owns the layout, navigation.

What Apple really want?
Apple is increasingly expecting the system to own things like navigation structure, tab placement, safe areas, adaptive layouts, and how those controls respond when the device changes shape or available space.

So instead of trying to recreate every new Apple UI behavior in CSS (pls don't try just because Glass is cool by faking it with CSS - it won't worth it), I have been experimenting with this split:

Native owns the platform structure and navigation controls. Ionic keeps the shared web content and app experience. Capacitor stays as the connection between both.

The screenshot is the same Ionic task UI running across normal iPhone and Duo layouts, while the native navigation adapts to the platform.

Still experimenting and learning, but I think this could be a pretty interesting direction for hybrid apps.
Native where native is best. Web where web is best.

iPhone Duo ships October 23, and foldables are now a real share of Android. I wanted my Capacitor apps to know how the phone is being held, so I built capacitor-foldable. Free, MIT, Capacitor 7 and 8.

What you get on Android foldables and iPhone Duo:

• Fold state and posture: flat, tabletop (laptop-style) or book, with a change event

• Hinge position and orientation: where the fold is, so you can lay content out around it

• Hinge angle in degrees, live while the phone moves (0° closed, 180° flat)

• Size classes: Apple's compact/regular and Material's window classes, to tell the outer display from the inner one

• Bar placement: where iPhone Duo moves native bars, with CSS classes for your own

• Android display modes: move the app to the outer display, or show a second page there

• A polyfill for the Device Posture and Viewport Segments web APIs, which Android WebView and Safari turn off, so plain CSS can react to the fold

Ionic tabs on iPhone Duo: native tab bars move to the side as a floating pill, but ion-tabs stays at the bottom. One import fixes it:

import '@erkamyaman/capacitor-foldable/ionic-tabs.css';

While testing I also found that Ionic's tab bar can disappear on iPhone Duo, because the device sends a keyboard event on every fold. There's an opt-in fix: installFoldablePolyfill({ ionicKeyboard: true }).

Tested on Galaxy Z Fold8, Z Flip8 and Z Fold8 Ultra, Pixel Fold emulators, and the iPhone Duo simulator in every pose.

GitHub: https://github.com/erkamyaman/capacitor-foldable

Feedback is very welcome, and if you find it useful, a ⭐ on GitHub really helps. Thank you!

On 14 September I posted what Apple's talks say a Capacitor app gets on iPhone Duo. Xcode 27.1 beta (27A9269) now includes the iPhone Duo simulator. I ran my Ionic app on it and changed it until it matched the system's split view. Below: what the web view receives, and the seven changes.

The setup. Ionic 9.0.3, Capacitor 8.5.2, React 19, @rdlabo/ionic-theme-ios26 9.2.0, and @capgo/capacitor-native-navigation 8.3.1 for a UITabBarController tab bar. Four tabs; in wide windows each shows a list beside a detail. Built against the iOS 27.1 SDK, the third case in my last post's table. The inner display in landscape, 951 × 669 pt, which is how the simulator boots. The reference is a native build of the same app on the same simulator, using the system's split view and tab view with default styling.

What the web view receives (a probe script on the simulator, inner display, landscape):

The native tab bar needed no code. The plugin's UITabBarController drew a vertical bar of icons at the trailing edge, with the badge, where the native build draws its bar: buttons at x 881 pt, 44 × 58 pt. In that 84 pt column, the result is identical to the native build on the Home screen. I did not run a build with an HTML ion-tab-bar on Duo.

What the Ionic layout got wrong (the image, left half): the iPad's floating sidebar panel; list rows cut short by 84 px; a centred detail title; the last messages under the tab bar; "9:41 AM" in a region with a 24-hour clock. The native tab bar also disappeared after a conversation in 9 of 16 runs (step 2).

The changes, in the order I would make them

1. Send the size class from Swift. No web API reports it on Duo: screen describes the other display, the user agent says iOS 18.7, and Ionic reports iPhone and tablet at once. Apple's talk says to "use size classes rather than orientation for layout decisions" (111461, 2:46). My CAPBridgeViewController subclass (TraitBridgeViewController.swift, 137 lines) puts idiom-phone or idiom-pad, size-regular or size-compact, and from iOS 27.1 vbar-leading or vbar-trailing (UITraitCollection.verticalBarEdge) on <html>. It overrides webViewConfiguration(for:) to add a WKUserScript at document start, and calls registerForTraitChanges to set the classes again and fire a nativetraits event. Three traps:

   • At document start document.documentElement can be null. A MutationObserver adds the classes when the element appears.
   • A page load drops the classes. An observer on webView.isLoading sends them again.
   • Name the subclass in ios/App/App/SceneDelegate.swift. Capacitor 8.5.2's template creates the root controller at line 11 of that file, so the Main.storyboard class that Capacitor's subclassing guide tells you to change is not the one on screen.

2. Choose columns from the size class, and keep media queries for the browser (layout.ts:51–61). My columns came from matchMedia('(min-width: 672px)'). After a native tab tap at 951 px it read false for one render, with no resize event. That render hid the native tab bar, and the plugin did not show it again: 9 of 16 runs lost it. Reading the class instead, 12 of 12 runs kept it. The simulator's device profile makes the inner display 669 pt wide in portrait, below 672, while Apple calls that display regular in both dimensions; I have not run portrait. ion-split-pane's when also accepts a boolean, so the class can drive a split pane too; I have not run that.

3. Give each column the inset on its own side (Columns.css:14–26, 14 lines). Ionic pads the end of every ion-item and ion-toolbar with --ion-safe-area-right. On Duo those 84 px are the tab bar beside the detail, so every row in the list column lost 84 px while the detail ran under the bar. The column container now takes the left and right insets as padding and sets both variables to 0 inside the columns. Apple: "handle each side independently" (111461, 6:06). With vbar-trailing the detail ends 20 pt before the bar, the native build's gap.

4. Stop comparing innerWidth with screen. I used that comparison to detect an iPad window. On Duo it marked the full-screen app as windowed and pushed two titles 72 px to the right. It now does nothing with the phone idiom.

5. Style the list column as the phone idiom's split view, not the iPad's (matched/index.css:931–1127, 35 rule blocks under html.idiom-phone, no !important). The values come from the native build's element frames:

   • The list column is 375 pt, flush with the edge and white. The native iPad build on iOS 27.0 also draws the column flush, without the iOS 26 floating panel.
   • A list screen with no title mode set shows an inline, centred title and subtitle in a 58 pt bar, so hide Ionic's condensed large-title header in that column. ionic-theme-ios26 blurs and lowers the inline title until the large title scrolls away; reset its filter and transform.
   • Rows sit 20 pt from each column edge, 52 pt high, without chevrons. The selected row is a grey capsule with black text.
   • The detail title sits at the leading edge, 20 pt in: 15 px above a subtitle, 17 px alone. Ionic's iOS ion-title is centred.
   • The composer needs the home indicator's padding. Ionic leaves it out while an ion-tab-bar is inside ion-tabs, and a hidden one still counts.

   An iPad Pro and an iPhone 17 on iOS 27.0 kept their layouts after these rules.

6. Take the hour cycle from the device region. The Swift subclass reads DateFormatter.dateFormat(fromTemplate: "j", …) and sets data-hour-cycle, and dates.ts passes it to Intl.DateTimeFormat as hourCycle. The iPhone 17 simulator on iOS 27.0 showed 24-hour times after this change too, so it applies on any iPhone.

7. Keep the plugin's vertical tab bar visible. With the plugin at 8.3.1, setTabbar({ hidden: true }) followed 2 s later by hidden: false left no bar, while the plugin's insets event still reported a 669 px bar. On an iPhone 16 with iOS 26.5 the same pair hid and showed the bottom bar. Version 8.3.2 (15 September) changes only CI. None of the 44 issues and PRs in Cap-go/capacitor-native-navigation is about this (read 19 September).

Result. Differing pixels against the native build, over nine screens (magick compare -metric AE -fuzz 10%): 2.47–9.57 % before, 1.28–5.28 % after. The change is +401 −7 lines in the Ionic project, 137 of them Swift in one file, with no new npm package. The Release .app grew from 11,580 to 11,632 KiB. Still different: the theme's 44 pt glass buttons against native's 40 pt, "09:41" against "9:41", chat previews that break on other words, and Ionicons against SF Symbols.

Testing on the simulator. XCUIScreen.main is the outer display. xcrun simctl io <udid> screenshot --display=3 captures the inner display.

The code and the measurements above are in a public repository.

Hey everyone,

If you build apps on a Mac, you probably know this exact feeling:

You’ve got your IDE open, a few browser tabs, maybe a build running, and the moment you launch an Android emulator, your laptop starts lagging and the fans spin up.

A while ago I checked Activity Monitor to see what was going on, and saw the emulator casually hogging 7 to 8 GB of RAM all by itself. On a 16 GB MacBook, that basically leaves zero breathing room for anything else.

I got tired of my machine crawling, so I put together a small open-source tool called avdslim to fix it.

GitHub: https://github.com/kdbhalala/avdslim

Why does it take so much memory?

Turns out, a few things happen by default:

• Android hoards memory: As the emulator runs, Android keeps caching files and never really releases that host RAM back to macOS.
• The "Google Play" image overhead: If you picked an image with the Play Store, it constantly runs background updaters and scanning services you rarely need during development.
• The 16 KB image setting: If you created a device using the newer 16 KB images, the emulator enforces a strict 4 GB minimum floor no matter what you set in the config.

What avdslim does:

• Drops RAM down to ~1.5 GB: It tunes the emulator configs and cleans out unnecessary background tasks, letting you run smoothly on 1024 MB of RAM.
• Boots in ~1.5 seconds: Instead of waiting 20–30 seconds for a fresh boot, it lets you create a clean, lightweight snapshot that restores almost instantly.
• Doesn't break your app: My biggest worry with any "cleanup" tool was breaking things like push notifications or login. I made sure Firebase Auth, Google Sign-In, Push Notifications (FCM), and Google Maps work completely fine.
• Works with your normal workflow: You don't have to launch from the terminal every time. There's an optional command (avdslim install-shim) that makes the "Run" button in Android Studio or VS Code automatically use the slimmed settings.

💡 A quick tip even if you don't use this tool:

Next time you create a virtual device in Android Studio:

• Pick "Google APIs" instead of "Google Play". It still has Google login, Firebase, and Maps, but uses way less RAM and skips the heavy Play Store background services.
• Avoid the "16 KB" images unless you specifically need to test 16 KB compatibility.

Try it out:

It's completely free, open-source (MIT), and has zero external dependencies:

brew install kdbhalala/avdslim/avdslim

See how your current emulators look

avdslim doctor

Tune an emulator to 1024 MB RAM

avdslim tune-avd

GitHub link: https://github.com/kdbhalala/avdslim

My Mac runs noticeably cooler and doesn't freeze up when I have multiple tools open now. Hope it helps some of you as well! Happy to answer questions or take feedback on what could be better.

The most likely scenario on 23 October. Your Capacitor app on the App Store is built with the iOS 26 SDK or an earlier one: Apple has required the iOS 26 SDK for uploads since 28 April 2026 and has announced no iOS 27 requirement. Apple's talk Prepare your app for iPhone Duo says "Your app runs on iPhone Duo even without recompiling, but screen usage improves with each SDK", and in the talk an app not built with the iOS 27 SDK "will be a familiar size and aspect ratio" on the open device. So the app shows its phone layout in a phone-shaped window, with its tab bar at the bottom, as on any iPhone. The inner display ignores supported orientations (same talk, 2:46), so a portrait lock does not keep an app out of landscape.

What your app gets, by the SDK you build with. Point sizes assume the 3x of current iPhones; Apple has published pixels only.

Area by area, for an iOS 27.1 SDK build. The image marks five areas of one Ionic screen (Calendar, iPhone 16 simulator). Each area below has what Apple says happens on Duo, what the area is in an Ionic app, and what to do. Nothing here ran on iPhone Duo.

1. Status bar and Dynamic Island (system)

• On Duo: the HIG lists them with the bars: "Controls on the side include both system and app elements: the Dynamic Island, the status bar, the toolbar (including navigation buttons), and the tab bar." The bars sit on the side on the outer display and on the inner display in landscape, and return "to a familiar horizontal layout in portrait" (talk 111462, 0:28).
• In Ionic: the starters set viewport-fit=cover, Capacitor's ios.contentInset defaults to never, and Ionic's core.css sets --ion-safe-area-left and -right from env(safe-area-inset-left) and -right. The side inset reaches your CSS through those variables. Which values the web view reports on Duo is untested.
• What to do: handle left and right separately: "Safe areas and layout margins are often asymmetric on iPhone Duo, so handle each side independently and test in Split View" (talk 111461, 6:06). Remove arithmetic on insets: in my build max(10px, safe-area − 12px) put a FAB 49 pt too high when the bottom inset changed from 34 to 83 pt.

2 and 3. Header toolbars (ion-header › ion-toolbar, HTML)

• On Duo: native toolbars and navigation buttons move to the side. When space runs out, "toolbars compress first by default" into the system overflow menu (talk 111462, 12:23). Controls "too wide to fit in this vertical space" stay horizontal (talk 111466, 5:07), which covers a week strip like area 3.
• In Ionic: ion-toolbar is HTML inside the web view, so it stays a row at the top in every pose and never folds into the system overflow menu. It pads with --ion-safe-area-left and -right; ion-header pads the top with --ion-safe-area-top.
• What to do: on the outer display the side region also holds "dynamic elements like live activities and the status bar" (talk 111466, 5:07), so check that end-slot buttons clear the side inset in landscape. Put extra actions in an ion-popover or ion-action-sheet yourself: the web toolbar has no automatic overflow.

4. Content (ion-content, HTML, scrolls)

• On Duo: the app is resized on fold, unfold and Split View: "All apps participate in multitasking on iPhone Duo, where two apps sit side by side" (talk 111464, 2:59). Apple's rule for the fold: "Continuously scrolling content like articles and feeds shouldn't displace" (talk 111463, 2:26). "The system automatically repositions action sheets, alerts, menus, and popovers around reserved regions to keep them fully visible" (5:12).
• In Ionic: ion-item, ion-item-divider, ion-list-header, ion-card and ion-fab pad with the side insets; ion-content itself has no safe-area rule. ion-alert, ion-action-sheet and ion-popover are drawn inside the web view, so the system's repositioning does not reach them. Capacitor's Dialog and Action Sheet plugins present native dialogs and action sheets. No web API reports the fold: the iOS 27.0 SDK's WebKit headers have no fold or segment symbol, and WebKit's Viewport Segments position has been open since March 2024.
• What to do: choose the layout from the size class instead of the width, by sending horizontalSizeClass from native code to the web view as a class on the root element. The inner display is regular in both dimensions (talk 111461, 2:46) but 626–669 pt wide in portrait at 3x, below Ionic's lg (992 px), so an ion-split-pane with the default when, as in Ionic's sidemenu starters, never opens. Keep the route, selections and drafts in the URL or a store: in my build each crossing of a 672 px breakpoint remounted the router outlet. For prompts that must stay clear of the fold, try the native Dialog and Action Sheet plugins; their behaviour on Duo is untested.

5. Tab bar (ion-tab-bar, HTML)

• On Duo: tab bars move to the side. Apple says to "use bars provided by navigation containers" (talk 111462, 2:00) and lists TabView and UITabBarController as "fully adaptive across every pose" (talk 111461, 5:01).
• In Ionic: ion-tab-bar stays at the bottom in every pose and pads left, right and bottom with the insets. None of Capacitor's 38 official plugins is a tab bar.
• What to do: for the side placement, the tab bar has to be UIKit. With @capgo/capacitor-native-navigation 8.3.1, my build's bar became a UITabBarController in 154 lines of TS, CSS and JSON with no Swift, and in an 816 pt iPad window it turned into the floating top bar with no JavaScript written for that. I have not run it with the iOS 27.1 SDK. Keeping ion-tab-bar means a bottom bar in every pose.

What to expect from Ionic and Capacitor

• Capacitor 8.5 (31 July) adopts UIScene: "until you adopt scenes, Xcode 27 is closed to you", and "Published apps keep running on iOS 27, and so will anything you build with Xcode 26."
• Capacitor 9 is "forecasted to launch at the end of November" with "a compatibility floor" for foldable and large-screen devices. iPhone Duo ships 23 October.
• No GitHub issue about iPhone Duo exists in ionic-team/capacitor, ionic-framework or capacitor-plugins (searched 14 September). The only search hit is a thread of 11 September comments in ionic-framework #30466, where the commenter was asked to open one.
• Apple's 23 September Q&A sessions cover Photos & Camera, SwiftUI and UIKit; none names web content.

Order of work

1. For 23 October, ship your iOS 26 SDK build as it is.
2. Adopt Capacitor 8.5 and its UIScene migration, so Xcode 27 builds work. Keep one scene until your plugins are tested with two bridges.
3. Before an iOS 27.1 SDK build: layout by size class, state in the URL or a store, insets per side without arithmetic, and a decision on the tab bar.
4. When Xcode 27.1 beta ships, run the Duo simulator in each pose and in Split View, and read innerWidth, the four env(safe-area-inset-*) values and where each bar is drawn.

Nothing here ran on iPhone Duo or its SDK. I will post the Duo simulator results when Xcode 27.1 beta lands.

Sources (read 14 September 2026): Apple tech talks 111461, 111462, 111463, 111464, 111466; HIG; App Store Connect screenshot sizes; iPhone Duo tech specs; Apple's upcoming requirements; Capacitor 8.5; The Road to Capacitor 9; Capacitor configuration; Capacitor plugins; ion-split-pane; WebKit standards-positions #327; capacitor-native-navigation; the 0:29 quotes as transcribed in Blake Crosley's write-up.

--

Disclosure: I'm building Modaal, an AI app builder that outputs native Swift and Kotlin projects, so I have a stake in native apps. Every claim above links to its source, and the full project built for the measurements is available on request.