Why a climbing app breaks on real rock
In the gym, the app draws a smooth track, but on real rock after twenty minutes of recording the line drifts into the neighboring sector, elevation jumps by tens of meters, and battery drains twice as fast.
It is not the interface: this is how the bundle of positioning receiver, offline maps, and motion sensors behaves where no one calibrated it.
Loss of GPS signal in a gorge is the first cause. A narrow wall shades half the sky, and signals reflected off the rock arrive with a delay, and the receiver mistakes them for direct ones.
On negative slopes, two or three satellites are visible, position accuracy degrades to tens of meters, and the app draws a straight line through the terrain from the last known point.
Offline rock maps add desynchronization: tiles downloaded in advance are tied to a coordinate grid, while sector topology is coarsened to a diagram. The track lies next to the route rather than on it, and the logic “you are on the line” triggers where there is no line.
Battery consumption during track recording adds up from small things: frequent polling of the receiver, always-on screen, recording coordinates one by one instead of in batches, background syncs.
The accelerometer adds false triggers — movement on rock is jerks, changes in body orientation, and vibration, not a steady step, so auto-pause of the track and ascent counting are wrong.
We break down how this is addressed: adaptive polling frequency, local recording buffer, matching the track against route topology, and sensor thresholds tuned for climbing, not running.
What a robust app delivers: metrics and effect
A climbing app is tested not in a demo, but on a wall in a gorge where there is no connection.
That is why we record measurable indicators from the very beginning: share of routes recorded without losses, recovery time after connection loss, synchronization speed of downloaded map areas, interface response to touch.
Offline operation here is a baseline condition, not an additional feature. The track is recorded locally with accuracy sufficient for analyzing an ascent: key points, pace, belay pauses.
When network appears, track synchronization uploads only missing fragments rather than rewriting the entire route.
Resistance to connection loss is measured by time to full restoration of recording after returning to network: the buffer stays on the device, so signal loss mid-ascent does not turn into a hole in the track.
Separately, we capture the class of failures that previously spoiled statistics — track overlap when the same route is climbed again. Separating sessions by start time and ascent ID removes overlap, and route data is counted correctly.
Tracking accuracy and interface response time are directly connected. Map area loading happens in the background and does not block the screen, so the map loads while the user reads the description, and the interface responds to touch without delay.
The result is a predictable picture: ascents stop being lost, repeat attempts on a route no longer merge into one recording, and recovery after signal loss takes seconds and requires no manual actions.
Implementation options: native, cross-platform, hybrid
For a climbing app, the choice between approaches is determined not by the look of screens, but by three constraints: access to device sensors, offline operation, and speed of releasing updates.
Tracking attempts and rest time relies on the accelerometer and gyroscope, and connection to a heart rate monitor or tracker goes over Bluetooth — polling frequency matters here, and so does whether the platform allows background operation.
Offline data storage is the second most important factor: in the gym and on rock there is no connection, so workout recording goes into a local database, and the send queue goes to the server when network appears.
How deeply the data layer is integrated into the platform determines whether an attempt survives app minimization and how quickly a fix reaches users.
| Option | When it fits | Limitations |
|---|---|---|
| Native development | Maximum access to device sensors is needed, along with background recording and interface responsiveness on both platforms | Two codebases, releases run in parallel, updates ship more slowly |
| Cross-platform development | Shared logic, route catalog, training diary, and user account on a single codebase for iOS and Android | Sensor and Bluetooth access must be tested on each device, and some background scenarios are implemented separately |
| Hybrid app | Sections change often, and release speed without republishing in stores matters | Limited access to sensors and offline storage; heavy tracking hits the web layer bottleneck |
In practice, approaches are combined: tracking and recording of attempts go to the native layer, while the gym catalog, route descriptions, and breakdowns go to shared code that updates without rebuilding.
We map scenarios by the required level of hardware access and only then choose the scheme — otherwise the app hits the platform ceiling already at the beta testing stage.
Stages of climbing app development
A climbing app works in two modes: at home, where connection is stable, and on the crag, where there is none. Hands are busy, the phone is in a pocket, the screen must be readable in sunlight — so we build the order of work around the offline core, not around the interface. Below are the development stages we go through on every such project.
- Scenario analysis on rock. We go to the crag: how users find a route, mark an ascent, compare against the diagram. We record which actions must work without network.
- Data schema. What is stored on the device, what on the server, how records are numbered, and how conflicts between devices are resolved.
- Navigation prototyping. We test on the route: how many taps to mark an ascent, whether the diagram is readable while wearing a glove.
- Implementation of the offline core. Local storage, change queue, deferred sending to the server.
- Synchronization when connection is restored. We think through mid-route disconnection, repeat login, and device change, not just the standard scenario.
- Field testing. Real outings: weak signal, low battery, rain and cold on the wall.
- Handover and support. We provide source code, data schema documentation, and the update procedure.
Maps, sensors, and offline storage: how it works
Offline maps are not “downloaded everything just in case” indiscriminately, but an explicit download of a selected area.
The area is defined by a bounding box or radius around a point, and only the required zoom levels are pulled from the map dataset: for the approach, a schematic layer is enough; detailed is needed where the user studies holds and belay points.
OpenStreetMap data and sector diagrams are placed in one local container, so the map opens without network and without waiting for a server response.
Motion sensors are the most battery-expensive layer, so there is no constant polling in the app. We subscribe to accelerometer and barometer events and change polling frequency depending on the situation: approach to the rock, climbing, long stop at a belay station.
Until activity is recognized as climbing, sampling is less frequent — the track remains coherent, and battery consumption is roughly like in ordinary navigation.
The local route cache is structured as a journal, not as a single file that can be lost entirely: points are written in chunks, and background recording goes through the system scheduler, which works while the screen is locked.
The process can be unloaded from memory at any moment, so after restart the track is assembled from the last checkpoint — seconds are lost, not the entire ascent. With no network for a week, points simply accumulate on the device and do not interfere with recording new ones.
Track merging is where expectations most often diverge. One ascent may be recorded from two devices, break off when signal is lost, and continue from another point; during synchronization, overlapping intervals, duplicates, and coordinate discrepancies appear.
We resolve this with a deterministic rule: priority goes to the recording with denser sampling, duplicates within a window are discarded, and the gap is closed by interpolation — the output is one coherent track instead of two incomplete ones.
Bottom line: in the mountains there is no network, hands are busy, the screen is locked. That is why all layers are designed for failure — preloading instead of on-demand loading, events instead of polling, a journal instead of an in-memory buffer.
What the client receives after project delivery
Project delivery is not just an app that opens and works. We hand over a set of artifacts your team or another contractor can use to develop the product without us: from the repository to instructions on what to do if a service fails. Below is exactly what you will have on hand.
- Source code and build. A repository with change history, access to build services, signing keys, and instructions for releasing release and test builds on a clean machine.
- Architecture diagram. App layers, modules, external services — maps, authorization, route storage — and the points where data is cached and synchronized.
- Project documentation. Module descriptions, storage formats for routes, workouts, and achievements, server-side requirements, data dictionary.
- Offline documentation. What works without network, how synchronization conflicts are resolved, how the app behaves when connection drops in the gym or on rock.
- Update procedure. How a version is released, who approves it, how rollback is prepared, and what is checked before publishing to stores.
- Failure monitoring instructions. Which errors and events are collected, which thresholds are considered normal, who receives a notification, and what to do for each scenario.
- Access and rights. App store accounts, certificates, publishing rights, transfer of ownership to your organization.
- Acceptance checklist. Tested scenarios from registration to recording a route without network, with expected behavior for each.
Handover goes together with acceptance: we demonstrate each item on the live product, not just on paper.
How does offline mode differ from on-the-fly caching?
On-the-fly data caching fills storage reactively: the user opens an area diagram — the app fetches it from the server and keeps it in memory until eviction.
Offline mode works differently: the area is downloaded in advance and in full, together with the layers that will be needed on the route. The difference is visible not in the interface, but in what is on the device by the time there is no connection.
Preloading areas is a deliberate choice of region and dataset: topo diagram and approaches, difficulty grades, route descriptions, belay points, descent diagrams. The package comes with checksums, so a repeat visit to a familiar area downloads only changes. The app shows in advance how much space the area will take, and the decision remains with the user.
Working without connection exposes the difference instantly. With on-the-fly caching, any zone not scrolled to at home remains empty: on the rocks it turns out that the neighboring sector is exactly what is needed. Preloading covers the area in full, including access roads and backup escape routes.
Then comes the engineering of compromise. Downloaded areas live in separate storage and are not evicted, so memory volume grows predictably and is limited by a rule: old areas are deleted by recency of access.
On-the-fly cache lives by eviction and constantly raises the connection — intermittent downloads on the route noticeably drain the battery. We usually build a hybrid: frequent areas are preloaded, rare ones are left to on-demand cache.
Case study: how the share of recorded routes grew
We received the climbing app at a stage when the core already worked, but long routes far from the city fell apart.
The track was written to memory and sent to the server in one packet only with a stable connection: if there was no connection for a couple of hours, the session disappeared entirely — along with the completed path, attempts, and statistics.
The second wave of user feedback concerned battery consumption: the phone died by the end of the approach, and recording was already physically cut off.
We rewrote the recording layer: the track is saved locally in small chunks and immediately marked as unsynchronized, while sending goes through a queue with partial upload — a network drop no longer erases what has already been recorded.
Sensor polling was tied to actual motion and screen state, maps are cached in advance, and the background part stopped waking the app unnecessarily.
What the metrics showed
- share of lost tracks: 17% → 1.8%;
- session synchronization time after returning to network: ~40 s → 4–6 s;
- battery consumption over a four-hour approach: 34% → 11%;
- share of started sessions that reached a saved route: 62% → 94%.
User feedback shifted accordingly: complaints about battery drain and “missing” workouts occur several times less often, and the average rating rose from 3.4 to 4.6.
We also addressed integration with Garmin watches — a session started on the wrist is correctly picked up by the phone, so the route remains intact when switching between devices.
Technical concerns before starting work
Engineering concerns before starting are not about appearance, but about how the app behaves in the mountains and over a long support distance. Below are the points that clients most often ask to settle before work begins.
How does the app work in an area without connection?
The map, topo, and route points are stored in a local database on the device, and the track is written there as well. Records are queued and go to the server when network appears; conflicts are resolved by the time of the last change — data is neither lost nor overwritten.
How accurate is the marker on the route?
Under the wall and in a gorge, the satellite signal reflects and produces jumps.
The track is smoothed, outliers are cut off, and the position is supplemented by readings from inertial sensors and the barometer — the marker stays on the route section instead of jumping around the rock.
Will you integrate the app with our services?
Mapping, weather, payment acceptance, login through an existing account system, and track export are connected through a separate integration layer. Replacing a service affects only this layer; screens and logic remain the same.
What about support for older devices?
We choose the minimum OS version based on data about which devices are actually in use among the audience. On weak devices, heavy map layers are disabled while the interface remains functional; we test on physical devices, not only emulators.
What determines the scope of support?
It is determined by the number of platforms and supported OS versions: a wider device fleet means more build branches and test runs. We fix the procedure for planned updates for new OS versions in advance, so support effort is predictable.
Let's discuss your task and come back with a plan
So that the project estimate is based on facts rather than assumptions, we need to understand the domain: how the route catalog and difficulty grades are maintained, where the boundary of offline mode lies, and how the app works with geolocation and sensors in a climbing gym and on natural terrain.
Describe the task in your own words — what already exists and what is missing:
- product goal: route catalog, ascent diary, training plans, community, or a combination;
- audience and scenarios: beginner in the gym, athlete on an outdoor trip, instructor, climbing gym administrator;
- current work: prototypes, design, server side, route data, if already collected;
- constraints: platforms, timelines, requirements for offline operation and data synchronization;
- access and integrations: app store accounts, analytics, payment and CRM systems.
In response, we will come back with a project estimate and work plan: team composition for the task, stages with a verifiable result at each, timeline for developing the first working version, and the order of further releases.
We will separately show which decisions require your choice and which we handle ourselves. Write to us — we will discuss the task and schedule a short review with engineers.