🏄‍♂️ Live Activity(WidgetKit) 연동 및 사용해 보기

ActivityConfiguration | Apple Developer
Live Activities | Apple Developer

🍎 WidgetKit 이란 ?
🔒 [Swift] 잠금화면 위젯 만들기 - WidgetKit
🎸 [Swift] Live Activity 사용해 보기

이번 글에서는 앞서 작성한 iOS의 WidgetKit의 기능인 홈 위젯과 Live Activitiy 기능 중 Live Activity를 Flutter 프로젝트에 추가하고 연결하는 방법 및 사용법에 대해서 작성해보려고 한다.

WidgetKit 익스텐션을 추가하여 Flutter 프로젝트에 적용하는 방법과 Live Activity 기능을 Flutter에서 처리하는 방법 및 Live Activity의 상태를 로컬 및 서버에서 변경하는 방법까지 살펴볼 예정이다.
추가로 Flavors(빌드변형) 환경에서 iOS의 Extension을 다루는 방법까지도 함께 살펴보도록 하겠다.

📌 여기서는 WidgetKit Extension을 Flutter에 적용하고 Live Activity를 다루는 방법만 작성하였고, 홈 & 잠금화면 Widget의 사용 방법에 대해서는 해당 글을 참고 !
- [Swift+WidgetKit] 홈(Home) 위젯
- [Swift+WidgetKit] 잠금화면(Lock Screen) 위젯

WidgetKit ? Live Activity ?

WidgetKit? Live Activity? 이게 다 뭘까 ?

Widget	Live Activity
Home	Lock Screen	Lock Screen	DynamicIslands	DynamicIslands

위의 이미지가 모두 WidgetKit의 기능들이고, 대표적으로 홈과 잠금화면에 표시할 수 있는 Widget과 다이나믹아일랜드와 잠금화면에 실시간 현황이라고 나타나는 Live Activity로 구성된다.

WidgetKit과 Live Activity에 대해서 간단하게 설명하자면, WidgetKit은 iOS 14 버전부터 도입된 프레임워크로, 사용자가 홈 화면 및 잠금화면에서 손쉽게 정보를 확인할 수 있는 위젯을 개발하는데 사용되는 확장 기능이고, Live Activity는 WidgetKit에 내장된 기능 중 하나로, iOS 16 버전에 추가된 기능이고 사용자가 실시간으로 진행 중인 작업을 홈 화면 및 잠금 화면에서 직접 추적할 수 있도록 지원하여 사용자에게 실시간으로 업데이트되는 정보를 제공할 수 있도록 한다. 16.2 버전 부터는 DynamicIsland를 지원하는 디바이스에 대해서 추가적인 실시간 정보도 제공할 수 있게 해준다.

즉, WidgetKit은 사용자가 앱을 진입하지 않더라도 홈 또는 잠금화면에서 정보를 확인하고 실시간으로 추적할 수 있는 기능이다.

WidgetKit과 Live Activity에 대해서 더 자세히 알고 싶다면 아래 공유된 글을 참고하시길 바란다.

🍎 WidgetKit 이란 ?
🎸 [Swift] Live Activity 사용해 보기

Flutter + WidgetKit

본격적으로 Live Activity를 사용하기 앞서 Flutter에 배포된 패키지 중 Live Activity 기능을 Flutter에서 간단하게 구현할 수 있는 live_activities 패키지가 있다.
해당 패키지를 사용하게 되면, Native로 처리해야 하는 이벤트 및 기능들을 손쉽게 Flutter에서 사용할 수 있도록 해주는 점은 편리하지만 여전히 Extension이나 UI 부분은 직접 네이티브에서 처리를 해야하기 떄문에 직접 구축하는 것을 추천합니다 !

앞서 설명한 것과 같이 Widget이나 Live Activity, DynamicIsland나 모두 UI는 SwiftUI로 작업을 해야한다. 가벼운 UI만 처리하는 것은 SwiftUI를 모르더라도 조금만 찾아보면서 하면 어렵지는 않을 것이라 생각한다.

이제 본격적으로 Flutter 프로젝트에 적용해보도록 하자.

패키지 예시로 보면 축구 경기 스코어가 나오는 실시간 현황을 제공하고 있는데, 여기서는 예시로 야구 경기 점수를 보여주는 기능을 만들어보면서 Live Activity를 사용해 보도록 하자.

Open in XCode

프로젝트 수준에서 터미널을 열고, XCode를 열어주도록 하자. 만일 .xcworkspaces 파일이 없다면 ios 폴더를 XCode에서 직접 열어줘도 된다.

open ios/Runner.xcworkspace

Add Widget Extensions

Widget Extension을 추가하여 WidgetKit을 사용해 보자.

File > New> Targret

Product Name은 본인이 사용할 위젯킷의 이름을 지정하시면 되고, Team에는 현재 프로젝트의 팀과 동일한 팀으로 선택하시고 다음으로 넘어가도록 하자.

여기서 Live Activity 사용을 원한다면 반드시 "Include Live Activity"가 체크되어 있어야 한다.

Finish를 하게 되면 아래 안내 문구가 나오게 되는데(안나오는 경우도 있음), 생성하려는 위젯의 Scheme가 활성화 되지 않았다고 어떻게 할거냐 묻는건데, 실행 타겟을 설정 할지에 따라 선택을 하면 된다.

일반적으로 위젯킷은 실행 타겟이 아니라 번들로 함께 빌드되는 부속 타겟이기 때문에, Don't Activate를 선택해서 활성화하지 않으면 된다. 만일 Widget 익스텐션만 별도로 디버깅 또는 실행이 필요하다면 활성화 해주시면 되고, 이 설정은 나중에 언제든 변경할 수 있다.

이제 Widget 익스텐션이 새롭게 프로젝트에 추가된 것을 확인할 수 있다 !

새롭게 생성한 Widget 익스텐션은 iOS 입장에서는 하나의 독립적인 실행 단위이기 때문에, Assets, Info도 독립적으로 자신의 것을 가질 수 있게 되고 별도 설정들도 개별적으로 할 수 있게된다.

최소 지원 버전을 설정해야 하는데, 현재 프로젝트의 최소 타겟으로 맞춰 주면된다.
꼭 프로젝트와 맞춰야 하는건 아니지만 대부분 동일 환경을 유지하기 위해 프로젝트와 익스텐션의 최소 타겟은 동일하게 가져가는 편이다.

이어서 LiveActivity 사용을 위한 Info.plist 파일에 키를 추가하도록 하자.

Info.plist 파일에 "Supports Live Activities" 키를 YES로 추가해주면 된다. 해당 키 등록이 안되있으면, 아무리 Live Activity 실행을 하더라도 시스템에서 활성화가 되지 않으니 꼭 잊지말고 추가해 주어야 한다.

폴더 구조를 보면 ScoreWidget, ScoreWidgetBundle, ScoreWidgetLiveActivity 이렇게 3개의 swift 파일이 기본적으로 생성된다.

여기서 Widget 파일은 홈 & 잠금화면 위젯에 사용되는 파일이기 때문에, 여기서는 사용할 일이 없어 주석 처리하도록 하겠다.

Bundle 파일로 와서 Widget 파일을 제거하고 LiveActivity의 최소 지원 코드를 추가해 주도록 하자.

import WidgetKit
import SwiftUI

@main
struct ScoreWidgetBundle: WidgetBundle {
    var body: some Widget {
//        ScoreWidget()
        if #available(iOS 16.1, *) {
            ScoreWidgetLiveActivity()
        }
    }
}

LiveActivity 파일은 아래에서 더 자세히 살펴볼 예정이니 우선은 여기까지 하고 실행을 해보자 !

자 모두 실행이 잘 되었는가 ? 아마 대부분 실행에 실패하였을 것이다.

천천히 에러를 해결해 보도록하자. 대부분의 Flutter에서 익스텐션 추가시 발생하는 케이스와 Flavors 환경에 따른 케이스들인데, 이 외 케이스들은 댓글이나 메일 주시면 최대한 해결할 수 있도록 도와 드리겠습니다..

---

Case 1. PreviewActivityBuilder

해당 에러는 기본으로 추가된 Preview의 코드가 특정 버전 이상에서만 지원되기 때문이다. 미리보기(as: .content, contentState: ..)는 iOS 17.2 이상에서만 지원되기 때문에 Result Builder 시스템이 해당 블록을 사용할 수 있는 API 버전을 만족하지 못해 컴파일 에러가 발생한 것이다.

해결 방법으로는 LiveActivity 파일 아래 프리뷰를 주석처리하거나 또는 상단에 버전을 명시해주면 된다.

---

Case 2. Cycle inside Runner

Swift 프로젝트에서는 발생하지 않지만, 이상하게 Flutter 프로젝트에서 익스텐션을 추가하는 경우에만 주로 발생하는 에러로, XCode에서 빌드 타겟 간 순환 의존성(Circular Dependency) 문제가 생겼을 때 발생하게 되는 에러이다.

Build Phases의 실행 순서에 따라, 의존성 타겟이 꼬이면서 순환 의존성 문제가 발생하는 것이기 때문에 순서를 재배치 해주면 된다.

제가 찾은 방법으로는 "Embed Foundation Extensions"가 "Thin Binary"보다 선행되어야 한다는 것이다. 확장을 먼저 처리하고 메인 바이너리에 병합되어야 에러가 발생하지 않는다.

단 다른 순서로 꼬일 수도 있으니 Build phases 순서 재배치하시면 대부분 해결이 가능하다.

---

Case 3. Bundle Identifier

마지막 케이스는 바로 Bundle Identifier 문제이다. Flavors를 사용하지 않고 단일 환경만 구축한 경우에는 발생하지 않고 빌드 변형으로 인해서 발생하는 에러 케이스다.

익스텐션은 부모 Idnetifier에 고정되게 되는데, 부모 Runner가 변형된 상태이므로 익스텐션도 동일하게 빌드변형을 적용해주면 해결된다.

만일 빌드변형이 되어있는데, 에러가 발생하지 않았다면 아마도 production 앱으로 실행한 경우일 것이다.
production에는 suffix를 붙이지 않기 때문에, suffix가 붙는 (dev, qa, stg...) 앱으로 실행해보면 에러가 발생한다.

익스텐션을 확인해보면 부모 Bundle Identifier에 생성한 익스텐션명으로 독립된 Bundle Identifier를 가지고 있는 위젯이 생성된 것을 확인할 수 있다.

Flavors 적용시 메인 타겟에 한 것과 동일하게 익스텐션에도 suffix를 추가하여 빌드변형에 따른 부모 Bundle Identifier와 싱크가 맞도록 해주자.

빌드 변형이 이미 세팅된 프로젝트인 경우에 개념이 어려우시다면 아래 공유된 글을 참고하시길 바란다.
[Flutter] Flavor 빌드 변형

---

❗️ Xcode <Flutter/Flutter.h> file not found, after adding Extension to project

추가로 익스텐션으로 인하여 Flutter/Flutter.h 파일을 찾지 못한다는 에러나 Runner-Bridging-Header.h가 Flutter 헤더를 참조하는데 경로가 맞지 않는다는 에러가 발생한다면, Other Linker Flags와 Objective-C Bridging Header 경로를 없애주면 된다.

iOS 익스텐션은 Flutter 엔진을 로드하지 못하고, 메인 앱(Runner)과 별도의 타겟으로 실행되기 때문에, Flutter 관련 참조를 모두 제거하여야 한다. 이건 Widget 익스텐션 외에도 모든 익스텐션에 해당되는 내용이니 같은 에러가 발생한다면 동일하게 해결해주면 된다.

XCode에서 해당 설정으로 이동하여 참조되어 있다면 전부 제거해주면 된다.

🔥 Widget의 익스텐션 타겟에서 제거해야지 Runner 타겟에서 제거하면 안됨 !!!!

Other Linker Flags	Objective-C Bridging Header

자 이제 문제 없이 앱이 실행되고, 테스트로 Live Activity와 DynamicIsland가 정상적으로 활성화 되는지까지 확인해보자.

AppDelegate.swift

우선은 아래 코드를 추가하여 먼저 테스트를 해보도록 하겠다.

import Flutter
import UIKit
import ActivityKit

@main
@objc class AppDelegate: FlutterAppDelegate {
    override func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        GeneratedPluginRegistrant.register(with: self)
        
        startLiveActivity()
        
        return super.application(application, didFinishLaunchingWithOptions: launchOptions)
    }
    
    
    func startLiveActivity() {
        if ActivityAuthorizationInfo().areActivitiesEnabled {
            let attributes = ScoreWidgetAttributes(name: "TYGER")
            let contentState = ScoreWidgetAttributes.ContentState(emoji: "🔥")
            
            do {
                let _ = try Activity<ScoreWidgetAttributes>.request(
                    attributes: attributes,
                    contentState: contentState,
                    pushType: nil // or `.token` if push-to-start
                )
                print("✅ Live Activity started.")
            } catch {
                print("❌ Failed to start Live Activity: \(error)")
            }
        } else {
            print("⚠️ Live Activities are not enabled.")
        }
    }
}

익스텐션의 명칭이 다르다면 Attributes 객체가 다르기 때문에 본인이 생성한 위젯 명칭으로 변경하셔야 한다.

Attributes 객체를 찾지 못한다는 에러가 나올텐데, 추가한 익스텐션이 Runner에 포함되지 않았기 때문이다.

위젯의 LiveActivity 파일로 이동하여 우측의 File Inspector 열어보면, Target Membership을 확인할 수 있는데, Runner 타겟이 포함되어 있지 않는 것을 알 수 있다.

추가 버튼을 눌러서 Runner 앱을 선택한 후 저장해주면 자동으로 Delegate 파일에서 객체를 불러오는 것을 확인할 수 있다.

이제 앱을 실행해 보면 실행과 동시에 라이브엑티비티가 활성화 되고 백그라운드로 나가면 자동으로 다이나믹아일랜드가 표시되는 것을 확인할 수 있다.

만약에 실행이 안되시거나 에러가 발생한다면 댓글 남겨주세요. 확인 후 해결할 수 있도록 도움 드리도록 하겠습니다 !

Live Activity

Live Activity 사용을 위한 기본적인 세팅은 끝이났다. 이제 UI를 만들고 이벤트를 연결해주면 된다.

이 글에서는 UI 내용은 SwiftUI로 작성되기에 별도로 다루지는 않을 것이고, SwiftUI를 경험하지 않았더라도 그리 어렵지는 않으니 조금만 찾아보면 모두 원하는 UI를 만들어낼 수 있습니다. 여기서 작성된 예제의 UI 파일만 별도로 공유하도록 하겠습니다. 필요하시면 참고하시면 됩니다.

야구 점수를 보여주는 실시간 현황을 작업하기에 앞서 조금더 단순한 구조인 배달의 민족, 요기요, 스타벅스 등과 같은 픽업 현황을 보여주는 기능으로 먼저 Live Activity에 대해서 알아보도록 하자.

Live Activity를 구현하기 위해 작업해야 하는 기능들을 먼저 정리해보도록 하자.

가장 우선시 되는 것은 당연히 Live Activity를 활성화시키는 것이다. 이미 위에서 기본적인 활성화 방법에 대해서는 알고 있다.

다음으로는 Live Activity의 목적에 맞게 데이터를 실시간으로 업데이트(Update)하는 것이다.
여기서 업데이트를 하는 방법은 두 가지 방법이 있다. 바로 로컬과 서버에서 업데이트 이벤트를 발생하여 상태를 변경할 수 있는데, 거의 서버 요청에 의해 업데이트가 발생하는 것이 일반적일 것이다.
왜 주로 서버에서 업데이트를 하는걸까 ? Live Activity는 목적 자체가 앱을 사용하지 않아도 사용자에게 현황을 실시간으로 보여준다는 점이기 때문에 앱이 종료가 되었더라도 Live Activity는 계속 노출이 가능하다는 것이다.
로컬에서의 업데이트는 앱이 종료되면, 상태를 변경하는 이벤트를 발생시킬 수가 없어서 반드시 서버가 요청을 해야한다.

그렇다면 서버는 어떻게 Live Activity의 상태를 변경할 수 있는 것일까 ? 바로 푸시(Push Notification) 시스템을 이용하는 것이다.

푸시 알림에는 사용자에게 알림 배너를 띄우는 역할도 있지만 그 외에도 데이터 전송, 사일런트, 라이브엑티비티에도 활용할 수가 있다.

현재 자신의 프로젝트에 푸시를 사용하지 않고 있다면, 먼저 푸시를 세팅하는 작업이 선행되어야 한다. 저는 프로젝트에 Firebase Messaging(FCM)이 세팅되어 있기 때문에 FCM으로 작업할 예정이고, 꼭 FCM이 아니더라도 payload는 동일하기 때문에 문제는 없다.

*Flutter에서 Firebase Messaging 연동 및 사용 방법은 아래 글 참고 !!

Firebase FCM(Firebase Cloud Message) 사용해 보기

마지막으로 모든 플로우가 끝난다면, Live Activity의 DynamicIsland의 비활성화 및 LockScreen 제거 등의 종료하는 방법이다.

이 흐름대로 기능을 살펴보면서, 만들어보도록 하자 !

Design Guidelines

Live Activities | Apple Developer
🎸 [Swift] Live Activity 사용해 보기

Live Activity 디자인은 크게 다이나믹아일랜드(DynamicIsland)와 잠금화면(LockScreen)으로 나뉘게 되고 다이나믹아일랜드에는 3가지의 타입이 지정되어 있다.

참고로 디자인 가이드라인 규정을 준수하지 않으면 시스템에 의해 거절될 수 있으니, 애플의 디자인 가이드라인에 맞는 UI를 만들어야 한다.

다이나믹아일랜드+잠금화면은 함께 활성화되기에 반드시 모든 디자인과 기능을 제공해야 한다.

DynamicIsland	Lock Screen
Expand	Compact	Minimal

Live Activity는 iOS 16.1 버전부터 지원이 가능하고, DynamicIsland 기능은 iPhone 14Pro 부터 지원된다.

Live Activity가 활성화되면 Lock Screen에는 즉시 노출되고, DynamicIsland는 앱이 백그라운드(background) 또는 종료(terminated) 상태가 되면, 앱이 DynamicIsland에 들어가면서 활성화가 시작된다.

Live Activity의 지속 노출 최대 시간은 8시간이고, 잠금화면(LockScreen)에서는 종료 후 최대 4시간까지(총 12시간) 노출을 할 수 있다. 그리고 종료(end) 이벤트 발생 후에는 더 이상 DynamicIsland는 활성화 되지 않는다.

DynamicIsland의 기본 타입은 Compact 상태로, 이 때는 가운데를 중심으로 leading, trailing side가 표시되고, 2개 이상의 앱이 Live Activity를 요청하게 되면 Minimal 상태로 바뀌게 된다. 주로 Minimal 상태에서는 Compact의 leading, trailing side의 UI를 재사용한다. 물론 다르게 구성해도 상관없다.

Expand는 사용자가 길게 누르고 있을 때에 노출되는 상태로 이 영역의 모든 포지션을 사용하지는 않아도 된다. 실제로 Leading, Trailing 없이 Center만 사용하는 경우도 있고, Leading과 Option(.bottom)만 사용하는 앱들도 있다.

최대한 실시간성 정보를 보여주기 위한 데이터와 UI 제공에 집중해야 하고, 공간이나 타입이 제한적이니 로고 또는 앱을 보여주기 위한 불필요하고 의미없는 UI 구성은 자제하라고 한다.

Getting Started with Live Activities

앞서 테스트에서 어떻게 Live Activity를 시작하는지 코드를 작성해 봤는데, 디테일하게 살펴보고 이번에는 Swift에서 시작하는 것이 아닌, Platform Channel을 통해 Flutter에서 시작할 수 있게 구조를 만들어 보자.

기존 AppDelegate.swift 파일에 작성한 코드는 전부 제거해주자.

LiveActivity를 생성하고 호출하기 위해서는 ActivityKit에서 제공하는, Activity 객체를 선언하고 request를 호출해주면 된다.

import ActivityKit

static var currentActivity: Activity<SampleWidgetAttributes>?

currentActivity = try Activity<SampleWidgetAttributes>.request(
		attributes: attributes,
		contentState: state,
		pushType: nil,
)

pushType과 attributes에 대해서 알아보자

attributes는 라이브엑티비티의 정적인 데이터를 의미하며, 시작될 때 한번 설정되는 값으로, 업데이트의 대상은 ContentState를 사용할 수 있다.

ContentState를 업데이트하기 위해 서버에서 라이브엑티비티 전용 푸시를 통한 상태 변경 요청과 로컬에서 ActivityKit의 update를 사용하여 요청하는 두 가지 방식이 있는데, 이 때에 pushType을 사용하게 된다.

지금처럼 pushType을 nil로 지정하게 되면, 로컬에서만 업데이트를 할 수 있다는 것이고, 서버에서 업데이트가 필요하다면 .token을 지정해 주면 된다.

이제부터는 예제를 통해 본격적인 사용 방법들을 알아보자.
앞서 설명한 것과 같이 라이브엑티비티 중 가장 심플한 구조인 스타벅스의 음료 픽업 현황 라이브엑티비티를 만들어 보면서 좀 더 자세히 살펴보도록 하자.

OrderWidget이라는 위젯 익스텐션을 추가해 주었다. Attributes에는 정적 데이터로 name, address, count 값을 사용하여 주문한 매장의 이름과 주소 그리고 주문한 음료가 몇 잔인지를 보여주도록 하고, ContentState의 상태에 status라는 픽업 상태를 사용할 수 있도록 해주었다.

status의 상태로는 received(주문완료), preparing(음료 제조 중), ready_for_pickup(제조완료 / 픽업 가능) 3가지의 상태를 사용할 예정이다.

struct OrderWidgetAttributes: ActivityAttributes {
    public struct ContentState: Codable, Hashable {
        var status: String
    }
    var name: String
    var address: String
    var count : Int
}

Runner에 OrderWidgetManager.swift 파일을 생성해주어 라이브엑티비티 기능을 처리해 주도록 하자.

import Foundation
import ActivityKit

@available(iOS 16.1, *)
struct OrderActivityManager {
    static var currentActivity: Activity<OrderWidgetAttributes>?
    ...
}

start 함수를 만들어서 OrderWidget의 엑티비티를 시작해보자. Attributes의 정적 데이터를 생성하기 위해 name, address, count 값을 받아오도로 하고, 해당 예제는 푸시를 통해 데이터를 업데이트할 것이어서 라이브엑티비티 토큰을 반환하도록 해주었다.

ContentState에 선언한 status의 초기 값은 received로 넣어주면 된다.

static func start(name:String, address:String, count:Int, completion: @escaping (String?) -> Void) {
	let attributes = OrderWidgetAttributes(name: name, address: address, count: count)
    let state = OrderWidgetAttributes.ContentState(status: "received")
    ...
}

이제 OrderWidget의 라이브엑티비티를 request로 요청하고 생성한 정적 데이터와 상태, pushType(.token)을 지정해주면 된다.

엑티비티가 정상적으로 생성 및 호출이 되고나면, 라이브엑티비티 전용 푸시 토큰을 발급해준다. 만약에 pushType이 nil 이었다면, 토큰이 발급 되지 않기 떄문에, 그냥 request만 호출하면 된다.

        do {
            let activity = try Activity<OrderWidgetAttributes>.request(
                attributes: attributes,
                contentState: state,
                pushType: .token
            )
            currentActivity = activity
            Task {
                for await data in activity.pushTokenUpdates {
                    let token = data.map { String(format: "%02x", $0) }.joined()
                    print("📦 Push token: \(token)")
                    completion(token)
                    break
                }
            }
        } catch {
            print("❌ Failed to start Live Activity: \(error)")
            completion(nil)
        }

AppDelegate에서 Native와 Flutter간의 이벤트를 언결해 주도록 하자.
Flutter에서 네이티브에 라이브엑티비티 시작을 요청하면 네이티브에서는 요청을 시작하고 비동기로 토큰이 발급되면 다시 Flutter에 콜백을 넘겨주는 구조이다.

@objc class AppDelegate: FlutterAppDelegate {
    override func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {
        GeneratedPluginRegistrant.register(with: self)
        
        if let controller = window?.rootViewController as? FlutterViewController {
            configureLiveActivityChannel(controller: controller)
        }
        return super.application(application, didFinishLaunchingWithOptions: launchOptions)
    }
    ...
}

채널명은 live_activity_order라고 해주었다. 채널명이나 클래스명은 자유롭게 사용하셔도 됩니다.

start 메서드 요청시 정적 데이터를 파싱하고 앞서 만든 OrderActivityManager 클래스에 start 함수를 호출해 준 뒤, 결과를 다시 Flutter로 반환해 주도록 하자. 여기서 결과는 라이브엑티비티 전용 푸시 토큰이다.

private func configureLiveActivityChannel(controller: FlutterViewController) {
        let order = FlutterMethodChannel(name: "live_activity_order", binaryMessenger: controller.binaryMessenger)
        
        order.setMethodCallHandler { call, result in
            switch call.method {
            case "start":
                guard let args =  call.arguments as? [String:Any],
                      let name = args["name"] as? String,
                      let address = args["address"] as? String,
                      let count = args["count"] as? Int else {
                    result(nil)
                    return
                }
                OrderActivityManager.start(name: name, address: address, count: count) { token in
                    result(token)
                }
            default:
                result(nil)
            }
        }
    }

Flutter로 와서 동일 채널명으로 네이티브 채널을 연결하고 start 메서드와 함께 데이터를 넘겨주면 된다.

호출해보면, 정상적으로 라이브엑티비티가 실행되고 토큰이 반환되는 것을 확인할 수 있다.

static const MethodChannel order = MethodChannel("live_activity_order");
 
final String? token = await order.invokeMethod("start", {
          "name": "The Original Starbucks",
          "address": "1912 Pike Place, Seattle",
          "count": 3,
});

pushType을 nil로도 변경해서 테스트 해보면, 토큰을 반환하지 않는 것을 알 수 있을 것이다.

참고로 UI에서 데이터를 사용할 때에는 Attributes는 context.attributes 로 접근할 수 있고, ContentState는 context.state로 접근해서 데이터를 사용해주면 된다.

예제에서 사용하는 UI관련 파일과 이벤트 관련 파일은 글 마지막에 공유해 놓도록 하겠습니다. 필요하시다면 참고하셔도 됩니다.

Updating Live Activity States

다음으로 라이브엑티비티 기능의 핵심이라고 할 수 있는 실시간 데이터 업데이트에 대해서 알아보도록 하자.

LiveActivity는 말그대로 실시간 현황을 나타내는 기능이다. 그렇기 때문에, 실시간으로 데이터를 변경해 주어야 제대로된 기능이라고 말할 수 있을 것이다.

라이브엑티비티는 앱의 라이프사이클과 별개로 앱이 종료되어도 잠금화면과 다이나믹아일랜드에 지속적으로 노출되는 구조로 만들어져 있다. 결국 앱이 종료 되어도 업데이트가 가능하여야 하기 때문에, 로컬 외에도 푸시를 사용한 업데이트를 지원하고 있다.

로컬 ? 푸시 ? 어떨 때에 사용해야 할까 ?

앞서 만들고 있는 픽업 주문 현황과 같은 기능은 무조건 서버 푸시를 통해서만 상태를 변경해야 한다. 앱은 픽업 주문이 어떻게 되는지를 알 수 없기 때문에 앱이 실행 중이라고 해도 상태 변경의 관리는 서버에 있다고 할 수 있다. 하지만 건강, 위치와 관련된 디바이스의 기능을 활용하는 경우 주체는 로컬에 있을 것이다. 이 경우는 로컬에서 실시간 현황의 상태를 업데이트하면 된다.

먼저, 로컬에서 엑티비티의 상태를 변경하는 방법에 대해서 알아보도록 하자.

OrderActivityManager 파일에 update 함수를 추가해 주자.

ActivityKit의 update는 매우 간단한데, ContentState의 선언된 데이터만 새로운 데이터로 변경해서 요청하면 끝이다.

Flutter에서 업데이트 요청을 받아오기 위해 upate 함수에 변경하고자 하는 status 값을 받아올 수 있도록 하고, 해당 객체에 이미 생성한 currentActivity의 update에 새로운 ContentState를 제공해주면 즉시 상태가 변경된다.

    static func update(status: String) {
        guard let activity = currentActivity else {
            print("❌ Update failed: no active Live Activity found")
            return
        }

        let newState = OrderWidgetAttributes.ContentState(status: status)
        Task {
            await activity.update(using: newState)
            print("✅ Live Activity Updated: \(status)")
        }
    }

AppDelegate 네이티브 채널 케이스에 update 메서드를 추가해 주도록하자.

        order.setMethodCallHandler { call, result in
            switch call.method {
            case "start":
                ...
            case "update":
                guard let args = call.arguments as? [String:Any],
                      let status = args["status"] as?  String else {
                    result(nil)
                    return
                }
                OrderActivityManager.update(status:status)
                result(nil)
            default:
                result(nil)
            }
        }

Flutter에서 아래 함수를 실행하여 데이터를 변경해보자. 참고로 이미 생성된 LiveActivity를 업데이트하는 것이기 때문에 반드시 start를 호출하여 활성화한 뒤 업데이트를 진행하여야 한다.

static Future<void> update(String status) async {
	await order.invokeMethod("update", {"status": status});
}

정상적으로 로컬에서 LiveActivity의 상태가 업데이트 되는 것을 확인할 수 있다.

이어서 서버에서 푸시를 통해 LiveActivity의 상태를 업데이트하는 방법에 대해서 알아보도록 하자.

APNs(Apple Push Notification service)는 Apple의 푸시 알림을 전송하는 서비스인데, 해당 서비스에서 제공해주는 기능 중 하나가 push-to-update 즉, 푸시를 통해 특정 기능들의 업데이트를 제공하는 것이다.

라이브엑티비티도 APNs에서 제공하는 라이브엑티비티 전용 푸시를 통해 데이터를 변경할 수 있다. 하지만 이 기능을 사용하기 위해서는 반드시 Live Activity 전용 토큰(Token)이 있어야지만 푸시를 전송할 수 있다.

결국 앱에서 특정 조건에 의해 실시간 현황을 제공하고 싶다면, 라이브엑티비티 시작을 요청하고 전용 토큰(Token)을 발급 받아 서버로 토큰 정보를 넘겨주어, 실시간 데이터 변경시 서버에서 업데이트하고자 하는 내용을 푸시로 전송하여 시스템이 푸시 알림을 통해 데이터를 변경하는 흐름인 것이다.

사실 복잡해 보이지만 이미 Apple에서는 주로 사용하는 방식들이다.

푸시를 어떻게 전송해야 LiveActivity 전용 푸시로 전송 되는지, 자세히 살펴보도록 하자.

아래 payload가 라이브엑티비티 전용 푸시 전송을 위해 세팅하는 값들이다. 기본적으로 일반 푸시 알림에 있는 notification, data 등의 필드는 사용하지 않고, apns 필드를 사용해 주어야 한다.

FCM이 아닌 경우 payload 구조가 일부 다를 수 있으니, 본인이 사용하는 푸시 서비스의 공식 문서를 확인 하셔야 한다.

{
  "message": {
    "token": <device_push_token>,
    "apns": {
      "live_activity_token": <live_activity_token>,
      "headers": {
        "apns-priority": "10"
      },
      "payload": {
        "aps": {
          "timestamp": <timestamp>,
          "event": <event>,
          "content-state": {
          		...
				},
        "alert": {
            "title": <push_alarm_title>,
            "body": <push_alarm_body>
					}
				}
			}
		}  
	}
}

token은 FCM에서 발급받는 디바이스 토큰 값에 해당된다. apns.live_activity_token에는 라이브엑티비티 시작시 발급 받았던 토큰을 넣어주면 된다.

event 필드는 "update"와 "end"를 사용할 수 있는데, 지금은 상태를 변경하는 작업을 하고 있으니 update로 해주도록 하자.

alert 필드에 title과 body를 포함하게 되어있는데, alert는 필수 필드여서 반드시 값을 포함해야 하고, 미포함시 간헐적으로 업데이트가 작동하지 않을 수도 있다.

이제 마지막으로 timestamp 필드는 iOS 시스템이 타임라인에 의해 서비스의 라이브엑티비티를 업데이트하기 위한 필드로, 이미 시간이 지나게 되면 업데이트가 제외되기 때문에, 일반적으로 1분 후의 타임스탬프를 생성해서 요청해주면 된다.

이제 라이브엑티비티를 시작하여 토큰을 얻고 라이브엑티비티 전용 푸시의 상태를 preparing으로 전송해보면 상태가 변경된 것을 확인할 수 있다.

라이브엑티비티 전용 푸시를 테스트할 환경이 없는 경우에는 대시보드에서는 불가능하고, 포스트맨으로 간단하게 테스트를 해볼 수 있다.

Sending Live Activity Push via Postman

포스트맨에 접속한 후 POST로 요청 형식을 변경하고 아래 주소를 입력해주자.

Use this endpoint:
https://fcm.googleapis.com/v1/projects/<your_firebase_project_id>/messages:send

이제 사용자 인증을 진행해야 한다. 이건 보통 만료 시간이 있으니 401에러 발생시 인증 절차를 수행해주면 된다.

error": {
	"code": 401,
	"message": "Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. See https://developers.google.com/identity/sign-in/web/devconsole-project.",
        "status": "UNAUTHENTICATED"
}

Authorization 탭으로 이동해주자.

Auth Type의 셀렉트 박스를 열어 "Firebase Cloud Messaging API"를 선택해주자.

Authorize 버튼을 클릭하면, 자동으로 구글 로그인이 진행되고 후에 인증에 성공하면 자동으로 Auth credentials의 임시 토큰이 발급되게 된다.

구글 계정은 해당 프로젝트 팀에 포함되어 있는 계정이어야 한다 !

인증이 완료 되었다면, Body 탭으로 이동하여 raw+JSON으로 선택하여 위에서 살펴본 payload를 넣어주도록 하자.

timestamp 필드에 타임스탬프를 계속 1분 후로 계산해서 넣어주기 귀찮기 때문에, 자동으로 1분 후의 타임스탬프를 생성하는 스크립트를 추가해 주도록 하자.

Scripts 탭의 우측에 Pre-request를 선택하여 아래 스크립트를 추가해주면 된다.

// 현재 UTC 시간 + 60초 → Unix timestamp로 변환
const timestamp = Math.floor((Date.now() + 60000) / 1000);
pm.environment.set("LIVE_ACTIVITY_TIMESTAMP", timestamp);

이제 payload의 timestamp 필드의 스크립트를 넣어주면 된다.

"timestamp": {{LIVE_ACTIVITY_TIMESTAMP}},

마지막으로 서버 푸시 업데이트와 관련해서, 라이브엑티비티 전용 푸시의 payload를 구성할 때에는 반드시 일반 푸시에 사용되는 data, notification 등의 필드는 절대 포함하시면 안됩니다.
일반 푸시의 필드를 사용하여도 라이브엑티비티 토큰이 있다면, FCM이 라이브엑티비티 전용이라고 단정해서 푸시를 등록하기 때문에 일반 푸시도 거절되고, 라이브엑티비티 푸시도 거절되게 됩니다.

라이브엑티비티의 상태를 변경함과 동시에 푸시 알림을 노출하고 싶다면, 라이브엑티비티 푸시와 일반 푸시를 각각 개별적으로 요청해야 합니다.

여기까지 잘 따라왔다면, Postman으로 라이브엑티비티 전용 푸시를 보내고, 라이브엑티비티가 업데이트 되는 것까지 문제 없이 성공했을 것이라 생각한다. 포스트맨은 테스트 용이기 때문에, 실제 서버에서 전송되는 것도 반드시 테스트 해보셔야 합니다.

만일 제대로 작동이 안되시는 분들은 다시 반복해서 해보시고 그래도 안된다면 문의 남겨주세요. 최대한 자세하게 남겨주셔야 해결이 가능합니다 !!

Ending and Deactivating a Live Activity

이어서 라이브엑티비티의 상태를 종료 및 제거하는 방법에 대해서 알아보도록 하자.
여기서도 Update와 동일하게 로컬 & 서버 둘 다 가능하며, 업데이트와 다른 점이 있다면 언제 제거할지?를 요청할 수 있다는 부분이다.

라이브엑티비티의 최대 노출시간은 8시간으로 종료 이벤트가 발생한 후 부터 4시간 까지 잠금화면에 남아있을 수 있습니다. 즉 최대 12시간까지 노출이 가능하기 때문에, 즉시 제거하여도 되고 최대 시간까지 또는 n분 후, n시간 후 까지 남겨놓을 수 있다.

그렇다면, 다이나믹아일랜드는 어떻게 될까 ? 다이나믹아일랜드는 업데이트가 유지되는 경우에만 활성화되고, 종료 이벤트가 발생시 즉시 제거됩니다. 이러한 이유로 실시간 현황의 데이터가 모두 업데이트가 된 경우라면 반드시 종료 이벤트를 발생시켜 불필요하게 다이나믹아일랜드에 노출되는 것을 방지해야 한다.
실시간 현황의 변동이 더 이상 없는데도 불구하고, 종료를 시켜주지 않는다면, 사용자가 실시간 현황을 비활성화 해버릴 수도 있으니 다이나믹아일랜드 제거를 위해서라도 종료 이벤트는 필요하다.

추가로 end 이벤트를 요청하게 되면 라이브엑티비티의 접근 권한이 자동 삭제되게 되므로, update를 다시 요청하더라도 라이브엑티비티를 제어할 수 없다. 라이브엑티비티 푸시를 사용해도 동일하게 update는 불가능하다.

먼저 로컬에서 라이브엑티비티의 종료 및 제거하는 방법을 살펴보도록 하자.

업데이트와 동일하게 ActivityKit의 end를 사용하면 된다. end 사용시 update와 동일하게 ContentState의 상태를 변경해줄 수 있고, 추가로 dismissalPolicy를 사용해 제거 시점을 제어할 수도 있다.

dismissalPolicy에는 immediate, after 타입을 사용하여 즉시 제거시키거나 시간 함수를 만들어 원하는 시간 후에 자동으로 제거되게 요청할 수 있다.

.immediate를 사용해 라이브엑티비티가 즉시 제거될 수 있게 해주자. 이 경우에는 잠금화면, 다이나믹아일랜드에서 즉시 제거될 것이기 때문에, ContentState의 상태는 변경하지 않아도 된다.

이제 더 이상 해당 라이브엑티비티는 활성 상태가 아니기 때문에 currentActivity도 다시 NULL로 변경해 주자.

static func endImmediately() {
        guard let activity = currentActivity else {
            print("❌ End failed: no active Live Activity found")
            return
        }

        Task {
            await activity.end(dismissalPolicy: .immediate)
            print("🛑 Live Activity ended immediately")
            currentActivity = nil
        }
    }

.after를 사용하여 요청 시점으로 부터의 이 후 시간대를 생성한 뒤에 요청해주면 된다. 이 경우에는 라이브엑티비티가 다이나믹아일랜드는 즉시 제거 되지만, 잠금화면에서 즉시 제거되지 않기 때문에 ContentState의 상태도 함께 변경해 주어야 한다.

static func endAfterDelay(seconds: Int = 60) {
        guard let activity = currentActivity else {
            print("❌ End failed: no active Live Activity found")
            return
        }

        let finalState = OrderWidgetAttributes.ContentState(status: "ready_for_pickup")
        let oneHourLater = Date().addingTimeInterval(TimeInterval(seconds))

        Task {
            await activity.end(using: finalState, dismissalPolicy: .after(oneHourLater))
            print("🕒 Live Activity scheduled to end after \(seconds) seconds (status: ready_for_pickup)")
            currentActivity = nil
        }
    }

AppDelegate에 MethodChannel에 case를 추가하여 이벤트를 연결해 주도록 하자.

case "end_now":
	OrderActivityManager.endImmediately()
	result(nil)
case "end_later":
	OrderActivityManager.endAfterDelay()
	result(nil)

이제 라이브엑티비티를 다시 시작하고 이벤트를 요청해 보면, 라이브엑티비티가 종료 되면서 더 이상 다이나믹아일랜드나 잠금화면에 표시되지 않는 것을 확인할 수 있다.

1시간 후에 종료되는 이벤트는 다이나믹아일랜드에서는 즉시 제거되고, 잠금화면에서는 정확히 1시간 후에 자동으로 제거되는 것을 알 수 있다.

만약에 시간 함수를 10시간 후로 생성하게 되더라도, 종료 이벤트 발생 후 최대 노출시간은 4시간이라 시스템이 4시간 후에 자동으로 제거하게 된다.

.immediate	.after

이어서 라이브엑티비티 전용 푸시를 사용해서 end 이벤트를 전송해보도록 하자.

기본적인 payload는 update와 동일하고, event를 "end"로 변경하고 제거 시점을 요청하는 dismissal-date 필드를 추가해주면 된다.

"payload" : {
	"event" : "end",
    "content-state" : { ... },
	"dismissal-date" : <timestamp>
}

만일 최대 노출시간동안 라이브엑티비티를 잠금화면에 남겨놓고 싶다면, dismissal-date를 사용하지 않으면 된다.

Starting a Live Activity from the Server

iOS 17.2 버전에 추가된 Push to Start 기능에 대해서 간단하게 이게 뭐하는 건지만 알아보도록 하자. 저도 실제로 운영 단계에서 사용한 적은 없어서 자세한 내용은 추후에 다루도록 하겠다.

Push to Start, 서버 푸시를 통해 라이브엑티비티를 시작하는 기능이다.

해당 기능을 위해서는 push-to-start token을 생성해야 한다.

func observePushToStartToken() {
        if #available(iOS 17.2, *) {
            Task {
                for await data in Activity<YourAttributes>.pushToStartTokenUpdates {
                    let token = data.map { String(format: "%02x", $0) }.joined()
                    print("push-to-start token : \(token)")
                }
            }
        }
    }

해당 토큰은 Attributes 마다 고유한 스타트 토큰이므로, 여러 라이브엑티비티를 사용하고 있다면 개별적으로 관리를 해야한다.

payload는 update와 동일하며, event를 "start"로 요청하고, attributes-type과 attributes를 추가 해주면 된다.

"payload" : {
	"aps" : {
    	"event": "start",
        "attributes-type": <your_attributes>
        "attributes" : { ... }
    }
}

지금까지 예제로 사용한 OrderWidgetAttributes를 예로 들어보자면, payload는 아래와 같은 구성이 된다.

"payload" : {
	"aps" : {
    	"event": "start",
        "attributes-type": "OrderWidgetAttributes",
        "attributes": {
            "name": "Pickup store name",
            "address": "Pickup address",
            "count": 2
          },
    }
}

push-to-start 토큰은 기존 사용하던 "live_activity_channel"에 토큰으로 요청하여 라이브엑티비티를 시작할 수 있다.

서버에서 라이브엑티비티를 시작할 때에 사용하는 스타트 토큰은 시작에만 사용할 수 있고, update시에는 기존에 발급받던 형태로 다시 엑티비티마다 고유한 토큰을 사용해야 한다.

Token(push-to-start) : 라이브엑티비티 시작 요청시, Attributes마다 고유함
Token(live-activity) : 라이브엑티비티 업데이트 및 종료 요청시, 엑티비티 개별

토큰(Token)과 관련해서 다시 정리해 보자면, 라이브엑티비티 사용시 필요한 토큰은 3개로 나뉜다.

각각 Device Token, LiveActivity Token, LiveActivity PushToStart Token 이렇게 3가지라고 명칭 하겠다.

Device Token은 FCM을 보내기 위한 기기마다 고유한 토큰이다. FCM 전송을 위한 가장 기본적인 토큰이며, 모든 FCM 기능은 해당 토큰 없이는 전송이 불가능하다.

여기서 한 가지 의문점이 FCM 토큰이 없다면, 라이브엑티비티 푸시는 사용할 수 없나 ? Device Token은 payload의 필수 필드이기 때문에 사용할 수 없다.
혼동하시면 안되는 부분이 Device Token과 앱 또는 시스템의 알림 설정 여부와 별개라는 부분이다. 즉 앱에 알림을 거부하더라도 FCM 토큰은 이미 생성된 상태이기 떄문에, 여부와 별개로 발급은 가능하다.

현재 서비스 구조가 알림 설정 여부를 판단해서 토큰을 발급받아 서버에 저장시키는 구조 였다면, 라이브엑티비티 사용을 위해서는 무조건 앱에서 FCM 토큰을 발급 받아야 한다.

다음으로 LiveActivity Token이다. LiveActivity Token은 라이브엑티비티마다 고유하게 생성되는 개별 토큰이다. 만약에 A라는 라이브엑티비티를 3개를 요청했다면, LiveActivity Token도 3개가 발급된다. 그렇다면 A라는 라이브엑티비티 2개, B라는 라이브엑티비티 3개를 시작했다면, LiveActivity Token은 총 5개가 발급되게 된다.

마지막으로 LiveActivity PushToStart Token은 라이브엑티비티 종류에 따라 발급되는 토큰이다. A라는 라이브엑티비티에 대해서는 단 1개의 토큰이 발급되는 구조이다. B라는 라이브엑티비티가 있다면 역시 B에대한 토큰 1개가 생성된다.
앞서 살펴본 LiveActivity Token은 종류 상관없이 모든 라이브엑티비티 요청시 발급되는 반면, PushToStart Token은 종류마다 고유한 토큰인 것이다.

---

Live Activities in Action: Beyond the Basics

Pickup 주문 실시간 현황을 예제로 라이브엑티비티에 대한 전반적인 사용 방법들과 구조에 대해서 살펴보았다.

이번에는 야구 경기 실시간 현황을 예제로 좀 더 다양하게 활용할 수 있는 방법에는 어떤 것들이 있는지 가볍게 만들어보도록 하자.

ScoreWidget이라는 새로운 Widget Extension을 추가해 주자.

UI 구성을 위한 정적 데이터에는 각 팀의 정보가 필요할 것이고, 데이터 변경을 위한 ContentState에는 현재 경기의 상태가 필요하게 된다.

각각 모델로 구성해보자.

public struct ScoreStateModel:Codable, Hashable {
    let homeScore: Int
    let awayScore: Int
    let inning: String
    let status: String
}

public struct ScoreTeamModel: Codable, Hashable {
    let code:String
    let name:String
    let logo:String
}

구성한 모델을 사용해 ScoreWidget의 Attributes를 변경해 주도록 하자.

home, away는 팀의 정보이기 때문에 경기가 시작된 후에는 변경되지 않을 것이고 ScoreStateModel에서는 home, away 팀의 스코어와 현재 이닝, 경기 상태를 변경해 주어야 하기 때문에 status로 변경하였다.

struct ScoreWidgetAttributes: ActivityAttributes {
    public struct ContentState: Codable, Hashable {
        var status: ScoreStateModel
    }
    var home: ScoreTeamModel
    var away: ScoreTeamModel
}

경기 상태는 scheduled(경기 전), inprogress(경기 중), closed(경기 종료), cancelled(취소) 이렇게 4가지 상태를 사용하였다.

앞서 배워본데로 Manager 파일을 만들고 라이브엑티비티를 시작할 수 있도록 start 함수를 만들어주자.

import ActivityKit

@available(iOS 16.1, *)
struct ScoreActivityManager {
    static var currentActivity: Activity<ScoreWidgetAttributes>?
    
    static func start(home:ScoreTeamModel, away:ScoreTeamModel,status:ScoreStateModel, completion: @escaping (String?) -> Void) {
        let attributes = ScoreWidgetAttributes(home: home, away: away)
        let state = ScoreWidgetAttributes.ContentState(status:status)
        
        do {
            let activity = try Activity<ScoreWidgetAttributes>.request(
                attributes: attributes,
                contentState: state,
                pushType: .token
            )
            currentActivity = activity
            Task {
                for await data in activity.pushTokenUpdates {
                    let token = data.map { String(format: "%02x", $0) }.joined()
                    print("📦 Push token: \(token)")
                    completion(token)
                    break
                }
            }
        } catch {
            print("❌ Failed to start Live Activity: \(error)")
            completion(nil)
        }
    }
}

ScoreWidgetAttributes에는 모델을 사용하기 때문에, Flutter에서 전송한 객체를 Swift에서 파싱해주어야 한다.

score.setMethodCallHandler { call, result in
            switch call.method {
            case "start":
                guard let args = call.arguments as? [String: Any],
                      let homeDict = args["home"] as? [String: Any],
                      let awayDict = args["away"] as? [String: Any],
                      let statusDict = args["status"] as? [String: Any] else {
                    result(nil)
                    return
                }
                
                do {
                    let homeData = try JSONSerialization.data(withJSONObject: homeDict)
                    let awayData = try JSONSerialization.data(withJSONObject: awayDict)
                    let statusData = try JSONSerialization.data(withJSONObject: statusDict)
                    
                    let home = try JSONDecoder().decode(ScoreTeamModel.self, from: homeData)
                    let away = try JSONDecoder().decode(ScoreTeamModel.self, from: awayData)
                    let status = try JSONDecoder().decode(ScoreStateModel.self, from: statusData)
                    
                    ScoreActivityManager.start(home: home, away: away, status: status) { token in
                        result(token)
                    }
                } catch {
                    result(nil)
                }
            default:
                result(nil)
            }
        }

라이브엑티비티 전용 푸시의 payload의 content-state 구조는 객체 구조 그대로를 사용해 전송하면 된다.

그 외의 모든 기능은 동일하다.

"content-state": {
	"status" : {
		"status":"inprogress",
		"homeScore" : 2,
		"awayScore" : 3,
		"inning" : "Top 4th"
	}
},

자 이제 여러분들도 실시간 경기 현황을 보여주는 라이브엑티비티를 만들 수 있게 된것이다 !

라이브엑티비티를 적용하고 싶은데, 푸시를 보낼 수 있는 환경이 아니라면, 시스템 API 기능을 사용하여 서버 푸시 없이도 로컬에서 디바이스 위치 변화시 업데이트를 요청하여 러닝, 만보기 등의 라이브엑티비티도 만들 수 있다.

iOS의 CoreMotion + CoreLocation을 사용하여 사용자의 위치 변화시 로컬에서 업데이트하여 실시간 현황을 보여주는 라이브엑티비티이다.

이처럼 라이브엑티비티를 사용하면 주어진 구조안에서 얼마든지 자유롭게 커스텀할 수 있고, 원하는 실시간 정보를 빠르고 간편하게 제공해줄 수 있다.

🎨 UI Examples We Played With

🥤 Pickup Order Status - From order placed → in progress → ready for pickup
live_activity_order.zip

---

⚾ Baseball Scoreboard - Real-time score updates with team logos and vibes
live_activity_score.zip

---

🏃 Live Running Tracker - Distance, speed, step count — all updating live!
live_activity_step.zip

---

마무리

iOS의 WidgetKit+ActivityKit를 사용하는 Live Activity에 대해서 자세히 다뤄보았다.

Widget Extension을 Flutter 프로젝트에 추가하고, Widget의 빌드 변형을 적용하여 Live Activity를 Flutter에서 어떻게 적용해야 하는지를 알아보았다.

ActivityKit을 사용해 Live Activity를 시작하고, 상태를 변경하고 종료하는 방법에 대해서 알아보았고, 라이브엑티비티 전용 푸시를 통해 앱 외부에서도 상태를 업데이트하거나 시작하는 방법도 적용해 보았다.

본문에서는 다루지 않았지만, Method Channel 사용시 Android에는 지원하지 않는 기능이다 보니, 별도로 빈 이벤트를 연결해주거나 아니면 분기 처리를 하여 에러가 발생하지 않도록 주의하여야 합니다.

UI적인 부분은 내용이 길어져 다루지 않았지만, 어렵지 않으니 원하시는 UI를 구현하실 수 있을실 겁니다.

추후 Widget Extension의 또 하나의 핵심 기능인 홈 위젯과 잠금화면 위젯에 대해서도 Flutter 프로젝트에 적용하고 사용하는 방법에 대해서 다뤄보도록 하겠습니다.

라이브엑티비티에 대해 적용이 안되거나 궁금한 부분 있으면 댓글 남겨주세요 !