DEV Community: Momentum

Why Health Apps Need Native Mobile Apps for Wearable Integration

Piotr Ratkowski — Thu, 27 Nov 2025 09:23:01 +0000

In 2025, the healthtech market is booming. Wearables have quietly become the heartbeat of the digital health revolution, and if your app is not designed to talk to them natively, you are already behind.

Smartwatches and rings now track every beat, step, and breath we take. From Apple Watch and Garmin to Oura and Fitbit, users generate gigabytes of personal data every day. Heart rate, HRV, oxygen levels, sleep stages, stress patterns, it is all there.

But here is the uncomfortable truth: most health apps barely touch it.

They either rely on manual input, scrape partial data through APIs, or cannot access Apple Health at all because they skipped one crucial principle: mobile-first architecture.

If you are building a health app without a native layer, you are building a product that can never fully understand its users.

Let’s unpack why mobile-first is not just a design choice anymore. It is the foundation of any serious health platform.

The Data You Want Lives on the Phone

The world’s most valuable health data from Apple Health does not sit on a server you can query. It lives on your user’s iPhone, encrypted, local, and private.

Apple designed HealthKit so that data never leaves the device unless the user explicitly allows it.

That means:

You cannot pull Apple Health data from a cloud API
You must have a native iOS app installed on the user’s devicex
You need explicit permissions for every data type
Syncing and processing happen locally before being sent to your backend

Without a native app, your product is effectively blind to Apple users, a group that represents the largest and most data-rich wearable ecosystem in the world.

Even if your business is built around a web platform or coaching dashboard, you still need a small mobile bridge app. This bridge authenticates the user, gathers data from Apple HealthKit, and transmits it securely to your backend for analysis.

Without it, you are disconnected from the pulse of your audience in the most literal sense.

Mobile-First Is About Architecture, Not Just UX

or years, startups have treated “mobile-first” as a UX trend. Beautiful interfaces, smooth animations, intuitive navigation.

But in healthtech, mobile-first means something much deeper: data architecture.

Here’s how a modern health app’s data flow actually looks:

‍That native app is more than just another interface. It is your data gateway.

It connects to the user’s sensors through SDKs like Apple HealthKit, Garmin Health, or Google Fit. It handles authentication, permissions, and data sync. It ensures that the data entering your system is accurate, compliant, and timely.

Your backend, no matter how advanced, cannot do any of that on its own.

Without a mobile app, your backend has nothing to talk to. The most valuable health data will never reach your servers. You cannot measure HRV, detect recovery, or analyze sleep quality without it.

So the equation is simple:

No native app → no wearable data → no personalization → no long-term user engagement.

Apple’s Privacy Rules Make Mobile the Only Option

Apple’s health ecosystem is built around privacy-by-design. This is what makes users trust it, but it is also what locks developers out unless they play by Apple’s rules.

Here is what those rules mean in practice:

You cannot request or process HealthKit data on your backend servers
You must request permission on the device itself
Data cannot be shared between apps without user consent
All data is encrypted at rest and in transit within iOS
Developers are responsible for building compliant sync workflows
Apple does not provide exceptions. There is no hidden API or workaround.

If you want to access heart rate, sleep, mindfulness, or oxygen data, you must build a native iOS component.

From a compliance perspective, that is a good thing. It keeps your product aligned with privacy regulations like GDPR and HIPAA. From a product perspective, it forces you to commit to a mobile strategy early or risk being locked out of the most trusted data ecosystem in digital health.

Why Native Access Is a Competitive Advantage

While some see Apple’s restrictions as a barrier, visionary companies see them as a moat.

If you are one of the few startups with true native access, you can deliver:

Deeper personalization: Use HRV, sleep, and stress data to adapt recommendations in real time
Continuous engagement: Automatically detect fatigue, overtraining, or recovery patterns
Predictive analytics: Combine daily wearable data with contextual signals to anticipate health trends
Trust and transparency: Let users control their data locally and sync it only when they choose Meanwhile, competitors that rely on web scrapers or CSV uploads stay stuck in the 2015 era of digital health, disconnected and manual.

Every serious wellness, longevity, or performance app you admire, from WHOOP to Levels to Eight Sleep, has one thing in common: they own the mobile layer. That is what makes their experience seamless, data-driven, and alive.

Web-Only Apps Fall Behind (and Fast)

Many startups still launch with a web-only product, assuming they can add wearables “later.”

Here is what happens when they try:

They discover that Apple Health offers no backend API
They realize Garmin, Fitbit, and Oura each use different schemas
They spend months stitching together inconsistent SDKs
They burn budget on maintenance instead of insights

Without a native app, the data they get is incomplete and delayed. They cannot deliver the real-time, personalized experience users expect. Engagement drops, retention tanks, and the team ends up rebuilding from scratch.

In the healthtech market, real-time context wins.

If your platform does not automatically know that a user slept four hours or that their recovery score just dipped, your insights will always feel generic. And generic does not retain users.

What About Android?

Google Fit and Android’s Health Connect provide both local and cloud options, which seems more flexible. But in practice, the same logic applies.

Even on Android, the most reliable and permission-compliant way to access wearable data is through a native layer. Fitbit, Whoop, and Strava all require authentication flows that depend on mobile SDKs or in-app OAuth.

So while Android gives developers more freedom, you still need a native app to bridge user data securely and efficiently. Mobile-first is not just an Apple thing. It is the new standard across the entire wearable ecosystem.

The Blueprint of a Mobile-First Health Platform

Let’s map out what a proper mobile-first health app architecture looks like in 2025.

Core Components

Native Mobile App:
Handles Apple HealthKit, Google Fit, Garmin, and Oura SDKs.

Manages authentication, permissions, and background data sync.

Integration Layer (like Open Wearables):
Normalizes incoming data, removes duplicates, and standardizes metrics.

Provides one consistent schema for heart rate, HRV, sleep, activity, and more.

Backend / Analytics Layer:
Stores unified data securely. Powers dashboards, reports, and AI models.

Implements compliance, encryption, and data retention policies.

Frontend or Chat Layer:
Displays insights to users, coaches, or clinicians. Powers notifications or conversational experiences.

This modular architecture allows you to expand easily, add new wearables, plug in AI analytics, or connect dashboards, all without rewriting your pipeline.

The ROI of Mobile-First Integration

Going mobile-first may feel like extra work upfront, but it pays off quickly.

Faster Data Access

Once permissions are granted, wearable data streams in continuously with no manual syncs needed.

Higher User Engagement

Native experiences keep users returning. Notifications, widgets, and on-device insights boost retention dramatically.

More Accurate Insights

Native SDKs provide high-resolution data, second-by-second metrics instead of daily averages.

Easier Compliance

You operate within Apple and Google’s approved frameworks, minimizing legal risk.

Better Market Positioning

Mobile-first products feel more premium. Investors, partners, and users recognize it instantly.

Health apps that own their native layer do not just collect data. They build trust and loyalty. They become daily companions, not occasional tools.

Open Wearables: Built for the Mobile-First Future

At Momentum, we have spent years building Open Wearables, an open-source framework that solves the hardest part of mobile-first integration.

Instead of spending months managing APIs and SDKs, developers can connect to multiple wearables in minutes. Open Wearables provides:

Unified data schemas for Apple Health, Garmin, Fitbit, Oura, and Strava
Prebuilt ETL pipelines for data cleaning and normalization
Secure authentication and storage options
Ready-to-use connectors for AI-driven insights It is designed for health startups that want to launch faster, scale smarter, and stay in control of their data.

Open Wearables does not replace your mobile app. It empowers it.

It sits between your native client and backend, handling all the messy data work so your team can focus on user experience and differentiation.

The Future Belongs to Mobile-Native Health Intelligence

The line between consumer wearables and medical data is disappearing.

Continuous monitoring is the new normal, and users expect apps that react in real time to their health patterns.

The winners in this new market will share three traits:

Native access to wearable and biometric data
Unified infrastructure for processing and analyzing it
AI-driven personalization that turns raw numbers into guidance

You cannot do any of that without going mobile-first.

The longer teams postpone this decision, the harder it gets to catch up.

So if you are designing a health product, whether it is for fitness, longevity, or recovery, start where the data starts: on the phone.

Because in the next era of healthtech, it is simple:

Go mobile-first, or get left behind.

Do You Need a Mobile App to Access Apple Health Data? (Short Answer: Yes)

Piotr Ratkowski — Tue, 25 Nov 2025 11:24:43 +0000

If you are building a mobile health app or wearable technology platform, you've probably wondered whether you can get Apple Health data without building a native iOS app.

Maybe you already have a great web platform. Maybe your team wants to focus on backend AI features before investing in native apps. Or maybe you just want to test Apple Health app data in your prototype.

Here's the quick answer: you need a native iOS app. There's no way around it.

Apple Health data lives entirely on the user's iPhone, and Apple does not provide a backend API for the Apple Health app. That means you can't access a user's health data through your servers, your website, or any external system. You must go through the user's device.

In this article, we'll explain why that is, how it affects your mobile health app development roadmap, and what your options are if you still want to access Apple Health app data safely and efficiently.

How Apple Health Actually Works

Apple Health is not a cloud service. It is a local health data hub on the user's iPhone.

The Apple Health app on iOS collects data from the Apple Watch and other health monitoring devices, connected apps like Strava or MyFitnessPal, and manual user entries like weight or medications. All of that data stays on the phone. It is not sent to Apple's servers.

When your mobile health app wants to access this wearable data, it has to ask the user for permission, read it directly from the HealthKit store on the device, and optionally send it to your backend if the user agrees. There is no public API that lets you request Apple Health app data remotely.

That design is intentional. It keeps users in control of their health information.

Why You Can't Skip the Native iOS App for Apple Health

Let's say you're building a longevity platform, a remote care solution, or a fitness analytics dashboard. You already have a web interface where users sign in and view insights. You might think you can just let users connect their Apple Health app from there.

Unfortunately, no.

Apple Health app data is stored only on iPhones. There's nothing in the cloud to connect to. Apple does not provide a developer API that can fetch user data remotely. The only authorized access point is HealthKit, which runs inside a native iOS app.

So even if your core product is web-based, you still need a companion iOS app for mobile health app development. It doesn't need to be big or complex. It just needs to exist as the bridge between your backend and the user's HealthKit data.

What that mobile health app actually does is simple. Think of your iOS app as a data connector. It's not about replacing your web platform or duplicating features. It has one job: to manage Apple Health app permissions and sync data safely.

This mobile-first approach is essential for any wearable technology integration. Whether you're building fitness tracking, health monitoring devices integration, or digital health platforms, the native iOS bridge is non-negotiable for Apple Health access.

Here's how it works. The user installs your iOS app and grants permissions to specific HealthKit data types like steps, heart rate, or sleep. The app reads data locally from the user's HealthKit store. The app sends selected data to your backend using secure API calls and user authentication. Your backend processes and visualizes the data in your web dashboard, AI model, or analytics engine.

This flow respects Apple's privacy model while giving your system the data it needs. Without the mobile health app, there is simply no way to access the Apple Health app database.

Why Apple Enforces Mobile-First Architecture for HealthKit

Apple's privacy-first philosophy is not a technical accident. It's a deliberate strategy.

The Apple Health app is designed to protect user privacy in three ways. Data stays local, nothing leaves the user's device unless they allow it. Consent is required for each type of data. Even Apple cannot see or use the data.

This means users can trust that their health data is safe. But for mobile health app development and wearable technology platforms, it fundamentally changes how products are built. Instead of cloud-first APIs, Apple pushes everyone toward mobile-first architecture.

That's why even major players in digital health and wearable devices maintain native apps, even if most of their features live online. Companies like Calm, Lifesum, and fitness AI startups all need that mobile bridge to access Apple's health ecosystem.

How This Affects Your Mobile Health App Development Strategy

If you plan to use Apple Health app data, you need to make an early strategic choice about going mobile-first. That decision impacts several areas of your mobile health app development.

Time to market changes significantly. Building a native iOS app adds development time. You'll need Swift or SwiftUI developers, UI work, testing on devices, and App Store submission. However, you can start small. Many successful companies build lightweight "data bridge" apps before launching full-featured ones.

Engineering complexity increases. Your architecture must now include a mobile health app for data collection, backend for storage and analysis, web app for dashboards or management, and authentication layer to connect them all. This complexity can pay off long term because it gives you full control over your data flow and compliance.

Wearable data integration architecture. Your system must handle not just Apple Health, but potentially multiple wearable devices and health monitoring devices. This requires normalized data schemas and unified API layers for efficient wearable technology integration.

Data ownership and compliance improve. By using HealthKit correctly, you show regulators and users that you value privacy. It also helps with compliance frameworks like GDPR or HIPAA, since data sharing is transparent and user-driven.

Third-Party APIs and Why to Avoid Them

Some third-party wearable data platforms claim they can give you access to Apple Health app data through their APIs. Be cautious.

These services often rely on users installing their own mobile app that connects to HealthKit, not yours. That means your users are technically sharing data with an external provider, not directly with you.

This can lead to loss of control over data quality, legal ambiguity around ownership, and privacy concerns if users don't understand who handles their data. If you want full transparency and control, the only compliant path is to build your own iOS data bridge.

For developers serious about wearable technology integration, building your own infrastructure ensures you control the entire data pipeline from health monitoring devices to your analytics engine. This approach also simplifies compliance with healthcare regulations and maintains direct relationships with users.

The Good News About Building a Simple iOS Bridge App

The mobile health app you need to access HealthKit does not have to be a full product. You can think of it as a technical connector rather than a user-facing experience.

A minimal viable version could ask for permissions, run a background sync once a day, and upload health metrics securely to your backend. From there, you can expand as your business grows by adding login and onboarding, offering simple dashboards or reminders, and integrating with other wearables like Garmin or Oura.

This staged approach keeps your development light while unlocking access to critical health data.

Beyond Apple Health App Integration

The Apple Health app is only one piece of the wearable devices and health monitoring devices puzzle. If your users also wear Garmin watches, Fitbit trackers, Oura Ring, or Whoop bands, you'll need to combine those wearable data sources too.

Each brand has its own SDKs, APIs, and permissions for wearable data access. Without a unified wearable technology platform, you will spend months building and maintaining separate integrations. That is why modern mobile health apps increasingly rely on unified APIs that normalize data across wearable devices. They let your system speak one consistent data language, whether it comes from the Apple Health app or anywhere else.

What This Means for Product Teams

If you're leading a healthtech scaleup or product team, here are the key takeaways:

By designing around Apple's mobile-first model, you future-proof your app and position it for deeper integrations later on.

Real-World Example

Imagine a startup building a longevity platform that wants to combine Apple Health app data with nutrition and recovery analytics from multiple wearable devices and health monitoring devices. Their architecture includes a lightweight iOS app that reads heart rate, HRV, and sleep data from HealthKit. A secure API gateway uploads user-approved data to the backend. The backend system merges wearable data with nutrition logs and produces insights. A web dashboard visualizes insights for users and coaches.

The user controls everything about what's shared, when, and how. This architecture demonstrates modern wearable technology integration best practices: local data collection via native iOS, secure wearable data synchronization, and cloud-based analytics that respect user privacy while enabling AI-powered insights. Without the mobile bridge, none of it would be possible.

Getting Started with HealthKit Integration

If you're ready to access Apple Health app data, start simple. Define your use case and identify what metrics matter most. Design your data flow and map how data moves from HealthKit to your backend. Build a lightweight iOS app focused on permissions and syncing. Implement user consent and data transparency to make privacy a feature. Plan for scale so when you add Garmin, Fitbit, or Oura Ring, your backend is ready for multiple wearable devices and health monitoring devices. Consider unified wearable technology platforms that simplify multi-device integration.

By doing this right from the beginning, you'll avoid major refactoring later.

The Bottom Line

Do you need a mobile app to access Apple Health data? Yes, always.

Apple Health is built to protect users, not developers. It keeps data safe on their devices, which means only a native app can reach it. But that requirement doesn't have to slow you down.

A lightweight, mobile-first bridge can unlock the entire Apple Health app ecosystem and serve as a foundation for your multi-wearable strategy. The future of mobile health app development is mobile-first, privacy-driven, data-connected, and built on unified wearable technology platforms that seamlessly integrate health monitoring devices. Teams that learn to build within Apple's rules will win user trust and deliver better experiences.

Why Health Apps Struggle With Wearable Integrations (And How to Fix It)

Piotr Ratkowski — Mon, 24 Nov 2025 13:42:13 +0000

Every day, millions of people check their wearables before they check their phones. Apple Watch shows recovery scores, Garmin tracks training load, Oura monitors sleep quality. For mobile health app developers, this represents a massive opportunity to build more engaging, personalized experiences.

Yet most health app development teams struggle to integrate wearable data effectively. Despite the clear user demand and business value, wearable integration remains one of the biggest technical bottlenecks in mobile health development.

Why do teams that can build sophisticated AI algorithms, real-time chat systems, and complex user interfaces get stuck on something as "simple" as reading heart rate data?

The answer lies in a fundamental misunderstanding of what wearable data integration actually involves. It's not one API call – it's six different authentication systems, inconsistent data models, mobile-first requirements, and ongoing maintenance nightmares.

In this article, we'll break down exactly why mobile health apps struggle with wearables, what the real costs are, and how modern development teams are solving this problem faster using unified wearable APIs and open-source platforms.

The Hidden Complexity of Wearable Data Integration

When product teams first scope wearable integration, they often estimate 2-3 weeks of work. The reality is closer to 3-6 months for a production-ready system that handles multiple health monitoring devices reliably.

Here's what that "simple" wearable integration actually involves:

Different integration models across major platforms:

Apple HealthKit requires a native mobile app with local data access (no backend API)
Garmin Health API pushes data via webhooks with OAuth authentication
Fitbit Web API and Oura Cloud API use REST APIs with different token refresh schedules
Whoop API has beta documentation with frequent changes
Strava API focuses on activity data with limited biometric access

Data chaos across wearable devices:

"Sleep score" calculations differ completely between Oura, Fitbit, and Garmin
Heart rate variability (HRV) measurements use different algorithms per manufacturer
No standard schema exists for comparing metrics across brands
Timestamp formats, timezone handling, and data granularity vary widely

Authentication complexity at every level:

OAuth flows with device-specific implementation requirements
Token refresh schedules ranging from 8 hours (Fitbit) to 60 days (Garmin)
Rate limits that vary dramatically between providers
Permission scopes that require granular user consent management

Mobile-first architectural requirements:

Apple Health data cannot be accessed from your backend servers
Native iOS apps required for HealthKit integration
Device-local data processing capabilities most teams didn't plan for
Background sync management across iOS and Android platforms

Ongoing maintenance overhead:

APIs change frequently without advance notice
SDK updates require regression testing across all integrations
Device firmware updates can break data flows
Rate limit adjustments force architecture changes

This complexity explains why even well-funded startups often abandon wearable features or support only one device instead of building comprehensive health app development solutions.

The Real Business Impact of Poor Wearable Integration

Technical complexity is one thing, but what does this struggle actually cost mobile health apps?

Extended development timelines hit teams first. Projects that should take 6-week sprints end up shipping 6 months later. Each wearable integration becomes its own research and development cycle, complete with testing phases and maintenance requirements.

Limited device coverage becomes the compromise. Instead of supporting the devices users actually own, apps pick one or two "easier" integrations. Users with Garmin watches but Fitbit-only apps simply don't get the full experience they expect from a modern health platform.

Poor data quality emerges when teams rush to ship without proper normalization. Apps show inconsistent metrics that confuse users. Heart rate from Apple Watch doesn't align with HRV from Oura, making long-term trends unreliable and undermining the app's credibility.

Technical debt accumulates as quick fixes pile up. Each device needs its own sync logic, error handling, and testing strategy. Clean code becomes unmaintainable quickly, and teams find themselves maintaining integrations instead of building features users actually want.

The result is mobile health apps that feel incomplete, users who don't get personalized experiences, and development teams stuck in maintenance cycles instead of innovation.

Why Traditional API Integration Approaches Fail

Most mobile health app development teams try to solve wearable integration the same way they'd connect to a payments API or social media platform. This approach fails because wearables aren't like other APIs.

Payment APIs handle discrete transactions, but wearables generate continuous streams of biometric data that need temporal alignment, deduplication, and aggregation. Traditional REST patterns don't fit the continuous data model that health metrics require.

Apple's privacy-first design creates additional friction. Their local-only data model protects users but breaks cloud-first development patterns. Teams used to backend APIs struggle with device-local data bridges and secure sync protocols that respect user privacy while enabling app functionality.

Health data compliance requirements add another layer of complexity. Unlike social or commerce APIs, wearable data falls under HIPAA, GDPR, and other health information regulations. Standard API integration patterns don't account for audit logs, data residency requirements, and granular consent management.

User experience expectations create pressure that generic API approaches can't meet. Users expect wearable data to appear in real-time, show meaningful insights, and work across multiple devices seamlessly. Meeting these expectations requires sophisticated data processing pipelines, not just API connectivity.

This is why treating wearable integration as "just another API" leads to long development cycles and poor user experiences in health app development.

The Apple Health API Bottleneck

For many mobile health apps, Apple Health API integration becomes the defining challenge that shapes their entire architecture.

Apple HealthKit contains the richest health dataset available – heart rate, HRV, sleep stages, activity, even lab results and medications. For iPhone users, it's the central hub where all health data converges. Ignoring it means missing half the mobile market.

But Apple Health data lives entirely on the user's device. There is no backend API. No cloud service. No webhook system.

If your app wants Apple Health data, you must build a native iOS app that requests explicit permission for each data type, reads data locally from the HealthKit database, syncs selected data to your backend with user consent, and handles background updates and sync failures gracefully.

This mobile-first requirement forces architectural decisions that many teams aren't prepared for. Web-based health platforms discover they need companion mobile apps. API-first startups realize they need device-local data processing capabilities they never planned for.

The teams that succeed with Apple Health plan for mobile-first architecture from day one. They build lightweight "bridge" apps that handle permissions and sync, feeding unified data to their main product experience. Teams that fight this model end up with complex workarounds, limited functionality, or months of refactoring later.

The Multi-Device Normalization Problem

Even after solving individual API integrations, mobile health apps face the challenge of making sense of data from multiple sources.

Consider a user who tracks workouts with Garmin, sleep with Oura, and nutrition with MyFitnessPal. Each platform uses different units of measurement, timestamp formats, calculated metrics, data availability schedules, and quality indicators.

Without normalization, apps display conflicting information that erodes user trust. A user's recovery score from Whoop might say "red" while Oura shows "good" – based on the same underlying physiology but different calculation methods.

Effective normalization requires unified schemas that map different field names to consistent internal formats, unit conversion that handles imperial and metric measurements reliably, temporal alignment that synchronizes data points across time zones and update schedules, conflict resolution that handles overlapping metrics intelligently, and quality scoring that weights data based on device accuracy.

Most health app development teams underestimate this work. They focus on getting data flowing, then spend months debugging why trends don't align or metrics contradict each other. The normalization challenge often takes longer than the initial API integrations.

How Modern Teams Are Solving Wearable Integration

The most successful mobile health apps in 2025 no longer build wearable integrations from scratch. Instead, they use unified platforms that handle complexity automatically while preserving control over their data and user experience.

Unified integration layers have emerged as the standard solution. These platforms connect to multiple wearables through one consistent API. Instead of managing six different SDKs, teams write against a single interface that outputs normalized, time-aligned data ready for analysis or visualization.

Open-source solutions provide transparency and customization without vendor lock-in. Developers can inspect data flows, modify processing logic, and maintain full control over sensitive health information. This approach aligns with healthcare's need for auditability and compliance verification.

Mobile-first architectures embrace Apple's device-local model rather than fighting it. Successful teams build lightweight mobile apps that handle permissions and sync, feeding clean data to web dashboards and AI systems. This architecture actually improves privacy and user control while enabling powerful backend processing.

AI-ready data pipelines output structured, consistent data that machine learning models can consume immediately. Instead of months of data engineering work, teams can build intelligent features from day one, focusing on user value rather than data wrangling.

Platforms like Open Wearables demonstrate this approach in action. Developers can integrate Apple Health, Garmin, Fitbit, Oura, Whoop, and Strava through unified APIs that handle authentication, normalization, and sync automatically.

Building for the Future of Mobile Health

Wearable integration challenges won't disappear – they'll evolve. New health monitoring devices launch constantly. APIs change frequently. User expectations for real-time, personalized health insights continue rising.

Mobile health apps that succeed long-term build around these realities:

Design for multiple devices from day one - Users rarely stick with one wearable brand forever, so apps that assume single-device usage create switching costs that hurt retention
Plan mobile-first architecture early - Apple Health API integration requires native mobile components, so design your system around this requirement rather than retrofitting later
Invest in data quality over quantity - Clean, reliable data from three devices beats noisy data from ten devices every time
Build intelligence into your data layer - Raw metrics don't change behavior, but apps that interpret patterns and suggest actions create real value
Choose extensible infrastructure - Your integration approach should make adding new devices easier, not harder, as your platform grows. Consider open-source platforms that already solve common integration challenges.

The teams that master these principles build health apps that feel effortless and intelligent to users, while remaining maintainable and scalable for developers.

The Open Platform Advantage

Teams that choose unified, open-source wearable platforms gain advantages beyond faster development.

Full data control and transparency distinguish open platforms from proprietary solutions. Unlike SaaS APIs, open platforms let you see exactly how data flows, what transformations occur, and where information is stored. This transparency is crucial for healthcare applications where data governance directly impacts user trust and regulatory compliance.
Compliance readiness becomes straightforward with open platforms. HIPAA, GDPR, and other health data regulations require audit trails and clear data governance policies. When you can inspect and modify every aspect of your data processing pipeline, compliance verification becomes a technical exercise rather than a leap of faith.
Customization flexibility allows teams to adapt platforms for specific use cases. When your app needs unique data processing or specialized integrations, you can modify the platform directly rather than waiting for vendor feature requests or building workarounds.
No vendor lock-in preserves long-term flexibility. Your health data infrastructure shouldn't depend on external companies' business decisions, pricing changes, or strategic pivots. Open platforms ensure your investment in wearable integration remains under your control.

Open Wearables exemplifies this approach – providing production-ready wearable integration with full source transparency, community support, and deployment flexibility. Teams can self-host on their own infrastructure, customize data processing logic, and maintain complete data sovereignty while accessing unified APIs for Apple Health, Garmin, Fitbit, Oura, Whoop, and Strava.

The Path Forward for Health App Development

Mobile health apps don't have to struggle with wearable integrations. The technology exists to solve these problems elegantly. The question is whether teams will continue building custom solutions that slow development and create technical debt – or adopt modern approaches that unlock wearable data's full potential.

For teams ready to move beyond integration struggles, the path is clear. Start with unified platforms that handle complexity automatically while preserving your control and customization options. Design mobile-first to access Apple Health and provide real-time user experiences. Focus on intelligence over data collection, and choose open, transparent solutions that align with healthcare's compliance requirements.

The future of mobile health belongs to apps that make wearable data feel effortless and intelligent. The infrastructure to build those experiences exists today.

Apple Health MCP Server: Use Cases for Developers

Bartosz Michalak — Thu, 06 Nov 2025 04:12:00 +0000

Apple Health MCP Server: Use Cases for Developers

Apple Health stores years of health data from workouts, sleep tracking, heart rate measurements, and step counts. While this data is valuable for building personalized health applications, accessing it has always been challenging. Apple Health exports come as complex XML files that require significant parsing effort to use effectively.

What is Apple Health MCP Server

The Apple Health MCP Server is an open-source tool that implements the Model Context Protocol, providing a clean interface for accessing Apple Health data. It takes Apple Health XML exports, indexes them in DuckDB for fast querying, and exposes the data through tools that AI agents can use naturally. The server also supports Elasticsearch integration for advanced search capabilities.

The server handles XML structure analysis, health record search, data extraction by type, and trend generation. Instead of building custom XML parsers, developers get structured access to health data through simple API calls that work with AI applications like Claude Desktop.

Why It Matters

Building health applications typically means dealing with fragmented data sources and inconsistent formats. Apple Health solves data fragmentation, but its XML export format creates technical challenges. Parsing Apple's XML structure requires domain knowledge and custom code for each data type you want to extract.

The MCP server eliminates this friction. Developers can query health data using natural language rather than writing complex parsing logic. This means more time building features that help users and less time wrestling with data infrastructure.

Use Cases for Developers

Fitness and Training Applications

Fitness apps can leverage complete Apple Health histories to create personalized workout recommendations. A running coach app can query average weekly mileage over months and analyze rest day patterns between long runs. This historical context enables realistic training progressions based on actual performance rather than user estimates.

Sleep coaching applications benefit similarly by analyzing sleep patterns alongside other lifestyle factors. They can correlate sleep quality with workout intensity, daily activity levels, and timing patterns to provide targeted improvement recommendations.

Wellness and Habit Tracking

Wellness applications help users understand connections between different health metrics. Users can discover how their step count affects mood scores or whether meditation practice correlates with stress levels measured through heart rate variability. These insights require cross-referencing multiple data types over extended periods, which the MCP server handles automatically.

The server's trend analysis tools identify patterns that would be difficult to spot manually, enabling apps to surface meaningful insights without building custom analytics infrastructure.

Corporate Wellness Platforms

Enterprise wellness solutions can analyze employee health trends while maintaining privacy. Companies building B2B wellness platforms can query aggregate activity levels across teams, helping design better wellness initiatives based on actual usage patterns rather than assumptions.

These platforms often serve clients willing to pay premium prices for personalized medicine approaches, where detailed health analysis justifies higher service costs.

Research and Analytics Tools

Researchers studying personal health patterns can access structured data from Apple Health exports without building custom parsers for each study. A research platform can quickly extract heart rate data during workout sessions across hundreds of participants, standardizing the analysis process.

Data enthusiasts building personal health dashboards can ask complex questions about their metrics without database expertise. The natural language interface makes health data exploration accessible to non-technical users while providing the depth that power users require.

AI Health Assistants and Chatbots

Developers building AI health assistants can use the MCP server to create context-aware coaching experiences. An AI assistant can notice that a user's resting heart rate has been elevated for several days while sleep quality decreased, then suggest recovery strategies based on what worked during similar periods in their historical data.

These applications become particularly powerful when they can reference years of user data to provide personalized recommendations rather than generic health advice.

Clinical Decision Support Tools

Healthcare applications can use Apple Health data to provide additional context during patient consultations. While not replacing clinical monitoring, the lifestyle data helps clinicians understand patient behavior patterns between visits.

A telehealth platform might analyze a patient's activity levels and sleep patterns leading up to reported symptoms, helping providers make more informed recommendations during virtual consultations.

Getting Started

The Apple Health MCP Server is available on GitHub with Docker setup and documentation for popular MCP clients. Development teams can integrate it into existing applications or use it as the foundation for new health-focused products.

Resources:

The server represents a significant acceleration in accessing health context for application developers. Teams can focus on creating value-added features rather than building data processing pipelines.

FHIR MCP Server: Use Cases for Healthcare Developers

Bartosz Michalak — Wed, 05 Nov 2025 12:36:34 +0000

FHIR MCP Server: Use Cases for Healthcare Developers

Healthcare systems generate vast amounts of structured clinical data through Electronic Health Records (EHRs), but accessing this information efficiently requires deep knowledge of FHIR standards and medical terminology. FHIR is the gold standard for healthcare data exchange, but its complexity often becomes a barrier for developers who want to build healthcare AI solutions.

What is FHIR MCP Server

The FHIR MCP Server is an open-source tool that implements the Model Context Protocol, providing a natural language interface for FHIR-compliant healthcare systems. It bridges the gap between complex FHIR resources and AI applications by handling the technical complexity of healthcare data standards.

The server provides full CRUD operations on major FHIR resources like Patient, Observation, Condition, and Medication through tools that AI agents can use naturally. Instead of learning FHIR specifications and writing custom integration code, developers can query clinical data using conversational language through MCP-compatible clients like Claude Desktop.

Key capabilities include automatic LOINC code validation to prevent AI hallucination of medical terms, intelligent document processing through vector search, and seamless integration with existing FHIR-compliant backends like Medplum or Epic.

Why It Matters for Healthcare Developers

Building healthcare applications typically means spending weeks learning FHIR documentation before writing a single line of application code. Even experienced developers struggle with medical terminology validation, OAuth2 flows for FHIR servers, and the complexity of healthcare data relationships.

The FHIR MCP Server eliminates this learning curve. Developers can focus on building clinical features instead of becoming FHIR experts. The server handles authentication complexity, prevents medical code hallucination, and provides semantic search across clinical documents - all through simple natural language queries.

his approach is particularly valuable when building AI-powered clinical tools where accuracy is critical and development speed determines market success. Unlike traditional APIs that require developers to understand complex FHIR data models where nearly all fields are optional, MCP enables AI agents to adaptively select appropriate tools and input parameters, iteratively refining their approach when encountering errors.

Use Cases for Developers

Clinical Decision Support Systems

Healthcare developers building CDSS tools can leverage patient medical histories to help clinicians make better decisions. A doctor reviewing a patient with headaches can ask an AI assistant whether any previously diagnosed conditions might be related to current symptoms.

The FHIR MCP Server automatically retrieves relevant patient conditions, analyzes medication history, and checks recent lab results to provide a complete clinical picture. This eliminates the manual process of searching through multiple EHR screens and reduces the risk of missing important clinical connections.

EHR Integration and Analytics

Development teams building analytics dashboards for healthcare organizations can use FHIR MCP Server to query clinical data without writing complex FHIR queries. Instead of having technical teams become bottlenecks for every data analysis request, clinical staff can ask questions directly.

A quality improvement team can query "Show me all patients with diabetes who haven't had an A1C test in the past 6 months" without understanding FHIR resource structures or LOINC codes. The server handles the medical terminology and returns accurate results.

Healthcare AI Applications

AI-powered healthcare tools require reliable access to structured clinical data. Developers building diagnostic support tools, treatment recommendation engines, or clinical research platforms can use FHIR MCP Server to ensure their AI models receive accurate medical data.

The server's built-in LOINC validation prevents common issues where AI models hallucinate medical codes or misinterpret clinical terminology. This accuracy is essential for healthcare applications where incorrect data interpretation can impact patient care.

Telemedicine and Remote Monitoring

Telemedicine platforms need quick access to patient histories during virtual consultations. Instead of clinicians manually searching through patient records, AI assistants powered by FHIR MCP Server can surface relevant information contextually.

A telemedicine provider can ask "What chronic conditions does this patient have and what medications are they currently taking?" The server processes the query against FHIR resources and returns structured information that helps providers make informed decisions during time-limited virtual visits.

Clinical Research and Data Analysis

Research teams conducting clinical studies often need to extract specific patient cohorts or analyze treatment outcomes across large datasets. FHIR MCP Server enables researchers to query clinical databases using natural language instead of writing complex database queries.

Researchers can ask "Find all patients diagnosed with hypertension in the last two years who are currently on ACE inhibitors" and receive accurate results without deep FHIR knowledge. This accelerates research timelines and reduces technical barriers for clinical investigators.

Healthcare Workflow Automation

Healthcare organizations building internal tools for care coordination can use FHIR MCP Server to automate routine clinical workflows. Care managers can set up automated queries to identify patients who need follow-up care or are due for preventive screenings.

The server can power notifications like "Identify diabetic patients who haven't had eye exams in 12 months" or "Find patients on blood thinners who need upcoming lab monitoring." These queries run automatically and help healthcare teams stay proactive about patient care.

When FHIR MCP Server Adds Value

FHIR MCP Server is most valuable when you're building healthcare applications that need to integrate with existing clinical systems, require medical terminology accuracy, or want to provide AI-powered clinical insights. It's particularly useful for teams that want to prototype healthcare AI features quickly without investing months in FHIR learning.

The server works best for applications where clinical accuracy is critical, integration with EHR systems is required, or where non-technical healthcare staff need to query clinical data directly. It's designed for scenarios where generic AI tools aren't sufficient because healthcare-specific validation and terminology are essential. Traditional API endpoints often fall short in healthcare scenarios due to FHIR's complexity - making it an ideal use case for MCP's adaptive, AI-driven approach to data interaction.

Getting Started

The FHIR MCP Server is available on GitHub with Docker setup and works with popular FHIR backends like Medplum out of the box. The server includes comprehensive documentation, demo videos, and can be configured with Claude Desktop or any MCP-compatible client in under five minutes.

Resources:

For healthcare development teams, the server provides immediate access to clinical data through natural language interfaces, allowing teams to focus on building features that improve patient care rather than wrestling with healthcare data standards.

Apple Health Data Analysis with AI: Our Hackathon Story

Bartosz Michalak — Fri, 24 Oct 2025 05:59:29 +0000

Key Takeaways

Personal health metrics like VO2 max become truly actionable when you can ask questions about them and get AI-powered insights rather than just viewing raw numbers in an app.
The hackathon solution eliminates two major friction points: complicated setup processes and the need for manual data exports, making continuous access to Apple Health data practical for everyday users.
By connecting Apple Health data through a MCP Server connected to LLM Client, users can have natural conversations with AI assistants about their workout performance, trends, and areas for improvement.
Automation tools like n8n enable scheduled fitness summaries and coaching feedback delivered straight to your inbox, turning passive data collection into active motivation.
The project is evolving toward a complete open-source ecosystem that will support multiple wearables, local LLM models for privacy, and custom reports for trainers, making personalized fitness insights accessible to millions of smartwatch users worldwide.

Apple Health is a great source of various metrics. But what do all of these metrics mean? With each new version of iOS and WatchOS, we get more and more insights, but it's still far from ideal. I'll give you an example from my personal life.

A while back, I was reading Outlive. One chapter made the biggest impression on me. It was about VO2 max, what this metric says about our health, and what its value means for our current and future capabilities. I really love hiking, so Peter Attia couldn't have reached me with a better message. He showed what different values of VO2 max mean when it comes to fitness capabilities at different ages. The graph shows the decline of maximum oxygen uptake (VO2 max) with age for three fitness groups. You can clearly see that someone in high fitness condition (95th percentile) at age 62 has the same aerobic capacity as an average 25-year-old. Meanwhile, someone in poor condition (5th percentile) may struggle with simple activities like quickly climbing stairs already at age 45.

Source: Jayson Gifford (https://x.com/JaysonGifford/status/1537185279781482496)

So I was really curious: what's my current VO2 max? I was pretty confident about this value since I considered myself a pretty fit person. I ran quite a bit, played soccer, cycled, played squash, and walked a lot. So it couldn't be bad. But when I checked the values, it turned out my VO2 max didn't look that good at all.

I was below average. I looked at the table from the book again and realized I had to do something about it. I checked how I could increase this value. One way was interval running. I thought, why not? After all, I like running; I only needed to change the type of training.

So I added intervals to my running, and after a while, I started seeing results. I was curious, though: is my running technique and interval training good? Besides progress in VO2 max values, am I also making progress in my times? Could any of my habits (like getting relatively little sleep) be negatively affecting these values? I couldn't find answers to any of these questions directly in the app, so I started wondering what if I used LLMs to analyze my data?

That's how the idea for creating an Apple Health MCP server was born, which you can read more about here.

After a while, it turned out this solution had two main problems:

Difficulty with installation and setup, though it wasn't a problem for me personally since you only need to do it once, many friends asked me for help, and every time it took forever.
Data updates, the server relied on an export.xml file, which was the result of manually exporting data from Apple Health. In the long run, this was a really annoying process because to have current data, I had to spend about 10 minutes each time on manual export and then transfer the data to my computer.

But finally, an opportunity came up to solve these problems. That opportunity was a hackathon.

What did we do during the hackathon?

The goal was simple: solve the two problems above. My personal ambition was to “free” my data from Apple Health, make it available through an API, and then expose it to LLMs (like Claude) via an MCP server. The stretch goal was to add automation that would, for example, send a weekly summary comparing the results to the previous week.

So our architecture looked roughly like this:

Below you'll find a short description of each system component.

Mobile (export) app

The only way to have continuous access to Apple Health data is through integration with Apple HealthKit, so we needed an application. Our hackathon team didn't have a mobile developer, and there were only three of us. We determined this might be too ambitious a task for several hours. We therefore decided to use the Apple Health Export application, which enabled exporting data to external sources, including an HTTP endpoint.

Backend

The first component we needed to create was the backend. From building the Apple Health MCP, we already had experience with what data is available in Apple Health and what data models we would need. However, we made the decision that at the hackathon we would only handle workout data, omitting health metrics. The demo was supposed to focus on summarizing workout data, providing interesting insights, and motivation to keep pushing.

We based the backend on FastAPI. For this purpose, we used python-ai-kit, a boilerplate that significantly accelerates the initial steps of application development. Thanks to this, we could focus on the actual work:

creating models
exposing a webhook consuming data sent by the mobile application
exposing an endpoint returning workout data

That was really quick. With the help of generative AI (Cursor), we built all of these parts pretty fast; however, it wouldn't have been possible without knowing how Apple Health data is structured, so we could use the experience from building the Apple Health MCP Server.

The most important model was Workout:

`class Workout(Base):
tablename = "workouts"

id: Mapped[UUIDType] = mapped_column(UUID(as_uuid=True), primary_key=True)
name: Mapped[str | None] = mapped_column(String(255))
location: Mapped[str | None] = mapped_column(String(100))
start: Mapped[datetime] = mapped_column(DateTime(timezone=True))
end: Mapped[datetime] = mapped_column(DateTime(timezone=True))
duration: Mapped[Decimal | None] = mapped_column(Numeric(15, 5))

# aggregate metrics
active_energy_burned_qty: Mapped[Decimal | None] = mapped_column(Numeric(15, 5))
active_energy_burned_units: Mapped[str | None] = mapped_column(String(50))
distance_qty: Mapped[Decimal | None] = mapped_column(Numeric(15, 5))
distance_units: Mapped[str | None] = mapped_column(String(50))
intensity_qty: Mapped[Decimal | None] = mapped_column(Numeric(15, 5))
intensity_units: Mapped[str | None] = mapped_column(String(50))
humidity_qty: Mapped[Decimal | None] = mapped_column(Numeric(10, 2))
humidity_units: Mapped[str | None] = mapped_column(String(10))
temperature_qty: Mapped[Decimal | None] = mapped_column(Numeric(10, 2))
temperature_units: Mapped[str | None] = mapped_column(String(10))

# relationships
heart_rate_data: Mapped[list["HeartRateData"]] = relationship(
    back_populates="workout",
    cascade="all, delete-orphan",
    passive_deletes=True,
)
heart_rate_recovery: Mapped[list["HeartRateRecovery"]] = relationship(
    back_populates="workout",
    cascade="all, delete-orphan",
    passive_deletes=True,
)
active_energy: Mapped[list["ActiveEnergy"]] = relationship(
    back_populates="workout",
    cascade="all, delete-orphan",
    passive_deletes=True,
)`

This model captures comprehensive workout information, including:

Temporal data: workout duration and start/end times for time-series analysis.
Performance metrics: active energy burned, distance covered, workout intensity.
Environmental conditions: temperature and humidity during exercise.
Detailed heart rate insights through relationships (real-time HR data during workouts, post-workout recovery rates, and energy expenditure patterns).
Location context: indoor vs. outdoor activities.

Looking at this carefully, you'll realize it needs improvements, for example:

Lack of indexing on commonly queried fields (start/end dates, location, workout name).
No validation for data ranges (e.g., temperature, humidity, duration must be positive).
Workout type field is a string instead of an enum.
No source tracking to identify data origin (Apple Watch, iPhone, third-party apps).

However, due to hackathon time constraints, we prioritized getting a working prototype over data model polishing.

MCP Server

The next step was to create an MCP server. We again leveraged python-ai-kit, built on top of the FastMCP framework. Below you can see how this boilerplate streamlines project creation.

Since FastAPI, which we were using in our backend, exposes OpenAPI by default, we were able to ask Cursor to add two tools: get_heart_rate and get_workouts.

The logic was simple. The tools were essentially API wrappers without adding too much custom logic on top of them. However, it was a hackathon, and we simply needed a working version.

By basing the server on FastMCP, we were able to leverage deployment via fastmcp.cloud. The only thing we had to do was connect and specify the GitHub repository where the MCP server was located, and that went very quickly.

fastmcp.cloud also provides tools for debugging MCP servers and the ability to view logs, which is very useful during development.

N8N automation

Since we still had some time left, we decided to add automation in N8N.

It was pretty straightforward, which is why I love N8N. It's ideal for very fast prototyping due to many ready-made integrations.

What you can see on the diagram (from the left):

HTTP request node: it requested our backend to fetch workout data. We used query params to filter workouts only from the latest month.
AI summary node: it took the data returned by the API, then, using an OpenAI model, prepared a summary. We had quite a bit of fun creating prompts and setting the tone of voice. Some of the generated summaries weren't nice.
Summary sending by e-mail node: it's quite self-explanatory.

N8N allows you to save the flow configuration in a .json file, so it’s easy to experiment and keep a stable version safe in the repository.

Claude

To test our MCP server, we used Claude. Since the server was available online, the configuration was very straightforward.

Claude → Settings → Connectors → Add custom connector → Set name and URL → Done.

Tip: If you're using an enterprise Claude subscription, the “Add custom connector” option may be unavailable to you. Custom extensions must be activated by the organization administrator. Then it will be possible to select it from the “Browse connectors” list.

Once added, we could check if Claude could see all the needed tools

How did the solution work?

Demo time came faster than we expected. Like every team, we had three minutes to present our solution.

I started the presentation by asking Claude what it thought about my September activity. The summary was quite comprehensive and aligned with reality (I had to check in the Apple Health app because I didn't think I had worked out that many times in total).

I also asked it about the highlights.

Unfortunately, we didn't have time to construct questions to sensibly utilize the data from the MCP tool that returned heart rate data. If you look closely, not everything worked perfectly, the calorie count was incorrectly returned for some reason. It's impossible that I burned 1,740 calories during a ~7 km run. But it was a demo, and nobody noticed.

If you read the introduction of this article, you may also notice that although I also cared about analyzing my VO2 max, the summary doesn't mention it at all. That's right. As I mentioned during the backend implementation, we decided to severely limit the scope of supported data due to limited time.

Next, we presented the result of our automation created in N8N. For the demo, we decided to choose a gentler version of the coach (though still demanding).

As you can see, I have some things to improve.

Were we satisfied with our solution? Yes, we managed to ensure continuous data flow (which was previously a problem) and demonstrate that, thanks to the MCP server, our chosen LLM client has continuous access to the data. We were also very satisfied with how python-ai-kit, which we've been intensively developing recently, helped us set up both the backend and the MCP server.

The hackathon repository is available here.
You'll find all the above-described modules in it: backend, MCP server, and N8N workflow.

What's next?

The demo made quite a good impression (though we didn't win). However, for us, it was just the beginning. AI insights based on wearables data are something we've been thinking about for quite some time.

At Momentum, we also collaborated with many companies that utilized wearables data in one way or another, thanks to which we learned a lot about them. We know that time-series data analysis isn't always simple and straightforward.

We plan to develop the solution whose development we started at the hackathon. On our roadmap at this moment is:

support for all data supported by Apple Health
fixing all the known issues in the Apple Health MCP Server (issues)
creating our own open-source application that will allow users to export data but also analyze it directly on their phone
support for other wearables, such as Garmin, Fitbit, or Oura Ring
a web application that will allow browsing data and conversing with it
ability to share data with your trainer and generate custom reports for them
support for local LLM models (we know how important privacy is in healthcare)
model fine-tuning
many more

What’s more, we will build this ecosystem as an open-source solution, so we encourage you to follow our Momentum GitHub to stay informed.

The wearables market is huge. According to the latest data, there are over 450 million smartwatch users worldwide (as of the end of September 2025), and their number is growing rapidly. We believe that these users deserve the opportunity to leverage the latest technologies such as gen AI to receive personalized health and fitness insights.

We’d love for you to explore the Apple Health MCP repo, try it out with your own Apple Health exports, and share feedback or contributions. Open source works best when it’s collaborative, and this is our invitation to build the future of healthtech with us by proposing new features, participating in collaboration, and helping shape the direction of the project.

Project Templates in Python

Sebastian Kalisz — Tue, 21 Oct 2025 11:57:15 +0000

Have you ever struggled to know where to start with a programming project? This can lead to many questions...

How to divide code between modules?
What is the best way to name files?
How can redundancy be avoided?

... and many more. One way to master this chaos is to prepare suitable templates.

You can read entire article [HERE]!

Mastering SQLAlchemy Declarative Models

Sebastian Kalisz — Mon, 13 Oct 2025 11:23:22 +0000

Have you even wondered how to build ORM models like a pro? In my latest article you can read about:

how to create custom mapping for python and sql data types
how to use generic Annotated types to simplify syntax for columns properties
how to make use of metaclasses to achieve better relationships

You can read entire article here [HERE]!

FHIR MCP Server: Empowering Healthcare with Natural Language Interfaces

Bartosz Michalak — Wed, 08 Oct 2025 07:26:23 +0000

Open-source FHIR MCP Server, a tool that enables users to work with healthcare data using natural language-removing the need for in-depth FHIR expertise and reducing mistakes such as AI-generated code errors. Built on the Model Context Protocol, it integrates with AI clients like Claude, Cursor, and other MCP-compatible platforms. The server addresses key EHR integration challenges, including medical terminology validation, regulatory compliance, and clinical data accuracy. It supports full FHIR resource operations, automatic LOINC code validation, and semantic search across medical documents. With these features, developers can create applications that let clinicians query patient histories conversationally and build clinical decision support tools efficiently. Check it out on Momentum’s GitHub.

You’ll learn:

How FHIR MCP Server streamlines healthcare data access with natural language,
Which technical capabilities are included and how they address interoperability and compliance,
Practical examples of using conversational queries and rapid app development for healthcare,
What challenges in clinical data integration it helps overcome.

Watch our demos showing real patient data analysis and clinical workflows.

Read the full article and technical details here.

Python 3.14 - What's new?

Sebastian Kalisz — Tue, 07 Oct 2025 15:42:51 +0000

October is here, which means it’s time for the yearly Python release. At last, π edition (Python 3.14) arrives with new features, like deferred evaluation of annotations or template strings. Here’s my breakdown of the key changes that will be included.

What is highlighted?

deferred evaluation of type annotations
template strings
built-in support for free-threaded (no-GIL) Python
except expressions without parentheses
syntax highlighting in REPL

You can read entire article [HERE]! Checkout an example of what's inside -> example of how new t-strings works in comparison to the old f-string: