9 ms·

Should I use SwiftUI in production? A code-to-code comparison to help you decide

94 points by danielwbean 6y ago

echelon 6y ago
Apple's going to keep this platform closed, so you should write in a cross-platform framework. Don't adopt their tools or dance to their beat. The best way to protest Apple's iPhone dominance is to write cross-platform, non-native code. iOS should be a second class citizen.
- saagarjha 6y ago
  You mean make every platform a second-class citizen?
  - LeoNatan25 6y ago
    While I agree about the non-native sentiment, I feel like your comment describes SwiftUI exactly right on both UIKit and AppKit.
    - readarticle 6y ago
      For now. It’s still a first class citizen receiving the full attention & buy in of the platform to a level even Swift itself didn’t receive this early on AFAICT (iOS 14 widgets can only be written with SwiftUI).
      - LeoNatan25 6y ago
        That's an arbitrary limitation. Some of Apple's widgets are not written using SwiftUI. Just like Swift, I foresee SwiftUI being a black sheep for a very long time.
- quantummkv 6y ago
  And let the user experience of the paying users suffer due to the completely uncanny valley and frankly second tier implementation of the cross platform toolkits? Sorry my friend, it's the users that take the first priority and should take the first priority, not the developers or anyone else.
  - echelon 6y ago
    > Sorry my friend, it's the users that take the first priority and should take the first priority, not the developers or anyone else. Our field, ethics, and freedom take priority over users. If they don't, you should reevaluate what you're doing. In servicing those concerns, users will win.
    - ajconway 6y ago
      The whole field of engineering is about solving real, immediate tasks that users have. What you're describing is politics.
- jamil7 6y ago
  How is this the best way of protesting? Apple doesn’t care if you write an app in React Native.
snayebaziz 6y ago
Disclaimer: I make an app that is basically WYSIWYG SwiftUI for designers (https://www.detailspro.app https://www.detailspro.app). I think the author put it best with "If you've undergone the mental paradigm shift, the productivity gains were worth the minor setbacks, which really weren’t so hard to fix." My career has included periods where I had a React day job and a bunch of iOS side projects. So many times, I'd come home from work, stoked on React, and look at iOS and wish it were declaratively already. I actually took a stab at an open source, declarative UI library that's still on GitHub. SwiftUI, IMO, brings the smarts of React, with many dashes of magic that only Apple HIG magic that only Apple could come up with. Definitely, there are plenty of holes today, but I never, ever, ever have to hook up a UITableViewDataSource and a UITableViewDelegate ever again, and for that I am infinitely thankful. Looking purely ahead at SwiftUI and what it will do for Apple platform years from now. I recommend anybody who is thinking about it to try it out. Soon enough, I'll forget the signatures of the UITableView stuff, and other UIKit stuff, happily.
- sudoit 6y ago
  Nice! I love you app. I’ve been working on a similar one I call App Maker that’s more for developers. https://appmakerios.com https://appmakerios.com I’ve even made the entire App Maker app inside SwiftUI to prove to myself just have viable it is.
  - snayebaziz 6y ago
    Your app is so impressive! I remember seeing it on App Airport. Full-SwiftUI apps FTW!
jamil7 6y ago
I have two apps in the Store built with SwiftUI, one ported from UIKit and the other started from scratch in SwiftUI. I’ve been “all in” since it’s announcement in 2019, despite suffering through it’s growing pains. I really wish the framework was opened up or at least distributed separately to OS updates, watching how open and quick the Android team are with Jetpack Compose really shows the different approaches to library development and Apple’s feels really outdated.
nrvn 6y ago
as a side note to triplebyte: Introducing text-shadow on code blocks does not add to readability. Using low contrast color schemes does not add to accessibility.
yoz-y 6y ago
I think the important thing to say is that there are already APIs which are SwiftUI only. This trend will definitely continue and in (near) future you won't have much choice. While SwiftUI definitely lacks some finer customization of default elements (like the mentioned hairlines in the List/Form view), you can re-implement any UIKit view yourself in the end. Lazy loading is perfectly doable, I think the author could have shown an example on how to do the carousel properly with a full example of the UIKit code.
lunixbochs 6y ago
I think UIActivityIndicatorView is just: ProgressView() .progressViewStyle(CircularProgressViewStyle())
Jakobeha 6y ago
> As of June 2020, Apple Reports that 92% of devices introduced in the last 4 years use iOS 13, while 81% of all devices (including the oldest) use iOS 13. Some businesses are not willing to part with that remaining 8%-19% of users. I'm surprised that so many people have the latest iOS. I was reluctant to use SwiftUI because I thought that more people have older iPhones which wouldn't support it.
- wlesieutre 6y ago
  iOS 14 support goes back to the 6S and original SE, so the newest unsupported phone is the iPhone 6 from September 2014. Not a lot of those still around.
  - bsaul 6y ago
    Just for the anecdote : as an owner of an iphone6, i have to say this phone was perfectly functional. it made me feel extremely bad to buy a se2 just so that i could test my code on a real device. moving from iphone6 to se2 is the first time i've felt disappointed by my new iphone. it's bulkier, the battery lasts about just as long, and the screen feels cheap.
    - wlesieutre 6y ago
      I suppose when they were dropped in iOS 12 it wasn’t nearly as old. They’ve done well to keep the same devices supported since then. You probably don't want to buy a new phone again, but I recently went from an SE (2016) to a 12 Mini and can tell you it's a pretty great device. If the new SE feels too large, you might like it too. More expensive, of course.
- saagarjha 6y ago
  iOS adoption rates are extremely high these days, especially with the long support periods devices get and various ways to reduce friction while updating.
  - jonplackett 6y ago
anupamchugh 6y ago
I'd love to see a SwiftUI's API implementation for AVFoundation in their next iteration. Building camera based SwiftUI apps would get much easier.
mikenew 6y ago
I've been working full time on an app in SwiftUI for the past 8 months or so. I'll sum it up this way: I frequently oscillate between thinking "This is amazing, it truly is a joy to work with SwiftUI" and "Holy FUCK this is the most infuriating thing I've ever experienced in my life". I can't comment on the documentation, because there isn't any. The closest thing you get is the WWDC videos from the past few years where most things are outdated anyway. There's also lots of third party tutorials and what not that open with "Apple doesn't say anything about how this works, but I think I might have figured it out". And a lot of those third party sources are pretty good, but still. It's hardly ideal. There are also a lot of inscrutable little edge cases where something just doesn't work, and there's hardly any path to figuring out why. Scrolling performance will tank, for example, after some trivial change. The framework "works like magic", until it doesn't. And you're stuck tweaking random things hoping something makes a difference. BUT, at the same time, it's awesome. Code reuse is like, a real thing this time, not just something that works on paper but not in practice. You can compose things very quickly and succinctly, and you no longer have the unreadable, un-mergeable, unsearchable, existential nightmare that was storyboards. When it works, it really is fantastic. Don't count on the "live preview" though. That thing never works for anything other than the most trivial of examples. If I could go back to 8 months ago, I probably would have chosen differently. But it is clear that SwiftUI is the future, and within a year or two it will be unequivocally better than UIKit. So if you're starting now... maybe. Just be prepared for some pain.
- asimpletune 6y ago
  The only documentation you can count on is to just read the code. It’s all pretty well commented and the interfaces make sense. I’d say the difficulty is it’s not very discoverable, and you actually have to watch the wwdc videos to learn the high level concepts. The only discoverability you get is just surfing around, reading the code. I think it’s all in SwiftUI though, which is obviously a huge file.
  - saagarjha 6y ago
    What code? SwiftUI is closed source.
deleted 6y ago
[deleted]
deleted 6y ago
[deleted]
auggierose 6y ago
For a new app, it is a no brainer. I've been coding up an interface in SwiftUI in the last week that would have taken me ages with UIKit. And the resulting interface is so much better, because tuning a small detail corresponds to a single line or two instead of the agony of spinning up a new UIViewController ...
- LeoNatan25 6y ago
  If you want your new app to be more than just a simple view, have polish, have acceptable performance in simple use cases, then it is quite the “yes brainer”. SwiftUI has considerable shortcomings, very real and unfathomable limitations, and many, many performance issues. You might be fooled by how quickly you can come up with a skeleton interface, but that doesn’t make an app. Especially for people who are coming from “React” as many have said here, once they hit those limitations, they would be fish out of water, just like React Native “developers” are dumbfounded what to do once their app doesn’t work as expected, or slows down seemingly inexplicable. SwiftUI is a nice experiment, but it’s not a serious UI framework, and won’t be for a very long time.
  - auggierose 6y ago
    It is a very serious UI framework. People from React (I am not one of them) just understand this better, because they know that the reactive approach is superior for UI. People who have not experienced that have often a problem grasping this simple fact. SwiftUI has annoying bugs. I haven't hit performance issues yet. But if you encounter these issues you can always escape to UIKit. I already did several times, I have my little set of SwiftUI components already which replace the original ones. For example, Image is a buggy component which doesn't display SVG assets properly. I made an XImage component which fixes that. On the other hand, doing everything in UIKit from the start is just a waste of developers resources. My time is too precious for that.
    - LeoNatan25 6y ago
      I guess giving your users a good experience is also "a waste of developers resources". Just like with RN.
lupinglade 6y ago
SwiftUI is pretty and a pleasure to work with when you want to do something that is expected. The moment you need something more, SwiftUI is not your friend anymore. Too much is hidden away in internal implementation details and much of it is broken, incomplete or completely missing. It may be adequate on iOS, but on a Mac it is nowhere near usable at this stage.
- bartvk 6y ago
  How did you find out about this?
  - lupinglade 6y ago
    First hand experience.
shinycode 6y ago
I spent a year building an app from scratch in pure SwiftUI. The first few month were difficult because of the bugs and missing doc. But then it got refined and enhanced. I could do almost everything I wanted with it and this years release brought well waited features. Thanks to Big Mountain Studio’s work on documentation and lots of blogs with nice articles (swift with majid) it’s possible to get a good grasp on the subject. It’s definitely the future and a real joy to work with, definitely so in new projects. The app I built is bulletweek.
mushishi 6y ago
My personal experience: after working on existing UIKit application for over a month or so, I spent a couple of weeks trying SwiftUI out in last summer, by first watching most of the Stanford's great SwiftUI iOS lectures https://www.youtube.com/watch?v=SIYdYpPXil4&list=PLpGHT1n4-mAtTj9oywMWoBx0dCGd51_yG&index=13 https://www.youtube.com/watch?v=SIYdYpPXil4&list=PLpGHT1n4-m... With the little experience I got, I agree with mikenew's comment. SwiftUI felt like an expressive way to define UI elements, but I had some small weird details that took long time to solve, perhaps because I defined something in a way that wasn't supposed to. Ultimately, I mostly got the code to look in the way I preferred, but for example regarding animation or gestures there were some problematic details I didn't want to spend time to get exactly right. Overall I enjoyed it much more than UIKit but I would hesitate to use it in the future in a professional setting without properly investigating how mature it is at that point of time. If anyone is interested, here's the Shogi app I developed, intended for two local two players, and as a reminder I am quite new to the iOS ecosystem: https://github.com/EvidentSolutions/toodim https://github.com/EvidentSolutions/toodim
- cableshaft 6y ago
  Thank you for pointing out the Stanford lectures. I wasn't aware of them and they look really good to get up to speed. I messed around with SwiftUI a while back but I haven't for the past year, so those should help me get back into it. The game looks very impressive for being new to iOS. If you haven't looked into it yet, I recommend learning SpriteKit as well. Its animation system (SKAction) is pretty nice. I actually ended up basically re-implementing it in C# for another game I was working on, since it wasn't terribly hard to do (got the subset of actions I needed working in a couple of hours), and you can be very expressive with it, once you grok groups and sequences.
makecheck 6y ago
Where it works, SwiftUI is indisputably the most compact and maintainable form of data bindings and auto-layout that you have. It should be used immediately for those working cases. It is therefore critical to also learn the bridges (e.g. how to get a platform-specific view or controller out of SwiftUI) because you will also want those somewhere. Note, I have seen Herculean attempts on blogs, etc. to shoehorn ungodly amounts of hacks into SwiftUI objects to get certain behaviors that don’t exist yet; That Is Wrong. Do not fight this framework; either use a native element with full functionality and a bridge, or a succinct SwiftUI description. It is clear that “someday” everything will have a nice SwiftUI version and it isn’t worth faking it for now wherever it doesn’t work yet.
- LeoNatan25 6y ago
  What I don’t understand is why Apple made accessing the underlying UIKit/AppKit elements such a fight in the first place. They knew they couldn’t encompass the full breadth of these frameworks in many years to come, so why not allow easy access to underlying implementation details, to allow fine tuning for those that want/need it. Really dumb decision making, but that seems to be a lot of what Apple is doing in the last few years.
rnikander 6y ago
I'm using it in production, but a few situations that I could handle with autolayout constraints seem impossible in SwiftUI. Examples here: https://developer.apple.com/forums/thread/664283 https://developer.apple.com/forums/thread/664283 In these 1% cases, I can make things "good enough" by hacking it with SwiftUI. But it bothers me. Sometimes I want to go past "good enough" and reach for "perfect". I could do that with UIKit/AppKit, but with SwiftUI they haven't documented (or created) the layout system to allow it.
lukeh 6y ago
Agree with all the comments here. Once you get your head around it, it’s fast and capable – until you run into a corner case it doesn’t support (attributed text was the big one for me). Then you end up needing to wrap UIKit, which is straightforward except there is a new set of corner cases to deal with, eg. content sizing, embedding in native scroll views, etc. It all does work in the end but it takes a while to get there, and I know I’ll be replacing a lot of code as SwiftUI evolves. Having said that, it’s probably a better situation than releasing a half-baked but more featured framework. Also yes, the documentation is terrible. A few things I found helpful - https://gist.github.com/lhoward https://gist.github.com/lhoward
rnikander 6y ago
Most of what I like about SwiftUI is the syntax. I wonder if I'd be better off using Swift function builder syntax to build UI/NSView hierarchies and layout.
philipyoungg 6y ago
I've been using SwiftUI for macOS and iOS fully to make stayinsession.com It's my first app while I'm learning Swift. Coming from React, the transition is relatively easy. I did learn some UIKit and AppKit and find it extremely verbose. The thing is SwiftUI is not really ready for prime time. There's a lot of bug and inconsistencies here and there. Things that work on iOS doesn't work on MacOS. Vice versa. Keyboard navigation and input focus sucks. Minor update (like from iOS 13.1 to 13.2) could break some part of the app. Also performance is not optimized. I have a slideshow that took at least 10% CPU on Mac all the time. That limitation makes me decides to use animation sparingly across the app. But again, the productivity is no brainer. Basically my iOS and macOS app lives in monorepo because there's ~95% code sharing.
svntid 6y ago
1 min glance and I came to the conclusion that I should not use it - thanks cowboy
worik 6y ago
It is a bit like Linux in 1997. Mostly works....
andrekandre 6y ago
> Even if you use a LazyHStack, introduced in iOS 14, views will not be loaded until they appear, but they'll remain in memory thereafter. well, thats a dealbreaker if i ever saw one... i wonder if this is "just a bug" and gets fixed in an ios 14.x update...
valuearb 6y ago
“Unlike a collection view, all items will be loaded into memory at once.” I recently had to rewrite a UIView where the dev implemented a 3 by 30 scrollable image display only using StackViews. Despite image disk caching it took forever to load, the table was a veritable forest of spinners for 30 seconds. Re-Implementing as CollectionView only partially improved the display, eventually I had to add a memory cache to make it snappy. I’m at start of switching to SwiftUI right now for a new project and these are the kinds of edge cases that worry me. But as long as I can build UI in UIKit too I’m okay with it. Build the 90% that is easy on SwiftUI, and the 10% performant pieces in UIKit and I should still be much faster. So far it reminds me of a version of React not crippled by JavaScript. I once spent a year on a React Native project as iOS frameworks lead, and it was a nightmare. Terrible build problems every time they added new libraries, and debugging problems that crossed the Swift/React boundary was at times nearly impossible. Nothing like being blamed for endemic updating problems for months while pulling your hair out trying everything to solve them. Then to have the React lead quietly say “oh, I found the problem” during an offsite. The rest of the company never remembers that, just the months of the iOS team looking incompetent. This is so far a piece of cake by comparison, with far higher code quality.

94 points by danielwbean 6y ago

Apple's going to keep this platform closed, so you should write in a cross-platform framework. Don't adopt their tools or dance to their beat. The best way to protest Apple's iPhone dominance is to write cross-platform, non-native code. iOS should be a second class citizen.

saagarjha 6y ago
You mean make every platform a second-class citizen?
- LeoNatan25 6y ago
  While I agree about the non-native sentiment, I feel like your comment describes SwiftUI exactly right on both UIKit and AppKit.
  - readarticle 6y ago
    For now. It’s still a first class citizen receiving the full attention & buy in of the platform to a level even Swift itself didn’t receive this early on AFAICT (iOS 14 widgets can only be written with SwiftUI).
    - LeoNatan25 6y ago
      That's an arbitrary limitation. Some of Apple's widgets are not written using SwiftUI. Just like Swift, I foresee SwiftUI being a black sheep for a very long time.
quantummkv 6y ago
And let the user experience of the paying users suffer due to the completely uncanny valley and frankly second tier implementation of the cross platform toolkits? Sorry my friend, it's the users that take the first priority and should take the first priority, not the developers or anyone else.
- echelon 6y ago
  > Sorry my friend, it's the users that take the first priority and should take the first priority, not the developers or anyone else. Our field, ethics, and freedom take priority over users. If they don't, you should reevaluate what you're doing. In servicing those concerns, users will win.
  - ajconway 6y ago
    The whole field of engineering is about solving real, immediate tasks that users have. What you're describing is politics.
jamil7 6y ago
How is this the best way of protesting? Apple doesn’t care if you write an app in React Native.

snayebaziz 6y ago

Disclaimer: I make an app that is basically WYSIWYG SwiftUI for designers (https://www.detailspro.app https://www.detailspro.app). I think the author put it best with "If you've undergone the mental paradigm shift, the productivity gains were worth the minor setbacks, which really weren’t so hard to fix." My career has included periods where I had a React day job and a bunch of iOS side projects. So many times, I'd come home from work, stoked on React, and look at iOS and wish it were declaratively already. I actually took a stab at an open source, declarative UI library that's still on GitHub. SwiftUI, IMO, brings the smarts of React, with many dashes of magic that only Apple HIG magic that only Apple could come up with. Definitely, there are plenty of holes today, but I never, ever, ever have to hook up a UITableViewDataSource and a UITableViewDelegate ever again, and for that I am infinitely thankful. Looking purely ahead at SwiftUI and what it will do for Apple platform years from now. I recommend anybody who is thinking about it to try it out. Soon enough, I'll forget the signatures of the UITableView stuff, and other UIKit stuff, happily.

sudoit 6y ago
Nice! I love you app. I’ve been working on a similar one I call App Maker that’s more for developers. https://appmakerios.com https://appmakerios.com I’ve even made the entire App Maker app inside SwiftUI to prove to myself just have viable it is.
- snayebaziz 6y ago
  Your app is so impressive! I remember seeing it on App Airport. Full-SwiftUI apps FTW!

jamil7 6y ago

I have two apps in the Store built with SwiftUI, one ported from UIKit and the other started from scratch in SwiftUI. I’ve been “all in” since it’s announcement in 2019, despite suffering through it’s growing pains. I really wish the framework was opened up or at least distributed separately to OS updates, watching how open and quick the Android team are with Jetpack Compose really shows the different approaches to library development and Apple’s feels really outdated.

nrvn 6y ago

as a side note to triplebyte: Introducing text-shadow on code blocks does not add to readability. Using low contrast color schemes does not add to accessibility.

yoz-y 6y ago

I think the important thing to say is that there are already APIs which are SwiftUI only. This trend will definitely continue and in (near) future you won't have much choice. While SwiftUI definitely lacks some finer customization of default elements (like the mentioned hairlines in the List/Form view), you can re-implement any UIKit view yourself in the end. Lazy loading is perfectly doable, I think the author could have shown an example on how to do the carousel properly with a full example of the UIKit code.

lunixbochs 6y ago

I think UIActivityIndicatorView is just: ProgressView() .progressViewStyle(CircularProgressViewStyle())

Jakobeha 6y ago

> As of June 2020, Apple Reports that 92% of devices introduced in the last 4 years use iOS 13, while 81% of all devices (including the oldest) use iOS 13. Some businesses are not willing to part with that remaining 8%-19% of users. I'm surprised that so many people have the latest iOS. I was reluctant to use SwiftUI because I thought that more people have older iPhones which wouldn't support it.

wlesieutre 6y ago
iOS 14 support goes back to the 6S and original SE, so the newest unsupported phone is the iPhone 6 from September 2014. Not a lot of those still around.
- bsaul 6y ago
  Just for the anecdote : as an owner of an iphone6, i have to say this phone was perfectly functional. it made me feel extremely bad to buy a se2 just so that i could test my code on a real device. moving from iphone6 to se2 is the first time i've felt disappointed by my new iphone. it's bulkier, the battery lasts about just as long, and the screen feels cheap.
  - wlesieutre 6y ago
    I suppose when they were dropped in iOS 12 it wasn’t nearly as old. They’ve done well to keep the same devices supported since then. You probably don't want to buy a new phone again, but I recently went from an SE (2016) to a 12 Mini and can tell you it's a pretty great device. If the new SE feels too large, you might like it too. More expensive, of course.
saagarjha 6y ago
iOS adoption rates are extremely high these days, especially with the long support periods devices get and various ways to reduce friction while updating.
- jonplackett 6y ago

anupamchugh 6y ago

I'd love to see a SwiftUI's API implementation for AVFoundation in their next iteration. Building camera based SwiftUI apps would get much easier.

mikenew 6y ago

I've been working full time on an app in SwiftUI for the past 8 months or so. I'll sum it up this way: I frequently oscillate between thinking "This is amazing, it truly is a joy to work with SwiftUI" and "Holy FUCK this is the most infuriating thing I've ever experienced in my life". I can't comment on the documentation, because there isn't any. The closest thing you get is the WWDC videos from the past few years where most things are outdated anyway. There's also lots of third party tutorials and what not that open with "Apple doesn't say anything about how this works, but I think I might have figured it out". And a lot of those third party sources are pretty good, but still. It's hardly ideal. There are also a lot of inscrutable little edge cases where something just doesn't work, and there's hardly any path to figuring out why. Scrolling performance will tank, for example, after some trivial change. The framework "works like magic", until it doesn't. And you're stuck tweaking random things hoping something makes a difference. BUT, at the same time, it's awesome. Code reuse is like, a real thing this time, not just something that works on paper but not in practice. You can compose things very quickly and succinctly, and you no longer have the unreadable, un-mergeable, unsearchable, existential nightmare that was storyboards. When it works, it really is fantastic. Don't count on the "live preview" though. That thing never works for anything other than the most trivial of examples. If I could go back to 8 months ago, I probably would have chosen differently. But it is clear that SwiftUI is the future, and within a year or two it will be unequivocally better than UIKit. So if you're starting now... maybe. Just be prepared for some pain.

asimpletune 6y ago
The only documentation you can count on is to just read the code. It’s all pretty well commented and the interfaces make sense. I’d say the difficulty is it’s not very discoverable, and you actually have to watch the wwdc videos to learn the high level concepts. The only discoverability you get is just surfing around, reading the code. I think it’s all in SwiftUI though, which is obviously a huge file.
- saagarjha 6y ago
  What code? SwiftUI is closed source.

deleted 6y ago

[deleted]

deleted 6y ago

[deleted]

auggierose 6y ago

For a new app, it is a no brainer. I've been coding up an interface in SwiftUI in the last week that would have taken me ages with UIKit. And the resulting interface is so much better, because tuning a small detail corresponds to a single line or two instead of the agony of spinning up a new UIViewController ...

LeoNatan25 6y ago
If you want your new app to be more than just a simple view, have polish, have acceptable performance in simple use cases, then it is quite the “yes brainer”. SwiftUI has considerable shortcomings, very real and unfathomable limitations, and many, many performance issues. You might be fooled by how quickly you can come up with a skeleton interface, but that doesn’t make an app. Especially for people who are coming from “React” as many have said here, once they hit those limitations, they would be fish out of water, just like React Native “developers” are dumbfounded what to do once their app doesn’t work as expected, or slows down seemingly inexplicable. SwiftUI is a nice experiment, but it’s not a serious UI framework, and won’t be for a very long time.
- auggierose 6y ago
  It is a very serious UI framework. People from React (I am not one of them) just understand this better, because they know that the reactive approach is superior for UI. People who have not experienced that have often a problem grasping this simple fact. SwiftUI has annoying bugs. I haven't hit performance issues yet. But if you encounter these issues you can always escape to UIKit. I already did several times, I have my little set of SwiftUI components already which replace the original ones. For example, Image is a buggy component which doesn't display SVG assets properly. I made an XImage component which fixes that. On the other hand, doing everything in UIKit from the start is just a waste of developers resources. My time is too precious for that.
  - LeoNatan25 6y ago
    I guess giving your users a good experience is also "a waste of developers resources". Just like with RN.

lupinglade 6y ago

SwiftUI is pretty and a pleasure to work with when you want to do something that is expected. The moment you need something more, SwiftUI is not your friend anymore. Too much is hidden away in internal implementation details and much of it is broken, incomplete or completely missing. It may be adequate on iOS, but on a Mac it is nowhere near usable at this stage.

bartvk 6y ago
How did you find out about this?
- lupinglade 6y ago
  First hand experience.

shinycode 6y ago

I spent a year building an app from scratch in pure SwiftUI. The first few month were difficult because of the bugs and missing doc. But then it got refined and enhanced. I could do almost everything I wanted with it and this years release brought well waited features. Thanks to Big Mountain Studio’s work on documentation and lots of blogs with nice articles (swift with majid) it’s possible to get a good grasp on the subject. It’s definitely the future and a real joy to work with, definitely so in new projects. The app I built is bulletweek.

mushishi 6y ago

My personal experience: after working on existing UIKit application for over a month or so, I spent a couple of weeks trying SwiftUI out in last summer, by first watching most of the Stanford's great SwiftUI iOS lectures https://www.youtube.com/watch?v=SIYdYpPXil4&list=PLpGHT1n4-mAtTj9oywMWoBx0dCGd51_yG&index=13 https://www.youtube.com/watch?v=SIYdYpPXil4&list=PLpGHT1n4-m... With the little experience I got, I agree with mikenew's comment. SwiftUI felt like an expressive way to define UI elements, but I had some small weird details that took long time to solve, perhaps because I defined something in a way that wasn't supposed to. Ultimately, I mostly got the code to look in the way I preferred, but for example regarding animation or gestures there were some problematic details I didn't want to spend time to get exactly right. Overall I enjoyed it much more than UIKit but I would hesitate to use it in the future in a professional setting without properly investigating how mature it is at that point of time. If anyone is interested, here's the Shogi app I developed, intended for two local two players, and as a reminder I am quite new to the iOS ecosystem: https://github.com/EvidentSolutions/toodim https://github.com/EvidentSolutions/toodim

cableshaft 6y ago
Thank you for pointing out the Stanford lectures. I wasn't aware of them and they look really good to get up to speed. I messed around with SwiftUI a while back but I haven't for the past year, so those should help me get back into it. The game looks very impressive for being new to iOS. If you haven't looked into it yet, I recommend learning SpriteKit as well. Its animation system (SKAction) is pretty nice. I actually ended up basically re-implementing it in C# for another game I was working on, since it wasn't terribly hard to do (got the subset of actions I needed working in a couple of hours), and you can be very expressive with it, once you grok groups and sequences.

makecheck 6y ago

Where it works, SwiftUI is indisputably the most compact and maintainable form of data bindings and auto-layout that you have. It should be used immediately for those working cases. It is therefore critical to also learn the bridges (e.g. how to get a platform-specific view or controller out of SwiftUI) because you will also want those somewhere. Note, I have seen Herculean attempts on blogs, etc. to shoehorn ungodly amounts of hacks into SwiftUI objects to get certain behaviors that don’t exist yet; That Is Wrong. Do not fight this framework; either use a native element with full functionality and a bridge, or a succinct SwiftUI description. It is clear that “someday” everything will have a nice SwiftUI version and it isn’t worth faking it for now wherever it doesn’t work yet.

LeoNatan25 6y ago
What I don’t understand is why Apple made accessing the underlying UIKit/AppKit elements such a fight in the first place. They knew they couldn’t encompass the full breadth of these frameworks in many years to come, so why not allow easy access to underlying implementation details, to allow fine tuning for those that want/need it. Really dumb decision making, but that seems to be a lot of what Apple is doing in the last few years.

rnikander 6y ago

I'm using it in production, but a few situations that I could handle with autolayout constraints seem impossible in SwiftUI. Examples here: https://developer.apple.com/forums/thread/664283 https://developer.apple.com/forums/thread/664283 In these 1% cases, I can make things "good enough" by hacking it with SwiftUI. But it bothers me. Sometimes I want to go past "good enough" and reach for "perfect". I could do that with UIKit/AppKit, but with SwiftUI they haven't documented (or created) the layout system to allow it.

lukeh 6y ago

Agree with all the comments here. Once you get your head around it, it’s fast and capable – until you run into a corner case it doesn’t support (attributed text was the big one for me). Then you end up needing to wrap UIKit, which is straightforward except there is a new set of corner cases to deal with, eg. content sizing, embedding in native scroll views, etc. It all does work in the end but it takes a while to get there, and I know I’ll be replacing a lot of code as SwiftUI evolves. Having said that, it’s probably a better situation than releasing a half-baked but more featured framework. Also yes, the documentation is terrible. A few things I found helpful - https://gist.github.com/lhoward https://gist.github.com/lhoward

rnikander 6y ago

Most of what I like about SwiftUI is the syntax. I wonder if I'd be better off using Swift function builder syntax to build UI/NSView hierarchies and layout.

philipyoungg 6y ago

I've been using SwiftUI for macOS and iOS fully to make stayinsession.com It's my first app while I'm learning Swift. Coming from React, the transition is relatively easy. I did learn some UIKit and AppKit and find it extremely verbose. The thing is SwiftUI is not really ready for prime time. There's a lot of bug and inconsistencies here and there. Things that work on iOS doesn't work on MacOS. Vice versa. Keyboard navigation and input focus sucks. Minor update (like from iOS 13.1 to 13.2) could break some part of the app. Also performance is not optimized. I have a slideshow that took at least 10% CPU on Mac all the time. That limitation makes me decides to use animation sparingly across the app. But again, the productivity is no brainer. Basically my iOS and macOS app lives in monorepo because there's ~95% code sharing.

svntid 6y ago

1 min glance and I came to the conclusion that I should not use it - thanks cowboy

worik 6y ago

It is a bit like Linux in 1997. Mostly works....

andrekandre 6y ago

> Even if you use a LazyHStack, introduced in iOS 14, views will not be loaded until they appear, but they'll remain in memory thereafter. well, thats a dealbreaker if i ever saw one... i wonder if this is "just a bug" and gets fixed in an ios 14.x update...

valuearb 6y ago

“Unlike a collection view, all items will be loaded into memory at once.” I recently had to rewrite a UIView where the dev implemented a 3 by 30 scrollable image display only using StackViews. Despite image disk caching it took forever to load, the table was a veritable forest of spinners for 30 seconds. Re-Implementing as CollectionView only partially improved the display, eventually I had to add a memory cache to make it snappy. I’m at start of switching to SwiftUI right now for a new project and these are the kinds of edge cases that worry me. But as long as I can build UI in UIKit too I’m okay with it. Build the 90% that is easy on SwiftUI, and the 10% performant pieces in UIKit and I should still be much faster. So far it reminds me of a version of React not crippled by JavaScript. I once spent a year on a React Native project as iOS frameworks lead, and it was a nightmare. Terrible build problems every time they added new libraries, and debugging problems that crossed the Swift/React boundary was at times nearly impossible. Nothing like being blamed for endemic updating problems for months while pulling your hair out trying everything to solve them. Then to have the React lead quietly say “oh, I found the problem” during an offsite. The rest of the company never remembers that, just the months of the iOS team looking incompetent. This is so far a piece of cake by comparison, with far higher code quality.