Hey everyone, I've been experimenting around with the new searchable update to add scope to SwiftUI search bars. I requested this last fall and now I'm looking into it as available with Xcode 14 / iOS 16 (FB9674003). I found two bugs in case others run into them. The search bar's segmented 'scopes' only show if the search binding is a non-empty string. (FB10558607) The selected scope binding is not honored when updated outside of the searchable search bar itself. (FB10558881) It is my assumption that these are both defects. Attached is a sample view that illustrates the two bugs. Additionally, writing this up, I felt it was important to also provide developers the ability to specify the visibility of the segmented scopes within the search bar which is possible in UIKit (FB10558936). Something like .searchableScopeVisibility(.always). import SwiftUI struct ContentView: View {          enum FoodScope: CaseIterable {         case fruit         case veggies                  func scopeText() -> String {             switch self {             case .fruit:                 return "Fruit"                              case .veggies:                 return "Veggies"             }         }     }          private let fruits: [String] = ["Apple", "Apricot", "Banana", "Cantaloupe"]     private let veggies: [String] = ["Asparagus", "Beets", "Broccoli", "Cabbage"]          @State private var searchText: String = ""     @State private var scope: FoodScope = .fruit          private var filteredFood: [String] {         switch scope {         case .fruit:             guard searchText != "" else { return fruits }             return fruits.filter { $0.contains(searchText) }                      case .veggies:             guard searchText != "" else { return veggies }             return veggies.filter { $0.contains(searchText) }         }     }          var body: some View {         NavigationStack {             List {                                  Section {                     ForEach(filteredFood, id: \.self) { food in                         NavigationLink(food, value: food)                     }                 } header: {                     Text("Food")                         .textCase(.none)                 }                                  // FB10558607 - SwiftUI: Searchable "scope" non functional in Xcode 14 beta 2 (scope items not visible when searching)                                  Section {                                      } footer: {                     Text("The 'scopes' provided within the new searchable modifier will only be shown when the searchable text binding is a non-empty string. Try for your self by tapping inside the search. You \"should\" see the scope segments appear right away but they don't. Then type any character and they'll show on screen. FB10558607")                 }                 // FB10558881 - SwiftUI: Searchable 'scope' binding is not honored when updated by another mechamsim outside of the searchable scope picker                 // Create another binding to the selected scope and change it. The picker in the search bar does NOT reflect the state of SwiftUI's @State scope property.                 Section {                     Picker("Scope", selection: $scope) {                         ForEach(FoodScope.allCases, id: \.self) { scope in                             Text(scope.scopeText())                                 .tag(scope)                         }                     }                     .pickerStyle(.segmented)                     .buttonStyle(.plain)                     .listRowBackground(Color.clear)                 } header: {                     Text("Searchable Scope Binding Selector")                         .textCase(.none)                 } footer: {                     Text("Additionally, the scope binding will not update when modified via another mechanism (like another segmented picker). When the segments are visible with the search, change the scope and you'll see the binding to the picker change. But, if you change the scope of the picker below, the scope in the search bar will not react as expected. ")                 }             }             .listStyle(.insetGrouped)             .searchable(text: $searchText, scope: $scope) {                 ForEach(FoodScope.allCases, id: \.self) { scope in                     Text(scope.scopeText())                         .tag(scope)                 }             }             .navigationTitle("FB9674003")             .onChange(of: scope) { newValue in                 print("New scope \(newValue.scopeText())")             }             .navigationDestination(for: String.self) { value in                 Text("You selected \(value)")                     .navigationTitle("Yummy food")             }         }     } } #if DEBUG struct ContentView_Previews: PreviewProvider {     static var previews: some View {         ContentView()     } } #endif

Finally at last Apple Health supports saving .distancePaddleSports, .distanceCrossCountrySkiing, .distanceRowing, .distanceSkatingSports, and much more. The backstory. In the land of 10,000 lakes, there hasn't been a way to save 'canoe' or 'kayak' distance and I've been asking for it for years. Thank you health team for adding it this year! FB7807993 - Add HKQuantityTypeIdentifier.paddleDistance for canoeing, kayaking, etc type workouts (June 2020) Prior we could just save the totalDistance to a workout, but since the HKWorkout initializers were deprecated we no longer have a supported way to save these distances in our workouts. The iOS 18 / watchOS 11 introduction addresses this. If you want to know more why you can't do this in earlier versions you can check these feedback titles: FB10281482 - HealthKit: Deprecation of totalDistance on a workout session of paddleSports breaks apps that used that to save distance to the workout because there is no "paddleDistance" type available to save as sample data (June 2022) FB12402974 - HealthKit: Deprecation of HKWorkout completely breaks support for third party fitness apps from saving non-standard workout distance (June 2023) Great, so there is new support that solves all of these requests and issues for the new version of the OSes. However, the downside is now that there is not much for documentation. Unlike the .runningSpeed and .runningPower introduced in iOS 16 / watchOS 9, none of the new iOS 18 / watchOS 11 types have documentation, at all. To some degree this is understandable, but types from last year still remain undocumented too. Without this information for the data types introduced in both iOS 17/18 and watchOS 10/11 it makes building and integrating with these new types difficult to say the least. We can't make assumptions about anything. Can we get a documentation update for new (and existing) quantity types for when Apple Watch will automatically generate samples? FB14236080 - Developer Documentation / HealthKit: Update documentation for HKLiveWorkoutDataSource typesToCollect for which sample types are automatically collected by watchOS 10 and 11 (July 2024) FB14942555 - HealthKit / Documentation: App Update Release Issue - HKQuantityTypeIdentifiers are missing documentation describing when the system automatically adds data (today) I know that the behavior has changed from release to release for some of these types, so documentation would be based on OS version. If you didn't catch it, watchOS 11 will now associate .cyclingSpeed for cycling workouts both indoor and outdoor. FB12458548 - Fitness: Connected cycling speed sensor did not save samples to health via cycling workout (June 2023 - received reply that only saved for indoor cycling, but not documented otherwise) FB14311218 - HealthKit: Expected outdoor cycling to include .cyclingSpeed quantity type as a default HKLiveWorkoutDataSource type to collect (July 2024) To the other third party fitness apps out there, how are you managing the knowledge of which devices collect which data types on which versions of the OS? Sure, we could look at the HKLiveWorkoutDatSource and inspect the typesToCollect property across a bunch of devices, but again that is trial by error not 'as documented'. Is the behavior of simulators guaranteed to match the behavior of real devices? Maybe, but also maybe not. Fingers crossed for a nice documentation update to spell out all of the behavioral details. Apple folks / DTS, many of the above feedbacks are addressed and I plan to update or close them after the releases this fall. Some are still outstanding. P.S. I hope that .paddleSports gets deprecated and split into individual activity types like skiing did years ago. Their MET scores are different according to the research on the physical activity compendium site. FB7807902 - Split HKWorkoutActivityType.paddleSports into their own activity types (June 2020)

Apple is using the RPE scale for workout effort scores. This stands for the Rate of Perceived Exertion. They're specifically using the CR-10 scale, at least from what I can tell by saving values to HealthKit. They only accept value between 0 and 10. Has anyone been able to find a scientific or academic paper on how they have chosen their different effort breakouts? Right from the Fitness app on iPhone and Activity app on Apple Watch: 1-3 Easy 4-6 Moderate 7-8 Hard 9-10 All Out There is zero documentation on these new types, which makes it difficult for workout recording apps to properly and appropriately save this new data type. Sure, we can use the Apple apps as a reference, but since there isn't a built-in Apple SwiftUI sheet to present this data, and no references to academia to point our users to, our solutions would just look the same. FB15315876 - Documentation / HealthKit: Publish documentation about .workoutEffortScore and .estimatedWorkoutEffortScore FB15316109 - Documentation / HealthKit: Add documentation to .estimatedWorkoutEffortScore and .workoutEffortScore that you can't save those samples via the save API and that they must be related and let that API save the sample FB15316251 - Documentation / HealthKit: Add documentation for acceptible values of .estimatedWorkoutEffortScore and .workoutEffortScore - don't rely on a runtime error! Apple missed making an enum for all third party developers this year.

I've been writing about the DeclaredAgeRange a bit on LinkedIn and now it is time to take to the developer forums. In my efforts to prepare my apps for new local requirements, I've run across some rough edges. The DeclaredAgeRange API is missing on several platforms, and extension types. First and foremost, watchOS. An Apple Watch is a clear single user platform and for standalone apps, the DeclaredAgeRange being absent is felt by developers. FB20954931 - DeclaredAgeRange: Framework not available on watchOS making compliance a challenge for watchOS standalone apps In the same vein of thinking, while users on Apple Vision Pro are far fewer numbers than Apple Watch, it is also a miss. The tricky part would be testing on the simulator. So far I haven't gotten the simulator and sandbox testing to work and give real values across any platform. I don't think an Apple Store will let me try my app out via TestFlight on their devices and they're still too expensive to reasonably buy for most developers. Too bad Feedbacks are not a currency that developers can trade in for gear. FB20955020 - DeclaredAgeRange: Framework not available on visionOS making compliance a challenge for visionOS apps I'll recognize that the user model is different on tvOS, and that as a user while I have family group setup, I don't have any children on the account. I have to imagine that child accounts on an Apple TV exist and would be able to account for the sharing of age ranges to apps. Yes, the user could just switch profiles, but, app developers could still integrate the age range into their apps. Maybe it needs more robust system level support but here is the feedback just the same. FB20955029 - DeclaredAgeRange: Framework not available on tvOS making compliance a challenge on tvOS apps And finally, let's not forget about App Clips. While the App Clips might not be 'downloaded' from App Store itself, it is powered by App Store technologies to an extent. I'd rather not bifurcate my code more than it already is for the shared code between my apps and app clips. Rounding out platform support to App Clips, since it is iOS, would close the loop. FB20954846 - DeclaredAgeRange / App Clips: Add support for DeclaredAgeRange framework for App Clip targets - capability exist, Xcode cannot generate entitlement for it Oh wait, actually, not quite. To fully close the loop, make the DeclaredAgeRange work fully on macCatalyst. The documentation says it is compatible, but from my experiments trying to get it to even compile when targeting macCatalyst apps simply doesn't build. FB21117325 - DeclaredAgeRange: API documentation states available on mac catalyst - but fails to compile in Xcode 26.2

Like any good developer, I try to add tests where I can. The AgeRangeService.AgeRange type does not provide an initializer. I know the routine, create an interface or a simple struct that I control and use that instead. Thanks to extensive time with frameworks like Core Bluetooth or Core Location, this is a well understood practice (looking at you CBPeripheral...). Great I'll make my own 'AgeRange' struct. Make it Hashable, make it Sendable, use the framework types as properties. Scratch that, most of the properties on AgeRangeService.AgeRange type are not Sendable and many are also not Hashable. This is proving to be challenging. I hope to open source my little Swift Package wrapper library for DeclaredAgeRange which will add types with full Hashable and Sendable conformance. I hope Apple updates the API and makes this obsolete. I don't see why these simple types can't be Hashable and Sendable. They're structs, enums, and OptionSets (structs). FB20959748 - DeclaredAgeRange: DeclaredAgeRangeAction is not sendable causing main actor compile errors with default isolation settings FB20960560 - DeclaredAgeRange: AgeRangeService.AgeRangeDeclaration is not sendable as expected FB20960574 - DeclaredAgeRange: AgeRangeService.ParentalControls is not sendable as expected FB20960590 - DeclaredAgeRange: AgeRangeService.ParentalControls is not hashable as expected On the note of the library and using the types as-is, there are some issues using the new cases in AgeRangeDeclaration and the isEligibelForAgeFeatures property. I started another thread over here: https://developer.apple.com/forums/thread/808144

I'm trying to get the ASK Sample to discover and connect to a device using a 16-bit uuid. In my case, I have a few fitness sensors laying around like heart rate monitors and cycling sensors. Specifically, I've configured the following descriptor to be shown in the picker: private static let heartRateMonitor: ASPickerDisplayItem = { let descriptor = ASDiscoveryDescriptor() descriptor.bluetoothServiceUUID = CBUUID(string: "180D") return ASPickerDisplayItem(name: "Heart Rate Monitor", productImage: UIImage(named: "PolarH10")!, descriptor: descriptor) }() 100% another app on the device using an unfiltered scan can find this device, so I know the phone can see it. Also, the settings app Bluetooth screen sees it too. When the picker is active for this descriptor, in console I see the device is being discovered and it is matching the underlying filter. However the picker doesn't show the device. Received 'start active Unspecified scan' request , without duplicates, duration:unlimited, UUIDs [ E56A082E-C49B-47CA-A2AB-389127B8ABE3 E56A082E-C49B-47CA-A2AB-389127B8ABE4 0x180D ] on 1M PHY from session "com.apple.deviceaccessd-central-727-198" Matched UUID 0x180D for device "D3030A85-BBB9-6C0D-53C4-6697898B2E4B" This is an apparent bug: FB14078940 - AccessorySetupKit: ASDiscoveryDescriptor does not appear to identify 16-bit UUIDs like the Heart Rate Service/Profile UUID After more tinkering, I did discover that if I connect the device in the settings app, and keep it connected, the picker will find the device immediately. I assume it is under the hood it is calling this function or the internal implementation: https://developer.apple.com/documentation/corebluetooth/cbcentralmanager/retrieveconnectedperipherals(withservices:) This is still not expected, a developer should be able to discover and connect an accessory directly in their app. Noteworthy, I also found that ALL apps in the Settings app list the accessory once paired, which is totally not expected: FB14170263 - Settings: Viewing accessories in settings app for all apps show the accessory paired with another application P.S. forum moderators, there is no tag for 'AccessorySetupKit' which is the technology I'd like to tag this with. Last tested with iOS 18 developer beta 2.

I am very happy to see that HealthKit with OS26 is bringing HKLiveWorkoutDataSource to iOS and iPadOS. I have been replicating a similar type for the last several years for users that only have an iPhone. I did notice that the data types that the different platform data sources collect automatically is different. That makes sense if you think exclusively about what the device can actually capture. Bluetooth HRM is the only Bluetooth SIG profile that is out-of-the-box supported for Apple Health on iOS and iPadOS (right?). Whereas watchOS 10 got all of the cycling sensors (woohoo!). It would be great if the types to collect were the same across platforms even if the device couldn't collect the data now, because then in the future when / if new sensor support is added, it will be transparent to developers. Fantastic. Easier life as an indie / third party developer. At least that is the idea. And yes, I know I can also write Core Bluetooth code and roll my own SIG implementation for the cycling profiles, but Apple already has this code in one os, 'just copy it, it will be easy'. I know that isn't the reality especially against the new ASK framework, but one can hope and dream right? Imagine how many more apps would contribute that data if it was supported out of the box. An alternative, GitHub is a great place for Apple to share their Core Bluetooth implementation of the SIG profiles :). Just another thought. Here are some feedbacks related to this: FB17931751 - HealthKit: Add built-in support for cycling sensors on iOS and iPadOS - copy paste the code from watchOS. It will be easy they said (June 2025) FB12323089 - CoreBluetooth / Health / Bluetooth Settings: Add support for cycling sensors announced in watchOS 10 to iOS and iPadOS 17 (June 2023) FB14311218 - HealthKit: Expected outdoor cycling to include .cyclingSpeed quantity type as a default HKLiveWorkoutDataSource type to collect (July 2024) FB14978701 - Bluetooth / HealthKit / Fitness: Expose information about the user specified for Apple Watch paired Cycing Speed Sensor like isConnected and wheelCircumference values (August 2024) FB18402258 - HealthKit: HKLiveWorkoutDataSource should collect same types on iOS and watchOS even if device cannot produce data today (June 2025) FB14236080 - Developer Documentation / HealthKit: Update documentation for HKLiveWorkoutDataSource typesToCollect for which sample types are automatically collected by watchOS 10 and 11 (July 2024) Tangentially related: FB10281304 - HealthKit: Add HKActivityTypes canoeBikeRun and kayakBikeRun (June 2022) FB10281349 - HealthKit: Add HKActivityType walkCanoeWalk and walkKayakWalk (June 2022) FB7807993 - Add HKQuantityTypeIdentifier.paddleDistance for canoeing, kayaking, etc type workouts (June 2020) FB12508654 - HealthKit / Settings / Bluetooth / Workouts: Cycling sensor support doesn't allow for 'bike selection' in use case of multiple bikes and multiple sensors (borrow a bike to ride together) - production usability issue (July 2023)

I tried to use the Connect app this morning and it said a developer account was needed. On the contrary, I am the account holder, which is what the CTA to fix the issue in the app stated to ask for access from. Then I tried to sign in directly on the website and it also didn't respond there. FB19906255 - App Store Connect: Connect app not responding and neither is App Store Connect portal Aug 26, 8:15 AM Central Posting in case others run into this, I have not seen the developer status page report anything yet: https://developer.apple.com/system-status/

I'm making a wrapper library to abstract away some of the 'missing platform support' of DeclaredAgeRange until hopefully it expands to additional platforms. When I'm trying to fully enumerate all of the cases of AgeRangeDeclaration, which they all state available starting 26.0 (mysteriously added in Xcode 26.2 beta), the app crashes due to a missing symbol at launch time. This happens both for Xcode 26.1, 26.2 beta 2, and matching Xcode Cloud builds. So I've isolated it beyond "doesn't work on my machine". I just made a handful of crashes and attached a sysdiagnose to a fresh feedback. FB21121092 - DeclaredAgeRange: Eligibility property and new declaration cases unavailable on iOS 26.1 device contradicting documentation - causes runtime symbol not found crash If anyone is curious what these crashes look like I've attached the DiagnosticPayload.jsonRepresentation() generated from one of my favorite frameworks, MetricKit. Very clearly articulated in the diagnostic metadata you can see the symbol not found. "diagnosticMetaData" : { "platformArchitecture" : "arm64e", "terminationReason" : "Symbol not found: _$s16DeclaredAgeRange0bC7ServiceV0bC11DeclarationO14paymentCheckedyA2EmFWC\nReferenced from: <1894EDCB-3263-3604-8938-97D465FF3720> \/Volumes\/VOLUME\/*\/PerformanceOrganizer.app\/PerformanceOrganizer\nExpected in: <B8FD2C23-0CC9-3D94-902D-875900307A7A> \/System\/Library\/Frameworks\/DeclaredAgeRange.framework\/DeclaredAgeRange", "exceptionType" : 10, "appBuildVersion" : "745", "isTestFlightApp" : true, "osVersion" : "iPhone OS 26.1 (23B85)", "bundleIdentifier" : "dev.twincitiesapp.performanceorganizer", "deviceType" : "iPhone18,1", "exceptionCode" : 0, "signal" : 6, "regionFormat" : "US", "appVersion" : "2.0.0", "pid" : 22987, "lowPowerModeEnabled" : false } DiagnosticPayload.json This is the offending code in a type I control and make available on other platforms but leave unused. extension AgeRangeDeclaration { // A factory or initializer that takes the AgeRangeService.AgeRangeDeclaration and maps to the common AgeRangeDeclaration type public init?(platform value: AgeRangeService.AgeRangeDeclaration?) { guard let value else { return nil } switch value { // Xcode 26.1 visible cases case .selfDeclared: self = .selfDeclared case .guardianDeclared: self = .guardianDeclared // Xcode 26.2 visible cases // This is the first culprit, all of the following symbols would crash, this is just the first case .checkedByOtherMethod: self = .checkedByOtherMethod case .guardianCheckedByOtherMethod: self = .guardianCheckedByOtherMethod case .governmentIDChecked: self = .governmentIDChecked case .guardianGovernmentIDChecked: self = .guardianGovernmentIDChecked case .paymentChecked: self = .paymentChecked case .guardianPaymentChecked: self = .guardianPaymentChecked @unknown default: // Apple added new cases in Xcode 26.2 betas that were available in iOS 26.0, // so it is probable that this could happen again. If it does, assert to let developers // bring it to my attention. assertionFailure("Invalid or out of date knowledge of age range declaration \(value)") self = .unknown } } } For what it is worth, the same is also true for isEligibleForAgeFeatures which I suspect was also added to Xcode 26.2 somehow but not made available to real devices running [26.0 - 26.2). As a side note, thank you for this property, it will let me check what states I need to perform extra checks for in a clean way, I just will need it to now not crash my app on 26.0 and 26.1 runtime devices. :) Edit: DTS did confirm on a comment I had in another thread that this is a bug. Now just to wait for an Xcode beta update. https://developer.apple.com/forums/thread/807906?answerId=867205022#867205022 In any case, this is a great example of how MetricKit totally rocks capturing things other off the shelf crash tools might not have a chance to get. I did have to roll back my TestFlight to an earlier build, but MetricKit was there to send me the previous crashes as soon as the app could launch. Thanks MetricKit team!

I have several apps that contain extensions. For example an App Clip, Widget, Background Assets extension, etc. In Xcode Organizer Version 15.3 (15E204a), attempting to view crash data for these apps results in a failure. I have explicitly seen this error print out the app clip extension bundle identifier, as well as the background assets extension bundle identifier. It says the following error: An error occurred preventing Xcode from downloading crashes list. "" failed with error: Access Restricted with bundle id: com.example.app-name.extension-name Is anyone else experiencing this? I created a feedback a few weeks ago, it seemed to coincide with the release of Xcode 15.3 and or the new App Store Connect metrics APIs. App IDs and bundle identifiers detailed in the feedback if anyone at Apple wants the info. FB13677615 - Xcode: Cannot download crashes for apps that containg extensions --> "Access Restricted with bundle id:

I archived and uploaded a build with Xcode 16 RC earlier today since it wasn't available in Xcode Cloud at that moment. The upload was successful. Since then, Xcode Cloud was updated with Xcode 16 RC and I can build and deploy to TestFlight and App Store Connect that way too. Now, upon submitting my app to App Review, the binary is being rejected as invalid due to unsupported version of Xcode. Rejections Sept 9th at 11:28 PM Central and Sept 10th 12:37 AM. Here is the error message I received via email: ITMS-90111: Unsupported SDK or Xcode version - App submissions must use the latest Xcode and SDK Release Candidates (RC). For details on currently supported versions, visit: https://developer.apple.com/news/releases. Upon visiting the site, you can see a developer news article stating that App Review is now accepting builds created from Xcode 16 RC. I assume this is just the system going through upgrades and the whole system isn't updated yet. Is anyone else having issues submitting Xcode 16 RC builds to App Review? Or the inverse, has anyone had success yet? Submission ID cf4e80cf-1629-4267-8604-8c3c161a0051 Same content just for added visibility: FB15088221

Has anyone been successful creating a widget configuration that uses any of the "Measurement" type parameters? I'm running into crashes in the Widget/Home Screen when I try to do so. I am building a widget that provides functionality to 'nearby' points of interest. I just discovered that SiriIntents support specifying a Measurement type now --> Distance. When I have my configuration "nearbyDistance" parameter type set to the measurement type of Distance, adding the widget from the widget gallery crashes it after I hit the add button and it doesn't get added. This works: This crashes the Widget Preview and doesn't add the widget to the Home Screen: Right before I add my widget, things seem to be good: As soon as I tap Add Widget, this happens: I have created a feedback for this and attached some recordings and a sysdiagnose: FB10002319

I would like to socialize the idea of starting a Live Activity while the app is in the background. According to the ActivityKit, documentation, Live Activities can only be started while your app is foreground. I wrote up a really lengthy feedback about this enhanced ActivityKit permission concept but will summarize to share with others here. FB11308611 The idea is this, like CoreLocation, the ActivityKit framework could have the permission model of 'when in use' and 'always'. Apps that the user has granted the 'always' permission for would then be allowed to start an activity from some sort of background execution. I'm looking at the Background Modes defined in Xcode namely: Location Updates, Bluetooth, Remote Notifications, Nearby Interactions, etc. My specific use case is to combine my usage of Core Location Region Monitoring and Visit Monitoring into triggering a Live Activity to the users Lock Screen when they are at a place contextually relevant to my app(s). I can imagine this applies to many other applications too. While the current experience I have will present the user with a local notification gets the job done, the user experience could be so much more engaging. When I saw the Live Activities feature get announced during WWDC22, this was the first thing that came to mind. FB11308699 Some very high level concepts: Live Activity when entering a sport stadium Live Activity when entering a concert venue Live Activity when entering a gym Live Activity when entering a restaurant Live Activity when entering a store Got another use case? Share it! Like a use case in this thread? Comment on it!

Hey everyone, From WWDC23 lab conversations, in order to run a fitness app, health tracking apps, etc. on iPadOS 17 that 'requires' health, you actually have to remove the UI Required Device Capabilities for Health. The UIRDC will still prohibit the app from running on iPad this fall even though from a developer lens it is satisfied. I understand this is to allow iPhone apps a chance to upgrade and get ready for iPadOS 17, but there isn't a path forward if an app truly requires HealthKit. Namely for fitness apps that ONLY read and or write data to Health. Sure I could move my target SDK to 17, but that doesn't help my existing users who can't upgrade on iOS < 17. What is the path forward for Apps that want to target something like the following? iOS 14+ watchOS 7+ iPadOS 17+ Socializing the idea of having an App Store Connect feature or checkbox to allow / opt into being available on iPadOS 17+. The same applies for App Clips that also require HealthKit. FB12327957 - Health / App Store Connect: Ability to make HealthKit required on iPadOS and iOS together

I have an existing WidgetBundle containing a single widget today that works with iOS 14/15. When I add the ActivityKit widget (aka Live Activities), Xcode naturally complains that this is available iOS 16 only. Adding an #if available(iOS 16.0, *) check inside the WidgetBundle results in an error: "Closure containing control flow statement cannot be used with result builder 'WidgetBundleBuilder'" Would the proper mechanism here be to create a second widget extension that ONLY includes the widget for the Live Activity and then use the available modifier on the entire widget bundle to only include it in iOS 16+? This thinking is based off the following here Typically, you include all your widgets in a single widget extension, although your app can contain multiple extensions. For example, if some of your widgets use location information and others don’t, keep the widgets that use location information in a separate extension. This allows the system to prompt the user for authorization to use location information only for the widgets from the extension that uses location information.