SwiftUI tutorials rewritten completely | Hacker News Reader

SwiftUI tutorials rewritten completely

developer.apple.com

243 pointsAustin_Conlon112 comments

Is it my imagination or has Apple been quietly improving and expanding the documentation for SwiftUI over the last few months? It's becoming decent, though there are still dark corners.

Apple used to be awesome at documentation. I hope this effort extends to Apple's other frameworks.

It's been expanding ever since the WWDC 2019 release, same with other newer frameworks like Combine, and it mostly goes unnoticed. They should have some way of showing what docs have been updated, currently in the Apple Developer app I think it only highlights new articles.

>They should have some way of showing what docs have been updated

Back when I used wrote iOS crap, I used dash as a quick reference for APIs.That was pretty good at alerting me to documentation changes, since it has to download an update. https://kapeli.com/dash

I only started using it (never did buy it) because I was used to using zeal, a free-software alternative.

https://zealdocs.org/

I like Dash, I bought it. But unfortunately the version upgrade from 4 to 5 introduced some mandatory UI changes that made documentation lookup much more cumbersome. Looking up a function now takes several user interaction steps, instead of just one in Dash 4. I'm still on version 4. If anyone have alternatives, I'm all ears.

Yeah, I feel the same way about Dash 5. Eventually had to upgrade to 5 when 4 became incompatible with the latest Apple docets. But I much preferred the Dash 4 search.

The developer of Dash is very receptive to feedback (in fact I think this change was called out as something that he was interested in hearing opinions on).

That's not my experience. I've reported this to him on two occasions, with screenshots and detailed descriptions of how the UX had regressed.

First one took a year before I got a reply (after reminding him), and only partly answered the request.

The second one I'm still waiting for a reply.

I would love for Dash 5 to fix these issues still, and I would upgrade in a heartbeat, but as it stands, I'm stuck with Dash 4.

The issues are:

1. Dash 4's sidebar shows significantly more hits when searching, making it a lot easier to find what you were looking for, compared to the "omnibar" of Dash 5:

https://i.imgur.com/smuNFws.png vs https://i.imgur.com/SeTShSL.png

2. Dash 4 shows/loads the currently selected search immediately, requiring no extra step. Dash 5 requires the user to press enter to confirm the search. This is especially frustrating when triggering a search from an editor

edit: where did he indicate he was looking for feedback on these features?

> where did he indicate he was looking for feedback on these features?

I thought it was in the release notes for v5, but I can't find them at this point to verify. I suppose I may be misremembering.

Yeah, I’ve noticed that too. Which is good cause SwiftUI has tons of potential.

Oh wow, I personally know someone who joined the dev pubs team to work on this documentation. I think a big factor in the improvements was their hiring practices. Traditionally Apple has required that employees be on-site. Their dev pubs team is a notable exception and a signify part of that team is remote.

When has Apple traditionally required employees to be on site? I know a few people who have worked remote at Apple for over a decade.

Know a bunch of people working remotely for Apple too

My understanding - as someone who knows nothing but just read tweets - is that hiring strongly prefers on-site, whereas tenured employees are usually able to negotiate remote work.

Apple makes exceptions to exceptional people. I mean, OSX x86 port started with a remote engineer.

They've tended to prefer onsite, though I've known of exceptions for as long as I can remember.

I interviewed with them in early 2019, and it came down to me and one other person, but I was remote and the other person was in-person. After some back and forth, they went with the other person and told me it was because I would be the second remote person on that team, both hired around the same time, and that nudged them toward the other candidate.

Now everybody is remote, so... fortunately, I'm happy where I ended up instead.

This is so much better than the old guide. Highly recommend following along even if you’re familiar with SwiftUI. At a bare minimum, it’s a gentle introduction to some non-obvious (and perhaps undocumented) best practices.

This guide would’ve saved me countless hours had it been available in the summer.

So far dealing with stuff like PayKit SwiftUI integration still feels really bad. There's just tons of stuff expecting UIKit and it will take a while before all of that stuff is ported.

SwiftUI is really great, Combine can be hard to get into for people not initiated in Reactive and generally it's as fast to build stuff in as Flutter without dealing with the tragedy called Dart.

What is wrong about Dart? I come from a Kotlin background and I don't see anything wrong with Dart honestly

Failed to take over the Web as Chrome team was driving it, then ChromiumVM got dropped, several key designers like Gilad Bracha and Lars Bak left the project, it was ultimely rescued by AdWords team, which had just migrated away from GWT into Dart, got rebooted into a strong typed language with type inference, and picked up by the Flutter team.

Nowadays it is basically a language to write Flutter applications, hardly worthwhile to bother using it for anything else.

Flutter is taking place on Google politics, while Google lets Flutter, JetPack Composers and PWAs play the game of cross platform GUI frameworks, with the difference that Kotlin and JavaScript/TypeScript have a much broader eco-system than Dart.

In my opinion it's not an especially compelling language (yet maybe it evolves into one) and is useless outside of Flutter. It feels shoehorned into the project because Google wanted to find a use for it. It simultaneously alienates mobile developers and cross platform developers by picking a language neither have experience in and neither can use outside of this one framework. There are people taking about Flutter being to Dart what Rails was to Ruby so maybe time will tell. Flutter itself seems decent though, despite a few oddities.

The compile time guarantees could have been much better, especially around null pointers. Now they're hacking in non-nullability the same broken way they did it in Java. Same goes for a lot of things like switch / case statements requiring breaks but not supporting checks for covering all cases compile time.

In general it just feels like old Java spiced up with some Javascript niceties like Futures and a nice constructor syntax.

But you should've noticed that coming from Kotlin?

Why wouldn't they use Kotlin as most mobile developers are already used to it?

> especially around null pointers. Now they're hacking in non-nullability the same broken way they did it in Java

Typescript was my first introduction to a typed language and it astonishs me the decisions made in the 'earlier days' regarding nullability.

I'm curious what you have against Dart?

I sometimes wonder why do we continue to get macOS update. Were any of those "user" features really better?

I wish they spend more time looking into Xcode, developer documentation etc. And it is 25M developers at $99 a year. That is $2.5B. And it is looking less than $10M a year investment into Xcode.

For context: I remember hearing the paying developers are a very little fraction of the 25M. I don't pay for it, and I know many people who just created an account to play with the beta releases. I don't think I know anyone who pays the $99. You don't even need to pay this when your app is free. https://developer.apple.com/programs/how-it-works/

> https://news.ycombinator.com/item?id=25046691

Some relevant discussion.

Yes it's unfortunate that these tutorials and WWDC transcripts are effectively the replacement of core documentation, regardless of their quality. Overviews, code listings, and conceptual docs are being added, but at a slow pace and it's hard to find which ones have been updated outside of some people posting about it on Twitter.

Man I wish Xcode was a decent IDE

If there's anything you can credit the Google team for, it's using IntelliJ as the basis of the Android IDE.

Which is one of the reasons I am happy not having to deal with it every single day.

Android Studio requires a gaming rig to run properly, Android developer forums are filled with discussions on how to not use it in pain.

IntelliJ is amazing though.

I would have preferred them sticking with Eclipse. Sure, the Android plugins for Eclipse were pretty bad, but that was all Googles fault. They could have just fixed their plugins.

I used Xcode recently and it's gotten a lot better. It's still not as good as IntelliJ or AppCode but it's usable.

I remember around when Swift came out, Xcode was so bad that I couldn't even use it because typing was ~1 character/second and it would crash every few minutes. It's definitely recovered from that and I can actually type without lag now.

Xcode had no such problems with Objective-C though... Maybe Swift's design deserves some blame here for years of subpar developer experience.

It wasn't until Swift came out that autocomplete for ObjC in Xcode finally started to function at a useful level.

Autocomplete in Swift is still broken but I don't think it's an issue with the language itself (autocomplete is probably easier to implement in Swift given the nature of the language).

The autocomplete and syntax highlighting feature completely stops working sometimes. It’s beyond frustrating

Simply:

CMD+,

Locations

Derived Data

CMD+Q Xcode

Delete!!! Derived Data

Restart Xcode

Why not Clean Build Folder

  CMD+B

success!!

I have a source editor extension that has no job but to clean this clean this ;)

I have a shell alias for

  mv ~/Library/Developer/Xcode/DerivedData ~ && rm -rf ~/DerivedData &

And I use it constantly. This approach is fast because it does the actual rm in the background so I can relaunch Xcode right away.

Manipulating the source code leads to invoking the Swift compiler to generate the information required to drive the rich editing experience. I have found SourceKit’s performance in complex projects, especially those where there are a lot of third-party libraries or frameworks you’re linking against, to be pretty disappointing. Especially when you’re working with many ObjC dependencies.

Like many of Apple’s developer tools, if you stick to the happy path, performance is great. Practically that means compiling your source into a single Swift module and keeping the number of modules low. If you are a “basic” iOS or macOS app with just a couple of 3p libraries things work great. Real world projects are drastically more messy...

Sounds like an unusual problem. I cannot remember having that problem and I was using Swift from the beginning.

For me Xcode is quite nice. Didn’t like AppCode. Not sure why people are so enthusiastic about it. What does it give besides better code completion? Development is a lot more than code completion.

You're hardly the only one, 3.3/5 star rating on the Mac App Store and the #1 downloaded developer tool. Can't live with it, can't live without it.

I think JetBrains has a XCode replacement but I dont do Apple development so I'm not sure if its possible to use it as a complete replacement for developing macOS, iOS and IPadOS apps. Anyone have first hand experience?

AppCode. I used to use it a lot, and in many respects it's just plain better than Xcode. You can one-click install a plugin to use vim bindings, for example, whereas in Xcode you have to strip out the code signature so that you can install a third party plugin for vim bindings because, I don't know, fuck you I guess.

The problem was that AppCode was always a few months behind Xcode in terms of Swift support, and Interface Builder never really worked right. So the workflow was to have them both open at the same time and constantly switch back and forth, which at the end of the day just isn't great.

I wish Xcode didn't suck, but it does in so many ways. Not much to be done about it.

I wish Jetbrains could do what they did with .NET which is Resharper. A plugin for Visual Studio that brought IntelliJ like features and smartness to it. It was a breeze.

Unfortunately I don't think XCode is built to handle third party vendors plugins and it never will (which is why Appcode exists in the first place).

Xcode used to allow plugins but then disabled them in favor of relatively useless Source Editor extensions which offers nowhere near the capability required to build something like R#.

A stand-alone IDE like AppCode is the way forward, JetBrains usually take a while to get their new IDE's up to speed and catch up with the latest language & platform features, but afterwards is able to add a tonne of smarts and maintain feature parity fairly quickly as they've done with Rider which offers a much nicer & faster UX than VS.NET/R#.

My Visual Studio is an happy boy without Resharper bloat, never got the point of it.

Every time I upgrade Visual Studio I try running it without Resharper. I’m finding I can last longer before I give in each time but I always do end up installing it.

Maybe, but people say similar things for e.g. using Vim over an IDE too, though...

Xcode used to have this awesome plugins ecosystem (Alcatraz) that was built by 3rd party devs.

Then XcodeGhost happened. They try to replace it with Xcode Source Editor Extension but that one is just not as good as Alcatraz

That is appCode, which has some pretty big limitations last I used it. For instance, you can only edit XIB files in XCode.

But AppCode's navigation and refactoring capabilities are much better.

I tried using AppCode on our massive project at work (several million lines of code), and at the time (admittedly a few years ago), I couldn't even start working on any code until it indexed the entire project. I let it run while on a machine I wasn't using and it took several hours to complete. Xcode also takes hours to complete indexing on our project, but it runs in the background instead of blocking the UI so I could get to work immediately with a new checkout of the source.

Any comparisons after indexing is done?

As I say, it's been a few years, but if I recall, it just generally didn't feel like a Mac application. It worked alright and was basically calling the same tools under-the-hood as Xcode does. But there was nothing compelling about it that I could see when I tested it. Perhaps it's better now? I should probably give it another look.

Me too. I don’t understand how they release an IDE without Vim emulation or some support for plugins that enable Vim emulation. It’s quite miserable. Last time I checked you had to root the app to install a Vim extension.

*unsign the app

Re-sign the app using your own certificate.

FWIW you can invoke SourceKit LSP with a vim/nvim plugin now and have a really nice Swift editor inside nvim. It doesn’t work with third-party packages yet though so I mostly use it for one off scripts.

Thanks. Didn't know about SourceKit LSP.

So weird. I guess it might be because 99.9% of swift developers want as little vim as possible in their lives.

What’s the connection between swift and Vim? Why would they be anti-Vim?

Most people are naturally anit-vim, because it’s so unintuitive to the uninitiated. It’s not because they use swift.

Curious what your issues are? I personally love Xcode for C++.

A lot of the issues I encounter are mostly related to Swift and SourceKit more than they are Xcode. The language server will start choking after a mildly complex project and highlighting and autocomplete will stop working. Sometimes it won’t recover until you delete derived data. Xcode itself is missing some modern features for navigation and a plug-in system however. I’d also like it if the Xcode team could learn what software patches are rather than releasing an 11gb version for every update.

Odd, I don’t really like IDEs but I think Xcode is among the least shitty IDEs out there. Too many IDEs have just terrible GUI design.

Same here - I like working with XCode because the native UI!

Yeah, Xcode has some annoying bugs occasionally but in terms of UX, it's miles ahead of anything else I've used.

Xcode’s main issues are its bugs (which are inexcusable) and the project file format which is way too hard to work with.

Why aren’t files in groups sorted by default? Why does sorting them cause large sections of the project file to be rewritten? Why do I need to add files through the UI? (Why can’t I create them in the terminal and have them just show up?)

I know that groups vs folder references play a role here but most projects use groups, and groups are a terrible experience.

It all leads to constant merge conflicts and files just accidentally getting removed from groups and nobody being able to tell in code review. They need to fix the project file.

Instead of an excellent one you mean?

Xcode is so dammed slow and buggy. I use JetBrains AppCode for everything but storyboard editing.

Does AppCode support live preview?

It’s pretty cool that from the very first step that they are introducing how to use accessibility modifiers to improve support for voice over.

SwiftUI’s support for accessibility is pretty amazing, way ahead of any other framework I know of and takes minimal effort to adopt too from the examples I saw at WWDC.

I am impressed by the visualization and guidance giving in that tutorial. Good library documentation is really hard work but can be also super easy (looking). Check e.g. RabbitMQ tutorials. So nice.

Is SwiftUI just an abstraction over AppKit and UIKit ? Does it bring any widgets of its own - ie something native to SwiftUI as opposed to being wrapped ? (apart from the declarative stuff)

It can draw stuff directly rather than going through UIKit. Example via WWDC by Sundell: https://wwdcbysundell.com/2019/swiftui-relationship-to-uikit...

  struct ContentView: View {
      var body: some View {
          VStack {
              ForEach(0..<3) { _ in
                  HStack {
                      Text("Leading")
                      Text("Trailing")
                  }
              }
          }
      }
  }

> Looking at the above code sample, it’s easy to jump to the conclusion that the resulting UI will consist of a vertically aligned UIStackView — which’ll then contain a set of horizontally aligned, nested stack views, which in turn each will contain two labels rendered using UILabel. However, none of those assumptions are actually true — as SwiftUI instead draws our labels directly using the private CGDrawingView class.

I don’t think so, the look and feels is different.

Under the hood it will use some UIKit like UIScrollView but the whole architecture is different.

On UIKit, the objects you create stay retained as long as they are used and all you do is to change properties when using.

On SwiftUI, everything is released and retained every time there’s a change.

That’s why you need to address the life cycle differences when you use UIKit and SwiftUI together.

Sometimes yes, sometimes no. For most things, no.

That’s not really the right question to ask. Yes in some cases it is backed by UIKit, for now, but that can change at any time.

It is a completely new paradigm, that’s it. Implementation details are just that.

For now, it mostly wraps existing UI frameworks yes. In the future if Apple decides to, they can depreciate AppKit and UIKit without changing the SwiftUI APIs and have it drawing directly. I see that as a very, very long way away though, UIKit/AppKit will be around for years to come.

I asked a similar question on StackOverflow recently.

https://stackoverflow.com/questions/64049757/are-swiftui-com...

Cool, but this documentation wasn't really the issue. Apple seems to be taking the tack of explaining a few core concepts really well while ignoring the long tail of documentation. Why are there questions like this[1] on Stack Overflow? That's a clear sign that other documentation is lacking.

[1] https://stackoverflow.com/questions/65173861/saving-a-file-t...

There's certainly a lot that could be said about the gaps in Apple's developer docs, but the answer to that question is literally, "handle your errors instead of ignoring them, and it will tell you what went wrong."

They ignored errors, so didn't know there was no "Documents" directory, and their file write therefore failed.

I'm actually learning swiftui and finished the old version of the tutorial a few days ago. I'm glad they are fixing up the documentation. SwiftUI is pretty powerful, you can make really nice "cross platform" (within the mac ecosystem) apps.

Question, is it doable on Mojave? I can't lose 32 bits apps.

AFAIK, Xcode versions supporting that are bound to 10.15+. It's Apple's usual 1-2 punch.

Yeah and that's the kind of things that really annoy me about Apple.

How did you find this tutorial? I can't seem to find it by navigating on the developer site.

A friend sent me this Tweet: https://twitter.com/zntfdr/status/1338423623149707265?s=21.

Is SwiftUI open source?

the original ones on release were awful for sure

Super cool!

Why learn SwiftUI? If you want a declarative UI framework wouldn’t you be better served for your time to learn something like React Native or Flutter? I’m not trying to knock SwiftUI, I am genuinely curious what the value proposition is for anyone considering it...

Because it’s native to the platform. Seriously, that’s huge. The React Native toolchain is cumbersome to say the least.

There’s something to say about a first-class library, meaning one that is being used exactly as designed. I mean, why do people use Javascript? Because it’s the native language of the browser.

Yea I don’t disagree, but what development team has the luxury of choosing SwiftUI?

Most places hiring are looking for cross platform “2 developers for the price of one” ... and the burden of dealing with cumbersome react native falls on the developer.

I'm guessing companies that have the resources to go with two separate development teams for each platform will tend to go for that route since it leads to better performing applications. e.g. FB Messenger's blog post about going back to native after using React Native.

I make my money by doing internal projects for companies. These organizations run their own app store, or just force-download their apps onto all of their iOS devices. It's lovely to focus on one platform.

In my experience, cross platform development only works for simple apps. If all you’re doing is fill in some forms and update a database, sure, go with a cross-platform toolkit.

If you’re doing anything more complicated than that, the productivity gains diminish quickly to the point where it’s easier and faster to just build to native applications.

Anyone serious about doing high quality apps will do native development on each platform.

But I’m too lazy and want to target the most users with minimal effort and without learning anything new, their experience and performance be damned.

Or from the perspective of the employer:

I'm too cheap, and rather than bite the bullet and spend money on a good mobile team, I'd rather have one guy do it all in React Native! His quality of life be damned!

Because it's an Apple sanctioned technology within XCode?

Apple probably depends on SwiftUI more than Google does on Flutter, so they'll almost certainly keep it around for the long term. It's used for widgets, the SwiftUI preview feature in Xcode, and for various watchOS app rewrites to name a few examples, whereas with a Google project there's always the question of whether it's just a short-term hobby.

After you’ve used SwiftUI you wouldn’t want to work with any other framework.

Even with all the rough edges currently SwiftUI+Combine is how I want all my programming to be done from the day they were announced.

You should try to have a go at Smalltalk and commercial Common Lisp environments.

I highly doubt it is even possible in any og those to produce something that would actually be releasable as a high-quality iOS app, rather than an embarrassing, ugly mess.

There are a lot of reasons and they can be discussed ad-nauseum. When you boil your question down to it's essence: "Why use a first-party framework and language" it's much easier to answer. The simplest and most pragmatic answer is "because this is what Apple tells us to use". It's a business decision more than anything else, if your business somehow depends heavily on mobile then you want to build native apps.

If you only target iOS for example it's a no brainer. There are use cases where you absolutely have to use it, those are currently Home Screen widgets and WatchOS Apps + complications. I would not be surprised if more SwiftUI-only use cases were progressively added.

SwiftUI is also cross-platform, in Apple ecosystem. That is, you can develop all of your components and have them work on iOS and macOS. Then glue them together with platform specific main view.

SwiftUI will also always have all of the native features whereas cross-platform tools always lag behind. This is important for smaller developers as releasing before others can be what makes or breaks your app's success.

"cross-platform, in Apple ecosystem". Please, let's not gobble that crappy apple PR spin on what that term means.

Cross-platform never meant "just an iphone and a mac os with the correct version". SwiftUI looks like a very cool tech, but it isn't "cross-platform", period.

> Cross-platform never meant "just an iphone and a mac os with the correct version". SwiftUI looks like a very cool tech, but it isn't "cross-platform", period.

It might be crappy marketing spin but it's hard to call anything other than the web cross-platform by that definition. It's not just iPhone and a Mac either, it's every Apple platform that has a screen. I don't think Flutter or React Native can claim that despite being called cross-platform.

I’m all for using a different term, what would you suggest as a shorthand for “same code runs on a phone, a computer, a tablet and a watch”? Cross-Apple?

In addition to the other answers:

Because Apple could and I bet they sure will add hardware optimizations in future Mn chips for apps made entirely in Swift+SwiftUI+Combine etc.

Also I don’t think Flutter comes close to how SwiftUI spits native paradigms for each device like Mac, iPhone, iPad, Watch and TV from mostly the same UI code.

Reply on news.ycombinator.com