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.
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:
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?
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.
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.
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.
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.
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/
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?
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.
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#.
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.
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.
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.
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.
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...
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).
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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?
Apple used to be awesome at documentation. I hope this effort extends to Apple's other frameworks.