[$250] [Sentry: APP-8K6] HybridApp iOS Fatal App Hang in RCTMountingManager

[mountiny]

Sentry

https://expensify.sentry.io/issues/APP-8K6

Impact (snapshot at filing)

• Users (total since first seen): 88
• Events: 91
• Users (last 7d): 29
• Events (last 7d): 29
• First seen: 2026-03-27
• Last seen: 2026-07-02 (ongoing)
• Platform: iOS HybridApp
• App version(s): 9.4.23
• Affected route(s): unknown (main thread blocked during RN mount transaction)
• Mechanism: AppHang (Non Fully Blocked)

Stack trace (top frames, first-party only)

RCTMountingManager initiateTransaction
RCTMountingManager performTransaction
CA::Layer::collect_animations_ (deep recursion during commit)

Suspected cause

Main thread blocked for 2000ms+ during React Native mounting manager transaction, likely tied to heavy Core Animation layer tree work during a Fabric update.

Reproduction

Unknown — see Sentry events linked from the Sentry issue.

Related

• Sibling Sentry IDs (if any): none
• Prior GH issues: none
• Parent tracker: [Tracking] Top Sentry crashes monthly check-in #91302

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022072671162810566168
• Upwork Job ID: 2072671162810566168
• Last Price Increase: 2026-07-02

Issue Owner

Current Issue Owner: @KJ21-ENG

[KJ21-ENG]

Proposal

What is the root cause of that problem?

The iOS app has a React Native patch for RCTMountingManager that starts a CATransaction, disables actions, runs every Fabric mount transaction, and then commits the transaction synchronously. The Sentry stack reports the main thread hanging in RCTMountingManager initiateTransaction / performTransaction while Core Animation recursively collects animations, which matches this global mount-time transaction wrapper instead of a specific JS route.

App/patches/react-native/react-native+0.83.1+008+iOSCoreAnimationBorderRendering.patch

Lines 1 to 20 in a9e6aed

	diff --git a/node_modules/react-native/React/Fabric/Mounting/RCTMountingManager.mm b/node_modules/react-native/React/Fabric/Mounting/RCTMountingManager.mm
	index b4cfb3d..fdfae56 100644
	--- a/node_modules/react-native/React/Fabric/Mounting/RCTMountingManager.mm
	+++ b/node_modules/react-native/React/Fabric/Mounting/RCTMountingManager.mm
	@@ -265,6 +265,9 @@ static void RCTPerformMountInstructions(
	auto surfaceId = mountingCoordinator.getSurfaceId();
	+ [CATransaction begin];
	+ [CATransaction setValue:(id)kCFBooleanTrue forKey:kCATransactionDisableActions];
	+
	mountingCoordinator.getTelemetryController().pullTransaction(
	[&](const MountingTransaction &transaction, const SurfaceTelemetry &surfaceTelemetry) {
	[self.delegate mountingManager:self willMountComponentsWithRootTag:surfaceId];
	@@ -278,6 +281,8 @@ static void RCTPerformMountInstructions(
	_observerCoordinator.notifyObserversMountingTransactionDidMount(transaction, surfaceTelemetry);
	[self.delegate mountingManager:self didMountComponentsWithRootTag:surfaceId];
	});
	+
	+ [CATransaction commit];

That patch is shipped with the app because postinstall runs scripts/applyPatches.sh, and that script copies every patches/**/*.patch file into the patch-package directory before running patch-package.

App/scripts/postInstall.sh

Lines 31 to 32 in a9e6aed

	# Apply packages using patch-package
	scripts/applyPatches.sh

App/scripts/applyPatches.sh

Lines 27 to 32 in a9e6aed

	find ./patches -type f -name '*.patch' -exec cp {} "$TEMP_PATCH_DIR" \;
	if [[ "$IS_HYBRID_APP_REPO" == "true" && "$NEW_DOT_FLAG" == "false" ]]; then
	find ./Mobile-Expensify/patches -type f -name '*.patch' -exec cp {} "$TEMP_PATCH_DIR" \;
	fi
	if ! npx patch-package --patch-dir "$TEMP_PATCH_DIR" --error-on-fail --color=always; then

What changes do you think we should make in order to solve the problem?

Remove the broad CATransaction begin / setDisableActions / commit wrapper from the RCTMountingManager patch. If the original iOS border-rendering issue still needs no-animation handling, move that behavior to the smallest border/layer update path that actually needs it, or wrap only that targeted update in a short no-animation block. The Fabric mount transaction itself should not force a Core Animation commit over the whole layer tree.

App/patches/react-native/details.md

Lines 54 to 57 in a9e6aed

	### [react-native+0.83.1+008+iOSCoreAnimationBorderRendering.patch](react-native+0.83.1+008+iOSCoreAnimationBorderRendering.patch)
	- Reason: Fixes border rendering issues with Core Animation on iOS
	- Upstream PR/issue: 🛑

Test coverage:

• Add a patch-package verification/unit-style fixture for the React Native patch to ensure RCTPerformMountInstructions is not wrapped in a global CATransaction.
• Manually verify iOS HybridApp startup and heavy native transitions/search or inbox screens, then confirm new APP-8K6 events no longer show RCTMountingManager plus CA::Layer::collect_animations_ after the patch is removed or narrowed.

What alternative solutions did you explore? (Optional)

Filtering or suppressing the Sentry event would hide the symptom but would not unblock the main thread. Disabling Fabric or the HybridApp path would be too broad for a patch that can be narrowed at the native mount/layer-update boundary.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @bernhardoj (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022072671162810566168

[lorretheboy]

Proposal

What is the root cause of that problem?

The local patch iOSCoreAnimationBorderRendering wraps the whole Fabric mount in an explicit Core Animation transaction — [CATransaction begin] before pullTransaction and [CATransaction commit] after it — to suppress implicit animations:

App/patches/react-native/react-native+0.83.1+008+iOSCoreAnimationBorderRendering.patch

Lines 5 to 21 in a9e6aed

	@@ -265,6 +265,9 @@ static void RCTPerformMountInstructions(
	auto surfaceId = mountingCoordinator.getSurfaceId();
	+ [CATransaction begin];
	+ [CATransaction setValue:(id)kCFBooleanTrue forKey:kCATransactionDisableActions];
	+
	mountingCoordinator.getTelemetryController().pullTransaction(
	[&](const MountingTransaction &transaction, const SurfaceTelemetry &surfaceTelemetry) {
	[self.delegate mountingManager:self willMountComponentsWithRootTag:surfaceId];
	@@ -278,6 +281,8 @@ static void RCTPerformMountInstructions(
	_observerCoordinator.notifyObserversMountingTransactionDidMount(transaction, surfaceTelemetry);
	[self.delegate mountingManager:self didMountComponentsWithRootTag:surfaceId];
	});
	+
	+ [CATransaction commit];
	}

performTransaction runs in a block dispatched to the main queue, so at the moment begin is called no implicit CATransaction exists yet and the patch's transaction becomes the outermost one on the stack. When the outermost transaction is committed, Core Animation doesn't defer to the end of the run loop like it normally does — it flushes the entire layer tree to the render server synchronously, right inside the mount. That flush recursively walks every layer (CA::Layer::collect_animations_), which is exactly the hang stack Sentry shows under RCTMountingManager initiateTransaction → performTransaction. On the iOS HybridApp the layer tree contains both the OldDot UIKit hierarchy and the NewDot Fabric tree, so this walk is huge, and it now runs on every mount transaction instead of once per frame — blocking the main thread past the 2s AppHang threshold.

What changes do you think we should make in order to solve the problem?

Change the patch so it disables implicit animations without pushing/popping a transaction. disableActions is consulted at property-set time, so saving and restoring it around the mount gives the same animation suppression while leaving the actual render-server commit at its normal, coalesced end-of-run-loop point:

BOOL wereActionsDisabled = [CATransaction disableActions];
[CATransaction setDisableActions:YES];
// existing pullTransaction / mount mutations
[CATransaction setDisableActions:wereActionsDisabled];

That is, replace the begin/setValue:kCATransactionDisableActions pair and the trailing commit in the patch shown above. The mount no longer forces a synchronous full-tree CA commit, so the hang inside RCTMountingManager goes away, and the border-rendering fix (no implicit animations on mounted layers) is preserved.

What alternative solutions did you explore? (Optional)

Calling [CATransaction setValue:(id)kCFBooleanTrue forKey:kCATransactionDisableActions] alone (no begin/commit) also avoids the synchronous flush, but it disables implicit animations for everything else in the same run-loop tick — including OldDot UIKit code — so the save/restore approach is safer.

[trasnake87]

🚨 Edited by proposal-police: This proposal was edited at 2026-07-03.

Proposal

What is the root cause of that problem?

The hang originates from an App-owned React Native patch, not from a JS route or component. patches/react-native/react-native+0.83.1+008+iOSCoreAnimationBorderRendering.patch wraps the entire Fabric mount inside an explicit Core Animation transaction in RCTMountingManager performTransaction:

[CATransaction begin];
[CATransaction setValue:(id)kCFBooleanTrue forKey:kCATransactionDisableActions];
mountingCoordinator.getTelemetryController().pullTransaction(...);
[CATransaction commit];

The intent is legitimate. Fabric renders borders and backgrounds using standalone CALayer instances — _backgroundColorLayer, _borderLayer, _outlineLayer — created via [CALayer new] in RCTViewComponentView.mm (approximately lines 978, 999, 1026). Because these are bare CALayer objects rather than UIView-backing layers, they retain implicit animations by default. Without suppression, every Fabric mount that repositions or re-paths them triggers implicit border-flicker animations — which this patch eliminates.

The defect is the scope of suppression. performTransaction is dispatched onto the main queue via RCTExecuteOnMainQueue. When this block runs, there is often no UIKit-owned implicit transaction already open on the stack. The patch's [CATransaction begin] therefore becomes the outermost transaction. Committing the outermost transaction does not defer to the next run-loop turn — it flushes the entire layer tree to the render server immediately and synchronously, walking every layer via CA::Layer::collect_animations_. That call is exactly the RCTMountingManager initiateTransaction → performTransaction → collect_animations_ stack Sentry captures.

Why HybridApp and why intermittent: in standalone NewDot the Fabric surface usually sits inside a UIKit view controller that already has an implicit per-frame transaction open, so the patch's commit is not the outermost one and defers normally. In HybridApp, NewDot's Fabric surface is embedded inside an OldDot-managed UIKit hierarchy, producing a combined layer tree (OldDot UIKit + NewDot Fabric) that is far larger than standalone. When a mount fires between run-loop turns — a more frequent occurrence in HybridApp due to cross-app navigation events — the patch's transaction becomes outermost, and Core Animation must synchronously walk the entire combined tree. On a large screen (long report list, Search results) this walk exceeds the 2 s AppHang threshold. The intermittency reflects the timing of when mounts land relative to the run-loop transaction window.

What changes do you think we should make in order to solve the problem?

Remove the [CATransaction begin]/setDisableActions/commit wrapper from the patch entirely and suppress implicit animations at the layer level, permanently and unconditionally, at the moment each standalone sublayer is created in RCTViewComponentView.mm:

static NSDictionary *RCTNoImplicitAnimations(void) {
    id n = [NSNull null];
    return @{@"position": n, @"bounds": n, @"path": n,
             @"contents": n, @"frame": n, @"opacity": n, @"transform": n};
}
// applied once at creation for each standalone layer:
_borderLayer.actions = RCTNoImplicitAnimations();
_backgroundColorLayer.actions = RCTNoImplicitAnimations();
_outlineLayer.actions = RCTNoImplicitAnimations();

Apply the same dictionary to box-shadow and background-image layers. An actions dictionary on a layer takes precedence over implicit behavior for every key listed, regardless of surrounding transaction state. This eliminates the border flicker deterministically while never opening an outermost CATransaction — so Fabric mounts always coalesce into UIKit's normal end-of-run-loop render-server flush. Rename the patch to reflect it now targets RCTViewComponentView layer setup rather than the mount manager.

Validation: confirm on iOS HybridApp that AppHang events under RCTMountingManager no longer appear for heavy-layer screens (Search results, long reports) opened from OldDot, and that border/background rendering is visually unchanged.

---

Update (2026-07-03) — fix refined + testing branch up. After tracing current RCTViewComponentView.mm, the per-layer .actions form originally proposed above is fragile: Fabric creates more standalone layers than enumerated (_filterLayer, multiple mask CAShapeLayers, and sublayers built inside RCTGetBoxShadowLayer/gradient/background-image helpers), and missing any one re-introduces the flicker patch 008 exists to prevent. The branch therefore keeps patch 008 in place and swaps its [CATransaction begin]/commit for a save/restore of the transaction's disableActions flag (converging with the direction @lorretheboy suggested): implicit animations stay suppressed for every layer touched during the mount, but no outermost transaction is opened — so the mount can no longer force the synchronous full-tree collect_animations_ flush that produces APP-8K6, and the commit coalesces back to Core Animation's normal end-of-run-loop point. Root cause above unchanged.

Testing branch: https://github.com/Expensify/App/compare/main...trasnake87:proposal-95194?expand=1

[dilshodmackbook-sketch]

Proposal

What is the root cause of that problem?

This is a Sentry AppHang (not a deterministic crash) with no repro: the iOS Hybrid main thread is blocked 2000ms+ inside a single Fabric mount, and the first-party frames are RCTMountingManager initiateTransaction → performTransaction, with CA::Layer::collect_animations_ recursing deeply during the Core Animation commit.

collect_animations_ runs while a CATransaction is committing and walks every sublayer of the committed tree to collect the animations pending on it. Its cost scales with how many concurrently-animating layers sit in that one commit — so deep recursion plus a 2s+ hang points at a single mount transaction flushing a large tree of simultaneously-animating layers, not at one expensive view.

The strongest first-party surface that fits that signature is the viewport-filling animated skeletons. ItemListSkeletonView sizes itself to the screen and derives its item count from the measured height:

App/src/components/Skeletons/ItemListSkeletonView.tsx

Lines 62 to 63 in 55e5bed

	const totalHeight = event.nativeEvent.layout.height;
	const newNumItems = Math.ceil(totalHeight / totalItemHeight);

const totalHeight = event.nativeEvent.layout.height;
const newNumItems = Math.ceil(totalHeight / totalItemHeight);

Each item is a react-content-loader/native SVG whose gradient animates continuously (animate defaults to true), so every item is its own independently-running animation:

App/src/components/Skeletons/ItemListSkeletonView.tsx

Lines 75 to 87 in 55e5bed

	const loader = (
	<SkeletonViewContentLoader
	speed={speed}
	key={`skeletonContainer${i}`}
	animate={shouldAnimate}
	height={itemViewHeight}
	backgroundColor={theme.skeletonLHNIn}
	foregroundColor={theme.skeletonLHNOut}
	style={[themeStyles.mr5, itemViewStyle, {opacity}, {minHeight: itemViewHeight}]}
	>
	{renderSkeletonItem({itemIndex: i})}
	</SkeletonViewContentLoader>
	);

<SkeletonViewContentLoader
    speed={speed}
    key={`skeletonContainer${i}`}
    animate={shouldAnimate}
    height={itemViewHeight}
    ...

On a tall device this mounts dozens of independently-animating SVG layers in one transaction, and committing them all at once is exactly what makes collect_animations_ recurse long enough to trip the 2s AppHang threshold. Any surface that mounts a big animated layer tree in a single transaction (skeleton lists, a large animated list) fits the same profile.

Note on the App-owned RCTMountingManager CATransaction begin/commit patch that others have flagged: that wrapper forces the mount's commit to run synchronously, so it's the amplifier — but a synchronous commit is only as expensive as what it flushes. It turns into a 2s hang specifically when the tree it commits carries many concurrently-animating layers. Cutting that animated-layer count addresses the cost whether or not the wrapper stays.

What changes do you think we should make in order to solve the problem?

Reduce the number of animated layers committed in a single mount, starting with the viewport-filling skeletons.

Collapse the skeleton to a single running animation instead of N — animate only the topmost few items and render the rest static, so the commit carries one animated SVG rather than dozens while the skeleton looks unchanged:

<SkeletonViewContentLoader
    animate={shouldAnimate && i < CONST.SKELETON_ANIMATED_ITEM_LIMIT}
    ...

Alternatively, cap the derived count so a tall viewport can't mount an unbounded number of animated loaders:

const newNumItems = Math.min(
  Math.ceil(totalHeight / totalItemHeight),
  CONST.MAX_SKELETON_ITEMS,
);

(SKELETON_ANIMATED_ITEM_LIMIT / MAX_SKELETON_ITEMS would be new CONST values.)

Because there's no repro, I'd pair the change with verification: inspect the Sentry events for the affected route(s) to confirm the hang correlates with a skeleton / large-animated-mount surface, and profile the iOS Fabric commit (Instruments → Core Animation) before/after to confirm commit time drops below the threshold. If the events point at a different surface (e.g. a specific large animated list), apply the same "fewer concurrent animated layers per commit" fix there.

What alternative solutions did you explore? (Optional)

Deferring the heavy mount off the initial frame with InteractionManager.runAfterInteractions — it improves perceived responsiveness but still commits the same large animated tree in one transaction later, so it moves the hang rather than removing it. Narrowing or removing the RCTMountingManager CATransaction wrapper (as other proposals suggest) relocates the commit off the mount stack, but the same animated-layer walk still runs each frame on the main thread; cutting the concurrent animated-layer count reduces that work at its source.