You just need to change one or both of those parameter names in your code. The argument labels (didSelectTab and previousTab) are part of the method signature and need to match the protocol declaration, but the parameter names can be whatever you want. I’d recommend this: func tabBarController( _ tabBarController: UITabBarController, didSelectTab selectedTab: UITab, // better parameter name previousTab: UITab? // no custom parameter name needed ) (Or you can omit tabBarController and selectedTab entirely if you don’t actually use them in your code.) Also consider entering a Feedback to report that the method declaration in the SDK is poorly formed. Presumably your error came after letting Xcode auto-generate the method for you based on its declaration. So it would be better if the SDK declaration were formed like my proposal above.

AccountCreationData(name: "name", email: "email", phone: "phone", password: "password") 110 bytes Something is off. Testing here, if I encode your struct with those exact values, the result is 69 bytes, not 110 bytes. Can you print out a string representation of the encoded JSON? And separately, do you need to set a Content-Type: application/json header so your server knows that the body format is JSON?

Here’s one take: Apple’s Human Interface Guidelines. Learn it. Know it. Live it.

What you need to use is described here: In-App Purchase. Now there’s very little Capacitor discussion on this forum, but a quick search did turn up this which may help you get started: https://capacitorjs.com/docs/guides/in-app-purchases

Apple probably doesn't consider this a bug but I filed FB14378568 anyway. Did you frame it as a bug report, or as a feature suggestion? It’s definitely not a bug, since of course an “undocumented API” is no API at all. But lots of developers probably would concur with a suggestion to add proper APIs for these examples and others. You could call for others to submit their own suggestion feedback and reference your FB number.

Start here: Connect to the Find My network.

Start here: TN3111: iOS Wi-Fi API overview. Especially note this part: iOS does not have a general-purpose API for Wi-Fi scanning and configuration.

Start here: TN3111: iOS Wi-Fi API overview. Especially note this part: iOS does not have a general-purpose API for Wi-Fi scanning and configuration.

btw, why make such a big deal about FlatBuffers in the session video if its strictly an internal implementation detail? I suspect the motivation is found in the transcript here: If you are using the Swift API, this optimization comes for free. While if you use the REST API, it is optional, and you can activate it by specifying an accept header. And here: If you are using the REST API, please consider taking advantage of the new FlatBuffer response. So they are telling REST API users to go grab FlatBuffers from GitHub for whatever platform they are using, while the WeatherKit framework of course remains closed source and just so happens to use FlatBuffers too.

Start here: https://developer.apple.com/bug-reporting/ You can’t remove a forum post (unless there’s some pressing reason such as accidental disclosure of PII) but don’t worry about it.

Hear me out, developers at Apple! This forum isn’t an official channel for suggestions like this, so make sure to also submit a Feedback with your suggestion.

I have one here (model A1701) and can confirm that the iPadOS 18 beta isn’t available. The Settings → General → Software Update → Beta Updates menu does now include the iPadOS 18 Developer Beta option, but it has no effect.

You’ll want to transfer ownership of the app from the old account to the new account; see here for details.

Guessing that you mean some arbitrary other app not developed by your team: there is no API that can give you that information. Unlike on Android, the iOS platform has no APIs to discover what other apps are even installed [*], much less tell you anything about them. That’s example of how the concept of user privacy can differ between the platforms. [*] There’s actually a small crack in the armor with an API called canOpenURL (link) but it’s intended for a limited sort of cross-app integration, not for open-ended discovery of other apps, and tells you nothing about version numbers.

Can MetricKit support collecting these specific metrics at such frequent intervals? Unfortunately that iOS Network Signal Strength post already calls out MetricKit as an approach that won’t help. Note that MXCellularConditionMetric contains only a single property (see histogrammedCellularConditionTime at link) which is basically a crude bar chart of signal strengths aggregated over the 24-hour reporting period. There’s no API to get at the underlying data points or timestamps, and note this metric deals in signal bars rather than actual dBm units. I'm curious about how such an [internal Apple] app might collect data that is otherwise inaccessible through public APIs. Apple’s built-in apps can use whatever private APIs they want, and in many cases the OS has the means to allow access to such APIs by only specific apps (i.e. theirs or carrier apps) that are entitled to do so. For the specific case of accessing low level telephony data, the restriction was added as a security fix way back in iOS version 8.3 or so. So even if you had the secret header files or documentation, the code wouldn’t actually work without your app having that special entitlement which will never be available. is there any leeway or additional tools available for private/internal applications to gather more detailed cellular metrics? Nothing that would be documented by Apple or suitable for discussion on this forum.