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.
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.
If you're a business with a consumer facing app, you don't want to exclude 5% or 10% of your users. Most of the client projects I've worked on had a requirement to support iOS(-4) which is super painful from a development standpoint and usually the number of users on a device with iOS four versions old are in the range of 2%. But I get that it's tough for a financial institution or a streaming media company or a telco to exclude potentially 2% of users.
That chart doesn’t say you lose 10% of your market share.
It only says that 10% of your users can’t upgrade to the latest version of your app, which is a totally different proposition.
You say for some companies, this is unacceptable, which is obviously true.
It’s not obviously true for a lot of companies, so it’s worth questioning whether this is just a dogma that is handicapping developers and slowing progress in many cases.
It’s obviously not black and white. I’ve worked on bigger, more mature, products where not giving all users access to the latest features was unacceptable. And I’ve work on products where dropping an old version early only impacted like 2 users and it was acceptable. And big companies where it was okay to let ild versions lag because the model and api layer was super stable. Ultimately it’s a product decision not some unquestionable dogma and there no reason engineering can’t contribute to the discussion. It just turns out that the last two major versions is a good rule of thumb for most scenarios. It works very well in practice.
I agree that truthfully we're not talking about excluding those users, but only preventing those users from upgrading to the latest version of the app. But for lots of businesses those two things are viewed as effectively the same, because they believe they are adding value to the new version of the app that will result in greater user stickiness and direct or indirect revenue opportunities.
Honestly I'm thrilled anytime I'm working for a client that has a iOS(-2) rule versus an iOS(-4) rule.
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?
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.
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.
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 passing them across threads feels much more natural to me.
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?
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.
> 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?
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.
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.
> 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.
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.
As an iOS developer SwiftUI not being a library has been a huge pain, there were major bugs in point releases of iOS 13/14. It has improved a lot but there's still major headaches version to version.
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.
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.
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.
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.
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
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.
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.
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.
This is irrelevant, though, as the hottest Android framework (Jetpack Compose) is usable on devices released 9 years ago. This is the advantage of the way Google deploys major improvements vs Apple.
This is made possible by Swift macros, which also will make migration easier.
I can imagine starting out with SwiftData @Model's, but then redefining the @Model macro to work with another backend -- even deploying the same models to different backends on different platforms (e.g., CoreData on iOS and MySQL on Linux).
"API-compatible" now includes attributes. This could be a great opportunity for alternatives to the CoreData stack.
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.
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.
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.)
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
I have been a bit spooked on Core Data, after a friend of mine had a months-long ordeal with it; finally giving up on it, and setting up his own file-based DB.
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.
“Combining Core Data’s proven persistence technology and Swift’s modern concurrency features, SwiftData enables you to add persistence to your app quickly”
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.
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.
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"
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).
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.
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.
