[HN Gopher] SwiftData
___________________________________________________________________
SwiftData
Author : koinedad
Score : 141 points
Date : 2023-06-06 16:33 UTC (6 hours ago)
(HTM) web link (developer.apple.com)
(TXT) w3m dump (developer.apple.com)
| fareesh wrote:
| Very nice changes. It's a shame to see cross-platform development
| tools falling so far behind.
| sureshv wrote:
| Looks like a wrapper over core data - was wondering if they made
| it thread safe.
| sumuyuda wrote:
| This is a huge annoyance with CoreData, you can't pass objects
| between threads.
| secretsatan wrote:
| 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
| gfaure wrote:
| I didn't know that Swift had a macro system...
| rescripting wrote:
| They were just introduced in Swift 5.9, released w/ the Xcode
| 15 beta:
|
| https://developer.apple.com/videos/play/wwdc2023/10166/
| seanalltogether wrote:
| 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 across all the
| classes individually, it's harder to get a glance at the whole
| schema at once.
| jmull wrote:
| You still have the option to keep things organized, though you
| will need to supply a bit more of your own discipline.
| jondwillis wrote:
| CMD+F @Model would largely address the issue of not having an
| overview of the schema.
| refulgentis wrote:
| Not quite, having a list of lines it appears in won't be as
| helpful as the UML-ish graph.
| codetrotter wrote:
| Either Apple will add some graph tools to Xcode, or third-
| parties will develop tools to make the graphs you need
| refulgentis wrote:
| 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?)
| wahnfrieden wrote:
| put them in one file then.
| leovander wrote:
| Ditto to this suggestion. Especially when you auto generate
| classes it ends up creating the main class for each entity
| and a separate extension file for each. By default we merge
| the two and avoid the separate extension altogether.
| TheJoeMan wrote:
| I hope all the swift tutorials don't switch to just SwiftData,
| seeing as how we must support iOS(-2).
| wahnfrieden wrote:
| read tutorials authored up to wwdc(-2) then. tutorials cover
| the latest because that's where attention is.
| amadeuspagel wrote:
| 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.
| tantalor wrote:
| Er, how would that even work?
|
| Apple can sync over iCloud.
|
| What are Firefox users going to sync over?
| jahewson wrote:
| 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.
| mark_l_watson wrote:
| 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.
| koinedad wrote:
| 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
| trinix912 wrote:
| It'd be interesting to see a performance comparison of SwiftData
| vs. (objc?) CoreData vs. plain XML for large datasets. I recall
| plain XMLs being faster than CoreData a few years ago in certain
| scenarios.
| ardit33 wrote:
| 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.
| jakey_bakey wrote:
| 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"
| akmarinov wrote:
| Isn't SwiftData mostly a wrapper around CoreData?
| afinlayson wrote:
| It just makes it easier to use - meaning less glue code.
| Making CoreData Swift + SwiftUI native approach. Where
| currently you'd have to make a Core Data class wrapped by a
| @Observable Class.
| koinedad wrote:
| Most definitely
| akmarinov wrote:
| Then there probably won't be a difference in performance
| koinedad wrote:
| "Combining Core Data's proven persistence technology and
| Swift's modern concurrency features, SwiftData enables you to
| add persistence to your app quickly"
| tifa2up wrote:
| Noob here, how does SwiftData compare to Redux (as a paradigm)?
| jahewson wrote:
| Looks pretty different. Much closer to more modern state
| management approaches such as Recoil and Jotai.
| esprehn wrote:
| What part makes you think of Recoil? CoreData (and now
| SwiftData over it) are more like ActiveRecord in my
| experience.
| jahewson wrote:
| 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.
| _trackno5 wrote:
| 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.
| jahewson wrote:
| 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.
| bigtechennui wrote:
| 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.
| manmal wrote:
| If you need Redux in SwiftUI, you should check out
| ComposableArchitecture.
| RandallBrown wrote:
| It's not really comparable.
|
| SwiftData is the Swift version of Apple's CoreData, which is
| pretty much a database ORM.
|
| It's a massive improvement on the old APIs that were written
| decades ago for Obj-C.
| elthor89 wrote:
| I was waiting for this to come out. Hope to have sometime this
| weekend to play with it.
| zyang wrote:
| Is this a ground up rewrite or just varnish over CoreData.
| mjmsmith wrote:
| Models still have to be classes, so it seems more like varnish.
| [deleted]
| emehex wrote:
| This is really unfortunate... I wonder if they'll adapt the
| varnish to work with structs in a future release
| geodel wrote:
| Seems like varnish.
| mrtksn wrote:
| I built myself something similar on top of SQLite and Combine.
|
| Now I'm confused, should I abandon it and go with the first hand
| solution? I would actually prefer that but this requires the new
| versions of the Apple platforms. Why wouldn't Apple make these
| available downstream?
| wilg wrote:
| > Why wouldn't Apple make these available downstream?
|
| Because Apple cannot figure out that their deployment model is
| hamstringing adoption of their technologies.
| plagiarist wrote:
| 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...
| lockhouse wrote:
| 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...
| carstenhag wrote:
| 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.
| wilg wrote:
| Same, but its still a 1 year lag on relying on a new API.
| Probably 2 or 3 in practice if you support the old OSes
| for a bit. Could be zero lag.
| alwillis wrote:
| > 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.
| ecedeno wrote:
| I doubt iOS 17 will be adopted faster than previous
| versions. For one, they are dropping support for multiple
| device generations this time.
| Dreami wrote:
| They are actually of the same age, the iPhone 8 and X
| came out at the same time (yes it's still confusing now)
| qwytw wrote:
| Why? This way their new stuff get a year or two of free
| testing and time to mature before widespread adoption.
| alwillis wrote:
| > Why wouldn't Apple make these available downstream?
|
| Because it probably relies on new stuff that's only in the new
| version of the operating system. Otherwise, you'd have to back
| port a chunk of your new stuff to the older operating system,
| creating a lot more work for little gain.
|
| And why do all of that when over 80% of the installed base will
| be running iOS 17 within 8 months, so what are you really
| gaining?
| lockhouse wrote:
| Apple actively encourages everyone to adopt the latest version.
| If your device is from 2018 or newer it will support the latest
| OS, so back porting frameworks is less important than on
| platforms like Android where devices are only updated for a
| much shorter duration and often several months after that
| version is released by Google.
| manmal wrote:
| Apple need to ensure as many apps as possible raise their
| deployment target as soon as possible so that users with old
| devices are encouraged to upgrade to newer devices.
| simonh wrote:
| 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.
| manmal wrote:
| 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.
| GeekyBear wrote:
| > 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.
| secretsatan wrote:
| 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
| manmal wrote:
| 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.
| koinedad wrote:
| I'm actually really looking forward to this. I tried building a
| few apps in 100% SwiftUI coming from React/Node.js and it was a
| pretty major pain. I also don't know UIKit so I couldn't easily
| fallback.
| yreg wrote:
| I had the same experience as you. Using CoreData with SwiftUI
| feels strange. Unfortunately if we start using this now we can
| only target iOS 17+.
| valianteffort wrote:
| 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.
| yreg wrote:
| 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.
| Jaxan wrote:
| Thanks! I appreciate this attitude as I'm stuck on iOS
| 15, but still like my phone as it is.
| szundi wrote:
| While you're finishing it, it goes to 5%
| yreg wrote:
| 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.
| koinedad wrote:
| The typing of NSPredicate seems like a big upgrade as well. I
| went through all the old outdated docs for core data but still
| things aren't very clear in my mind. Hoping the typing helps
| mritchie712 wrote:
| Try it with ChatGPT. I've never built an iOS app and it took me
| 5 minutes to get a SwiftUI app running with gpt-4.
| koinedad wrote:
| A basic app or one you created a bunch of custom logic, cloud
| sync integration, etc? I can build a simple app in a minute
| or two.
| mritchie712 wrote:
| Yes, custom logic and cloud sync.
|
| It tracks sprint workouts with GPS / pedometer. It's not
| Uber, but it's a good bit beyond a hello world.
| koinedad wrote:
| That's pretty amazing, don't think I have access to
| GPT-4, need paid subscription for that right?
| jinjin2 wrote:
| Looks promising and it is about time that they modernized the
| interface to CoreData that was getting really long in the tooth
| by now.
|
| I still prefer Realm though. It has a much more flexible days
| model and I can use it both on iOS and Android with seamless sync
| between the two.
|
| When Apple adds cross-platform sync to SwiftData I'll consider
| it. Until then it is dead in the water.
| BooneJS wrote:
| 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?
| wahnfrieden wrote:
| (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.
___________________________________________________________________
(page generated 2023-06-06 23:00 UTC)