Given that the Submit button is disabled without the data populated, I'd say it's mandatory. Is there some reason you don't want to provide proof that you are who you say you are?

Raised for iOS 16 beta 8: FB11419295.

I've spent an entire day trying to get this to work, and failed to do so. It's clearly broken in Xcode, the Simulator, watchOS 9 and iOS 16. I just hope Apple get their trillion-dollar act together and fix these simple things before they push out the full release. (Oh, and it would be nice if some Apple engineers would step in here and there and help out the developers who are hitting these ridiculous issues every day.)

How are you going to hit high CPU usage in a widget? They aren't running apps. Your iOS app tells the widget what data to display and when, there's little to no processing. The system handles that. If you think you're going to hit high CPU usage then you haven't looked at how widgets should be: Glanceable, Personalised, etc.

I'm also getting this. I doubt Apple are denying timers in Lock Screen widgets as there's so little processing involved (and there's nothing in any documentation to say they don't work in those Widgets), so it might just be an issue in the betas. There's been an issue for a while in iOS 16 betas that the timers in Home Screen widgets don't run either, so it's likely connected to that.

I get errors like this: [WC] -[WCFileStorage enumerateFileTransferResultsWithBlock:] could not load file data at path /Users/username/Library/Developer/CoreSimulator/Devices/3ED00B83-5532-4721-8590-CB5E4B22C503/data/Containers/Data/Application/2AE6F6E2-9AFD-4144-A6EB-68454BFA86BD/Library/Application Support/com.apple.watchconnectivity/26972EDE-BA7C-4E60-8DCD-23190DC18928/FileTransfers/1D0BB287-F528-4020-A246-C0FE91A43FB9/file-transfer-result The Simulator doesn't support transferFile, so any error that comes from attempting to call it on a WCSession can be ignored whilst developing with the Simulator. I know it seems cumbersome, but I do wrap my transferFile stuff in a compiler conditional so it doesn't attempt to send files if the target is the Simulator, and you don't see the errors. You could have just one instance of the transferFile method in a shared functions file so the conditional only has to be in that one file? func sendFile(_ file: String) { #if targetEnvironment(simulator) session.transferFile() etc. #endif } // Somewhere else where you need to send a file sendFile(myFile) You can get stuck down a massive rabbit hole trying to correct errors you'll likely never actually see. I'd keep coding as though the file has been transferred across, and write code that handles receiving the file on the Watch, then deploy to an actual device to test it. I recently spent weeks updating my app for iOS 16 before I took the plunge and deployed to my only iPhone and Watch.

Does the "2022" folder exist? Can you grant your app "Full Disk Access" in System Preferences? Sorry if that doesn't help, but it's late and I can't think of anything else.

What version of iOS are you targeting? The old style widgets you used to have in the Today View/Notification Centre aren't supported in iOS 16. They were small apps that could react to various changes, so tapping the widget might've changed some information that made Steve jump, or whatever. New-style Home Screen widgets (that can also be placed in your Notification Centre) are not running apps; they are "glances at data". There is no real lifecycle running behind them. They simply take data from a provided timeline. So, in essence, you cannot make a Unity game into a widget.

I also see this behaviour in a PHPickerViewController on iOS 16. The UISegmentedControl that shows "Photos | Albums" is aligned to the top. In that picker, if you tap Albums then tap one of the albums, the control is replaced with a title which is correctly aligned. Go back to the start and the control is now aligned correctly. Looks like it's just a bug in the latest beta.

Please add some actual code (and use the "Code Block" button to format it correctly), and we'll see if we can help.

Already answered this here. There's no need for multiple posts.

Does your code (please use the "Code Block" button in the box on these forums to put your code in a code block) actually add the timeline entries? It's not in your shared code. The widget timeline is a set of timeline entries which tell the widget to display different data at different times. If you need the widget to be refreshed at 6am and 6pm, you need two entires: one for 6am and one for 6pm. They are not guaranteed to trigger at precisely those times. You don't need to worry that the user added the widget before or after 6am or 6pm; you just need to add the timeline entries because the system won't try and display data from a point in the past. So, if the user added the widget at noon, it won't care about the 6am timeline entry because that's in the past. You need to provide a snapshot of data that applies, and then add your timeline entries. I would add timeline entries for now, now + 5 minutes, 6pm and 6am, then have the timeline refresh .atEnd.

I think this is reserved for Apple's own complications. There's no obvious way of doing it (I've tried). You can rotate the text some number of degrees, but that only works for one corner of the Watch, and you can't tell which corner your complication is in.

You need to import WidgetKit.

Okay, that didn't work. By trying to put all the complications code into the Widget target I got a billion errors... I went through them all and got down to a few that simply cannot be fixed. (Two @main for some reason even though the Watch App and Widget were not sharing code.) So, this is what I have. Let me know if I'm doing something glaringly obviously wrong: (There's a ComplicationsIntentHandler and a WidgetIntentHandler that do almost the same thing but need to be separate.)