Post

Replies

Boosts

Views

Activity

Reply to Watch Complications (WidgetKit) do not show anything on device
OK, I think I've found the reason for this problem: The problem seems to be the size of the image I try to show in the complications. I could not find any information about the concrete sizes of the different complication variations (these might be larger on larger watches than on the smaller models). So I initially tried a size of 128x128 px. This caused runtime errors in the Xcode preview and inspecting the error message saying that the image size was too large and the maximum would be 124x124px (circular) and 93x93px (corner) etc. (the numbers can be slightly different) Therefore I created matching images of these sizes and have used these. This works fine for the simulator and the previce in Xcode. But when I run the complications on a real device, the allowed image sizes seem to be even smaller. Unfortunytely there are no error messages or console messages when running complications on a real device, so we are debugging blind... So reducing the image sizes even further made the complications appear on the device as well. This actually leads to the problem that for the circular complication on most watch faces an image size of 120x120 is too large, but for the cirular complication for the „large numbers“ watch face this image size is too small to be not blurry. The final question is, where can we find information about how large images should or can be for the different kinds of complications? When these images are too small, they look blurry, if they are too big, they waste space or cause errors. But what are the sizes which should be used?
Topic: App & System Services SubTopic: Core OS Tags:
Nov ’22
Reply to Accessibility Labels within the Dynamic Island
Some additional findings: The problem seems to be related to updates to the Live Activity content. Which means as soon as the main App sends an updated status to the live activity, VoiceOver starts reading all content multiple times. If you only setup the content of the Live activity once, the content is only read once. The update interval itself seems to be irrelevant. So it doesn't matter if I send updated content to the widget every second or every minute. As soon it was updated, Voiceover is failing...
Topic: UI Frameworks SubTopic: UIKit Tags:
Nov ’22
Reply to Slider inside a dynamic island
As far as I know, you can't have any working button or slider or any kind of user interaction control in live activity widgets. All touches will directly launch the corresponding App. You can only have "Links" which can deep link into your App. You can use different URLs for these links to do different things within your App.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Nov ’22
Reply to MapKit - Look Around - isNavigationEnabled not working?
This API is a little bit strange, or still very buggy. Just presenting the MKLookAroundViewController does not let you navigate at all. I hope that this is just a bug. But what is working is this: Add the MKLookAroundViewController as child to your main viewcontroller. Then add the view of MKLookAroundViewController as a subview somewhere in your main view controller and make sure it is visible. The view of MKLookAroundViewController will now show a static image of the street and if you tab on this view the MKLookAroundViewController will actually open as "ViewController" in fullscreen (like it would be presented). Which means you do not present MKLookAroundViewController yourself, instead you let the view of MKLookAroundViewController do this for you after the user taps on this view. This also means it is currently impossible to "navigate" without having the user to do this extra tap on this extra view. I'm not sure if this is supposed to work this way. But in my opinion this doesn't make much sense, because you can't really do anything useful with this "extra" view. You only need it to indirectly present the MKLookAroundViewController. It would make much more sense to be able to simply present the MKLookAroundViewController directly without the need to show this extra view. But the fact that the delegate has methods which are called when entering/leaving the fullscreen mode indicates that Apple probably is serious about this. If you would present or dismiss the MKLookAroundViewController yourself, you would not need these delegate messages.
Sep ’22
Reply to Watch Complications (WidgetKit) do not show anything on device
OK, I think I've found the reason for this problem: The problem seems to be the size of the image I try to show in the complications. I could not find any information about the concrete sizes of the different complication variations (these might be larger on larger watches than on the smaller models). So I initially tried a size of 128x128 px. This caused runtime errors in the Xcode preview and inspecting the error message saying that the image size was too large and the maximum would be 124x124px (circular) and 93x93px (corner) etc. (the numbers can be slightly different) Therefore I created matching images of these sizes and have used these. This works fine for the simulator and the previce in Xcode. But when I run the complications on a real device, the allowed image sizes seem to be even smaller. Unfortunytely there are no error messages or console messages when running complications on a real device, so we are debugging blind... So reducing the image sizes even further made the complications appear on the device as well. This actually leads to the problem that for the circular complication on most watch faces an image size of 120x120 is too large, but for the cirular complication for the „large numbers“ watch face this image size is too small to be not blurry. The final question is, where can we find information about how large images should or can be for the different kinds of complications? When these images are too small, they look blurry, if they are too big, they waste space or cause errors. But what are the sizes which should be used?
Topic: App & System Services SubTopic: Core OS Tags:
Replies
Boosts
Views
Activity
Nov ’22
Reply to Accessibility Labels within the Dynamic Island
Some additional findings: The problem seems to be related to updates to the Live Activity content. Which means as soon as the main App sends an updated status to the live activity, VoiceOver starts reading all content multiple times. If you only setup the content of the Live activity once, the content is only read once. The update interval itself seems to be irrelevant. So it doesn't matter if I send updated content to the widget every second or every minute. As soon it was updated, Voiceover is failing...
Topic: UI Frameworks SubTopic: UIKit Tags:
Replies
Boosts
Views
Activity
Nov ’22
Reply to Slider inside a dynamic island
As far as I know, you can't have any working button or slider or any kind of user interaction control in live activity widgets. All touches will directly launch the corresponding App. You can only have "Links" which can deep link into your App. You can use different URLs for these links to do different things within your App.
Topic: UI Frameworks SubTopic: SwiftUI Tags:
Replies
Boosts
Views
Activity
Nov ’22
Reply to MapKit - Look Around - isNavigationEnabled not working?
This API is a little bit strange, or still very buggy. Just presenting the MKLookAroundViewController does not let you navigate at all. I hope that this is just a bug. But what is working is this: Add the MKLookAroundViewController as child to your main viewcontroller. Then add the view of MKLookAroundViewController as a subview somewhere in your main view controller and make sure it is visible. The view of MKLookAroundViewController will now show a static image of the street and if you tab on this view the MKLookAroundViewController will actually open as "ViewController" in fullscreen (like it would be presented). Which means you do not present MKLookAroundViewController yourself, instead you let the view of MKLookAroundViewController do this for you after the user taps on this view. This also means it is currently impossible to "navigate" without having the user to do this extra tap on this extra view. I'm not sure if this is supposed to work this way. But in my opinion this doesn't make much sense, because you can't really do anything useful with this "extra" view. You only need it to indirectly present the MKLookAroundViewController. It would make much more sense to be able to simply present the MKLookAroundViewController directly without the need to show this extra view. But the fact that the delegate has methods which are called when entering/leaving the fullscreen mode indicates that Apple probably is serious about this. If you would present or dismiss the MKLookAroundViewController yourself, you would not need these delegate messages.
Replies
Boosts
Views
Activity
Sep ’22