# \[6.4\] Runtime Crash from SwiftUI parameter packs

**URL:** <https://forums.swift.org/t/6-4-runtime-crash-from-swiftui-parameter-packs/90043>\
**Category:** Using Swift\
**Created:** [October 13, 2026, 5:21pm UTC](https://forums.swift.org/t/6-4-runtime-crash-from-swiftui-parameter-packs/90043 "2026-10-13T17:21:30Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![vanvoorden](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/vanvoorden/32/33619_2.png) [@vanvoorden](https://forums.swift.org/u/vanvoorden)\
**Post date:** [October 13, 2026, 5:21pm UTC](https://forums.swift.org/t/6-4-runtime-crash-from-swiftui-parameter-packs/90043/1 "2026-10-13T17:21:30Z")

</div>

I would really like some help to bring this runtime crash over the finish line and hopefully find a fix. Anyone that can help triage or debug can please comment here or on the tasks.

This SwiftUI app will instacrash when built from Xcode 27:

```swift
import SwiftUI

struct Input<T> {
  init(_ input: T) { }
}

struct Repeater<each T> {
  @State private var storage = Storage()

  private var input: (repeat Input<each T>)

  init(_ input: repeat each T) {
    self.input = (repeat Input(each input))
  }
}

extension Repeater {
  final class Storage {
    
  }
}

@main
struct CrashDemoApp: App {
  private var repeater = Repeater(1)
  
  var body: some Scene {
    WindowGroup {
      EmptyView()
    }
  }
}

```

This app _did not_ crash from Xcode 26.

Here is a repro without SwiftUI:

> **[GitHub - vanvoorden/RepeaterCrash](https://github.com/vanvoorden/RepeaterCrash)**
>
> Contribute to vanvoorden/RepeaterCrash development by creating an account on GitHub.

FWIW I can repro the crash from 5.10. This has been here for a long time. It only looks like a "new" crash from SwiftUI because `State` was refactored to include new types that I assume are resilient… hence the runtime crash when building from Xcode 27.

Here is a repro from CI:

> <https://github.com/swiftlang/swift/pull/91791>
>
> https://github.com/swiftlang/swift/issues/90929

Here is a task with some more information:

> <https://github.com/swiftlang/swift/issues/90929>
>
> \### Description
> 
> https://developer.apple.com/forums/thread/838393
> 
> As of right n…ow I do not have repro steps outside of a SwiftUI project building from Xcode 27 Beta 4. I crash from \`debug\` and \`release\`. This does not crash from Xcode 26.
> 
> Here is my code:
> 
> \`\`\`swift
> import SwiftUI
>  
> struct Repeater\<each Input\>: DynamicProperty {
> @State private var storage = Storage()
>  
> private var input: (repeat each Input)
>  
> init(\_ input: repeat each Input) {
> self.input = (repeat each input)
> }
> }
>  
> extension Repeater {
> final class Storage {
>     
> }
> }
>  
> @main
> struct CrashDemoApp: App {
> private var repeater = Repeater(1)
>   
> var body: some Scene {
> WindowGroup {
> EmptyView()
> }
> }
> }
> \`\`\`
> 
> My app \*does not\* crash from Xcode 27 when my variadic type is more than just one element wide:
> 
> \`\`\`swift
> @main
> struct CrashDemoApp: App {
> private var repeater = Repeater(1, 2, 3)
>   
> var body: some Scene {
> WindowGroup {
> EmptyView()
> }
> }
> }
> \`\`\`
> 
> \### Stack dump
> 
> \`\`\`text
> Thread 1: EXC\_BAD\_ACCESS (code=1, address=0x100000000000000)
> 
> Thread 1 Queue : com.apple.main-thread (serial)
> \#0	0x000000019a93aec0 in swift::TargetMetadata\<swift::InProcess\>::isCanonicalStaticallySpecializedGenericMetadata ()
> \#1	0x000000019a946b38 in performOnMetadataCache\<swift::MetadataResponse, swift\_checkMetadataState::CheckStateCallbacks\> ()
> \#2	0x000000019a8c85f0 in swift\_checkMetadataState ()
> \#3	0x00000001004a2c78 in type metadata completion function for Repeater ()
> \#4	0x000000019a94cfe4 in swift::GenericCacheEntry::tryInitialize ()
> \#5	0x000000019a94c870 in swift::MetadataCacheEntryBase\<swift::GenericCacheEntry, void const\*\>::doInitialization ()
> \#6	0x000000019a94f820 in swift::LockingConcurrentMap\<swift::GenericCacheEntry, swift::LockingConcurrentMapStorage\<swift::GenericCacheEntry, (unsigned short)14\>\>::getOrInsert\<swift::MetadataCacheKey, swift::MetadataRequest&, swift::TargetTypeContextDescriptor\<swift::InProcess\> const\*&, void const\* const\*&\> ()
> \#7	0x000000019a93c714 in \_swift\_getGenericMetadata ()
> \#8	0x00000001004a4190 in \_\_swift\_instantiateGenericMetadata ()
> \#9	0x00000001004a2a5c in type metadata accessor for Repeater ()
> \#10	0x00000001004a5094 in type metadata accessor for Repeater\<Pack{Int}\> ()
> \#11	0x00000001004a4fcc in type metadata completion function for CrashDemoApp ()
> \#12	0x000000019a9543bc in swift::MetadataCacheEntryBase\<(anonymous namespace)::SingletonMetadataCacheEntry, int\>::doInitialization ()
> \#13	0x000000019a8d2ae0 in swift\_getSingletonMetadata ()
> \#14	0x00000001004a479c in type metadata accessor for CrashDemoApp ()
> \#15	0x00000001004a473c in static CrashDemoApp.$main() ()
> \#16	0x00000001004a4a34 in main ()
> \#17	0x0000000186e47e00 in start ()
> \`\`\`
> 
> \### Environment
> 
> \`\`\`text
> swift-driver version: 1.168.5 Apple Swift version 6.4 (swiftlang-6.4.0.27.1 clang-2100.3.27.1)
> Target: arm64-apple-macosx26.0
> \`\`\`

Here is a fix for what could be an adjacent crash:

> <https://github.com/swiftlang/swift/pull/91115>
>
> … when extracting a vanishing-tuple element
> 
> emitTypeMetadataPackElementRef's …materialized-pack fast path forwarded the caller's (state-raising) request to the local-type-data cache lookup for the metadata pack. A metadata pack pointer is not a scalar Metadata\* (it is an array of Metadata\* with an on-heap tag in the LSB), so raising its state made the cache emit swift\_checkMetadataState(pack) as if it were a metadata record. The runtime then dereferenced garbage and the extracted element pointer was corrupted, crashing metadata instantiation.
> 
> This reproduces for a variadic-generic struct with a resilient stored property laid out before a tuple built from the pack: the resilient field's metadata accessor binds the metadata pack into the completion function's local cache at Abstract state, and the subsequent vanishing-tuple element lookup then state-raises that cached pack.
> 
> Fetch the materialized pack at Abstract state instead: we only need the pack pointer to index into, and the extracted element's state is still checked by the caller. The fallback paths that apply the request to the element metadata are unchanged. Runtime is unaffected.
> 
> rdar://183073688

What is interesting here is this fix actually _did_ fix an earlier version of this crash. I then found a new version of the crash after I added an extra layer of indirection.