Post

Replies

Boosts

Views

Activity

Xcode producing corrupt build
I'm experiencing 100% reproducible bug with Xcode. It took me days to figure it out. After many tears shed. Xcode is producing a corrupt binary. It seems like my metal buffers are being mis-aligned or something. The problem showed up after changing the Deployment to iOS 15. It had been at iOS 13 and built and ran without any related issues - for years that I've been developing this app. So at some point after changing the target to iOS 15, compiling the shaders went from about 0.001 seconds to 30 seconds. When that happens, the GPU will also hang with the messages: GPUDebug] Invalid device load executing kernel function "computeArtPointsToRender" encoder: "0", dispatch: 0, at offset 22080048 Shaders.metal:1290:41 - computeArtPointsToRender() To fix the issue, I have to change the build target to iOS 13, clean, build, change to iOS 15, clean, build and then works again as expected (until it doesn't at some random point or until I have restarted the machine). This is 100% reproducible: Restart mac Build project Issue occurs Change build target to iOS 13 Clean build folder Build Change build target to iOS 15 Delete derived files Build Works as expected Xcode: Version 13.1 (13A1030d) macOS: 11.5.2 (20G95) Mac mini (M1, 2020) In my 11+ years as a full time iOS developer, I've never encountered such a serious issue with Xcode. If I don't have stable tools, it is impossible for me to develop.
3
0
2.2k
Nov ’21
Copying/moving multi-gigabyte images with NSFileCoordinator
My app is capable of writing multi-gigabyte images. I need a way to allow the user to do something with the full-resolution images (such as AirDrop). It does not appear possible to write the image to Photos since there may not be enough memory to read the whole image in RAM and as far as I can tell PhotoKit allows readonly access. With UIActivityViewController I am able to copy the large images with a NSFileCoordinator, but only if I use an extension of .zip or .bin for the destination URL. The file is copied, but macOS thinks they are archives and not an image. After the file has been copied, changing the extension to .jpg on the Mac allows the copied image to be used, but that is less than an ideal user experience. Zipping the image (that is already compressed) is not a viable solution since the whole image would need to be read to zip it, which may exceed the amount of memory available. Not to mention it is a total waste of time/power consumption. How can I allow a user to copy multi-gigabyte images from my app, and ideally with UIActivityViewController? Here is the code that allows the image to be copied. If I don't use .zip or .bin for the destination URL, the image isn't copied, nothing happens, no errors reported. func copyImage() { let fm = FileManager.default var archiveUrl: URL? var error: NSError? let imageProductURL = TDTDeviceUtilites.getDocumentUrl( forFileName: "hugeImage.jpg") let coordinator = NSFileCoordinator() coordinator.coordinate(readingItemAt: imageProductURL, options: [.forUploading], error: &error) { (zipUrl) in let tmpUrl = try! fm.url( for: .itemReplacementDirectory, in: .userDomainMask, appropriateFor: zipUrl, create: true ).appendingPathComponent("hugeImage.jpg.zip") try! fm.moveItem(at: zipUrl, to: tmpUrl) archiveUrl = tmpUrl } if let url = archiveUrl { let avc = UIActivityViewController(activityItems: [url], applicationActivities: nil) present(avc, animated: true) } else { print(error) } }
3
0
1.2k
Jul ’22
CoreML not using Neural Engine even though it should
When I run the performance test on a CoreML model, it shows predictions are 834% faster running on the Neural Engine as it is on the GPU. It also shows, that 100% of the model can run on the Neural Engine: GPU only: But when I set the compute units to all: let config = MLModelConfiguration() config.computeUnits = .all and profile, it shows that the neural engine isn’t used at all. Well, other than loading the model which takes 25 seconds when allowed to use the neural engine versus less than a second when not allowing the neural engine: The difference in speed is the difference between the app being too slow to even release versus quite reasonable performance. I have a lot of work invested in this, so I am really hoping that I can get it to run on the Neural Engine. Why isn't it actually running on the Neural Engine when it shows that it is supported and I have the compute unit set to run on the Neural Engine?
3
3
3.4k
May ’23
MapKit super slow loading tiles stored on device
Loading tile overlays is slow even when the raster data is locally available on the device running iOS 18.2 and built with Xcode 16.2. In this video (https://3dtopo.com/superSlowTileLoading.mov) it takes 38 seconds to load tiles readily available on the device. Then, the whole screen flashes when tiles that are already drawn are redrawn, making for a very poor user experience. 38 seconds to load a dozen or so small images (512x512) stored locally on the device is simply unacceptable. I can't release a product like this that I've spent the last 1.5 years building and many years developing the maps themselves. This severe issue is new since I committed to basing my app on MapKit. Note that this issue does not occur with Apple's base map tiles. I created a Feedback Assitant case, FB16110803, for this issue. For the video, I disabled loading any tiles from the network and disabled loading any other data, such as polylines. Essentially all I am doing is loading the tiles stored on the device and returning them, such as: public func loadTile(at path: MKTileOverlayPath, result: @escaping (Data?, Error?) -> Void) { fetchData(forKey: key, failure: {error in result(nil, error)}, success: {data in result(data, nil)}) } open func fetchData(forKey key: String, failure fail: ((Error?) -> ())? = nil, success succeed: @escaping (Data) -> ()) { let path = self.path(forKey: key) do { let data = try Data( contentsOf: URL(fileURLWithPath: path), options: Data.ReadingOptions()) succeed(data) self.updateDiskAccessDate(atPath: path) } catch { if let block = fail { block(error) } } }
6
0
801
Dec ’24