Development of a Mobile Application for Government Services

You need a mobile app for government services, but integration with ESIA, Goskey, and SMEV is complex, and data protection laws like 152-FZ require strict compliance. We build turnkey mobile apps for government services, handling the regulatory maze so you can focus on delivering value to citizens.

Problems We Solve

The most painful point is authorization via ESIA and Goskey. ESIA uses OAuth 2.0 with modifications — not standard. Request signing is GOST R 34.10-2012, not RSA. Standard libraries like AppAuth for iOS and Android won't work directly; you need either the Rostelecom SDK or implement signing yourself via CryptoPro or ViPNet.

On Android CryptoPro CSP is embedded as an .apk provider or through a JCE provider. The user's certificate resides in the CryptoPro storage, accessed via a custom KeyStore provider:

val keyStore = KeyStore.getInstance("CryptoProKeyStore") keyStore.load(null) val privateKey = keyStore.getKey(alias, null) as PrivateKey val signature = Signature.getInstance("GOST3411withGOST3410EL") signature.initSign(privateKey) signature.update(dataToSign) val signedData = signature.sign() 

On iOS it's trickier — no native GOST, so we use the ViPNet CSP SDK via an Obj-C/C++ wrapper. Bridging Header, static linking, manual memory management in critical spots. On one project, this increased cold start from 1.2 to 2.8 seconds — we had to move provider initialization to a background thread with a readiness check before the first crypto operation.

Goskey is integrated via Universal Links: the app forms a signature request, passes it to Goskey via a URL scheme, and receives a callback with the signed document. The scheme works, with a nuance — if Goskey is not installed, a fallback to the web version or a QR code is needed. Handle this in UIApplicationDelegate / Activity.onNewIntent carefully: the screen state may change while the user is in Goskey.

Step-by-step Goskey Integration

1. Set up a Universal Link in the app for the government services domain.
2. Form a signature request with a unique document ID.
3. Open Goskey via a URL scheme with request parameters.
4. Handle the callback via continuation/onNewIntent and verify the signature.
5. Implement a fallback — web version for signing via browser or QR code.

Integration with SMEV and GIS

SMEV 3 works via SOAP with WS-Security. The mobile app does not communicate directly with SMEV — only through the backend. But this doesn't eliminate the problem: XML request schemas can be large (registers, certificates), and validation on the client is needed before sending. The app handles up to 10,000 simultaneous requests to ESIA.

For Android we use javax.xml.validation with XSD:

val schemaFactory = SchemaFactory.newInstance(XMLConstants.W3C_XML_SCHEMA_NS_URI) val schema = schemaFactory.newSchema(Source(xsdInputStream)) val validator = schema.newValidator() validator.validate(StreamSource(xmlInputStream)) 

On iOS — libxml2 through C bindings, or simply a JSON API via a backend proxy. The second option is simpler but loses some control over the format.

Application statuses are a separate pain. Government processes are asynchronous: a request is submitted, processed in 3-5 business days, and a notification arrives. You need polling or push via FCM/APNs. Push notifications from government services often contain only a serviceId without details — so on tap, you need a separate request for data before navigating. If the request fails, show a skeleton, don't crash. 95% of users return because of such details.

Data Storage and Security Requirements

152-FZ requires personal data storage on the territory of Russia. For a mobile app this means: backend on Russian servers (Yandex.Cloud, SberCloud, VK Cloud), prohibition of data transmission via foreign CDNs and analytics.

Local storage of sensitive data — only via EncryptedSharedPreferences on Android (AES256-GCM via Jetpack Security) or Keychain on iOS with kSecAttrAccessibleWhenUnlocked. ESIA session tokens must not be stored in SharedPreferences without encryption — this directly violates personal data protection requirements.

FSTEC certification is not always required, but if the app processes restricted-access information (not state secrets, but official data), attestation under Order 17 is needed. This affects the choice of cryptographic libraries: only certified cryptography means.

Vulnerability scanning before release is mandatory. We use MobSF (Mobile Security Framework) for static analysis of APK/IPA, OWASP Mobile Top 10 as a checklist. Special attention to exported Activities without Intent checks, unprotected ContentProviders, and logging tokens in LogCat.

UX Specifics for Government Apps

When developing a mobile app for government services, consider the audience: people aged 18-80 with varying digital literacy. Default font size — 16sp. Support for Dynamic Type (iOS) and sp units (Android) is mandatory. Screens with forms — short steps, no multi-page wizard forms without saving progress.

Accessibility (a11y): contentDescription for every significant element, correct accessibilityRole in React Native or UIAccessibilityTraits in SwiftUI. Government apps are periodically inspected by Roskomnadzor, including accessibility for people with disabilities.

Offline mode is critical: not all users have stable internet. We cache directories (list of regions, document types) via Room / Core Data. Application statuses are synchronized when connection is restored via WorkManager (Android) or BGTaskScheduler (iOS).

Why Native Development Outperforms Cross-Platform?

Native development is 1.5-2 times faster on crypto operations. For most government apps, native development — iOS (Swift + UIKit/SwiftUI) + Android (Kotlin + Jetpack Compose) — is optimal. Flutter is acceptable if the team is prepared and there is no hard dependency on native crypto libraries. React Native with react-native-crypto is risky: GOST cryptography via the JS bridge is unstable.

Architecture: Clean Architecture + MVVM. The Repository layer isolates SMEV/ESIA from the UI. UseCase contains business logic for status processing. ViewModel manages screen state. Dependency Injection — Hilt (Android) / Swinject (iOS).

Typical Problems and Solutions

What’s Included

• Legal and technical review of requirements, audit of integrations.
• UX design considering the 18-80 age audience.
• Development of authorization modules (ESIA, Goskey), forms, push notifications.
• Integration testing in the ESIA test environment.
• Instructions and training for the customer’s staff.
• Post-release support, monitoring of ESIA and SMEV API changes.

Process of Evaluation and Work

The audit of requirements includes legal expertise: what data is processed, whether attestation is needed, which ESIA/SMEV APIs are used. Without this stage, technical design is impossible.

Design: UX for the target audience, authorization scheme, data model, API contracts with the backend.

Development proceeds iteratively: first authorization and core flow, then forms and directories, then push and offline. Integration testing is done in the ESIA test environment (there is a separate sandbox for developers).

Publishing: RuStore is mandatory for government apps recently. Google Play and App Store are parallel. RuStore review is slower (5-10 days vs 1-3 days in Google Play).

Support: ESIA API and SMEV schema changes are released without notice. Monitoring via Firebase Crashlytics + custom alerts for response structure changes.

Timeline Estimates (No Fixed Prices)

MVP (authorization + 2-3 government services): 3-5 months. Full-featured app with a wide service catalog: 8-14 months. The full-cycle budget is determined after analyzing your requirements and integration scope. Contact us for a consultation — we will assess your project and provide a timeline and cost estimate.

Request a consultation for your government services mobile app.