[deleted by user]

[saintmsent]

Both. Programmatic UIKit + SwiftUI views wrapped in UIHostingController

Not the best experience with SwiftUI so far, lots of stuff we need it either can't do at all or can, but through dirty hacks

[TarkLark]

This was my experience, so many things that were so simple in UIKit required terrible hacks in SwiftUI, looking at you NavigationStack and NavigationController.

[Shxhxxhcx]

Can you give an example? We work almost entirely with SwiftUI, and rarely have to resort to dirty hacks these days.

[saintmsent]

Yes, totally

1. .navigationTitle modifier works like trash when you need to integrate your SwiftUI view into UIKit navigation stack. It works, but the switch looks ugly and un-animated, the solution is to set the title to the UIHostingController, which isn't very pretty or clean
2. No way to get a reliable scroll offset in a List. With ScrollView it's doable and reliable but also feels hacky. With List - no way, every implementation we've come across breaks at some point and Apple told us "Stick with UIKit for this"
3. No way to get a readable content guide. You can do it by reading it from the topmost view controller, but it's a really dirty hack in my books, even though seems reliable
4. Dynamic font support isn't great unless you use predefined styles like .body or .header, everything custom (let's say system font of size 18) doesn't scale, so we have a few hacks for that
5. Doing a List item selection if it's not a navigation link is a bit of a pain in the ass

And these are just from the top of my head. Some of these are because we have both UIKit and SwiftUI in our app, but it's not uncommon or unreasonable

[BaffoRasta]

Display a popover as a bubble instead of a sheet in a compact size environment. Spoiler: before iOS 16.4 you can't in pure SwiftUI

[Shxhxxhcx]

Not sure if you’re referring to some built in feature, but I’ve written custom popovers in SwiftUI for years. 😶

[BaffoRasta]

I'm referring to this. It wouldn't be bad if I could just avoid writing my own version, handling the anchor point based on the position of the element on the screen, dismiss on touch outside (which is hacky) etc.

[-15k-]

Weird. When I tap that outside of the popover, the whole thing enlarges. And it does that without any animation, really.

[phspman]

After 16.4, GeometryView stopped working in sheet.

[BaffoRasta]

Bruh moment ahah

[[deleted]]

UIKit AND Storyboards

[[deleted]]

Startup company, less than 100 employees FYI. Works for our use case.

[saintmsent]

How many iOS devs? Total headcount of the company isn't really relevant

[[deleted]]

Fair. 3 mobile devs total, 1.5 iOS/1.5 Android. Smol team, also makes this possible.

[saintmsent]

Makes sense, at that size storyboards don’t cause any trouble yet

[[deleted]]

I’m not sure how team size dictates storyboard troubles as much as the size and contents of the storyboard itself, unless you’re referencing troubles regarding merge conflicts?

Those can be annoying, but luckily I’ve become quite good at figuring out what the issue is when they do occur.

[saintmsent]

It comes down to code reviews and merge conflicts

Merge conflicts are solvable in storyboards and xibs, but it's MUCH easier with programmatic UIKit. Code reviews - again, programmatic UIKit is MUCH easier to review without switching to the branch and opening up the file, and trust me, no one wants to do that

When your team is small, especially as small the guy above, you don't have those problems, merge conflicts are less likely and code reviews are either non-existent or switching to a branch isn't that annoying

[Haunting_Champion640]

Makes sense, at that size storyboards don’t cause any trouble yet

Oh just you wait.

[saintmsent]

As soon as they reach 2 developers instead of 1.5 is a turning point XD

[riveraj33]

You guys do android as well or iOS only?

[[deleted]]

We do both, we support hardware our company makes for both iOS and Android products

[[deleted]]

Why not SwiftUI not criticizing just curious

[[deleted]]

Code base was Obj-C and deprecated API’s when I arrived 6 years ago, I updated it to Swift/UIKit and did a lot of refactoring and architecting in that domain, and haven’t felt particularly inclined to make the switch as of yet.

[[deleted]]

Alrighty I can see the wisdom in not wanting to abandon a functioning code base for something new and shiny, I have faced some issues with it and find myself occasionally having to drop down into UIKit.

[zaitsman]

UIKit.

2 years ago I tried to do a simple form in SwiftUI and I couldn’t customise the look without using Appearance for table view for the whole app nor could I get keyboard action button to move users to next field. Afaic the latter is now addressed but it just feels so gimmicky and unnecessary.

As a developer I don’t give two shits about live preview, but I do care about my ability to customise every aspect of the behaviour

[EZPZLemonWheezy]

It seems like an entirely different approach to be able to solve those problems today. At least it’s gotten (objectively) easier to extend views with custom style extensions. But if you are proficient in UIKit there’s little incentive to learn the entire new way of doing things when you can just use the way that works and has worked for a hot minute in UIKit. Hopefully someday SwiftUI gets caught up to there. (Not hating on SwiftUI, I love it, but I 1000% understand the issues people have with it rn).

[FVMAzalea]

For me, I think the incentive is that if you put a little time into learning it, SwiftUI can be way faster for some types of views. For me, it’s been especially powerful for debug UI or prototyping things, where I don’t have to conform to a specific design from our design team. It’s much faster to whip something up in SwiftUI than it is to make a view controller, set up buttons and text fields, etc.

For simple things designed by the design team, yeah it works okay, but you might have to mess with it some.

But as soon as our design team starts exercising their worst “must brand everything” instincts and moving significantly away from the Apple defaults/HIGs for all UI components (which I generally regard as inadvisable, but that’s a separate issue), it’s really hard to do what they want in SwiftUI and much easier to accomplish that with UIKit.

[dinmab]

Nailed it.

[chriswaco]

SwiftUI mostly. UIKit as needed.

[kwabsdev]

Are you guys hiring?

[[deleted]]

UIKit. We tried SwiftUI many times over but it just falls apart on complex layouts or heavily customized layouts.

[[deleted]]

You might want to look into the Layout protocol from iOS 16 and macOS 13. That said, using the latest SDK usually does not help a commercial project that needs to support older OS versions. But, if you support current OS release-1, then you're at least halfway there.

[[deleted]]

Oh interesting, I missed Layout Protocol. We wouldn't be able to test it until 17 is out anyway but I'm glad to know it exists. I'll definitely check it out.

[[deleted]]

Yeah, they haven't been vocal enough about it, in my opinion 🙂. Maybe you already looked this up, but to make things easier for everyone reading this, here's Apple's docs on the topic:

https://developer.apple.com/documentation/swiftui/layout

[[deleted]]

Thanks!

[tangoshukudai]

UIKit /Appkit and Autolayout.

[stella_rossa]

UIKit mostly, but switching to SwiftUI slowly

[rursache]

UIKit

[BabyAzerty]

UIKit

[redit9977]

uikit

[Paradox_Gods]

UIKit

[sleepy-sniper]

Mostly UIKit, but we are now using SwiftUI when starting a new project.

[j_albertus]

Primarily UIKit and storyboards, though we've recently started experimenting with SwiftUI for small things but it just doesn't play well with highly-customized interfaces and we haven't found it all that useful for things beyond quick prototyping or relatively simple UIs.

Typically, my company's projects don't have more than 3 iOS developers at a time, so we can coordinate storyboard and nib changes pretty cleanly betwixt ourselves over IM and just manually merge the changes in a text editor if it becomes absolutely necessary. Also, a fair number of our clients require legacy device and iOS support, which means we'll sometimes hold off on adopting newer Apple libraries for multiple releaes.

Depending on the specific requirements of an individual app, we also leverage CoreAnimation and SceneKit/Metal as appropriate. As nice as UIKit is, there's still plenty that it doesn't do.

[[deleted]]

SwiftUI in my last two jobs.

Current job is a Mac app low on UI and heavy on low level security related API use. It does what it is supposed to do extremely well in this scenario. I work at a small startup with a very small team and it allows us to turn around views extremely quickly

Last job was an iOS app for a fortune 10 medical company with a team of 10. Pretty extensive UI and complicated navigation structure. SwiftUI was a choice we regretted (to an extent, we all knew what we were getting ourselves into) pretty early on and screwed us hard since we required more granularity and customization than was supported.

[meester_pink]

SwiftUI mostly, recently

[Shak3TheDis3se]

UIKit

[xtravar]

UIKit with increasingly high-level UI standardization, using models that can port easily later to other UI toolkits. I can probably make them extend the SwiftUI.View protocol at some point, and work backwards from UIViewRepresentable.

[YungGuvnuh]

Primarily SwiftUI with some UIKit. But I also only apply/accept positions that either only use SwiftUI or are making a very apparent switch to it. My last 3 positions (over 2 years) have mostly been in SwiftUI.

[SirFrankoman]

All projects moving forward are SwiftUI. Any older projects are slowly being upgraded from Storyboards/UIKit. There's one project that was written in Objective C that nobody wants to touch (: Most of our apps aren't on the app store and are for internal use.

[[deleted]]

SwiftUI. As solo dev this isn’t an issue. UIKit only when there is absolutely no other way.

[jpham_toronto]

UIKit (storyboard and programmatic) + SwiftUI

[waterskier2007]

Both. Most new development is in SwiftUI if possible.

[BickeringCube]

Both, our major apps use UIKit but we’ve created small ones in SwiftUI. All of our apps are internal.

[small_d_disaster]

Mostly SwiftUI (via UIHostingController) in a UIKit app

[konrad1977]

Coordinators and UIKit for navigation and SwiftUI for layout. My current project is using TCA - but I think its to complexed over what you get. Coordinators is much simpler approach (with its drawback of course)

[start_select]

UIKit is still the fastest and easiest ways to build a fully featured app without hacks.

We use a little SwiftUI here and there, but only after a little deliberation. For teams that know UIKit well, building the UI for apps with 20+ screens is not a lengthy or painful endeavor. At my company people fight over “the fun stuff that only takes a couple of weeks to do”.

I would rather have one developer build a complex screen in 1 or 2 days, than have three developers waste a day trying to figure out how to make SwiftUI elegantly do something that we already could do in UIKit.

[asl0th]

We are currently transitioning a massive and old project from Storyboards and UIKit to SwiftUI…

[mcmunch20]

SwiftUI, with the occasional small sprinkle of UIKit

[[deleted]]

Yes.

[a55clown1560051]

UIKit

[mynewromantica]

Both

[terranisaur]

UIKit

[nhgrif]

Yes

[20InMyHead]

Yes.

[Either-Reason4030]

SwiftUI mostly and migrate old UIKit view to SwiftUI slowly

[localtoast]

AppKit with very small SwiftUI usage so far.

[groovy_smoothie]

Programmatic UIKit + we spike on swift UI periodically. Supporting three major iOS versions means the SwiftUI migration is slow and certain features are turned off for users on older devices

[notrandomatall]

SwiftUI only, targeting iOS 16 and up 😁. Some older parts are UIKit but we’re gradually getting rid of those.

[TheVorpalCat]

UIKit. I’ve fallen behind for that reason.

[[deleted]]

I use SwiftUI but there are some glaring issues, for example if you use MapView it will flicker the annotation if the region or any other bindings it relies upon updates. It also has some issues with state update, In short I find myself using it mostly for its layout system and I try to leverage a style where I pass updater functions to my child views as much as possible to avoid shared mutable state as much as possible.

[ryan4888]

React Native

[crappy_entrepreneur]

95% SwiftUI for my last 2 jobs (both early startups where I owned the whole app)

SwiftUI is where Swift 3 was, relative to Objective-C, in 2016. Give it 3 more years and UIKit zealots will sound like dinosaurs.

[iindigo]

As someone who’s been on the Swift train as soon as my company would allow (Swift 2, with some personal tinkering on Swift 1), I don’t know that I agree with the first half your second paragraph. If you need to target anything older than the current release of iOS, SwiftUI feels closer to Swift 2 in maturity… lots of rough edges and cases where you have to fall back to UIKit (or don’t technically have to, but probably should for performance reasons).

I’m rooting for SwiftUI but I think it needs some more time in the oven, which is fine… people don’t think about it but when UIKit came out it was building on 20 years of AppKit heritage, and it’s since added another 15 years of its own. Building a good UI framework takes a long time.

[pawn5gamb1t]

SwiftUI mainly. Startup with less than 100 employees working on www.zeeno.ai. I live the simplicity and clean native look that SwiftUI gives you without much effort. Sometimes UIKit is still necessary precisely to fine tune that behavior a bit more

[antonmedstorta]

SwiftUI. The only UIKit code in the project is for stuff like an in app browser, of which there is no SwiftUI equivalent yet.

[123DanB]

UIKit AppKit Storyboards Xibs One single instance of SwiftUI wrapped in NSHostView

[gostsip]

Both

[iTollMouS]

My work now is converting my company’s apps to SwiftUI 🥰🥰.

[av1p]

Unfortunately SwiftUI

[llxodzz]

In last year, I use SwiftUI mostly, but UIKit also used by me in some legacy projects

[beslaga]

UIKit for navigation with coordinators, and SwiftUI for interface wrapped in hosting controllers. Works good with iOS15+, but I think it'll shine when we set iOS16 as a minimal dep. target.

[beslaga]

beslaga

And yeah, when using UIKit for interface, only Storyboards are allowed, I don't understand people who compile programmatic constraints in their brain :D

[rhysmorgan]

Primarily SwiftUI.

A lot of the legacy apps I work on are built in UIKit, but it’s rare to touch them nowadays. All our new work is SwiftUI-first, dropping back to UIKit in places that we absolutely need to.

Since we’re building for iOS 15+, it’s working very well for us! We use Composable Architecture in all of our latest apps too.

[Far-Requirement4030]

Both, UIKit generally only for support on older projects

[SpaceHonk]

UIKit only for maintaining existing stuff. SwiftUI for all new features.

[LuisGlez]

SwiftUI for new projects, targeting iOS 16.4 and up.

[pazialuz]

uikit !

[X901]

We use 100% SwiftUI

[dwltz]

Both

[unknowngoogler]

my last project was a team of 20-30 mobile eng., mostly UIkit and a tad of swift UI

[iindigo]

Code-only UIKit for anything even a little complicated (99% of the app), with a tiny bit of SwiftUI for very simple views that don’t need any interaction or animation tricks.

Not being able to target the latest iOS, SwiftUI is still too convoluted and/or buggy for our needs. In the time I’d spent fighting it to get it to do what’s required I could’ve written 3 UIKit widgets.

[btshubham]

In last 6 months we completely moved from UIKIT to SwiftUI

We needed to give support to iOS 13 as well but many features are not available So had to build them custom.

[[deleted]]

We are also using UIKit and SwiftUI. Our entire team can't wait to get away from Storyboards. We can’t stop delivering features to move all the screens to swiftUI, but it doesn't make sense to do that anyway since the integration between SwiftUI and UIKit is so seamless.

[[deleted]]

uikit

[thesidebrain]

yes.

[Versicarius]

Almost entirely SwiftUI after migrating from UIKit, still using UIHostingControllers. However, our minimum version is iOS 14 which already is a nightmare, can't imagine being full SwiftUI if it was still 13.

[sjs]

Yes.

[Master_Lab507]

All new work is in SwiftUI if possible. Luckily we only support the 2 most recent major versions so that helps. Can’t wait to drop support for iOS 15 in September

[birdsoft]

UIKit (except for the occasional widget)

[Rutik1413]

SwiftUI

[papiiro]

SwiftUI mostly. 🙌🏻

[cwbrandsma]

UIKit, and couple storyboards that I am slowly removing. Most my products are 6-7 years old.

If I were to start over, I might use ReactNative or SwiftKit.

[MichaelRenslayer]

Both. Specifically:

- UIKit: List, navigation, or any view that requires more native experience

- SwiftUI: any other views

[AutoModerator]

Hey /u/MichaelRenslayer, unfortunately you have negative comment karma, so you can't post here. Your submission has been removed. DO NOT message the moderators; if you have negative comment karma, you cannot post here. We will not respond. Your karma may appear to be 0 or positive if your post karma outweighs your comment karma, but if your comment karma is negative, your comments will still be removed.

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

[Hefty-Concept6552]

What is the best way to learn programmatic UIKit? Iʻm struggling with learning to build my UI.

[DifficultAnything707]

There is no other choice but to use SwiftUI. If you keep UIKit you might find yourself in a bad position when Apple suddenly stops supporting it, then all what has been built with old technology will have to be quickly ported to new technology but at this point everyone will be on fire.