“file uri scheme”

Not all the Map app settings are surfaced in the URL scheme so please file a bug report asking for this feature. I know it's not what you're looking for but does dirflg=w give you an appoximation of what you want to see? -M

Ah. Correct, we only support /v1 prefixes at the moment. Please file a feedback request so we can bump the priority on this. As an alternative, you could have a local service act as a passthrough so you can make that service implement /v1 and then bounce to your other URL scheme from there.

Geting Xcode to recognise your source editor extension can be tricky. There are two cases to consider: Debugging Production I recommend you start with the debugging case. When you create a new source editor extension target, Xcode create a scheme for it. That scheme isn’t very useful out of the box. Do this: Use your primary copy of Xcode for this work. Ideally it’d be the one in the Applications folder. Select the extension scheme in Product > Scheme. Choose Product > Scheme > Edit Scheme. In the Run action, switch to the Info tab. On the Executable popup, choose Other and select your primary copy of Xcode. Make sure Debug Executable is not checked. Close the sheet and then choose Product > Run. Xcode should launch a second copy of itself. In the Dock, you’ll see the icon with an orangey tint. Bring that to the front. In this copy, open a test project and navigate to a source file. Your extension should be visible at the bottom of the

Did you try making sure that the redirect uri has https:// in front of it? I was stuck with this same issue until I came across this post https://forums.developer.apple.com/thread/130197. Now, the popup is closing, and I'm getting the DOM events to fire. 😅

Select the phone scheme first, then select the watch scheme.

Are you trying to submit the archive build using the Watch scheme or the iOS scheme?

I have a ton of issues Importing and Exporting Localisation files, and have burnt too many evenings ! I usually resort to the XCode command line , that seems pretty reliable .... I do a clean build maybe -SkipMacroValidation helps I cant recall ! /usr/bin/xcodebuild -sdk iphoneos -skipMacroValidation -configuration Debug -workspace my.xcworkspace -scheme myScheme build CODE_SIGNING_ALLOWED=NO Then an Import or export /usr/bin/xcodebuild -sdk iphoneos -configuration Release -workspace my.xcworkspace -scheme myScheme -importLocalizations -localizationPath path-to/my.xcloc CODE_SIGNING_ALLOWED=NO

This would appear to be a content authoring issue or .m3u8 playlist issue. For debugging purposes only, to determine if it is a content authoring issue we recommend you set your EXT-X-KEY tag KEYFORMAT attribute in the .m3u8 playlist to identity instead of com.apple.streamingkeydelivery, add the initialization vector (IV) of the key you are using to the IV attribute, and set the URI attribute to an http URL pointing to a (16-byte) resource containing only the raw, unencrypted AES key. For example, instead of something like this:#EXT-X-KEY:METHOD=SAMPLE-AES,URI=skd://key67,KEYFORMAT=com.apple.streamingkeydelivery,KEYFORMATVERSIONS=1do something like this:#EXT-X-KEY:METHOD=SAMPLE-AES,URI=http://mysite.com/my16ByteKey.bin,KEYFORMAT=identity,IV=0xA30FE123ECBF1BE323A775A119C553BCand make your 16-byte key available on your mysite.com web server.This allows the client to receive the same content, but instead of decrypting it with FairPlay Streaming it decrypts it with a clear text AES key

Thank you for explaining. We discussed your case here and we recommend doing an archive build and then copying the app out of the archive. We expect this will give you the best results using code paths that are currently supported. You can copy the app out of the .xarchive by changing the file name ending from .xarchive to .zip. Then you can open the .zip file and copy the app into the Applications folder. Note ~ Searching on the web I found some folks talking about duplicating the run Scheme and changing the Build Configuration to Release and using the result from that. That may work in some cases, but it may not produce correct results in others. This is not a supported code path. We do not recommend using this duplicate Scheme approach.

It appears to be centered around the usage of a custom scheme in the HLS m3u8 file link to the encryption key: if I use http(s) to link the encryption key, it works fine. If I use something custom like fakey, it never even makes it to the delegate method for AVAssetResourceLoaderDelegate called resourceLoader(_ resourceLoader: AVAssetResourceLoader, shouldWaitForLoadingOfRequestedResource loadingRequest: AVAssetResourceLoadingRequest) where I'd swap out the scheme for a real one, because it crashes first. So far, I can only replicate this on the iOS 15 simulator. I've opened a feedback: FB9764319