The "Last Day" filter in the crashes section of the Xcode Organizer, never has any crashes in it. If we use the "Last Two Weeks" filter, then you can clearly see that we do have crashes every day. They even show crashes for yesterday in the little graph in the "statistics" window. So why dont they show up in the last day filter? Is there some hidden setting we don't have enabled? This also seems related to the fact that the number of crashes from "yesterday" is always incomplete. i.e. waiting another day makes the number go up, implying not all crashes were included in the original number. This means we have to wait two days to get the data from one day ago. Why?

When trying to launch the app through testflight, i'm getting an error popup saying: "MyAppName" Beta Has Expired However, it literally says "Expires in 90 days" in testflight (i made this build yesterday). Only uninstalling the app and reinstalling through testflight fixes the issue. Restarting the phone does not work. This has happened multiple times with different builds and is starting to become an issue. I suspect it might be related to us having many older builds that are expiring due to age, however I've double checked that only the latest non-expired build is the one installed on the device. I also found this other (unsolved) forum post from 3 years ago which seems to describe the same problem. https://developer.apple.com/forums/thread/117035

Hello. In the iOS app i'm working on we are very tight on memory budget and I was looking at ways to reduce our texture memory usage. However I noticed that comparing ASTC8x8 to ASTC12x12, there is no actual difference in allocated memory for most of our textures despite ASTC12x12 having less than half the bpp of 8x8. The difference between the two only becomes apparent for textures 1024x1024 and larger, and even in that case the actual texture data is sometimes only 60% of the allocation size. I understand there must be some alignment and padding going on, but this seems extreme. For an example scene in my app with astc12x12 for most textures there is over a 100mb difference in astc size on disk versus when loaded, so I would love to be able to recover even a portion of that memory. Here is some test code with some measurements i've taken using an iphone 11: for(int i = 0; i < 11; i++) { MTLTextureDescriptor *texDesc = [[MTLTextureDescriptor alloc] init]; texDesc.pixelFormat = MTLPixelFormatASTC_12x12_LDR; int dim = 12; int n = 2 << i; int mips = i+1; texDesc.width = n; texDesc.height = n; texDesc.mipmapLevelCount = mips; texDesc.resourceOptions = MTLResourceStorageModeShared; texDesc.usage = MTLTextureUsageShaderRead; // Calculate the equivalent astc texture size int blocks = 0; if(mips == 1) { blocks = n/dim + (n%dim>0? 1 : 0); blocks *= blocks; } else { for(int j = 0; j < mips; j++) { int a = 2 << j; int cur = a/dim + (a%dim>0? 1 : 0); blocks += cur*cur; } } auto tex = [objCObj newTextureWithDescriptor:texDesc]; printf("%dx%d, mips %d, Astc: %d, Metal: %d\n", n, n, mips, blocks*16, (int)tex.allocatedSize); } MTLPixelFormatASTC_12x12_LDR 128x128, mips 7, Astc: 2768, Metal: 6016 256x256, mips 8, Astc: 10512, Metal: 32768 512x512, mips 9, Astc: 40096, Metal: 98304 1024x1024, mips 10, Astc: 158432, Metal: 262144 128x128, mips 1, Astc: 1936, Metal: 4096 256x256, mips 1, Astc: 7744, Metal: 16384 512x512, mips 1, Astc: 29584, Metal: 65536 1024x1024, mips 1, Astc: 118336, Metal: 147456 MTLPixelFormatASTC_8x8_LDR 128x128, mips 7, Astc: 5488, Metal: 6016 256x256, mips 8, Astc: 21872, Metal: 32768 512x512, mips 9, Astc: 87408, Metal: 98304 1024x1024, mips 10, Astc: 349552, Metal: 360448 128x128, mips 1, Astc: 4096, Metal: 4096 256x256, mips 1, Astc: 16384, Metal: 16384 512x512, mips 1, Astc: 65536, Metal: 65536 1024x1024, mips 1, Astc: 262144, Metal: 262144 I also tried using MTLHeaps (placement and automatic) hoping they might be better, but saw nearly the same numbers. Is there any way to have metal allocate these textures in a more compact way to save on memory?

Xcode 12.4, iOS 14.4 I'm debugging my app's memory footprint and it seems like the allocated sizes for a large number of textures don't make sense with what their actual sizes should be. I found this other post that describes a very similar issue: https://developer.apple.com/forums/thread/668963 For me, the "Textures" section of the gpu frame capture reports 305mb total, but hovering the mouse indicates 8075 resources taking 805mb. Looking at the resources section, I can see a lot of small textures taking up 128kb instead of their normal size. Most of these textures should only be around 1kb to 16kb (32x32 to 128x128 dimensions, various ASTC block sizes, mostly sRGB 12x12). When putting a breakpoint at the newTextureWithDescriptor: call where they are allocated, I can see that the resulting MTLTexture is being allocated out of a "_masterBuffer" that is 128kb, and the image itself has a _masterBufferOffset and a _length that make sense. Eg: _masterBufferIndex = 14, _masterBufferOffset = 30976, _length = 896. However, looking at this exact texture in the frame capture shows an "allocated size" of 128kb. I suspect this inflated amount is being used for the xcode memory gauge, since the app is getting killed when loading into a large level due to memory usage. In the other forum thread, they mentioned a fix was in progress. Are there any updates about that? Otherwise, is there something I can do to make these numbers more sane?

When trying to build a metal library from a shader with the Metal Developer Tools for Windows 1.2 i'm getting the following error: MetalDeveloperTools\ios\bin\metal -c test.metal -o test.air MetalDeveloperTools\ios\bin\metallib test.air -o test.metallib						 																													 LLVM ERROR: Error opening 'MetalDeveloperTools\ios\bin\..\lib\clang\31001.138\lib\darwin\libmetal\_rt\_osx\_air2.2.a': no such file or directory! I noticed that libmetal\_rt\_osx\_air2.2.a is a file in the macos folder, so I tried running the below command and it seems to build with no errors, but haven't had the opportunity to test the library yet. MetalDeveloperTools\macos\bin\metallib test.air -o test.metallib																																														 Is this a bug? Is it okay to mix targets like this?

https://developer.apple.com/metal/ The above page says: Tools for WindowsThe Metal Developer Tools for Windows enables Metal Shading Language (MSL) compilation on Windows into Metal Library Objects targeting Apple platforms. Download now Download now links to https://developer.apple.com/download but the tools are nowhere to be found. Are they even still available? It's been less than a year since they released. Here's another unanswered question asking the same thing: https://developer.apple.com/forums/thread/663620