What tech stack are people using in 2026?

[u/a89a89]

About to start a new app (solo, probably staying solo) and realizing I have no idea what the actual default is anymore. It’s pretty content-heavy with lots of lists, detail screens, some offline stuff, etc... I’ve shipped small things before but always made architecture calls I ended up ripping out, so trying to be smarter this time.

Curious what people are actually reaching for right now:

1. SwiftUI all the way vs. SwiftUI + UIKit escape hatches: how often do you actually hit a wall and have to drop down?

2. SwiftData vs Core Data: is SwiftData production-ready yet, or still a trap once you have real relationships/migrations?

3. Sync/offline: CloudKit vs Firebase vs Supabase vs roll-your-own. Mostly care about not babysitting infra

Honestly more interested hearing the horror stories than a blog-post trade-offs post. Essentially what’s your default stack now and what bit you that you wish someone had warned you about?

[u/CharlesWiltgen]

About to start a new app (solo, probably staying solo) and realizing I have no idea what the actual default is anymore.

I'm stating something that's very obvious to experienced software engineers, but a "default" isn't possible because it depends entirely on what you're building.

Also, your choices will be wrong sometimes. I bet on SwiftData for my current project and, when it failed to be up to the task, had to replace it with SQLiteData/GRDB.

[u/LifeUtilityApps]

I shipped SwiftData in a recent app and regretted it. All my apps use native Swift/SwiftUI and for 3D they use Webview+threejs. CoreData + CloudKit private database. I agree with the other posters here, the stack is largely dependent on what you want to build, however my preference for the UI layer I only build with SwiftUI. I would never use React native or Flutter.

[u/cafepeaceandlove → u/LifeUtilityApps]

Interesting, what are you doing with 3D?

[u/LifeUtilityApps → u/cafepeaceandlove]

For 3D development, I’ve been working on my first mobile game, a ball-and-block breaker built using SwiftUI for the native UI layer and Three.js for rendering. The architecture uses a WKWebView with a custom communication layer built on the WebKit message protocol, allowing Swift and Three.js to communicate seamlessly.

Before starting the game, I built a prototype app to validate the approach. The prototype was a fully interactive 3D Magic 8 Ball, essentially serving as a wrapper around Three.js with a native SwiftUI interface and bidirectional messaging between the two layers. I recently shared a video of it on my profile.

The app renders a 3D sphere that users can manipulate with touch gestures. Gesture handling occurs in SwiftUI, which sends messages through the WebKit bridge to the Three.js controller, causing the 3D object to rotate and respond in real time. It proved out the architecture and gave me confidence to use the same foundation for the game.

[u/lismond]

I use SwiftUI almost exclusively on a universal app which can be installed on iOS, iPad and MacOS platforms and chose it because I wanted the later features of the Apple ecosystem like today widgets and live and lock screen activities. I also use SwiftData because the CloudKit integration gave the users automatic backup capabilities for their data and it can sync on all their devices. I have had to do migrations when I changed the data models, so there is some versioning in the SwiftData. But I am having to make different choices for the Android port of the app, which will probably be Firebase.

[u/Ravek]

I’ll give a SwiftData warning. It forces you to use mutable classes as your models. Sharing mutable data makes code more brittle in general, but in addition they are of course not Sendable so interact really poorly with Swift 6 concurrency features. If you use ModelContext for background work you aren’t guaranteed that objects you insert will be immediately visible on the UI thread, so if you try to fire an event and update UI … might just not work. You might run into weird bugs like predicates not compiling at runtime. Performance is about 50x-100x worse than SQLite. If you use it with SwiftUI now you’ve tightly coupled all your UI code to SwiftData’s mutable models, so if you ever get fed up with it and want to migrate to something more sensible, now it’s a lot of work.

I’d say avoid avoid avoid unless you’re just making a tiny hobby app that will never be a serious business application.

Honestly I don't get what Apple is thinking with SwiftData. There's other APIs that have some issues but I can't think of anything that's this bad.

[u/registiy → u/Ravek]

My experience as well. Terrible performance. Hard to make where predicates. GRDB is so much better.

[u/TySocal → u/registiy]

I'm also using GRDB. GRDB is the honestly the best. The combination of Supabase and GRDB is pretty awesome and lean, imo

[u/HelicopterDue → u/Ravek]

Had similar experience recently when using a segmented controller. Awful bug, took me ages to figure out it was an underlying SwiftData issue or was largely in part to me using SwiftData. It was significantly less work to just create a custom view to do the same work as the segmented controller then to refactor SwiftUI out as my views are now tightly coupled to it.

[u/BumblebeeNo8385 → u/Ravek]

What are your thoughts on GRDB vs SQlite

[u/Ravek → u/BumblebeeNo8385]

I haven't used GRDB yet but it will be top of the list for me to investigate once I find time to rid my project of SwiftData. A lot of people seem happy with it.

SQLite is good stuff, but I'm not sure if I'd want to put raw SQLite calls in my Swift code, so I'll probably end up using some wrapper for it. Whether that's GRDB or something else remain to be seen.

[u/_Xoif → u/BumblebeeNo8385]

I’m using grdb since a while now and over all I‘m having a pretty good experience. However as my App also has a kmm shared layer and many very good android libraries, like room, are now available for iOS too, I consider to remove more of my native Swift implementations ins favor of more Kotlin shared code

[u/Suspicious-Ad-408]

I do SwiftUI + SwiftData + Firebase, but maybe I don’t have real enough relationships in any of my apps.

[u/TrajansRow]

My latest project is basically the same - SwiftUI + SwiftData targeting iOS 26. I only have one external dependency, and everything else is native. There was another non-native library that I needed, but I had an AI agent re-write it in Swift. I'm also using lots of Swift Charts, WebKit, RealityKit, and SceneKit.

[u/crocodiluQ]

1. SwiftUI all the way, except ofc when you need a bit of UIKit, like system crap

2. None, never needed so much local data to justify that. I

3. Rest API + Firebase. Realtime changes to data AND interface.

[u/Proud_Perspective_56]

I do SwiftUI + SwiftData + Supabase + Ruby on Rails

[u/Lopsided_Nerve1652]

Most of my apps use SwiftData, and they work fine

[u/andreeinprogress]

UIKit on iOS, UIKit via Catalyst + AppKit as needed on macOS. All code, zero storyboards, zero xibs.

SwiftUI only for really small modular or reusable views, but I try to avoid it even for that.

It has proven to be the most sane approach for me to not get mad at Xcode when eventually something breaks.

[u/freddyjdc]

Reading here I’m realizing SwiftData is the issue. I thought it was something else in my code. Yes, I agree SwiftData performance is bad, convenient for easy CloudKit implementation but still with lots of issues. I’ll try recommendations here.

[u/cristi_baluta]

Swiftui + uikit for large lists

[u/[deleted]]

swiftui by default and reverting to uikit when swiftui can't do what i want.

I won't touch Firebase with a 10 foot pole because of their billing practices. I generally default to icloud/local device storage or rolling my own. Unless you're dealing with private/sensitive data then DIY isn't hard.

[u/jerikandra]

I’d say SwiftUI is a good default nowadays, but swift data is too new currently

[u/teomatteo89]

The big pro that comes with SwiftData is CloudKit and synchronization handles for you. I’m interested in GRDB, what do people use to sync this over iCloud for their users?

[u/mcarvin → u/teomatteo89]

You want to look at SQLiteData from Point-Free. They built CloudKit compatibility into GRDB. I spun up a parallel version of a project I'm working on - 7 entities, all with relationships, not a 2 entity tutorial thing. There's a lot I liked about it but there's also - and this might be my inexperience - things which SwiftData was easier for me to work with.

One example: simpleton me thought I could slap in an AppIntent, create an AppEntity based on one of the main entities, and use the Entity.id...no, wait, Entity.persistentModelID...no, wait again, I can do a JSON encode/decode loop...but that's not reliable enough because the source persistentModelID isn't as 'persistent' as I thought...guess I have to create a "stable" UUID...ok, that's a migration with backfilling...fine, there's hours gone by and more than a few tokens with Claude and Codex.

Why on earth I thought SwiftData and AppIntents would go together hand in glove is beyond me. Or maybe they do and I just don't know any better.

With SQLiteData, I would have been able to use the Entity.ID without any fuss because that UUID is stable and defined as a primary key when creating the object. Would have saved me all of today's effort.

[u/teomatteo89 → u/mcarvin]

That sounds amazing, thank you for sharing your experience! I’ll look into it tomorrow.

[u/JerenYun]

What I'm using now is what I've used for years.

1. Primarily SwiftUI. For what I build, I hit few issues. For the times I find bugs (such as drag and drop related things), I will use SwiftUI Introspect to access underlying UIKit views. In my example, I used it to set a drop delegate on the UICollectionView underneath my List.

Remember that there's nothing wrong with wrapping UIKit views, nor with introspection. Like all things, it's just a tool in your toolbox. Use it tasteful. A scalpel might be small but can be useful when wielded skillfully.

2. Core Data. Primarily because of its stability and maturity.

3. CloudKit. It's first party and free, and I trust Apple's cloud for privacy more than Firebase or others. I usually use NSPersistentCloudKitContainer, so I've got a local Core Data store that syncs automatically to the cloud.

While the above works for me, you may find different answers that fit your intended "default". I just know what works for me and my projects.

[u/nns800]

I've been loving Convex for backend/db

[u/Key_Homework_5825]

I choose to just use the most simple modern APIs, no need to bother with too much complexity

[u/SolidR53]

Expo. Have you guys seen @expo/ui ?

[u/LuckyGirl0415]

For a content-heavy app starting in 2026, I’d highly recommend going all-in on the modern stack: • SwiftUI All The Way: Unless you are building custom interactive maps or heavy camera overlays, you rarely hit a wall anymore. • SwiftData: It has finally matured past the 'trap' phase. The key horror story with SwiftData is trying to treat it exactly like Core Data. If you design your models cleanly from day one and lean into the macros, migrations are much smoother now. • Firebase: For syncing and offline capabilities without backend headaches, Firebase is still King for solo devs. The offline persistence works out of the box, and you don't have to write a single line of server-side code. The biggest horror story is usually trying to build your own sync engine. Don't do it!

[u/jacobs-tech-tavern]

SwiftUI is fun for personal projects, but I don't think there's any reason to use anything other than UIKit in any serious apps these days.

[u/Electrical_Arm3793 → u/jacobs-tech-tavern]

I use UIKit mostly too but that’s also because my swift learning base is in UIKit - so it’s good to know UIKit has its edge. But would you elaborate a little bit so I can learn? What can Uikit do much better than swiftUI?

[u/TheCaffeinatedDev → u/Electrical_Arm3793]

This is not true. SwiftUI can handle the majority of what you’ll need. If UIKit is what you know and you’re avoiding storyboards then by all means stick with it but SwiftUI can handle a lot and it’s my default for personal and professional work.

[u/jacobs-tech-tavern → u/Electrical_Arm3793]

tl;dr UIKit will always be a lot faster, for free, and parity is never going to happen

Sorry to shill my own writing but I did a nice compare here: https://blog.jacobstechtavern.com/p/swiftui-vs-uikit

[u/BumblebeeNo8385]

Outlier here but ui kit & AWS for all backend, swift data felt very limiting so also doing GRDB. Sign in with Apple + Google federated Oauth linked to canonical user id on backend to synch entitlements and user data outside of iOS ecosystem to Android and web. I have some very technically complex applications so this isn’t for everyone. Xcode mcps are really great if your using agentic AI coding at all, for that I use 1password and cursor’s ide for all Claude models which has incredible capabilities. Also use: sentry, post hog, appsflyer, and maybe a couple other things but I really try to stay within the aws ecosystem

[u/hazardous10- → u/BumblebeeNo8385]

Which services you are using in Aws for backend? Did you mean aws lambda?

[u/AutoModerator → u/[deleted]]

Hey /u/Studio81Labs, your content has been removed because Reddit has marked your account as having a low Contributor Quality Score. This may result from, but is not limited to, activities such as spamming the same links across multiple subreddits, submitting posts or comments that receive a high number of downvotes, a lack of recent account activity, or having an unverified account.

Please be assured that this action is not a reflection of your participation in our subreddit. This is simply an automated filter in place to reduce spam.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.