Mobile app for a ski resort: where it breaks
A ski resort mobile app is tested not in a demo but on the slope. The trail map in the app loads tiles over the network, but in a hollow and at the upper station there is no signal — the screen shows gray tiles exactly when the tourist is deciding where to go. Below the start level, the phone enters cold mode, and the request to load more simply times out.
The costliest failure is a ski pass failure at the lift: the app reads the tag via radio channel, but the system has managed to unload it from memory, the radio module is idle, and the queue of unsent passages is not saved anywhere.
The queue at the lift grows, some passages are not counted — and the resort learns about it from the tourist, not from its own statistics.
The GPS track is lost in a hollow: satellites are visible, but recording only happens with a live connection, and background work is strictly limited by the operating system.
The track breaks, elevation gain and speed are calculated incorrectly, the numbers in the personal account diverge from actual skiing — and trust in the app falls faster than the error is fixed.
The root cause of all three failures is the same: offline mode on the slope is designed as a temporary exception, although it is the main scenario. The map, ski pass and track must work from local data and sync when connection appears. We analyze how this is closed at the architecture level.
What the solution gives: trail map, ski pass, tourist tracks
The user opens the resort map in freezing cold and often without network, so map fragments and trail layers are preloaded on first launch and stored in local cache, while updates are pulled in small portions.
Map opening takes one to one and a half seconds instead of five to seven with constant loading from the network, and the map remains live where connection drops.
People are used to the smoothness of the track line from sports services like Strava — they read breaks and "jumps" as app malfunction, not as a feature of the mountains.
The electronic ski pass in the app is a separate responsibility: the pass identifier is stored on the device, passage is confirmed offline, and events accumulate in a queue and upload when the network returns.
The turnstile does not "go blind" when connection drops, the share of successful passages stays above 99%, and incident analysis at lifts stops being a daily support task.
Tourist tracking on the slope is built on buffering: points are written to the device, sent in batches when network appears, and duplicates are filtered by IDs.
The share of lost tracks falls from tens of percent to single digits, and the security service sees the last known location even if the person went into a "dead" zone.
High season is peak weekends when load grows several times in an hour. Horizontal scaling, edge cache and separation of urgent and background requests keep response steady, so support requests phrased "app doesn't work" become an order of magnitude fewer.
Implementation options: native build, shell, web version
The choice of option is determined by three conditions: operation at sub-zero temperatures, autonomy without network on the slope, and direct connection with ski pass readers at turnstiles.
A native app gets access to communication and power-saving modules — the map remains responsive in cold, and charge doesn't go past half a day of skiing.
A cross-platform build is cheaper to maintain, but some system limitations are removed only by separate modules for each platform.
The key question is how close the app gets to the hardware. Reading a ski pass, checking passage right and recording an event require either a native layer or a ready-made kit from a turnstile vendor.
The web version is good as a storefront, schedules and ski pass sales, but offline work and reader work are cut down in it.
| Option | When suitable | Limitations |
|---|---|---|
| Native app | Ski pass reading, offline map, route track | Two codebases, slower release of updates |
| Cross-platform build | Map, schedules, track without reader | Access to hardware — via vendor modules |
| Web version | Storefront, ski pass sales, schedules | No offline and no direct work with reader |
In practice, a mixed scheme is more often chosen: sales and information — web, slope and lift access — native core. This way compatibility with access systems doesn't depend on platform limitations.
Work stages: from trail audit to access handover
Work begins with an audit of data on lifts and trails: we find out which resort systems provide queue status, opening statuses and schedules, at what frequency, in what format, and who owns each field.
In parallel, we fix the cartographic base — whose tiles and trail maps we use, how often they change and what to do when they diverge from reality on the slope.
- Audit of data on lifts and trails. We collect a list of sources, verify lift and trail identifiers against actual signs on the ground, and agree on a priority rule if a dispatcher's manual edit contradicts the export.
- Exchange scheme with resort systems. We describe contracts: what we request, what we cache locally, how we verify ski pass authenticity and what we show the guest if there is no connection.
- Map and offline layer. We assemble styles, zones, hazard layers and points of interest, and calculate package weight so the app can download over mobile network and open at -20 °C without network.
- Build and automated tests. We separate map, ski pass and track modules, and cover with checks the parsing of lift states, stitching of GPS track and recovery after a break.
- On-slope testing. Field trip with real lifts: cold, gloves, transition between communication towers, comparison of recorded track with reference log and analysis of discrepancies by ascents and descents.
- Access handover. We hand over repositories, signing keys, store accounts, access to resort systems, exchange scheme and instructions for the on-duty person — with a recording of the training session.
After each stage we record the result in a document that remains with the client: it also becomes the basis for the next iteration when the resort changes trails or adds a lift.
Handover package: schemes, regulations, accesses, documentation
A resort app rests not on screens but on connections with internal systems: ski pass sales, turnstiles, trail directory, rentals. If these connections are described only in correspondence, every update of slopes or tariffs runs into downtime.
Therefore, in the handover package we include documents according to which your team can work without us.
- Integration scheme: which systems exchange data, in what format, at what frequency, and what happens when a source is unavailable.
- App documentation: module composition, build environment requirements, list of external dependencies and release procedure to app stores.
- Roles and accesses in the panel: a "role — section — action" matrix for rentals, slope dispatcher, marketing and support; separately — who has the right to change tariffs and publish trail status.
- Map update regulation: where the base layer comes from, how trail and lift layers are loaded, who approves and how correctness is checked before publication.
- Instructions for rental service: shift, issue and return of equipment, marking damage, resolution of disputed charges.
- Release and rollback regulation: who signs off the update, how to roll back to the previous version if the build breaks the map, payment or ski pass.
- Control and alert points: what is checked, at what thresholds a signal is sent and who it is addressed to at night.
We write documents for your processes — with names of your departments and real accounts. After handover, we stay in touch according to the support regulation so that logic doesn't have to be reconstructed from code.
Case study: trail map and ski pass for a mountain resort
A resort with several skiing zones and dozens of trails came with two related problems: a guest on the slope didn't understand where they were and how to return to the right lift, and passage through the turnstile depended on connection quality.
A plastic ski pass, if lost, could only be restored at the ticket office, and the trail map was loaded from the server — in roaming and in the cold it either didn't open or opened after the person had already managed to go the wrong way.
What was changed
We moved the map to an offline package: vector layers of trails, lifts and food points are downloaded to the device and updated when connection appears, so it appears on screen instantly and works without network.
We linked the ski pass to the guest profile, and passage events began to accumulate in a local queue: if there is no connection, the passage is still recorded and goes to the server later, without re-tapping.
The same ski pass was put into Apple Wallet — the guest doesn't need plastic, and the turnstile doesn't need a permanent channel to the server.
Metrics before and after
| Metric | Before | After |
|---|---|---|
| Successful passages through turnstile | 9 attempts out of 10 | 99 or more out of 100 |
| Trail map opening without network | 5-8 seconds or blank screen | less than a second |
| Support requests about navigation | sharp increase on peak load days | decrease by roughly three times |
Support load stopped growing along with guest flow: questions "where am I" and "ski pass doesn't work" left the first line, and remaining requests mainly concern refunds and season passes.
This ski resort case set a standard set of solutions for us — offline map, ski pass in profile, passage resistant to connection loss — and we transfer it to similar sites: from small slopes to resorts with several skiing zones.
How does an offline map differ from online data loading?
An offline map is a package of tiles and trail maps that lies in the app's file storage and doesn't depend on network. It is downloaded once before the trip, unpacked locally and drawn from device memory; online loading instead requests tiles as you move and at every zoom change.
On the slope there is no stable channel: terrain, forest, network overload at peak hour at the lift break the connection for minutes.
At that moment the online map is incomplete — tiles arrive with delay or don't arrive at all, and the track gets breaks that cannot be restored later.
Updating the offline package is a separate step: the app compares the version of the local set with the server one, fetches only changed sections over the appeared channel and replaces the file after integrity check.
The tourist doesn't end up in a situation where the map is half-downloaded: either the previous version works or the new one entirely.
In device storage we keep the trail and lift map, points of interest, directory and service layers — this is a few megabytes, they don't compete with photos and videos.
The track and marks are written to a local queue and go to the server at the first available network, so loss of signal on the slope doesn't turn into lost data.
For the tourist, the difference is visible in the first seconds: the offline map opens instantly and equally in the lift, in the forest and in the lowland, and searching for a trail and meeting point works without waiting.
We leave online mode to reference layers — weather, schedule, promotions — which are not critical while moving.
Common technical questions before starting work
Before starting, three things are usually checked: how the app behaves outside coverage, who updates the trail map every season and whether lift equipment will have to be changed. Below are answers in the form in which we discuss them at the evaluation stage.
How does the app work where there is no network?
Map and track are built on local data: terrain fragments and trail map are downloaded in advance, and the ride recording goes to phone memory. When connection appears, the accumulated data goes to the server as a queue — loss of signal doesn't erase the track. We run scenarios in cold and with fast battery drain, when the app is minimized for half a day.
What happens when trails change every season?
Trail map, difficulty levels and points of interest are stored as data, not as part of code. The new configuration is loaded from the server, and the app picks it up without re-releasing in app stores. For the resort service we make a simple editor — edits are made without developer involvement.
How is the app connected to the ski pass system?
We connect to the access system that already works at the lifts and read ski pass status through its standard access points. There is no need to change turnstiles or reissue cards — the app integrates into the existing environment.
Who is responsible for updates after launch?
Releases for new mobile OS versions, failure monitoring, trail data updates and on-duty support in high season. We fix the regulation and response time in the support contract before work starts.
Let's discuss the task and come back with an estimate and plan
To discuss the task and come back with an estimate and work plan, rather than general considerations, we need initial data to start.
Below is the minimum that removes most unknowns; if something can't be found, we'll suggest what to replace it with and how to assemble it during the project.
- Trail map with georeferencing: boundaries of sections, elevation changes, start and finish points of lifts — both the map and track recording are built on them.
- Resort rules and restrictions: closed zones, avalanche conditions, lift schedule — the logic of on-slope alerts depends on them.
- Access to the access control and ski pass system: test environment, passage export, method of verifying carrier authenticity. Without this, neither balance nor skiing statistics can be assembled.
- List of scenarios important specifically to you: ski pass purchase, track, weather, alerts, ski school booking — we'll break them down by stages and estimate each.
- Contact of the operations service on the resort side: a person who knows how lift equipment works and who to contact in case of failure.
- Brand materials and design requirements if the app is released under your name.
- Existing sales, customer accounting and weather service systems — name those already in use, and we'll agree on the data exchange format.
On our side, we'll review what you sent, clarify disputed points and come back with stages, timelines and scope of work for each. Describe the task — we'll respond with specifics for your resort.