Live data from Hacker News

SwiftData

developer.apple.com

71–80 of 109 posts

Re: SwiftData

#71

Earlier quoted context omitted.

CMD+F @Model would largely address the issue of not having an overview of the schema.

Not quite, having a list of lines it appears in won't be as helpful as the UML-ish graph.

Either Apple will add some graph tools to Xcode, or third-parties will develop tools to make the graphs you need

Re: SwiftData

#72

Earlier quoted context omitted.

Not quite, having a list of lines it appears in won't be as helpful as the UML-ish graph.

Either Apple will add some graph tools to Xcode, or third-parties will develop tools to make the graphs you need

Okay awesome, great news

(what is going on here, exactly?

why do we need to solve this and tie it off with a bow, today?

why is 'maybe someone else or maybe them will maybe make something similar someday' a resolution?)

Re: SwiftData

#73

Earlier quoted context omitted.

I don't get what you're saying here. Swift Data is just a framework to annotate data structures to be stored by Core Data. It looks a lot like an ORM.

If we think of CoreData's role here as simply providing persistent storage then the annotation layer is the interesting bit - binding a persisted model to a view via a query is conceptually similar to Recoil's atoms' support for complex fetching, persistence, and offline support.

Thinking of CoreData as simply providing the persistence layer is incorrect. It also provides the schema. CoreData’s object graph management and persistence are separate - you can use CoreData without persistence, but you can’t use it without a schema.

The annotations are for defining the CoreData schema – i.e. the necessary piece – rather than relying on a schema definition file as one would prior to SwiftData.

There are additional syntactic niceties for SwiftUI binding, but the annotations are very much an ORM.

Re: SwiftData

#74
post #46
post #45

Earlier quoted context omitted.

The latest stuff is still compatible with 5 year old iPhones. 80% of iPhones run the latest OS precisely because they are dead serious about long term support for devices.

5 years could certainly be improved upon. Those devices cost north of 1k now. I‘ve been an iOS dev since iOS 4, and have always been put off by this sneaky way of planned obsolescence. Older iOS releases do get security fixes, but only a tiny fraction of the fixes newer versions get. I don’t find this applaudable.

> 5 years could certainly be improved upon.

Every flagship iPhone since 2011 has received at least five years of OS updates. Some models have received more.

For instance, the 2016 OG $399 iPhone SE got six years of OS updates and just got another security update last month.

In comparison, the original Pixel phone also came out in 2016 and got it's last update at the end of 2019.

There does need to be improvement, but it's not the iPhone side that is badly lagging.

Re: SwiftData

#75

One of the things I like about CoreData is that all the relationships and entities are defined in one file, and its easier to browse the history of that schema to see how the models evolved. One of the things I dislike though is that it doesn't interop well with swift types and almost everything has to be marked as optional. It looks like this SwiftData solves the second problem, but since definitions are spread acro…

I hope all the swift tutorials don't switch to just SwiftData, seeing as how we must support iOS(-2).

read tutorials authored up to wwdc(-2) then. tutorials cover the latest because that's where attention is.

Re: SwiftData

#76
post #49

There’s a number of indie devs who rely on https://github.com/ccgus/fmdb for fast persistence. The rebirth of NetNewsWire came with FMDB at its core ( https://inessential.com/2020/05/18/why_netnewswire_is_fast ). What’s not clear is if a project starts with, say, SwiftData, and finds it to be a bottleneck, how easy is it to remove unless one goes to great lengths to make a clean API between the 2?

(For SQLite GRDB is more popular/refined)

I was all bought into RealmSwift, with iCloud syncing. Because I added a layer already that syncs Realm with iCloud, I expect transitioning to SwiftData (or from it to anything else) will work nearly out of box, without having to rip out the Realm code yet either. It'll receive the same iCloud data as Realm does.

Re: SwiftData

#77
post #52
post #39

Earlier quoted context omitted.

I know, but even with my small app I don't feel comfortable dropping support for the 20% users who are behind. And if I'm supposed to maintain both the old and the new API in parallel then why bother. Now for new apps I can see going all in with the latest SDKs.

While you're finishing it, it goes to 5%

So be it. I released a year ago and for now I support iOS 14.0 and above. I just think it's the right thing to do when reasonable enough. I will probably rewrite some parts to more modern SDKs and cut that support at some point, but I don't want to do it just for the sake of using the newest thing.

Re: SwiftData

#79
post #8

Earlier quoted context omitted.

Most definitely

Then there probably won't be a difference in performance

There certainly could be. SwiftData @Models aren't subclasses of NSManagedObject, and don't have to use the Objective-C runtime for dispatch, or the KVC-style property accessors that Core Data uses.

The fact that it is built atop Core Data's persistent stores, cloud sync, etc. doesn't mean that it's a fascade in front of the Objective-C APIs.

Re: SwiftData

#80

Sync really needs to be a feature of the web platform. A web app should be able to ask the user to sync its data accross devices. There's no reason you should have to worry about sync and authentication when you make an offline first web app.

Er, how would that even work? Apple can sync over iCloud. What are Firefox users going to sync over?

They do have something called Firefox Sync. It doesn't do that though.
Post reply on HN