Live data from Hacker News

SwiftData

developer.apple.com

61–70 of 109 posts

Re: SwiftData

#61
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.

Is there an alternative that offers longer?

Apple do seem to be shortening a bit, but as an app developer, we generally support iOS 2 versions behind unless there’s a particularly good feature we want to add to our workflow.

I don’t see much of interest to us in 17, I’m surprised there weren’t any major updates to arkit considering the announcement of Vision Pro

Re: SwiftData

#62
post #3

Earlier quoted context omitted.

Looks pretty different. Much closer to more modern state management approaches such as Recoil and Jotai.

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.

Re: SwiftData

#63

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?

Re: SwiftData

#64
post #15

Looks like a wrapper over core data - was wondering if they made it thread safe.

This is a huge annoyance with CoreData, you can’t pass objects between threads.

I remember tearing my hair out over that, i did eventually get it working reliably across the 2 threads i needed and i swore if i ever had to try again i’d try something else, it was just so easy to start with

Re: SwiftData

#65
post #34

Earlier quoted context omitted.

They actually can figure that out, though [0]. I hope this can solve some of it because their deployment model is the dumbest fucking thing. I'm glad they figured out how to backport async/await, it's just impossible to use in a serious library otherwise. [0] https://github.com/apple/swift-evolution/blob/main/proposals...

Over 80% of iPhones are running the latest version. I’ll take that any day as a developer over the Android hellscape of versions that need to be tested for and supported. https://www.macrumors.com/2023/06/01/apple-shares-ios-16-ado...

Some input as an Android dev: the API level stuff is not nearly as much as a problem as it was some years ago. Nowadays you can easily require 23 or 25 (see https://apilevels.com/) - since 23, there were definitely some changes, but not terribly big ones that are really painful.

I'm rather getting a headache with new form factors (window insets, foldables, tablets being revived).

Also: Usually all google libs are backwards compatible to 21. The new ui system (Compose) just gets shipped with the app itself, increasing download/installation size. Apple does not do this afaik, they require a recent minimum OS version for compose ui.

Re: SwiftData

#66
post #16
post #3

Earlier quoted context omitted.

Looks pretty different. Much closer to more modern state management approaches such as Recoil and Jotai.

What part makes you think of Recoil? CoreData (and now SwiftData over it) are more like ActiveRecord in my experience.

Yes, that's CoreData but we're talking about this new intermediate SwiftData layer. If you think of the ORM part as just "storage" the bindings are quite Recoil-like. Take a look at `recoil-sync`, which handles querying and syncing with persistent storage.

Re: SwiftData

#67

When out of beta and generally available, this will be useful! Ideally the iCloud sync will work across the same app built for macOS, iOS, and iPadOS. I used SQLite a few years ago for a Swift/SwiftUI macOS app, and this looks like what I would have used if it was available. All in all, Apple is going in a good direction with Swift, SwiftUI, SwiftData, etc.

Yeah I’m feeling you on this. I built an iOS/MacOS app with iCloud sync in SwiftUI a few years ago and it was a chore

Re: SwiftData

#68

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.

If you make an offline first web app you need to spend most of your time worrying about sync and auth. Otherwise the semantics of your app are going to be... iffy.

Re: SwiftData

#69

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…

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.

Re: SwiftData

#70
post #46

Earlier quoted context omitted.

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.

Is there an alternative that offers longer? Apple do seem to be shortening a bit, but as an app developer, we generally support iOS 2 versions behind unless there’s a particularly good feature we want to add to our workflow. I don’t see much of interest to us in 17, I’m surprised there weren’t any major updates to arkit considering the announcement of Vision Pro

Samsung is ca on par or slightly worse (depends what year you are looking at), but it’s hard to compare because Android updates are more fine grained and can partially be done without releasing the whole OS. With Samsung you at least know how many releases you‘ll get and how many years of security updates a phone is good for. And afterwards you might be able to put Ubuntu or Lineage on it.

I think, as a dev, it’s reasonable to only target the last 2 versions on iOS, but this is owed to bespoke Apple‘s behavior regarding new APIs. Android devs usually need to support twice as much or more major versions, but it’s way less painful for them because the Support Library (now Jetpack) allows them to use a big part of the latest stuff.

For example, you can use Jetpack Compose (SwiftUI pendant) with min API level 21 which was released 9 years ago. If you have a phone from 2012 that happened to get an Android 5 update, you can run modern declarative UI on that. The first iPhone that can run SwiftUI is the 6s, released in 2015.

Post reply on HN