On this page: https://developer.apple.com/documentation/storekit/testing-age-assurance-in-sandbox It says: Start with a Sandbox account. What is a Sandbox account and how does one set one up? Just it just simply mean an Apple account id used for testing, or something else?

In the summary documentation about the declared Age Range API:https://developer.apple.com/news/?id=2ezb6jhj It states: "The API will also return a signal from the user’s device about the method of age assurance, such as credit card or government ID" But if the api itself, and its documentation is examined, there is no such mechanism nor mention of it: https://developer.apple.com/documentation/declaredagerange/agerangeservice So my question is, is the first documentation incorrect, if not, then where and how to access the method of age assurance?

I'm working on an out-sourced application for a company and when a version of it built using ids and provisioning profiles from my Apple account it runs without problems. However when it is built and run using the company's ids and provisioning profiles I am seeing an issue with it. What is happening is when a notification service extension uses a call extension then the OS logs: doQueryCallExtensionStatusWithDispatchGroup() COMPLETED WITH ERROR: Error Domain=NSCocoaErrorDomain Code=4099 "The connection to service named com.apple.CallKit.CallDirectory was invalidated: failed at lookup with error 159 - Sandbox restriction." UserInfo= NSDebugDescription=The connection to service named com.apple.CallKit.CallDirectory was invalidated: failed at lookup with error 159 - Sandbox restriction. I noticed that in the company's provising profile for the notification service extension the app identier prefix is different from the team identifer. In my own provisioning profile the app identifier prefix and team identifer are the same. Could it be the case that this difference in identifiers within the provisioning profile is leading to the sandbox error message? Attached is the notification service extension provisioning profle provided to me by the company (converted to a .plist for readability)

I've added a background downloads extension to my app and added device console logging to every method in the placeholder code created by XCode, then installed the app to the phone. When I run the following command: xcrun backgroundassets-debug --app-bundle-id com.myCompany.myApp  --device-id 00008110-001E0DDA0AB8801E --simulate --app-update  and watch the console log - there's none of my logging from within the extension. In the OS log I can see this: error 11:24:41.550702-0700 backgroundassets.user Event (1) dropped for client () failed because client Info dictionary is missing its 'BAManifestURL' key. The template generated code says this: "The manifest that is downloaded is determined by BAManifestURL defined in the application's Info.plist" So I tried adding a key of BAManifestURL with a url hoping to initially just get the extension launching. But I still get the error saying the info dictionary is missing the BAManifestURL key. So exactly how should the BAManifestURL key value pair be added to the info.plist?

I've added a background asset extension and am trying to invoke it using this: xcrun backgroundassets-debug --app-bundle-id com.myCompany.myApp  --device-id 00008120-000225060C9B401E --simulate --app-update  When I run that command I see this in the phone's log: Unable to observe extension for (com.cequint.myapp), the BAApplicationInfo is missing an extensionIdentity. So how should an extension identify be added? The extension's info.plist is as created by the Xcode template: <key>EXAppExtensionAttributes</key> <dict> <key>EXExtensionPointIdentifier</key> <string>com.apple.background-asset-downloader-extension</string> </dict> And I've added the following to the app's info.plist: > <dict> <key>BGTaskSchedulerPermittedIdentifiers</key> <array> <string>kBackgroundTaskIdIdentifier_RNScheduleAppRunEvent</string> </array>   <key>BAMaxInstallSize</key>   <integer>3221225472</integer>   <key>BAInitialDownloadRestrictions</key>   <dict>          <key>BADownloadDomainAllowList</key>          <array>                 <string>*.drive.google.com</string>          </array>          <key>BADownloadAllowance</key>          <integer>2147483648</integer>   </dict> <key>BAManifestURL</key> <string>https://drive.google.com/file/d/1doJtzxBKCoVHEF80sndK6VskCrkD9H9r/view?usp=sharing</string> What else needs doing to provide the extension identifier the OS is saying is missing? (Using Xcode 14.1 and iOS 16.2)

Apple this is dead easy and quick to reproduce. Just create an app and then add a target of type background download. Xcode automatically assigns a group id to the target and generates a corresponding entitlements file like so: However the extension will not build, there is this error: You can bugger about in the developer portal as long as you want, ensuring the group identifier exists, ensuring provisioning profiles have this group capability, etc. etc. nothing will make this error go away. Now, what is unique about the download extension's entitlements file is the com.apple.developer.team-identifier key. This does not get generated for other extension - go ahead and see for yourself, create an action extension and give it a group, the result is its group appears in the entitlements file but not this com.apple.developer.team-identifier. If you try to print out $(TeamIdentifierPrefix) (via echoing it in a build script), you get this /Users/me/Library/Developer/Xcode/DerivedData/experiments-clpwbtcvdpqwuodxzwmsxwpztguo/Build/Intermediates.noindex/experiments.build/Debug-iphoneos/backgroundDownloadExtension.build/Script-243C9904292461BC001FDE14.sh: line 4: TeamIdentifierPrefix: command not found Hmm, command not found, but if you change the echo to ${TeamIdentifierPrefix} guess what gets printed, yes the team identifier i.e. in my case MV8J9D3236. Now if in the entitlements file I add the team identifier explicitly, like so Then magically the error about automatic signing and the provisioning profile goes away. Change it back to $(TeamIdentifierPrefix) and the error appears, change it to be explicit and it goes away. So by tweaking the entitlements file its possible to get the extension to build, however all is not well, now that it builds, if the extension is installed and run, the OS says: "Event (1) dropped for client (com.company.experiments) failed because the app and extension do not share any application groups." It says that despite the fact the app and extension both do have the same group capability. This is driving me nuts - the auto generated entitlements file is stopping the extension from compiling, but if you fix the build, it can't run. (Xcode 14.1, iOS 16.2)

If the code below is run it causes an exception 'NSInvalidArgumentException', reason: '-[__NSCFType set]: unrecognized selector sent to instance 0x283130be0' However, the exception can be removed by reducing the width value from 100.0 in positionRect, for example setting it to something like 50.0 removes the exception. But why is this? With a width value of 100.0 specified for positionRect, that's well short of the width of imageSize. And even if there is some size issue, why is there an unrecognized selector exception? let imageSize = CGSize(width: 400, height: 100) let testRenderer = UIGraphicsImageRenderer(size: imageSize) let testImage = testRenderer.image { context in context.cgContext.setFillColor(UIColor.black.cgColor) context.fill(CGRect(origin: .zero, size: imageSize)) let paragraphStyle = NSMutableParagraphStyle() paragraphStyle.alignment = .left let attributes: [NSAttributedString.Key: Any] = [ .font: UIFont.systemFont(ofSize: 8.0), .paragraphStyle: paragraphStyle, .foregroundColor: UIColor.white.cgColor ] let attributedString = NSAttributedString(string: "This is some text", attributes: attributes) let positionRect = CGRect(x: 10, y: 10, width: 100.0, height: 8.0) attributedString.draw(with: positionRect, options: .usesLineFragmentOrigin, context: nil) }

I've been successfully using CXProvider.reportNewIncomingVoIPPushPayload() as follows: a (non VoIP) push is sent to the handset this is intercepted by a notification service extension the extension calls CXProvider.reportNewIncomingVoIPPushPayload() (the extension has the required com.apple.developer.usernotifications.filtering entitlement) this results in the app delegate's implementation of PKPushRegistryDelegate:didReceiveIncomingPushWithPayload getting called (the app is launched if terminated) This all works as expected, in particular when the app is terminated it still works. However its suddenly stopped working since my phone got updated to iOS 16.6 (I can't remember exactly what was on it previously, 16.5 or 16.4). Now with iOS 16.6 the behavior is that PKPushRegistryDelegate:didReceiveIncomingPushWithPayload() only gets called if the app is not terminated. If the app is terminated then calling CXProvider.reportNewIncomingVoIPPushPayload() results in the app getting launched and didFinishLaunchingWithOptions() getting called BUT didReceiveIncomingPushWithPayload() is not called when launching from a terminated state. As a consequence of didReceiveIncomingPushWithPayload() not getting called, the app isn't calling reportNewIncomingCallWithUUID() and so after a few runs the OS stops launching the app entirely saying: "Application will not be launched because it failed to report an incoming call too many times". When didFinishLaunchingWithOptions() is called the launchOptions are nil, i.e. there is no way to distinguish the app from being launched as a consequence of reportNewIncomingVoIPPushPayload()(*) being called and therefore it is not possible to call reportNewIncomingCallWithUUID(). So this feature is totally broken apparently from previous behavior. Any comment? TIA (*)Well actually, the extension could write a flag to a shared group and the app read that on launch, but what a hack, and should be unnecessary.

Our app has some Crashlytics & Localytics reporting to collect metrics for diagnostic and info gathering. One thing I'm noticing recently is that if a user has version m of the app installed and updates to version m+1, then for some users, the app has detected and reported that the push token obtained with version m+1 is different from that of version m (for the same handset). That's fine - if the app has detected the change to the token it can send the new one to the server so the server can update. But my question is - if the user didn't explicitly launch the app and thus present the app with the chance to send the new token to the server, then what will happen to the pushes sent by the server using the old token? Presumably they won't get delivered if the token has changed, but if the user has no need to launch the app then they're never going to receive any pushes from the server until they do launch the app. However there's not necessarily any reason why a user should repeatedly launch an app once it's been set up (depending upon what it does and how it delivers info to the user and how the user interacts with it, there's no reason why a user should have to launch the app after initial installation and launch). If so then this seems like a gap in the design of push notifications? If they can change on the same handset, or another scenario is the user backs up their device to iCloud and then restores to a different handset, then in that case the push tokens will have definitely changed, yet any apps using push don't get the chance to send the new token to the server until the user launches the app, meanwhile all pushes from the server will be dropped.

I don't follow the section in the wwdv video on http3 https://developer.apple.com/videos/play/wwdc2021/10094/ From about 07.00 onwards for a couple of minutes, the presenter says URLSession won't use http3 unless the server advertises it. Then he uses instruments to show the app is using http2 - BUT the server is advertising http3. Then he says the fact the server advertised http3 will be remembered for future sessions. Why does the app use http2 for the first session even though the server advertised http3? Does that mean the first time any app connects to a http3 server it'll actually be http2 and only http3 for subsequent connections?

I've got an app which has a notification service extension (and has had so for a few years). I noticed that the pushes were getting delivered directly to the user for a handset, and in the log could see a SpringBoard error saying Error Domain=PluginKit Code=4 RBSLanchRequest error trying to launch plugin Error Domain=RBSRequestErrorDomain Code=5 Launch failed ErrorDomain=NSPOSIXErrorDomain Code=111 Unknown error:111 I rebooted the phone and it started working as expected. But it's worrisome this happened, and it's not the first time I've seen it either. Observed with iOS 17.3.1

We have an app which is using CTSubscriber.simInserted (using the carrier entitlement com.apple.CommCenter.fine-grained). In iOS 18, simInserted returns false for every sim (where it should instead be returning true). Presumably this just is a temporary bug in 18 beta?

I'm getting Sandbox:rsync.samba deny errors trying to build an app using Xcode 16 betas. There's lots of info on this on google, and the solution everybody used to fix it is to change the Xcode build setting User Script Sandboxing from NO to YES. However this doesn't exist with Xcode 16. Does it have a replacement?

If an app has a Live Caller ID Lookup extension and the lookup server indicates that a caller is identified and not blocked, then if the user wished to locally block that number they can do so either via the iPhone call block button, or via the app's Call Extension block list. However there's apparently no way for the user to do the inverse. i.e. if Live Caller Id Lookup indicated that a number should be blocked, then how could a user indicate they don't want that number blocked for them? If they added it to the Call Extension as an identified number, but live lookup is saying the number should be blocked, then what does the OS do? Give priority to the blocking instruction from the live lookup server, or give priority to the fact its in the Call Extension's Identified list?

I've followed the instructions to configure and launch a live caller id test service (https://swiftpackageindex.com/apple/live-caller-id-lookup-example/main/documentation/pirservice/testinginstructions) i.e. I've constructed a database, built and installed the PIRService etc. Additionally I have created a test app with a Live Caller ID Extension. The problem I'm facing is when turning on the Live Caller ID feature on an iPhone (the Settings|Apps|Phone|Call Blocking & Identification|Live CallerID Lookup switch) with iOS 18 Beta 4 is the phone logs: "The request timed out." UserInfo={NSLocalizedDescription=The request timed out., NSErrorFailingURLKey=http://MacBook-Pro.local:8080/.well-known/private-token-issuer-directory The configuration notes say: "When running things locally on your Mac, and your testing device is on the same network, then you can use mDNS to let the device find your Mac. Let’s assume that your Mac’s hostname is Tims-MacBook-Pro.local. Then we should use the following value for the URLs: http://Tims-Macbook-Pro.local:8080. Thanks to the mDNS protocol your device should be able to resolve your hostname to the actual IP address of your Mac and make the connection." My Mac hostname is "MacBook-Pro" therefore the Live Caller ID Extension is configured as: LiveCallerIDLookupExtensionContext( serviceURL: URL(string: "http://MacBook-Pro.local:8080")!, tokenIssuerURL: URL(string: "http://MacBook-Pro.local:8080")!, userTierToken: Data(base64Encoded: "BBBB")! ) And the service-config.json is configured as: { "issuerRequestUri": "http://MacBook-Pro.local:8080", "users": [ <snip> (I've also tried excluding the issuerRequestUri as the instructions say "This value can be omitted from the configuration. Setting this explicitly will not be required for devices using iOS 18.0 beta 4 or later.") And the PIR Service is started on the Mac as: PIRService --hostname 0.0.0.0 service-config.json And it starts and runs. The iPhone and Mac are on the same Wifi network and connected by usb cable. As far as I can tell, everything has been set up in accordance with the Testing Live Caller ID instructions, yet I get the error when attempting to enable the extension on the iPhone. Is there something missing/incorrectly configured?