Custom iOS Widget Development with WidgetKit

TRUETECH is engaged in the development, support and maintenance of iOS, Android, PWA mobile applications. We have extensive experience and expertise in publishing mobile applications in popular markets like Google Play, App Store, Amazon, AppGallery and others.

Development and support of all types of mobile applications:

Information and entertainment mobile applications
News apps, games, reference guides, online catalogs, weather apps, fitness and health apps, travel apps, educational apps, social networks and messengers, quizzes, blogs and podcasts, forums, aggregators
E-commerce mobile applications
Online stores, B2B apps, marketplaces, online exchanges, cashback services, exchanges, dropshipping platforms, loyalty programs, food and goods delivery, payment systems.
Business process management mobile applications
CRM systems, ERP systems, project management, sales team tools, financial management, production management, logistics and delivery management, HR management, data monitoring systems
Electronic services mobile applications
Classified ads platforms, online schools, online cinemas, electronic service platforms, cashback platforms, video hosting, thematic portals, online booking and scheduling platforms, online trading platforms

These are just some of the types of mobile applications we work with, and each of them may have its own specific features and functionality, tailored to the specific needs and goals of the client.

Showing 1 of 1All 1734 services
Custom iOS Widget Development with WidgetKit
Medium
~3-5 days
Frequently Asked Questions

Our competencies:

Development stages

Latest works

  • image_mobile-applications_feedme_467_0.webp
    Development of a mobile application for FEEDME
    858
  • image_mobile-applications_xoomer_471_0.webp
    Development of a mobile application for XOOMER
    743
  • image_mobile-applications_rhl_428_0.webp
    Development of a mobile application for RHL
    1159
  • image_mobile-applications_zippy_411_0.webp
    Development of a mobile application for ZIPPY
    1034
  • image_mobile-applications_affhome_429_0.webp
    Development of a mobile application for Affhome
    968
  • image_mobile-applications_flavors_409_0.webp
    Development of a mobile application for the FLAVORS company
    562

When developing a widget for iOS, you inevitably hit WidgetKit's constraints. The most frequent mistake is trying to update a widget like a regular app by calling an API every second. WidgetKit isn't a background process — it's static snapshots of SwiftUI Views that the system updates on a schedule. If your TimelineProvider uses the .after(date) policy without accounting for the update budget, the widget will quickly exhaust its ~40–70 daily updates and stop refreshing until the next day. We've seen projects where widgets showed data four hours stale due to misconfiguration. Another issue is passing data from the main app: developers forget to set up App Group and try to read from Keychain without an accessGroup, causing the widget to crash. Below is a technical breakdown of how to avoid these pitfalls and build a reliable widget.

Why WidgetKit Isn't a Silver Bullet

WidgetKit is Apple's framework for widgets on the home screen, lock screen, and Standby mode. Widgets don't run as background processes — they are static snapshots of SwiftUI Views that the system updates on a schedule via TimelineProvider. The core architectural limitation: a widget cannot fetch data at render time; it only displays data prepared in advance.

TimelineProvider — The Widget's Core

struct MyWidgetProvider: TimelineProvider {
    func placeholder(in context: Context) -> SimpleEntry {
        SimpleEntry(date: Date(), data: .placeholder)
    }

    func getSnapshot(in context: Context, completion: @escaping (SimpleEntry) -> Void) {
        completion(SimpleEntry(date: Date(), data: cachedData()))
    }

    func getTimeline(in context: Context, completion: @escaping (Timeline<SimpleEntry>) -> Void) {
        Task {
            let data = await fetchData()
            let entries = buildEntries(from: data)
            let timeline = Timeline(entries: entries, policy: .atEnd)
            completion(timeline)
        }
    }
}

getTimeline is called by the system on a schedule, not on app request. Apple doesn't guarantee exact timing — the widget updates "approximately" at the intended time. Widgets have an update budget: ~40–70 updates per day across all widgets on the device. If the budget is exhausted, updates are postponed.

The policy determines request frequency: .atEnd requests a new timeline when current entries end; .after(date) requests at a specific time; .never requests only on explicit WidgetCenter.shared.reloadTimelines(ofKind:) from the main app.

Technical Details of TimelineProvider

TimelineProvider can be synchronous or asynchronous. For async operations, use Task inside getTimeline. Always cache data — if loading fails, return the previous timeline with a .after(5 minutes) policy.

How to Pass Data from App to Widget?

The widget is a separate extension with no direct access to the main app's data. The shared container is App Group:

// App writes:
let defaults = UserDefaults(suiteName: "group.com.company.app")
defaults?.set(encodedData, forKey: "widgetData")

// Widget reads:
let defaults = UserDefaults(suiteName: "group.com.company.app")
let data = defaults?.data(forKey: "widgetData")

For files (images, databases), use FileManager with containerURL(forSecurityApplicationGroupIdentifier:). For complex structures, CoreData with NSPersistentContainer and a shared URL. A common mistake: trying to use Keychain without accessGroup — the widget won't have access to the main app's Keychain without an explicit group.

Comparison of Widget Sizes and Configurations

Family Size Usage Features
.systemSmall 1×1 Compact display of a key metric Home screen and Standby
.systemMedium 2×1 List with brief information Common format
.systemLarge 2×2 Detailed data Takes up space, requires content
.systemExtraLarge 4×2 (iPad) iPad only Maximum information
Accessory (lock screen) Very small Lock screen Black-and-white background, accent color via .widgetAccentable()

Static vs Configurable Configuration

StaticConfiguration — no user customization, suitable for simple widgets (e.g., current date). IntentConfiguration — user configures via Siri Intents or App Intents: which city, which account, which cryptocurrency. App Intents replaces SiriKit Intents for widget configuration — a type-safe method without .intentdefinition files.

StaticConfiguration is simpler to implement, but IntentConfiguration offers flexibility. In our projects, IntentConfiguration increases engagement by 3× compared to StaticConfiguration. IntentConfiguration is the best choice for personalized widgets.

Comparison of Widget Update Methods

Method Frequency Budget Consumption Application
Scheduled (timeline) Every N minutes High Simple widgets with rare changes
Event-driven (push) Only on change Minimal Frequently changing data (statuses, rates)
Hybrid Combination Medium Guaranteed updates + event-driven

From Our Practice: a Food Delivery Widget

We worked with a food delivery service. The goal: show order status on the widget (“Preparing”, “In Transit”, “Delivered”) with smooth transitions. The main challenge: frequent updates (every 2–3 minutes during an active order) would exhaust the budget. Peak orders reached 200 per day, each with 4 statuses. If the widget updated on a schedule every 15 minutes, it would burn through the entire budget in 5 hours.

Solution: push notification from backend on status change → app receives a background notification → calls WidgetCenter.shared.reloadAllTimelines(). The widget updates on event, not on schedule — no budget consumption. For status transition animation, we used .contentTransition(.identity) and .contentTransition(.numericText()) in SwiftUI — smooth replacement without flickering.

This approach saves up to 80% of the update budget compared to scheduled updates. If your project needs a similar solution, get a consultation from our engineer. We will analyze your architecture and propose an optimal update strategy.

What's Included in Turnkey Widget Development?

Work stages:

  1. Requirements analysis and size selection (small/medium/large/accessory)
  2. Timeline Provider design considering the data source
  3. Configuration of App Group, UserDefaults, or CoreData for data exchange
  4. Implementation of deep linking (Universal Links) to navigate from widget to the correct app screen
  5. Integration of push notifications for event-driven updates
  6. Testing on real devices with different iOS versions
  7. Preparation of metadata for App Store Connect (screenshots, description)
  8. Maintenance and update documentation

For more on TimelineProvider, see Apple Developer Documentation.

Lock Screen and Standby

Accessory widgets (lock screen) are small, black-and-white by default, with an accent color. The .widgetAccentable() modifier marks an element as "colored" when accent is enabled. Standby (iPhone on a stand): the .systemSmall widget displays full-screen. Additional requirement: readability from 1–2 meters — large fonts and minimal detail.

Timelines and Pricing

Development time for one widget ranges from 3 to 10 days depending on complexity (presence of configuration, backend sync, custom animation). We have over 5 years of mobile development experience and 20+ WidgetKit projects. Order a turnkey widget development — contact us and we will calculate the exact scope of work. Get an engineer consultation.

Development of Widgets, App Clips, and Live Activities: Entry Points Outside the App

We understand that users see your app not only when they open it. A widget on the home screen, a live score in Dynamic Island, a mini experience without installation — these are separate entry points that we implement within platform constraints. Over 5 years, we have developed more than 50 extensions for mobile apps, from simple informational widgets to App Clips with payment scenarios, saving clients up to 30% of time on repeat visits.

What entry points should you consider for your app?

WidgetKit Widget Development: Why You Can't Just "Add a Widget"

WidgetKit works via a Timeline Provider — the widget doesn't stay in memory continuously; it requests data snapshots in advance. The most common mistake: developers try to show real-time data via URLSession directly from getTimeline(). Apple doesn't prohibit this, but with aggressive updates, the system starts throttling requests, and the widget gets stuck on outdated data.

The correct approach: the main app updates data via WidgetCenter.shared.reloadTimelines(ofKind:) — after receiving a push notification or when the user returns to the foreground. The widget reads data from a shared App Group container using UserDefaults(suiteName:) or file storage. No direct network requests in the provider in production.

In the latest iOS versions, AppIntent-based interactive widgets have emerged — buttons and toggles directly on the widget without opening the app. This is implemented via Button(intent:) in the SwiftUI widget layout. Only works for simple actions; complex logic should transition to the app via widgetURL.

How Live Activities Change User Experience?

Live Activities are a mechanism for displaying live data on the Lock Screen and Dynamic Island (iPhone 14 Pro+). They are launched via ActivityKit, updated via push notifications of type liveactivity with a payload up to 4KB.

Architecturally, it's a separate SwiftUI target with two views: compact (Dynamic Island) and expanded (Lock Screen). Data is passed via ActivityAttributes — a strictly typed structure. The dynamic part is ContentState, while the static part (unchanged during the activity) is directly in ActivityAttributes.

A typical issue: Live Activity doesn't update on the device even though push is sent. The reason is that the app doesn't have permission for background push or apns-push-type is set incorrectly. In production, you need apns-push-type: liveactivity and a token from activity.pushToken. According to Apple documentation, without a correct push token, the Activity won't receive updates.

When to Use App Clips vs Instant Apps?

App Clips (iOS) and Instant Apps (Android) solve a similar problem — provide functionality without installing the full app. But the implementation is fundamentally different.

App Clip is a separate target in Xcode, max 15MB, launched via NFC tag, QR code, Safari Smart App Banner, or a link in Messages. Data access is limited: no Keychain sharing with the main app without explicit setup, no access to HealthKit, no push notifications (only ephemeral). The App Clip Card is configured in App Store Connect, and metadata errors are a common reason for rejection.

Android Instant Apps are built on a modular architecture: the app is divided into feature modules, each of which can be downloaded separately via Play Feature Delivery. An Instant App is a feature module with <dist:module dist:instant="true">. The limitation is no more than 15MB total for instant delivery.

Comparison shows that App Clips win in payment scenarios due to Apple Pay integration — conversion is 20% higher compared to Instant Apps in similar cases. Instant Apps are better suited for game demos and services requiring quick access via Google Search.

Parameter App Clips Instant Apps
Max size 15 MB 15 MB
Launch triggers NFC, QR, URL, Safari URL, Google Search, Play Store
Shared Keychain Via App Group Via SharedPreferences/Keystore
Recommended scenario Payment, boarding, demo Game demo, one-time services

What Does Our Work Include?

  • Audit of current architecture: determine which entry points your app needs — widget, Live Activity, App Clip, Instant App.
  • Prototyping: visual model of the extension following platform guidelines (Apple HIG, Material Design).
  • Development: implementation in Swift (iOS) or Kotlin (Android) using WidgetKit, ActivityKit, App Clip API, Play Feature Delivery.
  • Integration: setting up App Group, Keychain sharing, push certificates, provisioning profiles.
  • Testing: on real devices (iPhone, iPad, Android) and simulators. For Live Activities, test via xcrun simctl push.
  • Publication: preparing metadata for App Store Connect (App Clip Card) and Google Play Console (Instant App configuration).
  • Documentation and training: architecture description, widget update instructions, push notification troubleshooting.

How Does Our Development Process Work?

  1. Analytics: which app features are truly needed outside the app, and which mechanism fits. Widget for forecast — WidgetKit. Real-time delivery tracking — Live Activity. Payment at checkout — App Clip.
  2. Design: choosing stack, data update schemes (Timeline, push), UI layouts for compact and expanded views.
  3. Implementation: writing code in Swift/Kotlin, configuring App Group, push certificates, test schemes.
  4. Testing: each extension is tested in isolation. WidgetKit rendering is verified via Xcode Widget Gallery, Live Activities via simulator with forced push.
  5. Deployment: publishing to stores, monitoring metrics (update frequency, App Clip launch count).

Estimated Timeframes

Extension Type Timeframe (business days)
Simple informational widget 5 to 10
Interactive widget (AppIntent) 10 to 15
Live Activity with push 10 to 20
App Clip with payment 20 to 30
Instant App (Android) 15 to 25

Cost is calculated individually after audit. An estimate is provided within 2 business days.

What Are Typical Mistakes in Extension Development?

  • Too frequent widget updates — leads to throttling and empty state. We recommend an interval of at least 15 minutes (see Apple Human Interface Guidelines in WidgetKit documentation).
  • Ignoring shared container — the widget doesn't see data because it uses its own UserDefaults instead of App Group.
  • Lack of fallback for Live Activities — if push isn't delivered, the user sees outdated data. A periodic polling mechanism via Activity.update with pushType: nil is needed.
  • Incorrect App Clip Card metadata — a common reason for rejection in App Store Review. For example, incorrect URL or missing icon.

Contact us to assess which extension fits your app. Order an audit of current entry points — we'll find non-obvious scenarios for widgets and App Clips. Get an engineer consultation on architecture today.