My provisioning profile had expired (but was automatically managed so I didn't notice). Cleaning alone was not enough, re-opening (as you suggested) was also required. Thanks!
jpangburn
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
I had that exact same error but it was because I was trying to add Core Data to an existing project with Xcode 12 beta, so I had copied the Persistence.swift file from a test project I'd make that started out with Core Data.
In my case I was getting that same error:
Fatal error: UnsafeRawBufferPointer with negative count because I hadn't modified this line in Persistence.swift:
container = NSPersistentContainer(name: "HWSCoreDataProject")
Took a while to figure out until I'd commented about everything else :-) but that needs to match the name of your ".xcdatamodeld" file. I thought it was just a name to distinguish containers if you had multiple or something, but apparently not. For example, if your core data model file is "HWSFriendsChallenge.xcdatamodeld" then that line better be:
container = NSPersistentContainer(name: "HWSFriendsChallenge")
It really is super annoying. I guess it's Apple and Google's little game to annoy people who use both companies. Apple is like "Too bad Google Fi sucks with iPhone, maybe you should use some other carrier" and Google is like "Too bad iPhone sucks with your Google Fi, probably should be using an Android".
I imagine Apple could fix it by not clearing those fields on literally every iOS update, and probably Google could fix it because why doesn't this happen on other carriers?
You run into this on microcontroller based "web servers" because you're not really running a proper web server following the HTTP protocol- you're just returning your HTML content directly on the socket. Ask me how I know :-) Ran into the same problem on the Raspberry Pi Pico W.
Anyway, how do you fix this? I did the following (the client variable is the open socket you're writing back on):
html = "Your HTML code or generator goes here, along with your javascript that isn't working"
client.send("HTTP/1.1 200 OK\r\nContent-Type: text/html\r\n\r\n")
client.send(html)
client.close()
That's about the bare minimum you need to pretend to be following the HTTP protocol. Then Safari won't put your webpage in its sandbox.