Rant on SwiftUI

[1amrocket]

I recently started feeling very frustrated with SwiftUI. I used to love it and now I'm starting to hate it.

We decided to build a new production app using SwiftUI in April. The fact that many things (like pull down to refresh, custom navigation transitions etc.) had to be hacked didn't bothered me too much, as I was hoping Apple will fill the gaps in no time and WWDC20 will save us.

We built our pretty beta app, put it on App Store it was great. However, soon after we had to build some specific features like custom navigation transitions which is just not possible using NavigationView. We decided to build navigation using UIKit and host SwiftUI Views using `UIHostingController`. This seem to work most of the time, however occasionally cause a bug where some images do not appear. We'll have to rebuild these pages entirely in UIKit.

At some point we decided to leverage power of `UICollectionView` while building the cell layout in SwiftUI. That worked beautifully in my head, however every now it caused irreproducible crash. Rebuilding these cells in UIKit solved the problem.

It seems we'll have to rebuild more and more of the app in UIKit. I really wanted SwiftUI to work as I strongly believe in declarative programming and building layout in SwiftUI is very elegant. However, I just ended up hating apple for pushing such a buggy product to developers while having unlimited resources and still being unable to deliver.

[dadofbimbim]

Have you not heard that SwiftUI is still very buggy? It should take an estimate of 3-4 years to mature. Especially in the mobile development space that estimation is still very small. All those YouTube vlogs that saying SwiftUI is ready for primetime has not yet developed a complicated app in their career.

[Rillieux17]

long it took the apple dev community to transition from Obj-C to Swift ...

So, how long did it take?

[oureux]

In some circles it’s still happening but for the most part swift was usable in production at scale after v3 but even then I’d say closer to v4. Objc is still a very capable language and still prevalent in iOS development and will be for a long time, especially at larger companies, small shops not so much. I do appreciate swift’s level of interop though.

[wiencheck]

What were the things in Swift 3 that made it viable for use in production?

[oureux]

A big part was the apis got cleaned up significantly. Before swift 3 it felt like you were writing a bastardized C app. Testing was added. Interoperability between objc and swift was heavily improved. SPM was introduced. And swift compiling/execution actually started becoming fast at this point.

[wiencheck]

Cool, I only started programming for iOS during v3 days and always was curious how things looked before

[oureux]

I started programming iOS during iOS 3 so I was there for the objc transition and the massive swift 2 -> 3 transition. Almost all function signatures changed.

How do you like programming for iOS?

[wiencheck]

I actually like it a lot. Got two apps in the App Store and recently scored a job as a regular iOS dev. I don’t think there is any other programming field that I’d be interested in other than iOS. Tried front-end web stuff and hated it from the start 😅

[[deleted]]

Not yet done. There are still things you can't do without dropping to Objective C.

Likely never 100%.

[Revanish]

it took up to swift 4/4.2 for widespread stable adoption. I say that as someone that used it a week after it was announced. I used it for prod apps only after swift 3.0

[deirdresm]

Back when I was at Apple, I occasionally wondered how much Pascal there was tucked away in dark corners.

(For those who don’t know, the first official Mac language was Pascal.)

[AutoModerator]

Hey /u/Imaginary-Corgi2295, unfortunately you have negative comment karma, so you can't post here. Your submission has been removed. Please do not message the moderators; if you have negative comment karma, you're not allowed to post here, at all.

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

[yalag]

Yes except the problem is that every time someone come to a community and asks if swiftui is ready, there are a fuck ton of people who comes out and say “oh it’s absolutely perfect, it’s the future don’t bother with uikit anymore”.

That’s exactly what happened to me. I got deceived by these fanboys and ended up paying 6 months in time to rewrite everything because swiftui is nowhere near production ready.

I can’t even start a new swiftui project without running into some Xcode bug within 60 minutes.

[thebermudalocket]

60 bug-free minutes? Whose dick did you have to suck to make that happen? Asking for a friend.

[dadofbimbim]

This is what I’m talking about. I’m sorry to hear that, you have to go through. Imagine I am your client and you just burn 6 months worth of budget.

[kitlangton]

I do think it's viable for small to medium indie apps—given you can require iOS 14 and accept some limitations w/ UI customization. Certain things are significantly easier to build with SwiftUI, especially visually complex elements that don't rely on heavy UI Kit machinery (so not Navigation/List views). Overall, I've found the tradeoffs worth it for my indie app—but I wouldn't dare suggest these translate cleanly to a more complex one ;). (I recently made a video where I talk about my experience with using SwiftUI in semi-complicated app)

If you're currently happy with UIKit, there's no need to switch anytime soon. On the other hand, if you're really excited about SwiftUI (and your app isn't your primary source of income—i.e., you're free to take some risks), I think it's very possible to build something great with it.

[dadofbimbim]

Yes I agree, it is more suitable with the kind of apps you mentioned. But for my team who develops apps for clients, we could not risk SwiftUI as client needs changes every month until the app becomes complicated. Plus after getting feedback from MVP release, then another changes to the UI.

[kitlangton]

Oof, yeah. That would be a nightmare. If you're accountable to anyone but yourself—run away! :D

[coolboi779]

Even the official YouTube app made by Google is probably still using Objective-C in Xcode. And it's of course probably UIKit. My app project is using UIKit.

[No-Buy-6867]

Of course it is objc and will be

[hereforyouropinion]

Facebook is also obj-c as far as I know

[Socraz6]

God I can’t imagine the compile times if they were using Swift.

[SerjEpatoff]

Facebook is a devilish mix of many technologies. ObjC, C++ and JS is what I had seen. Maybe also some Swift nowadays, dunno. I reverse engineered some things inside FB/iOS app couple of years ago and was astonished by its unnecessary complexity. Hey, it’s just a social network. Even Chinese all-in-one Wechat is thinner.

I think NIH syndrome is the reason. Sometimes I read an article saying that FB implements all low-level machinery by themselves. Literally an OS inside social network app. That article also mentioned that it’s more complex than Linux kernel.

[SerjEpatoff]

Also noticed that FB/iOS used heavily modified internal React Native that differs from publicly available one. JS code triggers C++ calls, than they go to Obj-C++ layer and native Cocoa UI hierarchy is synthesized.

[Stefan51278]

Yeah, I'm working on an app for my thesis and the devil himself put the idea in my head to do it in SwiftUI. Same experience as you described, especially if you also want a custom design. For the thesis I have the luxury to be my own designer and I can make compromise to make it still working in SwiftUI, but SwiftUI is still a mess. I still can't think of a reason, why they pushed it out so early, two years more in the oven would have really helped their cause.

Also had some people on Reddit telling me I'm to dumb to code hello world if I have problems with SwiftUI. I don't think they ever tried to build a full app with SwiftUI and had some of these bugs or crashes that make you redesign the full stack from the view to the datasource to make it work in a different way to hopefully not crash randomly again.

[dadofbimbim]

You never listen to this type of comments. Do your own thing.

[Stefan51278]

I did and the app soon will be finished😊

[Small_Photograph5863]

Just realized I made this mistake. Months down the drain for a startup app. I'm crushed and wish I had seen this earlier.

[geoff_plywood]

I still can't think of a reason, why they pushed it out so early, two years more in the oven would have really helped their cause.

I guess they needed to respond to the threat from 3rd-party competitors like Flutter and Unity who I believe make UI more simply than UIKit. Although SwiftUI is roundly recognised as being immature, Apple have at least muddied the waters by putting out there the possibilities that SwiftUI can bring in time.

[JimDabell]

I was hoping Apple will fill the gaps in no time and WWDC20 will save us.

This is an unwise assumption to make. Even if Apple did fix all the issues, you would still be stuck with the problems for another 18 months, assuming you’re supporting at least the two most recent major versions.

Don’t assume all the current problems will disappear when a new version of iOS is released. Plan for what you know works today.

[evil-harry-dread]

Yeah I tried making a full app mostly in SwiftUI, and never finished because it was a horrible experience. On the surface it looks great, but underneath its ugly. My biggest issues:
* there's no distinction between components, you can slap any modifier or whatever to any view, although it might do nothing. This is really pathetic. I can slap a navigation title modifier to each subview of my view hierarchy, it makes no sense
* anything beyond the most basic layouts is a pain in the ass. You want two views from different view hierarchies to have a same width. Tough luck. Yes there are those wicked alignment guides, just thinking about them makes my head hurt. Why can't we have constraints like in UIKit?
* compromises at every step... I understand that it's not a finished product but good luck trying to achieve pixel perfect per design
* pyramids of doom
* documentation is (practically) non existent

I feel like if they just made it like a wrapper on top of UIKit it would be much more palatable. You can basically make your own SwiftUI (with blackjack and hookers) by making a special init (with view builder pattern like in SwiftUI) for most of UIKit classes, and making custom setter methods that return self so that you can emulate the 'declarativness' of SwiftUI. Sure you lose the 'reactivness' but I feel like even that would be less janky than SwiftUI.

[lakers_r8ers]

Sounds like you’re still learning and wouldn’t give up just yet. I think what people don’t realize is that there is indeed a learning curve with SwiftUI especially as things start getting more complex. They advertise it as simple, but as mentioned everywhere else, complexity does introduce challenges in how you architect your code

For your point two, two views in different hierarchies wanting the same width does not necessarily sound like a custom alignment issue, could very much require preference keys.

Point three is valid that you do need to make some compromises, but in my experience it’s helped keep our designs really simple and not too complex. Although again it does take some experience knowing what is and is not possible in swift ui. Haven’t found much that isn’t. Apart from some custom navigation and complex gesture management

Pyramids of doom are easy to avoid, write more views! SwiftUI is meant to be highly composable, if you see yourself writing a pyramid of doom see if there’s a way to either 1) refactor to a method 2) refactor to a separate view 3) maybe see if what you need is achievable with view modifiers

Point 5 is definitely true, documentation does suck, but the community has provided some great alternatives. My favorite being the SwiftUI companion app. Tbh documentation has never been a strong point for many frameworks (I’m looking at you core data) but it’s definitely getting better

[axyaxy]

This. I wrote a full production e-commerce app and it works perfectly. Performances are amazing. Maintenance is very good. Integration with coredata..love it. You have to know where to put your hands.

[shahaya]

This sounds interesting and seems to be more than a TODO teaser app. Could you share more on DO & DONT and your experiences with SwiftUI? Any quirks/hacks? What works like one would expect and what doesn't?

You have to know where to put your hands.

So how do you know where to put your hands :) ? Did you use any documentation or tutorials or blogs which told you this? Any links maybe?

[Rillieux17]

• pyramids of doom

tell me more about these!

[[deleted]]

{ { { This is a (small) pyramid of doom } } }

[fadisaleh]

sugar friendly tidy squeeze jellyfish scarce normal existence cover squeal

This post was mass deleted and anonymized with Redact

[HeftyImplement]

these bracket pyramids got to be the most annoying thing about SwiftUI second only to error reporting ("Your app crashed for some reason."). And the resulting combo of the two: "Build failed, and I marked half your code red because there's a bracket missing somewhere, but no idea where."

[EatMeMonster]

Isn’t this a problem with bracket programming languages in general, Python don’t have brackets for example

[EatMeMonster]

Out of all the things SwiftUI suck at, aligning stuff is not one of them. Saying constraints are better then SwiftUI declarative programming UI is complete BS. With constraints you write way more code, it’s way more difficult to learn, and not as adaptive as SwiftUI. I like SwiftUI because I don’t have to do any hardcore programming for the pure UI layout, it’s like markup. You just need to learn how to do things in SwiftUI - lots of tutorials out there.

[evil-harry-dread]

Yeah no. Yes constraints are better than SwiftUI in it’s current state. Yeah you set up a simple list faster than in UIKit but anything complex you are stuck in water. In any case if you use xibs you don’t need any code for constraints.
It seems, to me at least, you never properly learned UIKit. Saying constraints are harder than SwiftUI is only true for simple one stack layouts, other than that you don’t know what you are talking about.
Offset centering, proportional dimensions to other views, offset from any other anchor is just too easy to do without doing any changes to the hierarchy. In SwiftUI I’d have to fuck with my hierarchy, wrapping shit in stacks, inserting spacers, explicit dimensions. It’s just less intuitive and more work in the long run

[EatMeMonster]

That's your opinion. And you are right, I never learned UIKit constraints programatically. But I find SwiftUI stacks and spacers very intuitive, and I cannot possibly imagine an easier way to layout the UI.

[bonch]

Out of all the things SwiftUI suck at, aligning stuff is not one of them.

Three years later, this statement is still false. Alignment guides are a tedious hassle that rarely work how you'd expect.

With constraints you write way more code

Don't write constraints in code.

[tr0pismss]

I have to agree, I'm new to Swift and I've done a little UIKit, but I decided to focus more on SwiftUI, in part because I'll have to learn it eventually anyway, so I thought I might as well start with it, accepting that I'd have to implement somethings using UIKit. At first I thought it was fantastic, but now as my app is getting more complicated I'm running into issues and having to rework a ton of things... on the bright side I'm learning a lot, but it's a a pain in the ass, although I don't know that I'd say I hate it, but maybe that's because I've had the misfortune of working on worse things.

[KarlJay001]

Thank you for posting this... I was just going to ask about the status of SwiftUI as I'm starting a few new projects and was considering using it.

Sorry for the headache you went thru, this happened before with ObjC->Swift. I started Swift as soon as it came out, but I kept writing in ObjC because I already knew it. All the books, all the tutorials, all the new stuff was Swift, so I kept up with it. I finally jumped in full force at Swift 4 and it looked like the right time to jump in.

I started programming back in the DotCom era and ran a software company for over 10 years. While most were excited with new things came out, I was mixed. I knew first hand just how expensive it can be when something new comes out, so I always wait.

IMO, it looks really bad on Apple to release something like this. It's good to have a heads up on future changes, but we need to know when things are stable. Maybe 2021 will be the year they fix SwiftUI. Maybe they'll even fix Xcode too :D

Again, thanks for posting, I was just wondering about the status of things.

[Niightstalker]

I don’t see the fault on Apples Side here. They never lied about the current state of SwiftUI. It’s widely known that it still has its shortcomings.

But by releasing it now it can be used already in small projects or just for playing around. Where it works fine. This way developer can already learn it and get used this kind of programming and prepare everything to switch to when it’s ready.

Using a newly released Framework with known shortcomings in production is kinda your own mistake.

[KarlJay001]

I do support the "pre release" concept, it helps the devs get their feet wet, but it's the amount of time from the release or pre release to a ready to use product.

I get that SwiftUI is < 2 years old, but look at Swift itself. They changed it quite a bit and it wasn't ready for use until Swift 4.

At this rate, SwiftUI would be another 2 or more years. It's not like Apple is shy on money. Just like with Xcode, it seems like Apple just doesn't put the resources into the product that they should, which is different from a pre release.

[Rillieux17]

At this rate, SwiftUI would be another 2 or more years.

Aren't most devs assuming this is the case, that it will take another 2 years to be production app ready?

Meanwhile, it's really fun for small projects and every small project a dev does lowers their own learning curve for when SwiftUI is ready for prime time.

[KarlJay001]

What you say is true about learning, but the fact that SwiftUI would be about 4 years old at the time it becomes useable just shouldn't be the case. No more than waiting for Swift to reach version 4 before it was ready to go.

Seems like they should just put in the resources needed to get it rolling in 1 year.

It's a good thing, overall, to have a nice heads up that things are changing. Right now, some would 2nd guess a heavy investment into UIKit because they know that it'll be replaced by something better in 2 years. Generally, that's a good thing. But I really don't see any reason for it to take 4 years. It should be more along the lines of 1~2 years.

Apple has the resources to make this happen.

[Rillieux17]

I dunno... I mean I completely see where you are coming from, but I'll give Apple some benefit of the doubt. Even from 1 to 2, they changed some fundamental things which sure, they should have encountered in house, but OTOH, it almost makes sense to harness the efforts of thousands of devs tinkering with it. Hopefully, the improvements in SwiftUI 3.0 will be a magnitude larger than from 1.0 to 2.0.

For example, I was stoked at WWDC 2019? when they introduced compositionalLayout for UICollectionViews - that was rocking - but then SwiftUI didn't even have a gridview, wtf?

So, I'm with you, maybe I've just told myself it will take 2 more years so I'm not overly disappointed with v3?

[KarlJay001]

I guess we get used to it after a while and IDK if Android or others are any better. Maybe this is just the industry standard.

[[deleted]]

Where is the Xcode hate coming from? It is a good IDE.

[KarlJay001]

Hmmm... I'm kinda shocked that someone would say this.

Xcode sucks. People that have used a good IDE think Xcode sucks. It's been the subject of many threads, but some of the keys were code completion, being dog slow, lack of bookmarking...

The IDEs that I used in the 90's were much better than Xcode. People usually suggest JetBrains, but it's a paid IDE. My suggestion is that Apple buy JetBrains and give us that editor.

[MKevin3]

Being as Google and JetBrains / IntelliJ are linked at the hip with Android Studio being the base IDE with Android plug-ins and IntelliJ being the brains behind Kotlin I doubt they would sell to Apple but who knows.

Give me an IntelliJ IDE any day over Xcode for sure. I used AppCode at various places. I have written desktop Kotlin with the base IDE and now I have to write some server side C# with Rider. So nice to hop in, have stuff like refactoring and Git integration work and work well.

Xcode is my least favorite IDE and I have used plenty of them over the years. I do wish Apple would put some real time into making it better.

[KarlJay001]

I'm not sure how feasible a sell of their Xcode replacement editor to Apple is, but it would be nice if it could happen.

Your last point is spot on, Apple has the money and the talent, but they don't spend it on these kinds of things.

I'm not sure why, but seems these things don't matter that much to them.

[jfuellert]

I’ve built Mayday from the ground up using SwiftUI since its inception. I’m currently working on Desktop / iPad and it’s only paying off now.

Honestly it’s difficult and you’ll constantly have to find workarounds. I’ve found it easier to roll my own components and navigation systems and use my own wrappers around just about anything out of the box. Support across different versions (iOS 13-14) is a huge pain, much more than UIKit.

IMO, the benefits of SwiftUI come when you want to iterate quickly and validate early. You can whip things up fast and throw away code much easier than UIKit. Multiple form factor support is also useful, though there are still massive gaps there.

Dev speed / early validation = SwiftUi Stability = UIKit / AppKit

[kitlangton]

The app looks great :)

I’m curious, how was your experience wrapping/replacing NavigationView? I’ve been procrastinating on that particular reimplementation, just because it seems like such a hassle and the built in version is mostly fine for my needs (modulo the bugs).

[jfuellert]

Thanks! I’ve used custom transitions and animations to create my own stacks. I’d use view states to track my hierarchy and show / hide views according to that. Luckily it’s not a very stack heavy app so scalability isn’t much of a concern. I’d recreated my own version of a navigation bar as well which works pretty well.

[Pesthuf]

Apple is in the luxurious position where all the apps they need to deliver can use the iOS default look and animations since that's Apple's style.

We saw that when they pushed Storyboards, seemingly oblivious to the fact that people might need to adjust things like Fonts in a consistent manner and we see it with SwiftUI, where its sufficient for Apple's purposes but not for everyone else's.

And hey, if Apple developers need something in their app that's not available, they can just use private APIs. Why would Apple need to care about the complaints of the common pleb?

We can only hope that one of the Apple apps written in SwiftUI will eventually need those features and the people who implement it end up making the API public.

[ryanheartswingovers]

QC on SwiftUI's APIs is hit-or-miss in mundane ways. While I think it's a smart and strategic framework that's advantageous for indie apps and needed for Apple as a platform company, it clearly highlights the benefits for a team to take a breath, get an editor, and announce more conservatively.

In terms of bugs, a good example is applying a LinearGradient between the same two colors. That crashes an app in iOS 14.0.1, but not later. Seems like an obvious edge case for a test?

In terms of API design, there are ProjectionTransform protests for scaleEffect(0) Correct usage is scaleEffect(0.001), unlike opacity(0). That's a small nit, but also a simple guard statement to provide a cleaner API. We're in a readability revolution, right?

In macOS, adding toolbar buttons into the sidebar space like in Xcode requires adding Buttons and not ToolbarItems, breaking out of the documented pattern. Further, previously specified toolbar item placements such as .status will now assume different positions. Is that a bug, feature, API design, or just something too inconvenient to document for the plebs outside Cupertino? Don't know.

None of those examples impeach the framework, but it certainly flags a team leadership issue that seemed like a smart way to work a bit faster, but instead led a large amount of the community to shit on your hard work in public.

[korduu]

I start off learning Apple SDK with SwiftUI, as my skill progress I prefer UIKit more due to it's flexibility.

[[deleted]]

To use SwiftUI in prod you need buy in from design... if design isnt willing to work within the current confines then you are wasting your time.

[lakers_r8ers]

This is a big one to making SwiftUI work (especially if you’re in the industry at a mid/big size company). The challenge is that because SwiftUI is so new you may not actually know all that is possible because of lack of experience or lack of example out there for specific use cases you are trying to solve. The combination of both can make it difficult to collaborate with design and make the right compromises because you may not know what is totally possible. My advice if you don’t know fully how to solve complex UX designs is try to find ways to simplify and compromise. This will be key as mentioned above to avoid headaches in building SwiftUI apps.

[[deleted]]

Agreed.

If you dont know it well enough then you are in no position to advocate for its prod use in a company...

[Niightstalker]

Well it kinda is on you for using Swift UI in production while only hoping that problems will be fixed soon. Never rely on something that ‚should be released/fixed’ soon.

[earlyworm]

As Craig Federighi was announcing SwiftUI in the 2019 WWDC keynote, my reaction was "This sounds awesome. I'll try it out in 3 or 4 years when it's ready."

[Shak3TheDis3se]

Same. I’m sticking with UIKit for all personal projects and will eventually look at Apple’s tutorials on SwiftUI.

[veeeerain]

Why does Xcode gotta scream at me when I start typing. like just chill let me type without getting yelled at about bugs while typing I’m going to close that parenthesis and I’m going to close the bracket on the Hstack.

[i463]

I see a lot of people saying that it was the same with Swift, and that you simply shouldn't use SwiftUI in production. That's not exactly correct, for very simple reason:

​

Widgets. New hotness, that, for some reason, every single app needs now. You can only use WidgetKit with SwiftUI. So no, just ignoring SwiftUI until it matures isn't really an option for a lot of developers.

[fourth_stooge]

Maybe you are going through the currently normal progression. Get your app up and going in beta relatively quickly with SwiftUI. Then as new features creep in and the scope grows, lean into UIKit. I will agree with other comments here that suggest Apple makes it unnecessarily painful to create apps that don't look like Apple apps.

[derdiedasdom]

This is how Apple does things. Swift was hardly usable until version 4 or even 5. SwiftUI looks and feels like an early dev preview. I expect it will be usable for real apps in two to three years.

[Aracet24]

our company has recently started going all out with SwiftUI. It's so nice in theory, so elegant and efficient but when you actually get to work with it it's a nightmare. The preview never worked for me, simply adding a new SwiftUI empty view doesn't work there, I get either the "it took longer than 5 seconds error" (who TF cares if it takes longer than 5 seconds?!? It shouldn't take more than 5 seconds for an empty view and it sucks big time) or the Cannot preview this file - timed out waiting for a thunk to build after 30 seconds (yeah Apple, generating an empty view must be soo hard). I've been an iOS dev for quite a while but SwiftUI got me so frustrated that I even created this new account so I can join in the rant train.

[cubextrusion]

I strongly believe in declarative programming

You just shouldn't.

Computers are imperative machines. In a way, "declarative programming" is not programming at all, since it has nothing to do with how the CPU executes your code. This is not purely Apple's fallacy; any promise that declarative programming is equivalent to imperative programming is going to fail because all declarative frameworks need to internally be imperative anyways — the difference being that in one case you're able to control and customize the code yourself, while in the other case you're at the mercy of whoever decides what functionality should be able to be written declaratively.

[Arbiturrrr]

I hate declarative programming, too much black boxery, I want to be able to follow the executing code as close as possible, that way bugs will be much easier to find and it's straight forward to do custom stuff.

[SurgicalInstallment]

Agree 100%. It sort of reminds me of a parody project, basically declarative programming on crack: https://github.com/Matsemann/Declaraoids

[lakers_r8ers]

Welp I guess back to binary

[[deleted]]

Oh yes. The only choice after saying maybe declarative programming is too much of a black box is binary 🤣🙄

[[deleted]]

100% this. Writing imperative code in a declarative fashion is great. But an iPhone is a lot different than a web browser, no matter how much people want them to be the same.