Barcode Plugin Breaks on Android 13 and Blocks the iOS Build
PortLine's warehouse app uses a community Cordova barcode plugin. It worked on Android 11 development builds. After the team raised target SDK to 33, scanning fails silently on Pixel 7 devices; logcat shows a missing CAMERA permission. The plugin was last updated three years ago. The iOS build in MABS now fails because the plugin references a deprecated framework. PortLine has six weeks before go-live and no native iOS developer on staff. Scanners handle 1,200 scans per day in a steel warehouse with no connectivity; a scan must return in under two seconds. The team is considering three options: keep the plugin and patch permissions, call a cloud barcode API from the device camera, or build a custom plugin. They also have 200 older Android 9 devices that must keep working.
1. Evaluate the three options against the constraints and recommend a path.
Read the worked answer
The cloud API option fails the core constraints. The warehouse has no connectivity, and a round trip to a cloud decoder plus image upload will not reliably return in under two seconds. It also sends warehouse images offsite, which may raise its own review. Rule it out for the primary scan path.
Building a custom plugin is technically valid but risky in six weeks with no native iOS developer. You would need Android and iOS implementations, permission handling, MABS compatibility, and testing across Android 9 and 13. That is a large surface for a small team, and the iOS build is already failing.
The pragmatic path is to replace or fork the plugin. First check whether a maintained plugin with recent releases supports both platforms and runtime permissions; if so, swap it and budget time for regression testing. If not, fork the existing plugin, add Android runtime permission handling, and update the deprecated iOS framework reference. That keeps the native surface small and preserves the offline, sub-two-second requirement. Keep the cloud API only as an optional fallback for damaged barcodes when online, not as the primary path.
2. How should the app request and handle the camera permission on Android 13 so scanning fails gracefully rather than silently?
Read the worked answer
A manifest entry alone is not enough on modern Android. The app must request the CAMERA permission at runtime before the first scan, and the plugin must expose a way to check and request it. On first scan, check permission state. If not granted, show a rationale and request it. If granted, start the scanner. If denied, show a clear message and do not open a black camera view.
Handle the permanent-denial case separately. If the user selects 'don't ask again' or denies twice, the request returns denied without a dialog. The app should explain that camera access is required and offer a button that opens the app settings page. Do not loop the request.
Also handle the older Android 9 devices, where the permission model differs, and test both. Log the permission state and plugin error code so silent failures become diagnosable. The scanner should have a manual barcode entry fallback so a permission problem does not stop warehouse operations entirely.
3. What build and release risks should PortLine manage in the six weeks, and what is the fallback plan?
Read the worked answer
The biggest risk is discovering another incompatibility late. The plugin is three years old, MABS has moved on, and the iOS failure is already a signal. Mitigate by doing a spike in week one: build both platforms with the candidate plugin, test scan latency on a Pixel 7 and an Android 9 device, and verify the iOS build in MABS. Do not wait for feature-complete to test packaging.
Second, pin versions. Record the plugin version, MABS plugin configuration, target SDK, and iOS framework changes so a rebuild is reproducible. Third, keep a manual-entry fallback and a feature flag that can disable scanning without shipping a new build. Fourth, test offline behavior explicitly: airplane mode, scanner open, scan, commit, then reconnect.
The fallback plan is a maintained commercial or community plugin, not a cloud API. If the fork cannot build on iOS by the midpoint, switch to the maintained plugin and accept a narrower feature set. Communicate that decision point in advance so the six-week date is protected.