React Native vs. native Swift for an indie alarm app: a post-mortem

LastAlarmClock built Last Alarm in React Native for cross-platform reach, then spent months fighting Expo, StoreKit, AlarmKit, and dual-store testing. Here's what broke and why.

TL;DR

Best for: Indie iOS founders who already own a Mac and are targeting a single platform with deep OS integration (lock screen, DND alarms, Live Activities, StoreKit UI).

Skip if: You genuinely need Android parity at launch and don't have a native iOS developer on the team. React Native's MVP speed is real; the cost shows up in month three, not month one.

Bottom line: For apps that depend on iOS-only APIs (AlarmKit, SubscriptionStoreView, Live Activities), React Native adds architectural debt that compounds faster than the initial cross-platform productivity gain offsets it.

Methodology

v0 review. This piece draws entirely on a single Reddit post by founder LastAlarmClock, published May 2026, at https://www.reddit.com/r/SideProject/comments/1tcfig5/i_wish_id_just_gone_native_swift_instead_of/. The app under discussion is Last Alarm (App Store ID: 6757664120), an iOS alarm clock with Live Activities and AlarmKit integration.

What's covered: the founder's first-person account of architectural friction points, specific APIs that caused problems, and the workflow overhead of maintaining a React Native + Expo project targeting both the App Store and Google Play.

What's not covered: independent performance benchmarks, code review of the actual RN implementation, Android user metrics, revenue figures, or any comparison of build times measured independently. No claims in this review should be read as independently verified. Update cadence: re-evaluated if LastAlarmClock publishes follow-up data or if the app's public store listing changes materially.

What it does

Last Alarm is an alarm app with deep iOS OS hooks

Last Alarm schedules alarms capable of ringing through the lock screen and Do Not Disturb mode, using Apple's AlarmKit framework. It also surfaces Live Activities (the lock-screen and Dynamic Island widgets introduced in iOS 16.1) and handles in-app subscriptions. These are not cosmetic features; they require direct integration with iOS system APIs.

The React Native + Expo starting point

LastAlarmClock chose React Native at project start because they owned an Android phone and wanted Google Play and App Store coverage from a single codebase. Expo was used initially for cloud builds, then dropped in favor of local builds after cloud build costs became a concern, which required purchasing a MacBook.

Where native Swift code entered anyway

Live Activities customization required writing Swift directly inside the app's ios folder. The problem: expo prebuild --clean wipes that folder. The workaround the founder describes is tracking the ios folder in version control, letting prebuild wipe it, then checking out the Swift files manually, running pod install, and resolving whatever React Native version mismatches surfaced. This is a repeatable manual step in every affected build cycle.

Payments: RevenueCat as the escape hatch

The founder initially implemented StoreKit purchases from scratch, ran into stale-request and duplicate-request failure loops, and switched to RevenueCat. The underlying issue: Apple's SubscriptionStoreView from StoreKit, which handles the purchase UI natively, has no Objective-C implementation and therefore cannot be called from React Native. RevenueCat solved the immediate problem but is an added dependency and cost layer that native Swift developers can avoid.

What's interesting / what's not

The honest part of the post-mortem

LastAlarmClock is explicit that the problems are not React Native's fault per se. The framing is accurate: this is an architectural cost, not a framework defect. React Native does what it says. The issue is that Last Alarm's feature set (AlarmKit, Live Activities, SubscriptionStoreView) sits almost entirely in the iOS-only API surface. A cross-platform framework buys you nothing on that surface and adds overhead everywhere else.

This is a meaningful data point for indie founders because the failure mode is invisible at MVP stage. The founder notes that getting an initial MVP working on both devices "works pretty well." The friction accumulates later, when you need OS-level features that platform vendors have not exposed through cross-platform bridges.

The testing overhead is underrated

The most practically useful observation in the post is about testing overhead. Every change to the iOS app requires building for Android and running through the Play Store test build configuration process. For a solo founder, this is not a minor inconvenience; it is a multiplier on every iteration cycle. Native iOS development collapses this to: change one thing, test on one device family. The founder's conclusion, that cross-platform has ended up being more work than building natively for each platform separately, is a strong claim. It's not independently verified here, but it is structurally plausible for an app in this category.

What the post doesn't address

The post doesn't quantify Android usage or revenue. If Last Alarm has meaningful Android users, the calculus changes. The founder mentions planning to "go back and get it all squared away on Android" after iOS launch, but there's no follow-up data on whether Android ever shipped or whether it drives any retention. Without that, the "should have gone native Swift" conclusion is correct for the iOS workflow but incomplete as a business decision.

The post also doesn't address the cost of rewriting. Switching to native Swift now means rewriting a shipped app with real users. That's a different risk profile than choosing Swift at day zero. The post-mortem is useful for founders who haven't started yet; it's less actionable for founders already in the same position LastAlarmClock is in.

What's marketing copy vs. verifiable behavior

Nothing in this post reads as marketing copy. It's a candid account of workflow friction with specific API names and specific failure modes. The expo prebuild --clean / Swift file checkout loop is a reproducible scenario any RN + Expo developer with native modules can verify independently.

Pricing

This review covers tooling costs mentioned in the source, not Last Alarm's own pricing.

• Expo cloud builds: Founder switched away due to cost; specific tier pricing not stated in source.
• MacBook (local builds): One-time hardware cost, amount not specified.
• RevenueCat: Not priced in the source. RevenueCat's public pricing as of May 2026 starts free up to $2,500 MTR, then 1% of revenue. Verify at revenuecat.com before acting on this figure.
• React Native / Expo (framework): Open source, free.

Pricing snapshot: May 2026.

Verdict

For iOS-first indie apps that depend on AlarmKit, Live Activities, or StoreKit's native UI components, React Native is the wrong starting point. The framework earns its keep on apps where the feature set maps cleanly to cross-platform abstractions. Last Alarm's feature set does not. The expo prebuild / Swift file recovery loop, the RevenueCat dependency forced by the absence of an Objective-C SubscriptionStoreView, and the dual-store testing overhead are all predictable consequences of the architecture, not bad luck.

If you ship an iOS app that needs deep OS hooks and you have a Mac: start in Swift. If you genuinely need Android at launch and your feature set is UI-heavy with minimal OS integration: React Native's MVP speed is real and the tradeoff may be worth it. Those are the two positions. Pick based on your feature list, not your current device inventory.

What we'd test next

• Does Last Alarm have active Android users? If Android drives any meaningful retention or revenue, the "should have gone native" conclusion weakens considerably.
• How long does the expo prebuild --clean + Swift file restore + pod install cycle actually take in wall-clock minutes? Quantifying the overhead would make the testing-cost argument more concrete.
• Is there a React Native wrapper for AlarmKit that has shipped since this post? The ecosystem moves fast; a community module could change the calculus for new projects.
• What does RevenueCat cost LastAlarmClock per month at their current subscription volume? That's the real price of the StoreKit gap.

Pull quote: “For apps that depend on iOS-only APIs (AlarmKit, SubscriptionStoreView, Live Activities), React Native adds architectural debt that compounds faster than the initial cross-platform productivity gain offsets it.”