I am also experiencing this on several of my devices. It worked before in an earlier iOS 15.x release, but I cannot find the "Local Experiences" listing on iOS 15.4 public release either within the Developer settings pane. This makes it impossible to test some experiences as well as having the App Clip card be shown for local demonstrations to business partners. @eskimo, can you help get some visibility to this? The instructions for testing App Clips locally is unchanged from the documentation. On your test device, open the Settings app, navigate to the iOS developer settings by choosing Developer > Local Experiences, and select Register Local Experience. I created a few feedbacks: App Clips Framework: FB9961137 Xcode Developer Tools: FB9961139 Feedback Assistant: FB9961143

iOS 15.4.1 has also resolved the issue on my devices. I also noticed a new "diagnostics" in both App Clips and Universal Links that lets you locally test the pathway to your server. I assume this is a mini AASA job that they're running. Maybe it isn't new with 15.4.1, but very cool and handy just the same. Closed out my feedbacks FB9961137 and FB9961139.

@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". :)

@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.

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.

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!

@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

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

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.

@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

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.

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/

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.

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."

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