Live data from Hacker News

SwiftData

developer.apple.com

101–109 of 109 posts

Re: SwiftData

#101

Earlier quoted context omitted.

Obviously the browser has to provide this backend. Browsers already sync passwords, history, bookmarks, extension data, they should offer sync as a feature for the web app as well.

That's fine but then it's not really a feature of the web... it's a browser feature. You are totally locked into that browser. Compare to browser bookmarks. Not a "web feature".

There are a bunch of web features about integrating with the browsers password manager: https://web.dev/security-credential-management/

These of course lock you into the browser (or the password manager) to the same extent. (Of course, just as a browser might support different password managers, so it might support different sync back ends.)

Re: SwiftData

#102
post #90

Unfortunately it looks to be mostly papering over Core Data, after a few huge Core Data projects I don't really care to work with it anymore, especially in SwiftUI. The more interesting addition to me looks to be CKSyncEngine, which would allow for easily adding a CloudKit sync engine to something like GRDB. Defining models in structs and extending and conforming them to various protocols, using them in SwiftUI and p…

It does seem like papering over Core Data, which is a papering over SQLite.

Can I ask what experience you had with CoreData and SwiftUI? And what do you prefer now instead? Thank you.

Re: SwiftData

#103
post #21

Earlier quoted context omitted.

It is a good addition. CoreData, is ok, but is not really used from serous apps. At least, none of the large ones that I have worked on. Either use flat files (serialized json) to save and restore state, or just Sqlite directly.

Super interested to understand more of this - I've worked on lots of serious apps, but not more than the scale of "banking app with ~1m users and 6 iOS devs"

And do you mind telling what did those apps use? CoreData, SQLite, json files. Also do "serious" apps use Firebase anymore?

Re: SwiftData

#104
post #58

Earlier quoted context omitted.

> Over 80% of iPhones are running the latest version. If the past is any indicator, the number will be over 90% by the time iOS 17 ships this fall.

I doubt iOS 17 will be adopted faster than previous versions. For one, they are dropping support for multiple device generations this time.

> I doubt iOS 17 will be adopted faster than previous versions. For one, they are dropping support for multiple device generations this time.

Each release gets adopted faster than the previous version; there’s no reason to expect anything different this year.

Also, just about every new iOS release drops support for older iPhones; this isn’t new.

No longer requiring developer accounts to install the iOS 17 beta will only increase the rate of adoption—many millions of users who aren’t developers will be running it before the official release in September, unlike years past.

Re: SwiftData

#105
post #39

Earlier quoted context omitted.

Apple has like >80% of devices released in last 5 years on iOS 16. Nowhere near the fragmentation of Android. Given only a minority of users are not on the latest major OS, worrying about supporting older firmware, at least in this case, is not worth the time or money.

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.

I mean it's not too complicated to add OS specific exceptions in Swift. You can build your app for the lowest version you want to support and add newer OS features a la carte.

Re: SwiftData

#106
post #9

Is this a ground up rewrite or just varnish over CoreData.

Models still have to be classes, so it seems more like varnish.

Wouldn't they need to be classes in order to be observable objects for SwiftUI?

Re: SwiftData

#107

Earlier quoted context omitted.

Super interested to understand more of this - I've worked on lots of serious apps, but not more than the scale of "banking app with ~1m users and 6 iOS devs"

And do you mind telling what did those apps use? CoreData, SQLite, json files. Also do "serious" apps use Firebase anymore?

think about apps that have billions of users, they build their own wrappers around sqlite.

Re: SwiftData

#108

Earlier quoted context omitted.

Super interested to understand more of this - I've worked on lots of serious apps, but not more than the scale of "banking app with ~1m users and 6 iOS devs"

And do you mind telling what did those apps use? CoreData, SQLite, json files. Also do "serious" apps use Firebase anymore?

they also have their own version of firebase. firebase is the open source version of what google uses inside. sometimes big tech open sources parts of their technology (if its coded nice to dissect).

Re: SwiftData

#109
post #21

Earlier quoted context omitted.

It is a good addition. CoreData, is ok, but is not really used from serous apps. At least, none of the large ones that I have worked on. Either use flat files (serialized json) to save and restore state, or just Sqlite directly.

Super interested to understand more of this - I've worked on lots of serious apps, but not more than the scale of "banking app with ~1m users and 6 iOS devs"

https://engineering.fb.com/2023/02/06/ios/facebook-ios-app-a...
Post reply on HN