Hi there, I have an app that builds and runs on iOS devices, and also builds and runs in "My Mac (Designed for iPad)" with my m2 mac. But im having issues building it to run in the xcode iOS simulator. We want to build on the simulator so we can test issues that only affect users with previous versions of ios that we dont have on any of our test devices. And we cant downgrade them so sim is our best option. I'm getting this linker error: building for 'iOS-simulator', but linking in object file built for 'iOS' The library it's complaining about we can't rebuild since we dont have the source code. We know that it was built with arm64 and it works with an actual iOS device, AND on m2 mac for ipad. Perhaps this is naiive but why doesnt this just work with the iOS simulator? The arch is the same, it works on a real device, but not the simulator. Is there anything we can do to get it working on the simulator without recompiling the library? Things we've already tried: Using Excluded Architecture x86_64 to make sure we're only building for the arm64 simulator Reading Technote 3117 this didnt help since our architectures already match. Other threads with the same or similar issue: https://developer.apple.com/forums/thread/744276 https://developer.apple.com/forums/thread/716586

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