Post not yet marked as solved
This most likely is a regression in iOS 17. I suggest that folks file a new feedback report for the WidgetKit team to investigate.
Post not yet marked as solved
Did you change your Core Data model in your new version app? If not, I'd assume that the "migration" you mentioned means "copy," which can be done using replacePersistentStore(at:destinationOptions:withPersistentStoreFrom:sourceOptions:type:).
Otherwise, you might consider doing the migration (lightweight or staged migration depending on your change) first, and then copy the migrated store to your App Group container.
Secondly, your flow doesn't seem to cover the widget side. Consider your users do the following:
Downloading and installing your app.
Configuring and adding your widget before running your main app.
Now your widget can run before your main app being launched, or they can run simultaneously. If your widget goes ahead to create an empty store and put some data there, the data will be lost when your main app copies the existing store. Also, if the widget and main app access the UserDefault simultaneously, a race will be triggered.
Without having the bigger picture, I may consider the following flow:
On the main app side:
Check if the destination store URL exists. If yes, the copy is done, and so you continue the normal process.
Otherwise, copy the store using replacePersistentStore....
Set hasMigratedToAppGroup to true in the shared UseDefault.
Continue your normal process.
On the widget side:
Check if hasMigratedToAppGroup in the shared UserDefault is true. If yes, continue your normal process.
Otherwise, present something in the UI to ask the user to launch the main app. With this, the widget doesn't access the store before it exists.
In this flow, hasMigratedToAppGroup helps the widget avoid accessing the store while the main app is copying. If your widget doesn't really write data to the store, you can load the store in readonly mode (See isReadOnly), and don't need the user default.
Post not yet marked as solved
Yeah, transferCurrentComplicationUserInfo(_:) doesn't work with WidgetKit complications for now, and that is a bug on the framework side :-(.
I suggest that you file a feedback report with your use case, if not yet, which may help the team prioritize the fix.
Post not yet marked as solved
In case this still matters, the watchOS Simulator doesn’t support transferFile(_:metadata:), transferUserInfo(_:), and transferCurrentComplicationUserInfo(_:). Please always use physical devices to test Watch Connectivity data transfers. This is documented in the API reference.
Post not yet marked as solved
Your first screenshot shows the following errors:
Localizable.xcstrings cannot co-exist with other strings or .stringsdict tables with the same name.
LocalizableDic.xcstrings cannot co-exist with other strings or stringsdict tables with the same name.
InfoPlist.xcstrings cannot co-exist with other strings or stringsdict tables with the same name.
These errors are typically triggered because the .strings or .stringsdict files exist in the Base.lproj folder in your project.
Base.lproj is for something like a storyboard, which you have a base resource in Base.lproj and each locale (including English) has a .lproj folder with a .strings file that overlays the translations on top of the same base resource. It should not contain any .strings or .stringsdict files.
Xcode doesn't provide a good way to remove the files from Base.lproj, and so I'd consider fixing the issue with the following steps:
Back up your project.
Remove the .strings or .stringsdict files from your project. In this case, they are Localizable.strings, Localizable.stringsdict, and InfoPlist.strings, as mentioned in the error message. Note that you need to trash the files, and not just remove the reference from your project.
Add the files back from your backup project. To do so, place your project and backup project side by side, and then drag and drop the files.
Localize the files for the languages you support. To localize a file, select it in Xcode's Project Navigator, click the Localize button in Xcode's File Inspector, then pick the languages. In this process, Xcode creates a .lproj folder for each language (if not yet), and copy the file to the folder. Replace the file in each .lproj folder with the localized version from your backup. As a result, your project has the localized files in each .lproj folder, but not in Base.lproj.
Now that your project is correctly configured, right-click a .strings or .stringsdict file in Xcode's Project Navigator to show the contextual menu, then select Migrate to String Catalog… menu. Xcode should do the migration for you.
Post not yet marked as solved
selectedRange returns an NSRange instance, and the range location and length are meant to be used with text as NSString, which natively uses the UTF-16 encoding. This is because UITextView (and many other Text APIs) was implemented with Objective C long before the introduction of Swift.
Range(_:in:) converts an NSRange instance to a Swift range, which is based on the character (Character) index (String.Index) of the string (String). If the lower or upper bound of the input range (NSRange) locates in the middle of a composed character sequence or an extended grapheme cluster, Range(_:in:) adjusts the output range to include the whole Swift character. So if the “valid indices” you mentioned means the valid Swift character indices, the answer is yes.
selectedTextRange is a part of UITextInput. It is based on UITextRange and UITextPosition, and is typically used with other UITextInput APIs, such as beginningOfDocument, endOfDocument, and position(from:in:offset:).
UITextRange and UITextPosition are abstract classes. TextKit provides concrete implementation for them, and the implementation is based on NSString / NSAttributedString as well.
Post marked as Apple Recommended
This is an issue on the framework side, and should be fixed in iOS 17.4, which is now beta. If you try with the beta and still see the issue, I suggest that you file a feedback report.
If you need to support iOS versions before 17.4, consider working around the issue by creating one container per configuration.
Just to share that the crash is a known issue, and the watchOS engineering is actively working on that.
Post marked as Apple Recommended
Sending data between a watch app and its companion iOS app via a mirrored workout session is demonstrated in the Building a multi device workout app sample. You might want to give it a try, if not yet. If the sample has the same issue, you can file a feedback report with detailed steps to reproduce the issue, and post your feedback report ID here.
Post marked as Apple Recommended
The error message typically indicates that your app ID isn't properly associated with your iCloud container, which can be a configuration issue on your side, or a bug on the system side.
To rule out the configuration issue, consider the following:
a. When creating a CloudKit container, use CKContainer(identifier:) to explicitly specifying the container ID. This avoids confusion in the case where your app uses multiple containers. If you use Core Data CloudKit, specify the container ID with NSPersistentCloudKitContainerOptions:
let cloudKitContainerOptions = NSPersistentCloudKitContainerOptions(containerIdentifier: yourCloudKitContainerIdentifier)
b. Be sure that your app ID and CloudKit container are correctly associated with the following steps:
Log in Apple's Developer Portal with your account, go to the Certificates, Identifiers & Profiles page, and find the app ID of your app.
Click the app ID to navigate to the Capabilities page, make sure iCloud is check, then click Edit to navigate to the iCloud Container Assignment page.
Find your iCloud container on the page.
Make sure the container ID is checked, meaning that the container ID is associated with your App ID. Without the association, your app won't be able to access the container.
Refresh your provisioning profile. If you are using Xcode’s Automatically manage signing, uncheck the box, check it back, and then pick the right team so Xcode refreshes the provisioning profile. Otherwise, you need to manually create the provisioning profile, download it, and install it for your Xcode.
If the error is still there, try with a new CloudKit container. (You can't delete an iCloud container after creating it, but in this case, you might want to create one to help diagnose the issue.) If the error goes away after you simply switching to the new CloudKit container, you can confirm that the association between your app ID and the CloudKit container isn't established, even though the Portal shows it is.
You can now forget the problematic CloudKit container, and use the new one to continue your development.
If the problematic CloudKit container has been shipped, and hence you need to fix the issue, start with filing a feedback report with the following information:
Your app ID.
The CloudKit container ID that triggers the problem.
The code that you use to specify the CloudKit container.
The screenshots that show the association between the app ID and the CloudKit container.
The fact that simply switching to a new container fixes the issue.
You can then contact Apple's Developer Technical Support with the feedback report ID so they can work with the CloudKit team to correctly associate your app ID and CloudKit container ID from the server side.
Post marked as Apple Recommended
As of today, a non-replicated file provider, or NSFileProviderExtension, on both macOS and iOS, has evolved to a replicated file provider, or NSFileProviderReplicatedExtension, and importDocument(at:toParentItemIdentifier:completionHandler:) isn't part of a replicated file provider. If you haven’t adopted replicated file providers, now is the time, and here is a well-written sample to show you how to do that: Synchronizing files using file provider extensions.
If you need to stick with NSFileProviderExtension for some reason, yes, use start/stopAccessingSecurityScopedResource() to access the URL the system passes to importDocument(at:toParentItemIdentifier:completionHandler:). This is documented in the API specification of the method.
Post marked as Apple Recommended
This was answered in the following post: https://developer.apple.com/forums/thread/737971?page=1#767265022.
Basically, the behavior change is intentional. If you have any feedback, please post your feedback report ID in that thread.
Post marked as Apple Recommended
On iOS 17, the behavior of saving an AirDropped file to the Downloads folder (and then launching Files.app) is intended. That is part of the effort to avoid directly passing a file to an app that declares itself as a handler of the file type but isn’t really the file handler that the user expects.
If you have feedback on the behavior change on iOS 17, feel free to file your feedback report http://developer.apple.com/bug-reporting/.
Post not yet marked as solved
CloudKit/CoreData/SwiftData should all work on visionOS. If you see anything wrong, I suggest that you file a feedback report http://developer.apple.com/bug-reporting/, and post the report ID here for folks to take a look. Thanks.
Post not yet marked as solved
Does this help?
timeInDaylight
https://developer.apple.com/documentation/healthkit/hkquantitytypeidentifier/4168154-timeindaylight
