Shipping app, real users, revenue that matters to me. Everything else in the dependency list looks fine.
The blocker is a bluetooth library whose readme says new architecture is not supported. It is the core of the product so I cannot drop it, and the last commit on it was a while ago so I am not waiting for anyone.
Do I turn it on and find out, or is waiting the sensible call here?
App ships, app makes money, nothing is on fire. The boring answer is wait until you have a reason. A bluetooth library that works is worth more to your users than an architecture that is technically better.
That works right up until the reason arrives as "we cannot upgrade the SDK", and by then it is urgent, you have no slack, and you are doing the migration and the SDK bump in the same week. Waiting is a real option but it should be a decision with a date on it, not a default.
The direction of travel is one way and it is worth naming. Each release makes the old architecture more of a special case and fewer maintainers test against it. Migrating in six months is the same work you would do today, plus six months of new code written against assumptions you will then have to revisit.
You can enable it per module, so you can leave the bluetooth library on the old one and move everything else.
Not quite. The interop layer lets old-style modules run under the new architecture, which is a different thing from running two architectures side by side. It is one flag for the whole app, and then a per-library question of whether that library survives the transition. Worth being precise about because "per module" makes it sound like there is a safe partial state, and there is not.
If you do it, ship it as its own release with nothing else in it. Then anything that breaks is unambiguously the architecture, and the rollback is one flag rather than an archaeology exercise across four features.
Budget for one weird visual regression somewhere in a scroll view or a modal. There is always exactly one, it is never where you expect, and it takes an afternoon.
@deadbug_wiring · 4mo ago · 3 replies
Find out what "not supported" means for that specific library before you decide anything, because the phrase covers two very different situations.
If it is a native module with no UI - which most bluetooth libraries are - the interop layer usually carries it fine and the readme is just a sentence nobody updated in eighteen months. If it ships a custom view manager that reaches into internals, that is the genuinely broken case.
Branch, flip
newArchEnabled, build, run your bluetooth flow on a real device. One hour. That hour is cheaper than either decision made blind, and you will spend more than an hour reading opinions about it.Reply
Report
@rest_day_rita · 4mo ago
The community directory has a new architecture flag per package and it is mostly right, but it lags reality in both directions. Useful for a first pass, not a substitute for building it.
Reply
Report
@stack_trace_sy · 4mo ago
Test on hardware, not the simulator. Interop differences show up in the view hierarchy and in native lifecycle timing, and a simulator will happily tell you everything is fine.
Reply
Report