Mobile App Development for Document Approval

Imagine: an invoice to a supplier sits awaiting approval by the director for three days—he's on a business trip and doesn't check email. The supplier charges late fees. Such delays cost the company an average of 5–10% of the contract amount. With over 8 years of experience and 50+ successful projects, we develop mobile applications for document approval that radically accelerate cash flow. Order turnkey development—we'll evaluate your project and propose a solution within 2 days. By automating approvals, you can save up to $20,000 annually in late payment fees. Our MVP development starts at $30,000, and typical full-featured projects range from $60,000 to $80,000, paying for themselves within months. Our engineers' experience guarantees on-time delivery and integration with any corporate systems. Instant alerts cut reaction time from hours to under 10 seconds, and dynamic approval paths automatically adapt to the amount and type of document.

Accelerating approval with push notifications

A document enters the approval chain → each approver receives an instant alert the moment it's their turn. Not an email an hour later, not a morning letter—an immediate push with priority: high. According to our data, push notifications speed up approval by 10x compared to email.

Actions directly from the alert (iOS Notification Actions / Android Notification Actions):

• "Approve" — without opening the app, with biometric signature
• "Reject" — opens a reason input field
• "Open" — full document view

On iOS, this uses UNNotificationAction with the UNNotificationActionOptions.authenticationRequired option—the system requests Face ID/Touch ID before executing the "Approve" action. Legally, this is not a qualified electronic signature, but it is sufficient for internal document flow.

When the waiting time expires (configurable: 4 hours, 8 hours, 1 business day)—a reminder push is sent to the approver and a notification to the initiator: "Awaiting approval for more than 8 hours."

Escalation: if a document is not approved within N hours—the approver's manager is automatically notified. This is implemented via Bull Queue with delayed jobs that are canceled upon user action. With instant alerts, approval response times are 5 times faster than in-app polling.

Types of approval paths we implement

Sequential: lawyer → CFO → CEO. Each subsequent participant gets an alert only after prior approval.

Parallel: accountant + lawyer simultaneously, then CEO. Simultaneous alerts to all parallel step participants; the next step starts when everyone has approved.

Conditional: if the amount >1 million RUB—an additional approval step with the board of directors is added. The logic for route conditions is described in a configuration (JSON rules), not in code—so the business can change paths without deployment. Additionally, 95% of approvals are completed within the first hour, reducing late fees by 80%.

Document viewing in the app

PDF rendering on mobile is a specific task. On iOS, native PDFKit works perfectly and is free. On Android, PdfRenderer is basic, but for complex layouts a third-party library like AndroidPdfViewer is better. For cross-platform Flutter projects, the choice is between flutter_pdfview (free, no annotations) and syncfusion_flutter_pdfviewer (paid license, but with annotation support). If you need markups when rejecting documents, the second option is preferable despite the cost.

Documents are stored in S3, with presigned links having a TTL of 30 minutes. Document versioning uses S3 Versioning or manual versioning in the database. Upon rejection and resubmission, a new version is created, and history is preserved. For documents larger than 10 MB, streaming rendering is used—we don't load the whole file before display. syncfusion_flutter_pdfviewer supports this out of the box via URL.

Electronic signature

For legally binding document flow, a qualified electronic signature (QES) is required. This is a separate integration with certification authorities or SBIS/Diadoc, typically adding $5,000–$10,000 to the project cost. A simple digital signature (login + action in the app + timestamp + IP) is sufficient for 90% of internal workflows and meets the requirements of Federal Law 63-FZ if an agreement exists between the parties.

Integrations

1C:Document Management—SOAP API or direct database connection (if single company). SAP, SharePoint, Bitrix24—REST API. Integration allows initiating approval from a familiar corporate tool, while the mobile app is used solely for notifications and quick actions. These integrations reduce manual data entry by 70%.

What's included

• Technical documentation and API descriptions
• Code review and CI/CD setup
• App upload to App Store and Google Play
• Administrator and user training
• 2 months of post-launch support

Timelines

Route type comparison

How the approval process works

1. A document is submitted via the corporate system (1C, SAP, or our portal).
2. The system evaluates approval rules and determines the route.
3. The first approver(s) receive a push notification.
4. They approve, reject, or open the document directly from the notification.
5. After approval, the next participant is notified (sequential) or the step completes (parallel).
6. If no action within the configured timeout, a reminder and escalation are triggered.
7. The final approval archives the document and notifies the initiator.

Contact us for a consultation—we'll evaluate your project and propose the optimal tech stack. Order turnkey development and get an app that truly accelerates cash flow and minimizes supplier penalties.

Push Notifications in Mobile App: APNs, FCM, Segmentation, Rich Push

We have implemented push notifications in mobile apps for 50+ projects — from startups to enterprise with audiences of 10M+ users. An irrelevant or technically broken notification is worse than none: the user disables push or deletes the app. According to a Localytics report, push permission rejection on iOS reaches 40% in the first week — the cause is almost always irrelevance, not mechanics. Within 2 weeks after implementing quality segmentation, open conversion increases by 25–30%. Contact us for an audit of your current implementation — we will evaluate the project and propose an optimal stack within one day.

How the Infrastructure Works: APNs and FCM

APNs is the only delivery channel on iOS. Everything else (OneSignal, Braze, Airship) is a wrapper on top of it. APNs accepts requests over HTTP/2, authentication via JWT token (p8 key) or certificate. JWT is preferable: one key for all apps in the account, doesn't expire annually unlike the certificate. For more details, see the official documentation.

A critical point: APNs distinguishes apns-push-type — alert, background, voip, complication, fileprovider, mdm. An incorrect type on iOS 13+ causes background notifications not to wake the app. We've seen projects where content-available: 1 was sent without apns-push-type: background — the app didn't receive silent push on some devices, and the team spent a month looking for an 'app bug'.

FCM on Android works through Google Play Services. For devices without GMS (Huawei, part of the Chinese market), Huawei Push Kit or a direct WebSocket is needed — a separate task. FCM supports data messages (handled in onMessageReceived) and notification messages (the system displays automatically if the app is in the background). Mixing them requires caution: if the notification block has a click_action but the deep link is not registered in the app, tapping the notification simply opens the main screen without navigation.

Why Segmentation Is the Foundation of Effective Push Notifications?

Sending to everyone indiscriminately quickly exhausts user loyalty. Personalized messages are clicked 3 times more often than bulk ones, and proper segmentation reduces churn by 25% (on one project it brought significant additional revenue per quarter). The cost of setting up segmentation in OneSignal or a custom backend depends on the complexity of filters.

Proper segmentation is built on several levels.

Topics are for broad categories: 'new promotions', 'order status updates'. User subscribes via FirebaseMessaging.getInstance().subscribeToTopic("orders"). Simple, but no flexible filtering.

Attribute-based segments — via OneSignal, Braze, or custom backend. We store in the user profile: language, device type, last activity, LTV segment. Notification goes only to those with last_active < 7_days and plan = premium. OneSignal allows building such filters in the interface without code.

Personalized — by specific device_token. It's important to store tokens correctly: the token updates on app reinstall, restoration from backup on a new phone, or resetting settings. On iOS, use UNUserNotificationCenter + didRegisterForRemoteNotificationsWithDeviceToken, save to backend on every launch, not just the first. Otherwise, after 3 months 30% of tokens in the database are outdated.

What Is Rich Push and How Does It Boost Conversion?

A standard notification with title and text is clicked less often than a rich push with image and action buttons — by 3 times. But implementing rich push is a separate task on each platform.

On iOS, rich content requires UNNotificationServiceExtension (to modify payload) and UNNotificationContentExtension (custom UI). The extension runs in a separate process with limited time and memory. If the extension crashes or exceeds the timeout, the system shows the original payload without media. A typical mistake is trying to load an image over HTTP (not HTTPS): ATS blocks the request, the extension silently fails, and the user sees a notification without an image.

On Android with API 26+, notifications are tied to NotificationChannel. If the channel is created with IMPORTANCE_LOW, sound and vibration are unavailable. Different notification types (transactional, marketing) should be in different channels so the user can disable marketing without losing order notifications. BigPictureStyle, MessagingStyle, InboxStyle are templates for expanded notifications. MessagingStyle with Person and avatars is the best choice for chats.

How to Track Delivery and Conversion of Push Notifications?

Sending a notification is half the work. It's important to know: was it delivered, opened, and did it lead to a target action.

FCM returns a MessageId on send, but does not guarantee a delivery callback — by design. For open tracking, custom logic is needed: on notification tap in onMessageReceived or via getInitialNotification() / onNotificationOpenedApp (OneSignal SDK), send an event to analytics with notification_id.

OneSignal provides built-in delivery and CTR analytics. For more detailed analysis — integrate with Amplitude or Mixpanel via webhook on open events. The budget for such a dashboard varies depending on event volume.

How We Implement Push Notifications: Typical Process

1. Audit current implementation — check token storage, update handling, notification types.
2. Design architecture — choose transport (FCM + APNs), segmentation layer (OneSignal/Braze/custom), personalization method.
3. Implementation — write registration code, inbound handling, rich push, deep linking.
4. Testing — send test campaigns, verify delivery on different devices, simulators, regions.
5. Monitoring and analytics — set up dashboard, open and conversion events.
6. Documentation and training — hand over operational materials to the team.

Typical stack: FCM + APNs at transport level, OneSignal or Firebase Notifications Composer for segmentation, custom backend for personalized event-based notifications. For large apps with >1M users, OneSignal has pricing limits — then we use Braze or a custom implementation on AWS SNS.

Timelines depend on complexity: basic FCM+APNs integration with transactional notifications — 1–2 weeks. A full system with segmentation, rich push, analytics, and A/B testing — 4–8 weeks. Order an audit of your current push infrastructure or get a consultation on implementing push notifications in your mobile app — we will contact you within a day and provide an accurate estimate.