Native or cross-platform: deciding on evidence rather than preference
Both approaches build excellent products. The decision follows device capability requirements, team composition and roadmap shape.
ZooBieDoo Infotech Engineering TeamRead
Key takeaways
- Cold start is the most visible performance characteristic.
- Dropped frames come from main-thread work — move it off.
- Battery complaints trace to background wake-ups and chatty networking.
- Profile on mid-range devices, not flagships or simulators.
Cold start is the first impression
The time from tap to usable content is the most visible performance characteristic an app has. Work done eagerly at launch — initialising analytics, loading configuration, warming caches — accumulates until start becomes noticeably slow.
Defer everything not needed for the first screen, initialise heavy dependencies lazily, and show meaningful content as soon as it is available rather than a spinner until everything is ready.
Smooth scrolling is about the main thread
Dropped frames come from doing too much work per frame: layout that is too complex, images decoded synchronously, or business logic running on the interface thread.
- Decode and resize images off the main thread, at display size.
- Recycle list cells and avoid deep view hierarchies.
- Move parsing, filtering and sorting off the interface thread.
- Profile on a mid-range device, never only on a flagship.
Battery and network
Battery complaints usually trace to background location, frequent wake-ups, or chatty networking that prevents the radio from sleeping.
Batch network requests, respect system scheduling for background work, and reduce polling in favour of push where possible. Users uninstall apps they believe drain the battery, whether or not the belief is precisely accurate.
Measure on real devices
Simulator performance tells you almost nothing about the experience on a three-year-old mid-range Android phone, which is what a large part of your audience is using.
Keep a small device lab covering the range your analytics show, and track startup time and frame statistics as release gates rather than investigating them after complaints.
Perceived performance
Measured performance and felt performance are different things, and users only experience the second. An app that shows meaningful content in stages feels faster than one that waits and then shows everything.
Use skeleton screens rather than spinners so the layout is established before content arrives, avoiding a jarring shift. Respond to touches immediately even when the underlying work has not completed — an optimistic state that reconciles later reads as instant.
Prefetch what the user is likely to need next based on where they are. Small anticipatory work removes visible waiting at the moments people notice it most.
Frequently asked questions
Under two seconds to usable content is a reasonable target on mid-range hardware. Beyond about four seconds, abandonment rises noticeably.
Platform profilers show a timeline of startup work. The cause is usually a small number of synchronous initialisations that can be deferred.
Yes, for installation and update conversion, particularly on limited connections and cheaper devices. Removing unused assets and libraries is usually straightforward and worthwhile.
