Swiftpack.co - tryVital/vital-ios as Swift Package

Swiftpack.co is a collection of thousands of indexed Swift packages. Search packages.
See all packages published by tryVital.
tryVital/vital-ios 0.31
The official Swift Library for Vital API, HealthKit and Devices
⭐️ 18
🕓 39 weeks ago
.package(url: "https://github.com/tryVital/vital-ios.git", from: "0.31")


The official Swift Library for Vital API, HealthKit and Devices


We currently support SPM.


Please refer to the official Vital docs provide a full reference on using this library.


vital-ios is available under the AGPLv3 license. See the LICENSE file for more info. VitalDevices is under the Adept Labs Enterprise Edition (EE) license (the “EE License”). Please refer to its license inside its folder.


Stars: 18
Last commit: Yesterday
jonrohan Something's broken? Yell at me @ptrpavlik. Praise and feedback (and money) is also welcome.

Release Notes


Vital iOS SDK 0.9.1 is a recommended update.

NEW: Device-comptued Daily Activity Summary

The Vital SDK now computes daily activity summary on the end device.

This helps reduce load on Vital's databases, while ensuring that aggregates in every activity summary are exactly matching day-by-day numbers in the week views of the Apple Health app in any named time zone, by using the same Apple-maintained aggregation API.

Summary time zone handling

Daily activity summary uses the device time zone at sync time [1].

While the time zone could potentially change over the course of a day, and you might receive webhooks that reflect the time zone changes accordingly, the general rule of thumb is that the last observed device time zone eventually “wins”. In other words, given a specific calendar date, Vital API always reports activity summary for it in the time zone where the final update for it was sent.

[1] Recap: Sync is automatically triggered when the SDK is configured during app launch, or in response to Apple HealthKit change notifications in foreground and background.

NEW: Performance improvements

We have optimized our HealthKit usage — a 7x reduction in execution time for 120-day historical backfill has been observed on iPhone 13 mini during our testing.

We expect this improvement to be proportional to the number of backfill days, and the device CPU power.

RECAP: Support for new data types

  • Mindful Minutes as a standalone resource (since 0.7.13)
  • Heart Rate Variability as a standalone resource (since 0.7.14)
  • Sleep resources now include Apple Watch wrist temperature (since 0.7.17)

FIXED: Discrepancies in Steps timeseries data

Any new dailly and historical steps timeseries data sent post SDK upgrade should now exactly match the hour-by-hour numbers in the day view of the Apple Health app.

FIXED: Excessive profile resource updates

The SDK now sends updates for profile resources only when value changes are observed, instead of sending one unconditionally every time the SDK is configured (i.e., practically every app launch).

FIXED: Miscellanous fixes

We have fixed a race condition that may cause multiple SDK instances being created, resulting in undefined behaviour.

We have addressed several issues that might cause the SDK to fail to comply with the tight timing requirements for HealthKit background delivery as imposed by Apple.

Incompliance to the tight timings can result in the app being deregistered from background delivery, until the app is relaunched by the user (where the SDK auto-renews the registration for background deliveries).

It is recommended to adopt the following APIs, if you haven’t done so already:

  • [Flutter & iOS Native]

    • Make sure VitalHealthKitClient.automaticConfiguration() is called before your AppDelegate’s application(_:didFinishLaunchingWithOptions:) method returns in your Swift-based Xcode project.
  • [React Native]

    • Make sure [VitalHealthKitConfiguration automaticConfiguration] is called before your native FlutterAppDelegate subclass' application:didFinishLaunchingWithOptions: method returns in your ObjC-based app project.
  • [iOS Native]

    • If you are using any of the async VitalHealthKitClient.configure* methods, consider adopting automaticConfiguration() as mentioned above.

Note that what automaticConfiguration() does is to use last-known SDK configuration to get ready for HealthKit background delivery reception. Your app is still expected to call the proper SDK configure(...) and setUserId(_:) methods (from Dart, JS/TS or Swift) eventually, with the most up-to-date configuration and user ID.

Example snippets

Swift app projects:

import VitalHealthKit

class AppDelegate: NSObject, UIApplicationDelegate {
  func application(
    _ application: UIApplication,
    didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
  ) -> Bool {
    // ... <snipped>


    // ... <snipped>

React Native ObjC app projects:

#import "VitalHealthKitConfiguration.h"

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
    // ... <snipped>

    [VitalHealthKitConfiguration automaticConfiguration];

    // ... <snipped>

ObjC app projects:

@import VitalHealthKit;

- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
    // ... <snipped>

    [VitalHealthKitClient automaticConfigurationWithCompletion:nil];

    // ... <snipped>

What's Changed

Full Changelog: https://github.com/tryVital/vital-ios/compare/0.9.0...0.9.1

Swiftpack is being maintained by Petr Pavlik | @ptrpavlik | @swiftpackco | API | Analytics