offloading

We are already done with the initial setup for implementing Push notifications and are able to send/receive notifications successfully.Now, we have been looking for the possible solutions to handle badge count increment from ios app (especially when app is not in foreground) -1. Delegate the badge count calculation to server side. - If we think of offloading the task of badge calculation to app server, then question arises is that, how server side will get to know about the count of viewed notifications so that badge can be decremented accordingly.2. Use UIBackgroundModes and call 'didReceiveRemoteNotification:fetchCompletionHandler' method. - Apple says, this method will get called when my app is either in foreground or background state. With this we should be able to track the count/notification info even when the app is in background & thus it probably enables us to do the necessary calculation in iOS app itself. However, we have noticed that this method doesn't invoke when app is in backgroun

Hey, I’m building a camera app where I am applying real time effects to the view finder. One of those effects is a variable blur, so to improve performance I am scaling down the input image using CIFilter.lanczosScaleTransform(). This works fine and runs at 30FPS, but when running the metal profiler I can see that the scaling transforms use a lot of GPU time, almost as much as the variable blur. Is there a more efficient way to do this? The simplified chain is like this: Scale down viewFinder CVPixelBuffer (CIFilter.lanczosScaleTransform) Scale up depthMap CVPixelBuffer to match viewFinder size (CIFilter.lanczosScaleTransform) Create CIImages from both CVPixelBuffers Apply VariableDepthBlur (CIFilter.maskedVariableBlur) Scale up final image to metal view size (CIFilter.lanczosScaleTransform) Render CIImage to a MTKView using CIRenderDestination From some research, I wonder if scaling the CVPixelBuffer using the accelerate framework would be faster? Also, Instead of scaling the final image, perhaps I could offload

Hi everyone, This project uses PyTorch on an Apple Silicon Mac (M1/M2/etc.), and the goal is to use the MPS backend for GPU acceleration, notes Apple Developer. However, the workflow depends on Float64 (double-precision) floating-point numbers for certain computations, notes PyTorch Forums. The error Cannot convert a MPS Tensor to float64 dtype as the MPS framework doesn't support float64. Please use float32 instead has been encountered, notes GitHub. It seems that the MPS backend doesn't currently support Float64 for direct GPU computation. Questions for the community: Are there any known workarounds or best practices for handling Float64-dependent operations when using the MPS backend with PyTorch? For those working with high-precision tasks on Apple Silicon, what strategies are being used to balance performance with the need for Float64? Offloading to the CPU is an option, and it's of interest to know if there are any specific techniques or libraries within the Apple ecosystem that could streamlin

I have been experimenting with different rendering approaches in Metal and am hitting a wall when it comes to reconciling bindless or GPU-driven approaches* with a dynamic scene where meshes can be added, removed, and changed. All the examples I have found of such approaches use fixed scenes, where all the data is fixed before the first draw call into something like a MeshBuffer that holds all scene geometry in the form of Mesh objects (for instance). While I can assume that recreating a MeshBuffer from scratch each frame would be possible but completely undesirable, and that there may be some clever tricks with pointers to update a MeshBuffer as needed, I would like to know if there is an established or optimal solution to this problem, or if these approaches are simply incompatible with dynamic geometry. Any example projects that do what I am asking that I may have missed would be appreciated, too. * I know these are not the same, but seem to share some common characteristics, namely providing your entire g

I've seen some discussion around performance on the forums but nothing official. What is the best practice for [handleNewFlow:] , [handleOutboundDataFromFlow:], and [handleInboundDataFromFlow:] callbacks in a content filter? Are all flows funneled through a single serial queue that calls into my subclass? If so this seems like we are back in the days of early OS X with the kernel network funnel serializing all network traffic. Should I offload flow processing onto a concurrent queue and then pause the flow and return from my callback? Or just do all processing in the callbacks? And once I return an allow/deny verdict for the flow (without asking for more data) do I no longer see that flow's traffic in my content filter? That's what I would expect and it seems to be the case in actual practice too. For reference I never need to interact with the user. All of the rules are loaded from an EDR platform. I bring this up because we have users complaining of stuttering during Google Meet / Zoom, etc when ou

On my XR, software version 14.7.1 storage reported as being used in Iphone Storage, exceeds the total of all the apps and date being used by them. I added them up twice to make sure (after offloading every apps data), I was throughal. This hasnt always been an issues, just with more recent IOS updates. I phoned and talked to the advanced D&D team at Apple twice and they could not figure it out. Telling me all was good, like I was kind of imagining things. I record alot of educational videos, some videos quite large... after downloading from Icloud to my computer, I delete them, and of course delete all 'recently deleted'. I believe after some time this data is getting corrupted on deletion, and still remains taking up 'app' space. This is a big problem apples programmers need to fix ASAP. The only fix I found was to erase my iphone and restore (a mirror) from a recent backup. Using restore (from backup) in Itunes... the problem is solved. But with all my apps and data back on - a replica of when

File system changes introduced in iOS 17 As part of iOS 17, tvOS 17, and watchOS 10, the system has reorganized where applications and their data containers are stored. In previous systems, both lived within the same volume but, starting in iOS 17, they will be stored on different volumes. What does this mean for you? Copying large amounts of data from the app bundle to a data container will take longer than in previous versions of iOS. Previously that copy would have occurred as an APFS file clone, but now the operation will occur as a standard copy, which may take much significantly longer. Because the data will need to be fully duplicated, storage usage will increase more than was the case in previous versions. You should minimize the data they copy out of their app bundle and avoid any unnecessary duplication of data between the app bundle and data container. When upgrading from previous system version, splitting the data into separate volumes may mean that there is insufficient space for all existing app

I am constantly running out of storage on my iPhone 16 Pro. I keep having to move my photos and videos to my laptop and delete them from my phone, and I’m constantly needing to offload apps and manually clear caches in some apps to free up storage. I finally got sick of having this cycle every two weeks so looked into it more closely. I’m finding that iOS consumes 32 GB, and then another system reserve category is consuming an additional 23 GB. Meaning the system reserved files are consuming half of the storage on this phone and effectively making it a 64 GB model. I understand the system will need to consume some capacity for itself and that iOS is getting larger, but nearly 50% of the capacity of the phone is insane. Looking closer into the categories, I’m seeing that iOS has taken it upon itself to also permanently provision 10% of the storage capacity for reserve update space. Already another instance of “why am I having to lose so much of my functional capacity to an occasional process?” but I c

Hi there, I am working on a 3d game engine in Swift and Metal. Currently I dynamically generate vertex buffers for terrain chunks on the CPU and pass all models to the GPU via argument buffer and make indirect draw calls. Calculating where vertices should be is costly and I would like to offload the work to a compute shader. Setting up the shader was straightforward and I can see that it (at least as an empty function) is being executed in the CommandBuffer. However, I come to this problem: since I do not know ahead of time how many vertices a chunk of terrain will have, I cannot create a correctly-sized MTLBuffer to pass into the compute function to be populated for later use in a draw call. The only solution I could think of is something like the following: For each chunk model, allocate a VertexBuffer and IndexBuffer that will accommodate the maximum possible number of vertices for a chunk. Pass in the empty too-large buffers to the compute function Populate the too-large buffers and set the actua

Hi,I have just started experimenting with Metal. I really just want to offload a few matrix multiplications to the GPU.So, I downloaded this perfectly applicable example code and ran it: https://developer.apple.com/library/ios/samplecode/MetalPartialSumsCompute/Introduction/Intro.html#//apple_ref/doc/uid/TP40015013-Intro-DontLinkElementID_2I can run it on my iphone 6 but there are several issues:It crashes sometimes (EXC_BAD_ACCESS (code=1), and other malloc errors). That's a bit worrying for reference code.It says I am getting approximately 0.04 gflops/sec[sic] using either CPU (Accelerate) or GPU (Metal). I believe I should be getting 3+ GFLOPS from the CPU? (http://www.anandtech.com/show/8554/the-iphone-6-review/3) I'm not sure what to expect from the GPU/Metal but I am assuming a considerably higher number.Here's example output:2015-12-02 14:48:27.772 MetalMatrixMultiply[5477:2056717] >> [12] Matrix Dimensions: A = [1248 x 1137], B = [1137 x 2004], C = [1248 x 2004], lda = 1248, ldb = 2008,