Sorta odd that we have this option, but no documentation on it, and no one (except Apple engineers) know what it does. I had seen that post - it was the only link I found to the exact text of the title.

I played around with your example. If I add a protocol conformance to Class, it breaks: static id makeObject(Class<sObject> cls) { return [[cls alloc] init]; } It gets a bit more complicated, as there are several initializers for this class: that said, I could add parameters to the function and switch on those to return a properly initialized. However, returning an allocated object works well, as it can be passed to various initializers. Can you comment on why the function above (with the protocol conformance) fails? What to me is so interesting here is that Swift deals with this just fine! I would have expected the converse! David

Part of the code: let queue = DispatchQueue(label: "NetworkManager") ssPathMonitor.start(queue: queue) ssPathMonitor.pathUpdateHandler = { path in DispatchQueue.main.async { let internetWifiAvailableOld = self.internetWifiAvailable let internetCellularAvailableOld = self.internetCellularAvailable let internetEthernetAvailableOld = self.internetEthernetAvailable self.internetWifiAvailable = path.usesInterfaceType(.wifi) self.internetCellularAvailable = path.usesInterfaceType(.cellular) self.internetEthernetAvailable = path.usesInterfaceType(.wiredEthernet) // Log("NetworkManager satisfied:", path.status == .satisfied ? "YES" : "no" , "WIFI:", self.internetWifiAvailable, "CELL:", self.internetCellularAvailable, "ETHERNET:", self.internetEthernetAvailable) let internetWifiChanged = internetWifiAvailableOld != self.internetWifiAvailable let internetCellularChanged = internetCellularAvailableOld != self.internetCellularAvailable let internetEthernetChanged = internetEthernetAvailableOld != self.internetEthernetAvailable In the past I had used Reachability, but no sane person can make sense of the code later on (even the author!). This PathMonitor seemed like a godsend! What I expected to see was changes to multiple interfaces going on: cell -> satisfied: block gets called wifi -> satisfied: block gets called cell -> unsatisfied: block gets called etc. But that doesn't happen - I get notified when a path is available, so in the 3 events above I get the first two, but not the 3rd - I don't get "unsatisfied" if there is a path. I recall that if both are unavailable (AirPlane mode), at least the last "satisfied". Perhaps I should have multiple monitors going - one for each of cell, wifi, and wired. Even then I'm skeptical of whether I'll get told when one goes down, but maybe that is unwarranted. I know of all the arguments against doing this, and we should just kick off the network no matter. The reality is that the designers of the app I use have you go down a deep hole to do something if it's up, and if network is unreachable it doesn't even try. Just ignoring status at the moment would wreck havoc with the user base. Because we allow massive data to flow in either direction, we also condition on cellular - but I believe most users don't disable cellular data, so its not been an issue (in the past they might have). My recollection is that I could maintain separate states for cell, wifi, and wired using Reachability. If I have three NSPathMonitors for each, will I then get a real status for each? Thanks!!!

The original host name is incorrect. User error.

Update: I've been running the app in Xcode for quite some time now, switching between newer and older versions of the code, and Core Data seems perfectly happy in accepting a "newer" repository and "downgrading" it to an older revision. I have never seen anything on this topic, but I guess the geniuses that developed Core Data anticipated this case! It sure has made my life easier!

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.

Well, I didn't state ir correctly. I ask Apple to approve 1.1.1 and they do. I then click "Release with slow rollout". Then, before they do that, they push 1.1.0 to every device that isn't on it, only then start rolling out 1.1.1. However, now I typed it all out - it does seem impossible. I guess I need to cut back on my drug use... That said, so the moment 1.1.1 is released, I have lots of users on 1.0.0 and a few on 1.1.0. All users candidates for 1.1.1 slow rollout?

Well someone must have reported this earlier, I just downloaded and tried Xcode 15.1 Beta, and it fixes the issue.

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.

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.

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] ...

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).