SwiftData
developer.apple.com
developer.apple.com
(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?)
It maximizes the user market. https://iosref.com/ios-usage
Losing a potential 10% of your market share because they’re 2 versions away is unquestionable for some companies.
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.
Honestly I'm thrilled anytime I'm working for a client that has a iOS(-2) rule versus an iOS(-4) rule.
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.
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.
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.
Can I ask what experience you had with CoreData and SwiftUI? And what do you prefer now instead? Thank you.
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?
Because Apple cannot figure out that their deployment model is hamstringing adoption of their technologies.
[0] https://github.com/apple/swift-evolution/blob/main/proposals...
https://www.macrumors.com/2023/06/01/apple-shares-ios-16-ado...
If the past is any indicator, the number will be over 90% by the time iOS 17 ships this fall.
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.
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.
Isn't really an issue these days. Almost everything Google puts out is in the Jetpack libraries and backported many major versions.
80% of iPhones run the latest OS precisely because they are dead serious about long term support for devices.
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
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.
Jetpack is cool, but the reason it exists is because the Android OS update picture is appalling. Anyway it doesn’t really address security updates.
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.
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?
Now for new apps I can see going all in with the latest SDKs.
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.
I think for both platforms, OS fragmentation depends heavily on your target audience, moreso than the platform stereotypes.
It tracks sprint workouts with GPS / pedometer. It's not Uber, but it's a good bit beyond a hello world.
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.
Apple can sync over iCloud.
What are Firefox users going to sync over?
Compare to browser bookmarks. Not a "web feature".
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 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.
But I do have use cases for this kind of thing.
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.
Either use flat files (serialized json) to save and restore state, or just Sqlite directly.
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.
Swift Data is just a framework to annotate data structures to be stored by Core Data.
It looks a lot like an ORM.
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.
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.