this is a bug right? because "Supports Running Without iOS App Installation" should not mean "cannot have ios app installed"? And does not on the real device, only on simulator?

I would recommend using the viewContext for everything by default. If you hit a real life scenario where this is causing an issue I would investigate how to solve that issue at that point, but it’s better to avoid complexity until you need it. (To be clear I think this is a good question and this is not an intuitive answer. I think the contexts could be better labelled as “default” and “expert” or something like that)

Xcode 12 is required for developing iOS 14 style widgets. You can run it along side Xcode 11 though.

In beta 1 it seemed like widgets refreshed from the timeline every few seconds. Since beta 2 it seems to be much less frequent, like maybe once an hour. I am fine with not updating every second, but once a minute seems quite reasonable given the low cost of the widget views. I think this will be a problem for apps which want to show timely glanceable information (for example the system clocks widget does not update every minute). I will raise a feedback.

Just to clarify, there is no way to pass formatting options into the style parameter right?

I don't work at Apple so my word isn't canonical, but my instinct is that the fact that onAppear is working is a bug. The widgets are totally static, you should imagine that they are generating a still image which is shown the user at the system's discretion. Much like the app switcher screens, or launch screens. They can't take any action on being shown or hidden, or under any other circumstance.

Yes, I am seeing this a lot, both with my own widgets and ones provided by Apple.

I think Apple is still deciding what this number should be and it is changing between betas. My hope is that at least a few times an hour should be possible.

I haven't tried this with the new widgets, but with the old widgets I found that the widget core data instance was very slow to receive updated, as in days later. This issue was true in watchOS for a while and then it was resolved, so it may be resolved in iOS 14 too, but just something to test for. (The workaround in my case is to store the database in a shared container)

With iOS 14 I notice that when you delete an app instead of offering to delete your health data it shows an option to go into the health app where you can delete your data. That screen also shows permissions. It would be very helpful to be able to deep link to that screen for users who change their mind about what permissions they want to grant. "How do I change my health permissions?" Is a common support request for us. Anyway, the above change implies that such a link/url does exist. I wonder if anyone knows what it is?

I see the same thing in iOS 14.5 (Xcode beta 3)

I've used https://github.com/RobotsAndPencils/XcodesApp/ to go back to beta 2. not tried it in beta 3 watch development on a production apple watch is not really possible for me, it's just too slow to be worthwhile

I see crashes for this too, and in production not just TestFlight. If anyone ever finds a solution or how to debug further please share 🙏

I'm on Xcode 14 beta 4. I created a new empty watch only app and then a widgets extension. I see the build error that yvsong mentions above. Then I run the terminal command that colejd recommends and that removes the build error. But I still don't see a widget preview, I just see a black rectangle. I tried changing the text color and removing the date formatting and just making it a string, I still just see the rectangle. I love this new combined framework so much. Can't wait to build some cool stuff with it.

I assume you are seeing this issue when archiving your code? Is it an error or a warning? I have an issue where images are not showing in my widgets, I'm wondering if this is related to what you are seeing or not. Probably not as I can't find any messages like this, but also can't figure out why the images wouldn't load. Everything on the watch is so much more painful than the phone.