Mobile Application Support: Monitoring, Hotfixes and OS Updates
Application in App Store — this is not completed project, but a living system. iOS 18 changes Background App Refresh behavior. Android 15 tightens foreground service policy. New iPhone 17 with different aspect ratio breaks hardcoded layout. All this requires reaction without full development cycle.
Crash Monitoring in Production
Firebase Crashlytics sends alert on crash rate rise above threshold. But receiving notification is not enough — you need a response process.
Metric to watch first: crash-free users rate. Below 99.5% — warning signal. Below 99% — incident. Google Play Console and App Store Connect show their own metrics calculated differently than Crashlytics — discrepancy is normal.
Typical scenario: after iOS 18.1 release a new crash appears in UISheetPresentationController on iOS 18.1 devices with specific app version. Crashlytics shows 0.3% affected users, but growing velocity. Operatively: verify on device, find cause (behavior change of detents in iOS 18.1), release hotfix.
For React Native additionally use Sentry with breadcrumbs — see what actions preceded crash. For Flutter — sentry_flutter with WidgetsFlutterBinding.ensureInitialized() and runZonedGuarded.
Hotfixes: What Can Be Done Without Store Release
App Store does not allow changing executable code without review (Review Guideline 2.5.2). But there are legal mechanisms for operative intervention.
Remote Config (Firebase or custom) — behavior change via flags without update. Disable problematic feature, show maintenance banner, change URL endpoint — all without release. Critical for monetization experiments and quick rollback.
OTA updates (React Native): react-native-code-push (Microsoft CodePush) or Expo Updates allow updating JS bundle without App Store. Limitation: JS code only, native modules require full update. Still falls under guideline restrictions on abuse — can't change key functionality via OTA.
Expo EAS Update — modern CodePush alternative for Expo projects with channel support (production/staging) and rollback.
OS Updates: Preparation and Testing
Apple announces iOS beta in June (WWDC), final release — in September. This gives three months for testing. In practice, many teams start in August and get surprises on release day.
Critical areas to check with every major iOS update:
- Privacy Manifest — mandatory from iOS 17 for certain API usage. Without it reject on review
-
UIScenelifecycle changes - Changes in
UICollectionViewandUITableViewanimations - Swift Concurrency behavior
On Android similarly: target SDK must update annually (Google Play requires targetSdk minimum Android -1). Moving from targetSdk 33 to 34 changes behavior for foreground services, broadcast receivers, implicit intents.
Technical Debt and Planning
Support is not just bug reaction. Plan technical debt in backlog: outdated dependencies with known vulnerabilities (npm audit / bundler-audit), deprecated API to be removed in next Xcode, unsupported libraries.
Dependency updates via Dependabot (GitHub) or Renovate automatically create PR on new releases. This doesn't replace testing, but prevents "we haven't updated libraries in two years" situation.
Minimum supported OS version — review annually. Apple publishes version statistics, Google — Android distribution dashboard. Raising minimum from iOS 15 to iOS 16 allows removing significant amount of workaround code.
Response timeline for crash: critical crash hotfix (crash rate >1%) — within 24-48 hours before release, 3-7 days before Apple review pass (Expedited Review available for critical security and functionality issues).