hingeStatus can lag the hinge angle

[erkamyaman]

Building capacitor-foldable I found UIKit updates UIHinge.status lazily, so it disagrees with the angle mid-fold: flat at 60 degrees, folded at 170, and stuck at closed for a moment after reopening. Simulator only so far, no hardware here. Table's in erkamyaman/capacitor-foldable#7.

Mild for the shell: a lazy status means one extra deviceLayoutChange when it corrects, and a stale hingeStatus in the payload until then. refreshHingeStatus() covers resume but not movement in between.

update.hinge?.angle is in the same handler if you want belt and braces. It's radians, and meaningless while status is .unknown. I let the angle override the status, 20 to 160 folded. I can send a PR if useful.

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

And I just want to say that I admire your work!

[rdlabo]

@erkamyaman Thank you for your interest in the project and your kind words! I really appreciate the detailed findings and your offer to send a PR.

Your issue made me reconsider whether device-state tracking belongs in the theme at all. Maintaining overlapping logic across both projects feels like unnecessary duplication, so I opened #230 to use @erkamyaman/capacitor-foldable for device state, update the demo, and remove that responsibility from the theme.

What do you think of this direction? I’d really appreciate your honest thoughts, including any concerns or trade-offs you see.

[erkamyaman]

@rdlabo

This made my week. I expected to point at a small lag and you read the whole thing and opened #230. Your project is the reason I knew what an iOS 27 shell should look like.

The direction is right, and I like that the theme takes edge and nativeEdge as inputs instead of importing the plugin. It still works for someone who never installs anything.

Reading the PR, your verticalBarEdge() fallback caught my eye: an app built against an SDK without the trait still gets the side bar, and my plugin returned null for it. My bug, not yours. Out as 8.3.2, same safe-area approach. On the Duo simulator the trait and the inference both report trailing where the old build reported null, so the class-based current fallback can go. Your range already allows it, the demo lockfile just pins 8.3.1.

inset is the one thing you're deleting that I don't cover, so nothing feeds --ios-theme-vertical-bars-native-inset after this. Say the word and I'll add it.

Small thing: with the string form, setVerticalControlAreaPlacement('trailing'), no nativeEdge is ever recorded, so nativeVerticalBars() trusts the native rail without a reported edge. Intentional?

Two notes for your users: ^8.3.1 won't resolve on Capacitor 7, that line is on the latest-7 tag. And foldStateChange can fire twice for one movement, so handlers want to be idempotent. Yours is. My numbers are still simulator only (erkamyaman/capacitor-foldable#4), so the folded thresholds may move on hardware, as a minor with a note.

I'm on X as @erkamyaman_ng if a DM is easier. Thank you again for this.

[rdlabo]

@erkamyaman Thank you! I'm really happy to be able to leave specialized device-state handling to your plugin.

I'd definitely welcome inset. Honestly, I don't trust Apple to keep that space at 80px forever. With possible future designs on iPad and other devices in mind, it would be great to receive the actual reserved width and updates when it changes.

For trailing, I don't want to restrict devices or use cases when an app developer deliberately chooses that placement. The goal is to bring the experience built on the web to native as much as possible, so attempting native projection with the string form is intentional.

That said, we currently fall back to the web when native rendering is unavailable, but we don't detect the case where native rendering succeeds without producing the requested vertical placement. Is your question about that behavior on, for example, an iPad without a native vertical rail? I'd appreciate hearing more about the case you have in mind.

Thank you for the 8.3.2 fix, too. I'll update the demo lockfile and review the current fallback. I've also noted the compatibility details, duplicate events, and the possibility of threshold changes after hardware testing. This integration assumes Capacitor 8.5 or later, so supporting earlier versions is outside its scope.

Thanks for sharing your X handle as well. If you're comfortable with it, I'd prefer to keep discussing this here in public, so other users and contributors can follow the reasoning behind the design as part of the open-source project.

[erkamyaman]

@rdlabo Thank you, and for the follow too.

inset is a good call, and you're right not to trust 80px. I'll add the measured
width to getBarPlacement() and fire barPlacementChange when it moves, so you
get the real number rather than my threshold.

On the string form, understood, and the case I meant is the one you named: native
rendering succeeds but no vertical rail exists, so the controls are hidden in the
web and never appear natively. An iPad, or an iPhone before 27.1, is exactly it.
getBarPlacement() returning a null edge is a reliable "no rail here" signal if
you want to detect it.

Public is better, agreed, I'll keep it all in the issues. Thanks again for taking
this seriously.

[erkamyaman]

@rdlabo inset is out in 8.3.3. Measured width of the bar on its edge in wholepoints, 84 on the Duo simulator, 0 where no bar is reported, and barPlacementChange fires when it changes.

[rdlabo]

@erkamyaman Thank you for the quick turnaround! I've updated #230 to use 8.3.3 and pass the measured inset on both the initial read and change notifications.

Your explanation also made me reconsider the trailing behavior. An app choosing a placement and a native rail actually existing there are separate things. Native vertical projection now stays disabled when nativeEdge has not been supplied or is null.

In that case, vertical-bars-only mode keeps the Web rail, while the full Native UI Shell returns to its ordinary horizontal layout. If a matching non-null nativeEdge is reported later, native vertical projection resumes.

This has helped clarify the responsibilities: the plugin handles specialized device-state reporting, and the theme handles rendering based on that information. Thank you for working through this with me, from the suggestions to the implementation!