+1, as a developer building 'experiences for businesses' it is crucial that information for the maps portal be made available to developers so we can teach/aid the external businesses through the process.

@Claude31, I'm also curious what you've encountered. I have yet to convert my watch apps over to SwiftUI but plan on doing so due to some WatchKit defects that surfaced the last two years that are quite annoying--though I just checked watchOS 9 beta 2 and they appear to be fixed. In any case, if you post your feedbacks here with a quick description and they apply to my apps too, I'd be happy to write matching ones up on my side and reference yours as duplicate to help upvote what you found. For other devs finding their way to this post, here are some defects that I've filed against watchOS 7 / 8: FB9972047 - WatchKit: awakeWithContext not invoked on page 2 and 3 in multipage layout until after swiping [watchOS 8] In short, three "page" layout in WatchKit, the second and third pages don't receive an init until the user swipes. Previously, in the init of the second interface controller, I was having it become the active page upon initialization. I can't do this anymore so programatic navigation is totally busted. FB8965949 - WKInterfacePicker text baseline clips with y and g [watchOS 7.2/8] In short, I added a picker that has "kayaking" and "canoeing" in my watch app. The letters are being clipped when using the WKInterfacePicker control, but when I rewrote in SwiftUI this was not the case.

Update: Xcode 14 beta 3 deprecated the above code using scope within searchable and now there is a new modifier .searchScopes. The behaviors described in my feedbacks still apply. I'd expect the scopes to be visible before typing in the search and the selected scope to respect the binding. These are still open issues. A visibility param now makes a ton of sense. The new API is here: https://developer.apple.com/documentation/swiftui/anyview/searchscopes(_:scopes:)?changes=latest_minor

Check out the App Store Review Guidelines: https://developer.apple.com/app-store/review/guidelines/ Specifically sections: 3.1.1 In-App Purchase 3.1.5 Cryptocurrencies 5.3 Gaming, Gambling, and Lotteries I think this is the line you're looking for from 5.3.3 that states "Apps may not use in-app purchase to purchase credit or currency for use in conjunction with real money gaming of any kind."

There are still a handful of things you can do in UIKit for UITabViewController that you can't in SwiftUI (even with iOS 16). If you want to mix and match, you can use a UIHostingController and shove your SwiftUI view inside one then add the hosting controller as a child of the UITabViewController.

Go into the Maps app and report an issue on the location place mark. I've had several missing or incorrect business listings fixed that way for breweries. Or the owner of the facility if they manage a Maps Connect account they could update information that way too. https://register.apple.com/placesonmaps/

I asked the same thing during WWDC22 Labs and the API behavior and design is pretty much on lock down. Taking hints from the system and the use cases that Apple has demonstrated, a package delivery, a sports event score change, a ride share service, these are all things that seem to be remote server updated. Meaning the phone can't do them on their own. Maybe you could do a conference planner/scheduler Live Activity that is all locally cached, but the use cases were telling to me. I have to imagine it will look like WidgetKit but have some aspect of content-available push that maybe goes right to your widget / live activity extension. Or to your app and then reload timeline if truly like widget kit. I'd also bet that just like widgets on home and Lock Screen, Live Activities will be 100% SwiftUI for visuals. So my vote goes to learning "systemMedium" widget family, and SwiftUI. If you make a systemMedium Home Screen widget visually, hopefully it would be reusable for your live activity view. Out of curiosity, what is your use case? How often would you want to refresh the live activity? This was also something I talked about in my lab, trying to get info on refresh policies--nothing :) Guess we will have to wait. I was encourage to #filefeedback on my ideas for Live Activities so Apple can see what we want to build.

@JJY, did you #filefeedback for this? The documentation for the openSettingsURLString describes "app" so my guess is that the behavior is expected. That having been said, I agree it would be nice to direct the user to correct permission issues if they want to access a feature they previously denied authorization for. I just filed mine requesting app clip settings url: FB10346783

There was a developer video a few years back that described the behavior of attribute caching. I want to say that attributes are cached if your devices is paired/bonded. Also, for things to work right, your peripheral needs to support the services changed service and characteristic. Attribute caching is a funny business. When ever coworkers ask me about it on iOS / Android I refer them to an article published by Punch Through. Search for "Punch through attribute caching" on the web and it should be one of your first hits. The forums tool said I couldn't post it here directly for some reason.

@pjb493 did you #filefeedback? Also, is your need "real time" or are you just sending data after the fact?

@Jaanus, Have you tried composing your NavigationSplitView with a NavigationStack as your detail? You can then control push / pop behavior with a bound NavigationPath type. You mentioned your button doesn't push anything on the navigation stack, but I don't see a NavigationStack in your view's body. All of my views are List driven but worth a shot. If you haven't already seen this video, check it out: https://developer.apple.com/wwdc22/10054

I'm hoping to be able to detect a tab tap while the tap is already selected so I can reset / pop my new NavigationStack back to root. Fingers crossed further TabItem control comes this year!

Xcode 14 tells you to use the new "SelectableTabsBuilder", but I haven't found anything on that yet. Hopefully Beta 2 we will see it.

@MintChoco, have you made a feedback for this? From user perspective it is undesired behavior if they have small font. I think the system is trying to honor that but then realizes "I'm in a nav bar item, I need standard size". Seems like a defect to me. Post your Feedback # in here and when I get around to capturing one I'll do the same and we can reference each other.

@MobileTen, thanks for sharing your thought. No third party, my privacy policy describes how iCloud works to developers, and the social aspect isn't a focus right now. Maybe in the future I'll add it since not all users will understand "Apple does the lookup for me, I never access your contacts directly". :)