file uri scheme

@bradpriddy Thank you for the post and the link to the code, this is really good with a great description as well as the comprehensive list of devices where the device fails to receive a push-to-start token. I believe is a bug however, regrettably, I am not an expert in the APN start token and update token. However, I believe the most expedient course of action, to resolve the issue is to submit a bug report with a zip file containing the code you have provided and a concise summary of the problem. Once you open the bug report, please post the FB number here for my reference. If you have any questions about filing a bug report, take a look at Bug Reporting: How and Why? Albert Pascual
  Worldwide Developer Relations.

I'm glad I found this thread because we're experiencing exactly the same thing. We're uploading a large-ish (hundreds of MB) file to AWS S3 and using a BGContinuedProcessingTask to show the progress. The actual upload happens in the background using the AWS S3 SDK. Everything goes fine until we lock the screen, then the BGContinuedProcessingTask is expired even though the upload is still ongoing. Is there any resolution on the horizon for this issue? Would it help if I file a Feedback Assistant report or can I join an existing one?

Hello I'm wrapping my head around on how to properly set up xcode project to produce a static library Why? file locations /usr/local/lib/libXXX.a and /usr/local/include/XXX/xxx.h so it can be used Unix style in other projects That's not really the way that macOS works. I could write an old style Makefile and have xcode call the makefile but there must be an easier way to do this. What's wrong with a makefile? Xcode is designed to build iOS apps. There is no easy way to make it build open-source style archives and headers. And why should there be? Any open source project would be using standard tools to do this kind of thing. They would never, ever use Xcode. This is for a cross platform development so having it packaged into a Framework would not solve it neither. The Mac and Xcode are not useful for cross-platform development. Just use whatever standard tools fit your technical and social requirements - autotools, CMake, Google-build-engine-du-jour, whatever. Now if you wanted to build an app with a

UPDATE: Nevermind, the feature to view the files in read-only mode is there, I just encountered an issue with the way the project in question was modularized and how the swift-openapi-generator was configured.

The redirect is used to work around the problem described above. Actually, the presence of the file at /.well-known/apple-app-site-association is irrelevant. The core issue described in the previous message is that the system does not even attempt to fetch the AASA from Apple's server, even though it exists here: https://app-site-association.cdn-apple.com/a/v1/xn--montral-fya.ca. But this is also irrelevant because the system blocks AASA requests for domains in Punycode. What I want to say is that the expected behavior is this: I specify Associated Domains. When the app is installed, a request for the AASA is made to Apple's CDN. This request might result in an error or return a valid file. For us, this is unimportant because the request is not being made at all. Another small clarification: when I specify non-existent domains like xnmontral-fya.ca, I can see via proxying that the system does try to fetch the AASA. However, if I specify any string containing the xn-- prefix (denoting a Punyc

I have filed a bug report to Apple: FB21144039

We did follow the debugging guide. The issue here is to understand why it works correctly the first time, meaning that the Apple-app-site-association files and associated domains are configured correctly, and not the second time while remaining on the same tab. We need help understanding what the security difference is between the first invocation and second knowing that it is the exact same website executed and javascript code executed on both attempts.

UPDATE: I finally found the solution. Looks like there is a so-called CoreSmartPowerNap feature that keeps waking the system up for Maintenance despite the user having turned off Power nap in Setting. Disabling this feature stoped the hourly dark wakes. The problem is, there is no user setting to disable it (for whatever weird reason), so it needs to be disabled using a user preference file that overrides the system preferences. Find the file powerd.plist under /System/Library/FeatureFlags/Domain and copy its contents Create a powerd.plist under /Library/Preferences/FeatureFlags/Domain with the contents above, but change the Enabled key for CoreSmartPowerNap to false Voilá... no more hourly dark wakes and your Mac will sleep like a baby until you wake it up manually :)

I'm assuming you want the IDR info in decode order rather than presentation order. This makes a difference if your movie contains bidirectionally predicted frames. If your H.264 video file is a QuickTime movie, you can do something like this: func getSyncInfo(url: URL) -> [Bool] { var idrInfo = [Bool]() let asset = AVURLAsset(url: url) guard let reader = try? AVAssetReader(asset: asset) else { return idrInfo } let videoTrack = asset.tracks(withMediaType: AVMediaType.video).first! guard let cursor = videoTrack.makeSampleCursorAtFirstSampleInDecodeOrder() else { return idrInfo } repeat { let syncInfo = cursor.currentSampleSyncInfo idrInfo.append(syncInfo.sampleIsFullSync.boolValue ? true : false) } while cursor.stepInDecodeOrder(byCount: 1) == 1 return idrInfo } This is unlikely, but if the CMSampleBuffer contains an access unit of a raw Annex B bitstream, then you have to: Get the raw data bytes from the CMBlockBuffers Remove encapsulation prevention bytes Search for start codes the look like 0x00