What 1C mobile app debugging really involves
The 1C mobile platform lets companies build apps for sales agents, couriers, merchandisers or warehouse staff. The logic follows the same principles as a regular 1C configuration, but it runs on a phone or tablet, with its own constraints: patchy connectivity, battery saving, different Android and iOS versions, and small screens.
So debugging is not a single action but a chain of checks. Does the code run correctly? Is data stored on the device? Does synchronization with the central database lose nothing? Is the interface usable on real screens? A fault can hide in any of these links, and searching blindly gets expensive.
Prepare a test setup before hunting for the bug
The biggest time sink in debugging is trying to reproduce a problem in a different environment from the user’s. If an agent in Samarkand sees the app crash while uploading orders, testing it only on office Wi-Fi in Tashkent proves very little.
Agree in advance which devices count as reference devices, which platform and configuration versions run on them, and where the test database lives so it cannot touch live data. Also document how the debugger connects to the device: usually the computer and the phone must see each other on the same network, and the required ports must not be blocked by a firewall.
Where 1C mobile solutions usually break
Problems in this kind of project fall into a handful of typical groups. It is more efficient to check them against a list than to guess.
- Synchronization: documents get duplicated, lost or delayed on an unstable mobile connection.
- Versions: after the central database is updated, the mobile configuration no longer matches its structure.
- Offline mode: data needed in the field was never loaded onto the device beforehand.
- Performance: heavy queries and large reference lists slow the app down on budget phones.
- Interface: forms that look fine on a monitor are awkward in a courier’s hand or in a warehouse.
- Device features: camera, geolocation, barcode scanning, push notifications.
A step-by-step debugging routine
Start by reproducing the issue: record which device, at what moment and with what data the failure occurs. Without an exact scenario, every fix is a guess.
Then attach the Configurator debugger to the app on a device or emulator and set breakpoints in the suspicious areas. Turn on logging at the same time, because event records help when an error appears for one employee and never in front of you. After a fix, check not just the corrected spot but neighbouring scenarios too, and run a full exchange with the central database.
The app is one link in a chain: website, payments, analytics
What matters to a business is not that the app launches but that it brings in orders and does not leak money. If orders from the app land in 1C while customers also buy on your website, confirm that stock, prices and statuses match across both channels.
If you accept payments through Click or Payme, test more than the successful payment: cancellations, repeated submissions and dropped connections too. Add basic analytics for opening the app, placing an order and errors. Without it you cannot tell whether the app pays for itself or the budget for fixes is simply being spent.
Who to hire and how to accept the result
Debugging on the mobile platform is best given to someone who knows that platform specifically, not only classic desktop 1C. Ask the contractor how they will reproduce errors, which devices they will test on and what you will receive at the end: a list of fixes, test scenarios and an update guide.
Accept the work against scenarios, not impressions: let real employees spend a working day in the app. If the app has to work with a website or online store, plan that from the start so the exchange is not rebuilt later.
markdev builds turnkey websites in Uzbekistan, including integrations with accounting systems and payment services. If you need to link a 1C mobile app to your website, or find where leads are being lost, describe the task and we will suggest a sensible order of work.
FAQ
Can I debug a 1C mobile app without a physical phone?
Partly. An emulator helps check logic and layout, but network behaviour, camera, geolocation and speed on weak devices only show up reliably on real phones.
Why does the app work in the office but not in the regions?
Usually the cause is unstable internet, exchange timeouts, or data that was not loaded onto the device in advance. Reproduce the failure in conditions close to real work.
What should I prepare before contacting a contractor?
The platform and configuration versions, a step-by-step description of the failure, a list of devices, access to a test database, and screenshots or logs of the errors. This noticeably shortens the search for the cause.
How do I know debugging is finished?
When typical working scenarios pass on the reference devices, the exchange with the central database loses no data, and users confirm the failures no longer repeat.
Let’s look at your task for free
Leave your contact — in a 15-minute call we’ll show where leads get lost and what to fix first.