Flutter 3 Released: Top New Features and Updates You Need to Know

Also Read: How to build a solar app like Solargraf?

With requirements in hand, the next step is deciding how to build the app. You’ll need to balance speed, cost, team expertise, and scalability when picking the tech stack. For a telehealth app, the typical architecture involves several layers:

You can choose native development (Swift/Kotlin) or cross-platform frameworks. We chose Flutter for the patient-facing mobile app. Flutter allowed rapid cross-platform development and a unified codebase. Cross-platform can be a great choice for telehealth since you often need to support various devices (patients might use iPads, cheap Android tablets, etc.).

Alternatives include React Native or NativeScript, but ensure whatever you pick can handle video streaming and Bluetooth/USB device integrations smoothly. For any admin or provider web portal, a web framework like Angular (which the case study used for an admin dashboard) or React could be used.

Telehealth apps require a secure backend to handle business logic (scheduling, user management), store data, and interface with external systems (like EHRs or IoT cloud services). A common stack would be a REST or GraphQL API server with a database.

We used a .NET Core backend with a PostgreSQL database. .NET Core provided performance and a strong typing advantage, and PostgreSQL is a reliable open-source choice that can be hosted on AWS easily. Other popular choices could be Node.js or Python (for rapid development), and databases like MySQL or MongoDB but the key is to ensure the stack can meet security requirements (e.g., using parameterized queries to prevent SQL injection, etc.).

It’s almost a given to use cloud services for modern telehealth apps. AWS, Azure, or GCP all have the needed compliance certifications to host health data (as long as you sign a Business Associate Agreement).

In our case, AWS was chosen, taking advantage of services like Amazon Cognito for authentication and identity management. Cognito being HIPAA-eligible meant it could handle PHI user attributes under AWS’s BAA, and it saved a ton of eff ort compared to building a user management system from scratch.

Similarly, the app was deployed on AWS, using its security and scalability. An AWS architecture might use EC2 or AWS Elastic Beanstalk/Kubernetes for the app servers, API Gateway and Lambda for serverless endpoints, and S3 for storing any uploaded content.

The benefit is you get built-in scalability (to handle usage spikes like a flu season) and pay-as-you-go cost efficiency. Indeed, our InnovAge project saw infrastructure cost savings by using AWS’s scalable resources on-demand rather than maintaining dedicated servers.

One of the trickiest parts of telehealth is implementing real-time communication. You generally have two choices: use a third-party platform or build on a protocol like WebRTC yourself. Given the complexity of reliably handling video (especially group calls, recording sessions, ensuring encryption), many teams opt for SDKs or cloud services.

Examples include Twilio, Vonage, Agora, or specialized telehealth solutions like Vidyo. The InnovAge app integrated Vidyo’s video call platform via its SDK. This saved the team from having to implement low-level WebRTC signaling and focus instead on embedding the video view and controlling call flows.

When choosing a video service, ensure it is HIPAA-compliant, for example, some providers will sign a BAA and off er HIPAA settings (disabling recording or using encrypted signaling). The video calls should be encrypted end-to-end or at least encrypted in transit; many telehealth regulations insist on that.

If your app connects to medical devices, your architecture needs to accommodate that data pipeline. There are a few patterns here. Devices might connect via Bluetooth or USB directly to the mobile app, which then reads measurements via an SDK and sends them to the backend.

Alternatively, devices (or a companion hub) might send data to a cloud service (like the device manufacturer’s cloud) and your app fetches it from there via APIs. The simpler approach for an initial build is often the former: connect directly to device from the app but it means the app needs to handle multiple device SDKs and the quirks of maintaining Bluetooth connections.

In our case, we integrated four types of devices (oximeter, BP cuff , glucometer, thermometer) using the device manufacturers’ SDKs in the Flutter app. This was ambitious because each SDK might have its own communication protocol and threading model. An architecture diagram would show the mobile app as the central hub reading from devices and then uploading readings to the cloud in real time for the doctor to see.

If implementing this, design your data flow carefully: you might have the app send each reading to the backend API, which then stores it and also pushes it to any listening client (e.g. the doctor’s dashboard) via WebSockets or a real-time database.

Security is vital here. Make sure any device data is transmitted securely (HTTPS) and consider encryption at the device level if possible. The InnovAge team had to ensure “real-time data sync and visual reporting” from devices without lag, which required optimizing how frequently data was polled and pushing updates immediately to the UI.

Besides video and IoT, think about other services to integrate. For example, push notifi cation services (Firebase Cloud Messaging or APNs) to handle reminders, analytics services to track usage (though be careful with analytics on health apps; avoid sending any PHI to third-party analytics).

If your telehealth app will incorporate things like e-prescribing, you might integrate with pharmacy APIs. Or for payments (if patients pay per visit in-app), use a secure payment gateway that can handle medical transactions. Each third-party integration should be vetted for compliance and stability.

With us, the focus was on integrating the core telehealth pieces (devices and video), and deliberately no custom complex algorithm or AI was built initially. The team focused on stitching together reliable components to meet the deadline.

When designing the overall architecture, keep scalability and maintainability in mind. It can help to separate concerns: e.g., a microservice for handling video sessions, another for handling device data ingestion, etc., if your scale demands it. However, for a v1 targeting a specific user group, a monolithic backend might be perfectly fine.

The InnovAge app was delivered in less than 3 months by our team. They likely kept things simple and cohesive, which is a good strategy under time constraints. Using an agile approach (the team did Scrum sprints with frequent reviews) also ensured the architecture evolved with continuous feedback and stayed on track.

One often overlooked architectural concern in telehealth is device management, especially if providing hardware to users. In InnovAge’s case, the app was deployed on managed Samsung tablets given to each resident. To control these devices (like preventing users from installing other apps or messing up settings), the team had to configure Samsung Knox; an enterprise mobile management solution.

This allowed them to lock down the tablets to only the telehealth app so that seniors couldn’t accidentally exit or use the tablet for other risky activities. If your scenario involves dedicated devices or kiosks, plan for an MDM (Mobile Device Management) solution and factor that into your tech stack choices.

Also Read: How Much Does It Cost To Launch A Fintech App?

Building a telehealth app means handling some of the most sensitive personal data: health records, live video of patients, biometric readings, etc. As such, security and privacy must be woven into every layer of the app. Here are key practices and how we applied them:

All PHI (Protected Health Information) should be encrypted in transit and at rest. Use TLS 1.2+ for any client-server communication (API calls, video streams) and enforce HTTPS only. For data at rest, enable database encryption (for instance, AWS RDS can encrypt PostgreSQL instances with minimal effort).

In mobile storage, if any sensitive info is stored on the device (cached messages, images, etc.), use the platform’s secure storage mechanisms or your own encryption layer. The HIPAA Security Rule expects that if a device is lost, the data on it is not easily accessible; mobile OS-level encryption or remote wipe features (as provided by MDM solutions like Knox) are essential safeguards.

In our project, all communication with AWS and between app components was encrypted, and AWS Cognito ensured that even user authentication tokens were securely managed.

Don’t rely on just usernames and passwords. Implement multi-factor authentication (MFA) for provider logins or sensitive admin functions at least. Even for patients, having a second factor (or biometric login as a factor) can prevent unauthorized access if a device is stolen.

The InnovAge app’s biometric login was a great example of balancing security with user convenience. A tech-savvy family member can’t just guess grandma’s password if she’s using her fingerprint to log in, yet it’s easy for grandma to use. Also enforce role-based access control on the backend: doctors should only see their patients’ data, patients only their own data, etc. Frameworks like Cognito or OAuth providers can simplify implementing roles and scopes for APIs.

Make sure every third-party service you use is willing to sign a Business Associate Agreement (BAA) or is covered under one. This includes your cloud hosting provider, video service, SMS gateway (if sending appointment info via text), etc.

For instance, AWS is a common choice because it offers a comprehensive BAA covering services like EC2, S3, RDS, and Cognito. In our project, using AWS services like Cognito and PostgreSQL on AWS meant we inherited a lot of compliance guarantees as long as we configured them correctly. If using a smaller vendor (say a startup’s video API), evaluate their security measures; sometimes larger players (Twilio, etc.) have more established HIPAA programs.

Telehealth apps can generate a lot of data: entire video sessions, device streams, chat logs. Decide what needs to be stored and for how long. Recording video calls, for example, introduces big storage and privacy questions; often it’s avoided unless absolutely needed (and if done, recordings must be encrypted and access-controlled).

For device data, storing trends is useful but maybe raw streams aren’t needed after processing. Our app converted real-time device readings into summaries and graphs for easy consumption; likely they stored key metrics and not every single data point to keep data volume manageable.

If your app sends push notifications or in-app chat messages, be careful about PHI. Never include sensitive details in a push notification (which might pop up on a lock screen). For example, say “You have a new message from your doctor” rather than “Dr. Smith has updated your insulin dosage.”

For in-app messaging, use end-to-end encryption if possible, or at least ensure messages are encrypted on the server. Some platforms like Firebase Cloud Messaging are not HIPAA-compliant for sending PHI payloads, so you may need to send only generic prompts and have the app fetch the actual message from your secure server after the user unlocks the app.

HIPAA requires the ability to audit access to PHI. Build logging into your backend for critical actions: log when records are viewed, modified, or when video sessions occur (at least metadata like “Doctor A consulted Patient B at time X for Y minutes”). Ensure these logs themselves are stored securely and access to them is limited.

Also Read: How much does it cost to build a Mobile Application?

Even with great planning, building a telehealth app involves complex technical challenges. Let’s go into some major ones our team faced in the InnovAge project and how they were addressed, as these hold valuable lessons:

Connecting one medical device is hard enough; each comes with its own SDK, data format, and sometimes obscure documentation. We had four. The challenge was ensuring real-time data sync from all devices and displaying it in an accessible way.

For example, if a patient is on a video call and measures their blood pressure with a cuff , the reading should pop up for the doctor within seconds. The solution was meticulous integration: our developers worked with each device’s SDK (often provided by the device vendor or a middleware like JetDoc in this case) and tested them in various scenarios.

We had to handle connectivity issues gracefully, e.x., if the Bluetooth connection drops or a reading fails, the app should show an error message like “Please retry measuring your blood pressure” rather than silently fail. One lesson learned was the risk of incompatibility or unstable updates from these third parties.

For instance, a device firmware update could break the SDK’s behavior. To mitigate this, we established a tight communication loop with the device providers (through our U.S.-based middleware partner, JetDoc) and did extra testing whenever an update was looming.

Tip: If possible, time your app’s release around stable versions of device firmware, and always have a fallback (even if it’s manual input of readings) so a single device glitch doesn’t halt a telehealth session.

We chose a proven video platform (Vidyo), but that didn’t eliminate all issues. Networks in care homes can be spotty; older tablets might struggle with encoding/decoding video. To ensure smooth video consultations, we had to optimize video settings and maybe limit video resolution on lower bandwidth.

We also included an audio-only fallback mode, since as noted, many seniors end up using telephone-like calls when video fails. Using Vidyo’s SDK meant we had less low-level control, but it also meant the heavy lifting of adaptive bitrate, echo cancellation, etc., was handled by experts.
Lesson: Use such specialized services to save time, but profile their performance on your target devices. We likely worked with Vidyo to fine-tune settings for the Galaxy Tab 3’s capabilities.

The Samsung Galaxy Tab 3 was not a high-end device (released around 2013!). Running a modern app on it, even with Flutter, was a challenge. The app had to handle video calls, device data via Bluetooth, and a smooth UI; all within maybe 1GB of RAM and a slow CPU.

The team took a multifaceted approach to optimization: we trimmed down animations, preloaded essential data, and possibly used lower-level platform channels in Flutter for performance-critical sections. We monitored app memory usage, ensuring we disposed of video streams or BLE connections properly after use to avoid leaks.

This “continuous challenge” of performance tuning was worthwhile. The app delivered acceptable responsiveness on the Tab 3, saving the cost of buying newer devices.

Takeaway: If you must support low-spec hardware, budget extra time for performance testing and be prepared to cut non-essential features. Also consider using profiler tools (like Android’s Systrace or Flutter’s DevTools) to find bottlenecks.

Meeting a 3-month deadline for such a feature-rich app was intense. We had to make trade-off s on what to include. Interestingly, the team reported no major trade-off s on quality; they were able to deliver all key features within scope, thanks in part to focusing only on essential functionality and reusing third-party components rather than reinventing.

We adopted Agile, which helped in continuously integrating and testing features every sprint. One practice was parallel work: while one team integrated the video SDK, another tackled IoT devices, and another built the UI/UX, all coming together in integration testing.

Regular sprint reviews with stakeholders (including the JetDoc middleware team and InnovAge management) ensured we built the right thing and could course-correct early. For example, early feedback from a pilot with one or two residents might have led us to enlarge font sizes or adjust color contrasts (hypothetically). Because we were agile, these changes could be done mid-flight.

A non-technical challenge was coordinating between multiple parties: our development team, the middleware partner, device vendors, and the InnovAge stakeholders. The risk of miscommunication was flagged as high. To mitigate it, we established clear documentation for requirements (since much info came via email/calls, we made sure to write down and get confirmations). We also likely used collaboration tools (like Jira for tracking tasks, Confluence or similar for shared documentation) so everyone had visibility.

Also Read: AI Is Moving Fast. Your Hiring Can't. That's Why Augmented Teams Win

The app was well-received by both end-users and stakeholders. Doctors appreciated how easy it was to schedule and conduct appointments, especially with instant access to patients’ latest data during a call. And despite initial concerns about whether seniors would adapt, the patients found the app simple.

Features like one-click check-in for appointments and gentle reminder notifications proved that even those with limited digital literacy could engage with the telehealth platform. This underscores an important point: if you design technology around the user’s needs and limitations, they will embrace it.

One delightful surprise was how certain features provided value beyond initial expectations. The mood tracker we discussed is a prime example. Originally, it might have been seen as a “nice-to-have” add-on. In practice, it turned out to be incredibly useful; doctors could pick up on mood trends (perhaps flagging depression or cognitive decline early), and patients felt heard by logging their emotional state.

Stakeholders praised this as a thoughtful innovation, and it likely improved holistic care. Similarly, the biometric login wasn’t just a fancy security option; it actually solved a real problem (elderly users forgetting passwords or struggling with typing).

Of course, not everything was perfect or reusable. The team noted that they didn’t create any notably reusable tools or IP, as the focus was purely on delivering the product for the client. That’s fi ne; in many enterprise projects the value is in the solution itself rather than spin-off tech.