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.
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Created
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
Xcode 14 beta 1 is yelling at me that CKNotification initializer should return a non-optional value. This happens only AFTER letting Xcode upgrade my project settings.
The change that the upgrade project settings made was it merged my WatchKit and WatchKit extension targets into a single watch app target.
After doing so, this code will not compile which I know to be good.
// This line fails to compile with '
if let notification = CKNotification(fromRemoteNotificationDictionary: userInfo) {
// Do something
}
Compile error: "Initializer for conditional binding must have Optional type, not 'CKNotification'"
Feedback w/ sysdiagnose:
FB10282805 - watchOS / CloudKit: CKNotification doesn't return optional, xcode build failing after updating project settings for Xcode 14
I could not reproduce this in a sample application. I tried making a standalone watch app with Xcode 13, upgrading the project file with Xcode 14 beta, and then creating a CKNotification object--but that worked fine. :/
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've noticed a bug in my app recently, it appears that in watchOS 8.5 (or earlier) that page layout is no longer initializing or awakingWithContext the pages beyond the first index.
According to the documentation:
In a page-based interface, all interface controllers are initialized up front but only the first one is displayed initially.
https://developer.apple.com/documentation/watchkit/wkinterfacecontroller/1619521-init
I am simply not seeing this happen anymore. I have logging in all of the lifecycle method of all three of my pages and the second and third controllers don't fire anything (including init) until I swipe to the right. This is when I would expect the willActivate and didActivate methods to be invoked. Instead I get init, awake, willActivate, and then didActivate. :/
This is unfortunate and a bug to the user because the second controller asks to becomeCurrent under some certain conditions that the first detects and fires via NotificationCenter. The automatic programatic switching between pages is totally broken.
FB9972047
Topic:
App & System Services
SubTopic:
Core OS
Tags:
watchOS
WatchKit
Health and Fitness
Accessibility
Hey developer community / CloudKit fans,
I'm making an application that utilizes CloudKit's identity system to provide my users a 'social' aspect of the app as well as their own identity. When filling out my App Privacy label, I'm torn if I should disclose Contact usage or not.
https://developer.apple.com/documentation/cloudkit/ckcontainer/1640421-discoverallidentities
Right now, I'm leaning to not specifying Contacts collection. Here are my thoughts:
Data Collection defined by Apple, paraphrased, is transmitting data off device for longer than needed for the request.
How Apple implements the function of the CloudKit identity lookup is outside of our control as developers, however, it is reasonable to expect that Apple would not save your contact address book in CloudKit and the data does not live in CloudKit longer than it needs to.
I don't access the Contacts app or API in the implementation.
Apple in fact use your contacts under the hood to service this request according to the documentation, however to the user, there is no contacts permission / access prompt for the application itself. The app doesn't get access to the full contacts db.
When you receive a CKUserIdentity, the contacts identifier is just that, a lookup identifier string.
I'm not going further than just displaying the information on the user identity. I could back link the identifier to a contacts record, but I don't need to. If I did that, even then I would say no, because the operation all happens locally on device.
Does your app use CKUserIdentities? How did you answer the App Privacy question for Contacts?
If you have strong feelings one way or another, I'd love to hear your perspective.
Topic:
App Store Distribution & Marketing
SubTopic:
General
Tags:
App Review
App Store
CloudKit
Privacy
In my application initializer, I set a property on ApplicationDelegate. It is a reference to my data controller that manages access to many things (core data model). It gets passed in there to handle launch keys and pushes, and is relied upon as a required dependency to many services--namely push, navigation actions (quick look, Siri intents, etc.).
In summary, I want to clean up and move some initialization code from my application initializer (tons of compiler directives for multi targets, watch, app, etc.) to the respective application delegates. BUT this requires an assumption that didFinishLaunching will be called after a property is injected into app delegate. Is this a safe assumption to make?
I have observed the didFinishLaunching getting invoked only AFTER the initializer of Application completes. Can this be relied upon in terms of dependency injection?
Can this order be assumed?
Application init
Property assignment on app delegate within app init
App delegate init
Property is set (didSet fires)
App initialization complete, return
Delegate fires willFinishLaunching
Delegate fires didFinishLaunching
Other delegate methods fire accordingly
I assume that the implementation of UIApplicationDelegateAdaptor under the hood is similar to the Coordinators in UIViewRepresentable where as soon as you try to access / assign something on it, then it constructs the object and assigns an instance to the property wrapper.
Additionally, if it hadn't already been initialized, because it DOES need to call delegate callbacks, the system will invoke it had you not already assigned a property to initialize it.
I have a record type called ContactInformation that has phone and email as fields. This record type also has two references that point to different types. Namely type1 and type2 for illustration (one is a person reference, another is a place reference).
When I seed my application I do a blind query operation to get all records. I don't think there is a way to perform a query using a predicate where the field isn't nil but thought I'd pose the question to the forums.
The idea would be query where type1 != nil and then a second one where type2 != nil. Using CloudKit Console doesn't receive any results when running the following queries so I don't think this is supported as of today.
CloudKit Console provides the following error when a reference filter by is applied with empty value: invalid id string: empty
As a work around, I could create a 'dummy/default' reference id then the != "dummy identifier" would in theory work but it feels very hacky.
Has anyone found a more elegant solution than to use a dummy reference ID?
I filed this feedback requesting the ability to create a predicate that supports nil values: FB9833175
Question: Do App Clips support receiving callbacks from ASWebAuthentictionSession's redirectCallbackURL?
Context: I'm trying to get CloudKit working in an app clip. Read support is done, but it would be nice for the user to see the capabilities before full download.
Presently, I have the CloudKit Web Services successfully invoking redirectURL within SafariViewController, but I haven't figured out how to get it to direct to something the App Clip can get a hold of.
CloudKit allows you to specify three different callbackURLs:
https:// [freeform]
http:// localhost[freeform]
cloudkit-icloud.:// [freeform]
I am new to AuthenticationSerivces framework so I may have missed something. The desired OAuth doesn't need to be CloudKit/iCloud but any provider.
Everything is working except the redirect URL.
Topic:
App & System Services
SubTopic:
iCloud & Data
Tags:
CloudKit
App Clips
Security
Authentication Services
I submitted a feedback asking what would be safe prevent MITM attacks against CloudKit web APIs, pinning against the CA was an okay'd implementation.
This is the response I got in my feedback: FB9445034
You can pin to the various Apple CA or sub-CA certificates that can be found here:
https://www.apple.com/certificateauthority/public/
https://www.apple.com/certificateauthority/
All the certificates for CloudKit and iCloud web APIs have cert chains that point to the certificates listed.
I have followed this article Identity Pinning and modified my App Clip info.plist accordingly to pin against CloudKit Web Services (https://api.apple-cloudkit.com). I intentionally mucked up the identity pin to verify my URLSession requests failed. I didn't receive any URLSession errors in my App Clip or Application targets when I had the plist updates in both.
In reading these other forum posts I'm curious if the Identity Pinning is supported in App Clips or not.
https://developer.apple.com/forums/thread/678081
https://developer.apple.com/forums/thread/681734
My application makes use of opaque navigation and tab bars in its layout. I also use modally presented nav bar controllers using the card style introduced in iOS 13. Everything looks clean and as expected when running the app compiled from Xcode 12 (Test Flight or App Store).
When I run my project using Xcode 13, I'm getting really strange rendering behavior of the bars. In light appearance, they're black instead of opaque white in some cases. In another case, when I have a MKMapView filling the entirety of my view, the tab bar is totally invisible and there are just the blue tab bar items floating on top of the map.
I have attached images of three different scenarios that visually render as expected on Xcode 12, but fail horribly when deployed via Xcode 13.
Opaque Tab Bar w/ nav controller
Opaque Tab Bar w/ map view inside view controller
Opaque Tab Bar w/ Opaque Navigation Bar presented modally as card.
I was able to produce these issues using both SwiftUI and UIKit via Storyboards
I've filed two feedbacks with Apple and sent them a sample project. If anyone else is encountering this issue feel free to mention feedback in yours to upvote the issue.
FB9611443 FB9207757
Hope this gets fixed before RC so I can send an app update in making use of new features!
Has anyone else discovered CoreLocations "NullIsland" print out?
I recently came across this easter-egg-esque message printed from my CLLocationManager in simulator and device (iOS 14.4.2) in some of my workout API code.
2021-04-10 08:30:11.547947-0500 AppName[28506:1222419] [Client] {"msg":"#NullIsland Either the latitude or longitude was exactly 0! That's highly unlikely", "latIsZero":0, "lonIsZero":0}
I was banking on CLLocationManagers caching/sharing the 'location' property and cheating a little not passing my 'lastLocation' data point from one area of code to another and just doing CLLocationManager().location. Oddly enough, when I am attached with a debugger and then PRINT that object via lldb po location, it is populated with non-zero lat/long.
I could refactor my code to pass the location property throughout my code, but if the value isn't really NullIsland, I'm not sure if it is worth the trouble.
Anyways, this message feels misleading because lat/log is non-zero. I would expect this message to be printed when returning NullIsland OR when returning nil itself.
Here is the gist - https://gist.github.com/edorphy/930dfbe73d4c471d4cd7a9668048b760
I'm adding Weather info to my workout app. The documentation for HKMetadataKeyWeatherHumidity states that the unit is percentage humidity.
https://developer.apple.com/documentation/healthkit/hkmetadatakeyweatherhumidity
HKUnit.percent() has valid values from 0.0-1.0 inclusive.
https://developer.apple.com/documentation/healthkit/hkunit/1615517-percent
For a given humidity of 61% (i.e. 0.61 from my server), I'm saving the following quantity:
metadata[HKMetadataKeyWeatherHumidity] = HKQuantity(unit: .percent(), doubleValue: humidity)
builder.addMetadata(metadata) { }
The health app is interpreting this at 1% humidity (school kid rounding) 0.61 -- 1% and 0.41 -- 0%.
When I print the humidity quantity of a workout recorded by Fitness app on Apple Watch, I see the value as 6100 %. Meanwhile, quantity.doubleValue(for: .percent()) prints out 61.0.
Seems that the Health app is scaling by a factor of 100. Has anyone else integrated humidity into their HealthKit compatible app? How were you saving it to make sure it displayed correctly in the Health app. I'd hate to account for this, only to find out it is a bug and have apple change their logic in the app.
Topic:
App & System Services
SubTopic:
Health & Fitness
Tags:
Health and Fitness
HealthKit
Apple Watch
I'm building an app based entirely on CloudKit and I'm super excited for technologies like App Clip to make a mini 'menu' version of said app. The main app target allows vendor/site location managers to update their menu in real time and then signed in iCloud users can subscribe to those public record updates.
I just discovered in the technology limitations of App Clips that CloudKit is out. It isn't in the list of 'supported capabilities' in the project editor. Additionally, as one would expect, trying to create a CKContainer without the entitlement in the App Clip target crashes with a fatal error due to the lack of that very entitlement. This feels unnecessarily restrictive and excludes developers from supporting App Clips who build their server tech stack on CloudKit.
Write capability isn't needed for my concept. Effectively I'd want for each unique venue to be able to continue to manager their menu/venue via CloudKit + Security Roles and allow updating content in the main app--and for users to view/browse with focused location/venue specific menus in the app clip. As recommended, the full app has to be installed for the full experience.
I'd rather not attempt to hit the public database via the JS library, or making an API proxy that just invokes CloudKit web tech under the hood. I really think supporting read operations from the public CloudKit database would enable many experiences that are currently restricted due to this limitation.
If someone at Apple is watching, I created FB8528010 feature request with a little more details on my new feature concept.
iOS 13 is requesting Bluetooth permission immediately upon central manager initialization. From the Bluetooth 2019 talk, the presenter illustrated in the didUpdateState method to check the authorization state and appropriately prompt the user (presumably the same way you would with CMPedometer--invoke a instance method). Is this behavior to expected in the GM seed? It is counter intuitive and doesn't conform to the pattern that other frameworks use for their authorization workflow.This permission model seems to be incorrect, most other frameworks have a static method on the corresponding class to get authorization status. For example https://developer.apple.com/documentation/corelocation/cllocationmanager/1423523-authorizationstatus, https://developer.apple.com/documentation/coremotion/cmpedometer/2913743-authorizationstatus. The API signature that has a "notRequested" state, will seemingly never be the case since the prompt happens upon first initialization NOT first usage. CMPedometer initialization does not initiate the privacy prompt, only calling a method to do work does. CLLocationManager has explicit methods to invoke the authorization modal.If we don't have the class func to check authorization, and are dependent on an instance of CBCentralManager to have been initialized with a delegate, we can't design an elegant workflow to prompt the user at the appropriate time.