compose multiplatform ui or two native uis with two devs and four months interop

Share the logic, write the UI twice. That is the version of this I have seen work repeatedly and the version I would bet four months of runway on.

The logic layer - networking, models, validation, the offline cache, the sync rules - is genuinely the same on both platforms and it is also where the bugs live. Sharing it means one implementation, one test suite, one place where a subtle sync bug gets fixed. That is a real and durable win.

The UI is where the sharing story gets expensive, and the cost is not in the screens. Your list screen and your form will look right on both platforms quickly. The bill arrives in:

• text input. Selection handles, the keyboard toolbar, autocorrect, password autofill from the system keychain. Users notice immediately when this is subtly wrong and cannot tell you why it feels off.
• accessibility. It works, but the two systems have different mental models and matching what VoiceOver users expect takes real effort.
• scroll physics and the small system gestures. Deceleration curves, rubber-banding, edge swipe back. Anything slightly off reads as "this is not a real app".
• the camera flow you mentioned. That is platform code either way.

So you save on screens and pay it back on behaviours, and the payback lands late - in month three, when you have no time.

With a Swift-weak second dev, the compromise I would actually make: share logic via KMP, write the Android UI properly, and make the iOS UI deliberately simpler. Fewer screens, less custom, no clever animations. A plain iOS app that behaves correctly beats a rich one that feels foreign.

Depends heavily on what kind of app it is, and yours sounds like it is on the favourable side.

Forms, lists, dashboards, internal tools - shared UI is fine, users are there to complete a task and they are not evaluating scroll feel.

Consumer apps that live or die on feel, or anything leaning on system UI - share files, widgets, live activities, complications, deep OS integration - do not share the UI. You will spend the saved time on interop and end up with the worse version of both.

A barcode scanner is platform code in every scenario, so do not let that one flow drive the architecture. Write it twice, it is a small screen.

Contrarian take on the constraint itself: with four months and two people, consider shipping one platform.

Pick whichever has your users, ship it properly, get paying customers, and then decide about the second with revenue and real feedback instead of a guess. Half of the second platform's design decisions will change once you have watched people use the first one.

Two mediocre apps in four months is a worse outcome than one good one, and the cross-platform question resolves itself once you know what you are actually building.

If you do go shared, know the escape hatches before you need them, because you will need them. You can host a native view inside the shared UI, and you can host shared UI inside a native screen. Both directions work.

The part people underestimate is state across the boundary - a native camera view that needs to write back into shared state is more plumbing than you think, and it is the kind of code nobody wants to own. Budget for a few of those rather than assuming zero.

Worth trying the shared approach for two weeks on the list and detail screens before committing. Two weeks of real code tells you more than any thread, and if it feels wrong you have lost very little.

The camera flow is going to take three weeks regardless of every other decision in this thread.