Post not yet marked as solved
Quinn,
Well that was sort of ******-in-cheek! I didn't really think they had gone away, but perhaps behavior had changed. Our issue is just so bizarre.
In he end I pulled out an old Mac running Montery, loaded Xcode 14.2, and build the much older version of the app for which there had been no memory complaints.
When I build the above app, I got the same result!
So something in our backend objects increased the size - who knows what at the moment.
What confounded the issue is we had one complaint with the new app, then we started getting an avalanche of them - and we had (to our knowledge) not changed anything!
Murphy at it again!
David
In the end I wrote some code that grabbed the last file modification date just before the end context, then immediately after, and once very 0.1 seconds for a minute. It never changed from the second read (immediately after the EndPDFContext).
I ran a slew of tests using different files being created, some tens of megabytes.
Thus I infer that the file is not modified after UIGraphicsEndPDFContext.
Post not yet marked as solved
Well someone must have reported this earlier, I just downloaded and tried Xcode 15.1 Beta, and it fixes the issue.
Post not yet marked as solved
Too late to edit it. This has got to be an "ibtool" problem. There are two custom fonts in the storyboard (actually 2 variations of each). There is a plist generated by ibtool in the bundle, and the order of these custom fonts differs between Xcode 14 and 15. Try as I might, I can't get that tool to create human readable nibs or even XML ones - always binary.
Post not yet marked as solved
Well hit this problem again at a new job. Cannot run app on Simulator because a binary .a from a 3rd party won't link. Sigh. And nothing from Apple :-(
I wrote this 6 years ago! I don't know if this was a static property or an ivar. I just did a search on my compute, I can't find a reference to "regExTrimSet" so that code is either archived or deleted. Guessing I just removed the lazy but unsure at this point.
Post not yet marked as solved
Just to be clear, as J-NIC wrote in a comment, adding additional classes to the unarchiver is what worked for me. In my case I just needed to add NSString:
let mySpecialObject = try? NSKeyedUnarchiver.unarchivedObject(ofClasses:[MySpecialClass.self, NSString.self] ...
Post not yet marked as solved
I just got this error and I'm on Version 13.2 (13C90)
So in the end it turned out that "Local Network" in Settings was off. But everything else the app does on the local network was operational (HTTP, etc). We were experimenting a while ago with techniques to try and detect if that setting was on or off (it does not appear there is any straightforward way to make that determination), and I must have left the toggle off. Sigh. But Quinn, thanks for the link above - it was very enlightening (even though we seem to have had everything defined properly).
Post not yet marked as solved
@robnapier - I never completed this - a job came up and I never swung back. It was/is for one of my open source projects. Like you 3rd party binary.
FB8335267
A second idea, again probably flawed. I see that APFS supports file "clones", that when first created allows one file to be a clone of another. From then on, edits to the cloned file will change the area modified, but leave much of the file the same.
The big question: how to "trim" leading bytes from the clone, while leaving the rest of the file pointing to the original. My guess is this is impossible, but maybe not - comments?
David
To anyone else reading this: its not obvious, just click on your profile to the left of the Edit button - don't hit the edit button. Took me a while to figure that out.
So I was going to post this question again, when I saw I already had done so 2 years ago!I poked around today and sort of answered my own question. The Network framework has this NWPathMonitor - it gives you notification when things change - WIFI state changes, celllular, even more.But what really helps if that you can find out if you can reach the "real" internet. You can probe if there is an active DNS and gateway(s).This is exactly what I had been looking for. Its not pinging the target host, but I now believe its as good as Reachability if not better (I understand Reachability is just confirming it can access the desired host entry in a DNS)What really cleared this up for me was an article written by Ross Butler : "Detecting Internet Access on iOS 12+". He also talks about how to use this framework to detect "Captive Portals" too.PS: my situation today is that the iOS device running my app will switch between internet wifi and a local hardware device. The above works perfect to know what the connection is!
I finally tracked the problem down. A framework Bugsee installed a video monitor in a displayLink. It probably got frames and then released them immediately, but the memory trashing took Instruments down. When I disabled most of Bugsee features relating to video/screen capture, this problem went away.
Combine is Apple proprietary, so I didn't think it appropriate (but did see another one there).Done: forums.swift.org / t / need-help-using-combine-demand-back-pressure / 35015
