There’s many ways you can approach this. At a surface level I thought plucky was doing DNS & HTTP filtering by acting as a proxy. But on closer look, it looks to be implemented as a browser plugin. For subdomain/domain filtering, you can look at implementing content blocking in a safari extension: https://developer.apple.com/documentation/safariservices/creating_a_content_blocker To implement the HTML content blocking stuff, you’d probably want to look into DOM rewriting within the safari extension. At least it all seems pretty straight forward to implement.

Put both views in a Pager view? Then add some condition for displaying the second view after validating the form contents in the first view.

Modern sites will give you the information you need in the meta tags. So as an example, Apple grabs site meta image tiles, description and has a webkit screenshot of a website when you paste a link in iMessage. There’s really no reason you need to something beyond SwiftSoup to parse out the meta tags for you. Really, you can just grab the site meta description for that page and use some favicon or other img meta that the site owner has probable already done. I’m trying to keep things simple for you since this is an entire field. Unless you’re looking to summarize large amounts of text then you’re going down the road of needing ML.

I just encountered and implemented this today actually. Your arrayGardenChildren shouldn’t return an optional per the compiler error. So that should be easy to fix. So I setup a SectionedFetchRequest<Folder, Note>. My example is similar but trickier. So I think if you wanted to do it on the children where its the same object type. Also your SectionedFetchRequest, you can try looking at it from a different perspective. You’re going down the right path of handling the optional parent. But instead of filtering via the sectionIdentifier, maybe you should just add a predicate. @SectionedFetchRequest private var notes: SectionedFetchResults<Folder, Note> ForEach(notes) { folder in DisclosureGroup(content: { ForEach(section) { note in NavigationLink(destination: NoteView(note: note), label: { NoteRow(note: note)})}}, label: { FolderRow(folder: folder.id) })

So you have a few problems. The other post noted some stuff. But to answer your direct question, you have no data because the NSPersistentContainer is held and being instantiated in a StateObject. You should instantiate it in a more global sense, such as in AppDelegate or give it its own class so you instantiate it only once. I’ll point out other things, when you’re creating a new account, you probably want to be saving the context in the same scope and not have that in a separate function (saveAccountData). As the other poster mentioned. You need to figure out a better structure for setting up the PersistentContainer first. Then you can figure out if you want to use @FetchedRequest in the views and/or implement NSFretchedController on some view model.

If you’re having to try and make modifications to fetchRequests, then you should probably be using fetchedresultscontroller. It’s kind of the purpose of it and handles your use-case.

You all are overcomplicating things. Apple for the most part abides by the Oauth standard. Without messing around with things too much, the default response_type for Authentication Request is {code, id_token, state, user}. You can parse user for the PII you want. You set response_mode to form_post so expect a POST request containing Authorization Response parameters. After that you can validate and exchange the code. Store user information and the server can execute a redirect to the user. Like I said, Apple’s implementation is nearly the same as everyones’s. The only difference is they go out-of-spec and include a user struct.