On paper Swift has a lot going for it. In practice it's easily the worst devx out of the modern languages. And SwiftUI is still so full of bugs and performance pitfalls I'm actually quite pessimistic about the future of native apps on Apple platforms.

To be honest, the way they are damaging their brand/products/OS just to make a bit more money is enough to be pessimistic about Apple.

But it's very true that the state of the language can be felt in their native apps, that tend to suck pretty bad recently. I still can't get over the nightmare that is the split up of iTunes; at least we knew that it was clunky because of old age, the new stuff is just bad.

Yeah there's a reason people go to all that effort with React Native to avoid writing Swift code or dealing with Apple's UI frameworks, and it's actually a reasonable approach for the majority of apps.

My main app is a cross platform Flutter app. I've considered rewriting it in Swift because most of my users are on macOS or iOS but all the prototypes I've written are actually slower even after extensive performance work and the development experience makes me want to tear my hair out.

Ironic, given Flutter's infamy regarding performance (jank).

I'm actually surprised at this because while UIKit is hard to use, at least it's fast. Though I remember the concurrency model being confusing, so you could accidentally block your UI thread.

UIKit is pretty fast although a major step down in dev velocity.

AppKit on the other hand seems to be pretty intrinsically slow and the controls are looking increasingly dated.

Odd criticism.

UIKit is the iOS counterpart to MacOS’s AppKit and both are implemented as convenience wrappers around CALayers. They are also infinitely customizable. You can overload UI/NSView and draw vector-pen style on a blank canvas or render whatever you want on a GPU frame buffer. This is how MapKit, Safari, and the Camera view is implemented.

Not sure what you mean by "implemented as convenience wrappers around CALayers," especially when it comes to NSView where you have to opt-in to layer-backing.

It’s a criticism from recent experience trying to build AppKit based UI. The examples you list barely use the stock widgets.

There’s decades of accumulated cruft in Cocoa that Apple discarded when implementing iOS.

Yeah I worried about that going in too but in fact I've found it much easier to get good performance with Flutter than SwiftUI, especially for large collection views and especially on the mac.

The work the Flutter team did on Impeller seems to have paid off.

You should try to implement the iOS photos.app in flutter and see how that goes. This requires scrolling through gigabytes of photos as fast as your finger can swipe without a single hint of slowdown or a loading spinner. And it’s been that fast since.. iOS 7?

Yeah it’s not the language or the SDK that’s slow. Rather it’s inexperienced, lazy, or overworked developers that can’t/won’t write performant software.

I’ve been building iOS apps since before Swift existed. Sure like I said if you code directly to UIKit and take a little care performance is good. It’s also very fast in Flutter with even less care. Rendering images in a grid isn’t hard unless your core abstractions are all wrong.

Now try that in SwiftUI. You’ll be forced back to UICollectionView.

That’s cool. I’ve been developing on Mac before Objective-C 2.0 and iOS since the AppStore was released. Millions of downloads, featured in the store, worked on dozens of projects from video games to MFi firmware, and have been invited to Cupertino to meet with teams.

I’m not defending SwiftUI. I mostly use it as a wrapper around NS/UIKit because it’s still buggy and not as flexible.

By the way, SwiftUI is also implemented on top of CALayers just like NS/UIKit. It can be fast in theory, but you have to know exactly where the pain points are and most developers don’t know how to do that.

I'm not sure why you keep bringing up CALayers. That is not where the performance bottleneck lies in SwiftUI.

I don’t think it’s impossible with proper caches to smaller dimension versions (that supposedly Apple already generates/has access to - like they are doing a bunch of processing, like object recognition, etc).

It's only that fast is the thumbnails are not too slow, the data is all there on device, the phone isn't RAM starved, and you largely have the latest iteration of iPhone for the current software, with the most powerful chip available.

In this way, yeah, it's pretty fast. Any other way it's blank square galore.

People go to React Native to stay on their cozy Web skills, it is exactly the same if we would be talking about Microsoft and Google platforms.

I started using RN when I had 0 web skills and didn't know JS. Everything from making a simple button to hooking up the model was easier to me in RN from day 1 than the native iOS way that I'd been using for years.

As someone that unfortunately has to deal with React ecosystem, and knows reasonably well native programming across Apple, Google and Microsoft ecosystems, I have some hard time believing that, but might be a knowledge issue.

The Google ecosystem? Isn’t that also just Web-based?

Not Android

I mean, I figure the more compelling reason to do that is so you can also ship an Android app without writing everything twice.

Sorta, but it's not as easy as they make it sound. And people will use RN even for iPhone-first stuff.

except for the thousand times you end up having to dip down into native components

I'd say most of the time it's a handful of times or less. Uniswap is a good example of a large OSS three-platform app that shares almost all the code, uses very few native dependencies, and has great UX. I maybe biased since I worked there and made the UI framework they use, though.

https://github.com/uniswap/interface

I have made a lucrative career by porting fragile, slow, bug-ridden react-naive disasters to native code bases. There is a lot of demand for this from startups that took the cross-platform shortcut and the MVP became the product.

You can make a disaster in any framework. SwiftUI is a mess, for example, and slow.

React Native took a while to mature, but with the right tooling you can ship amazing UX now.

I don’t doubt there’s a ton of crap out there.

But you’re wrong if you think you can’t make seriously great stuff with it. It’s matured quite a lot.

And the React programming model is untouched, hot reloading and dev tools far ahead, and code share is worth it with something like Tamagui that actually optimizes to each platform. If I never had to touch an ObservableObject again that would be great.

It can get tough with the native dependencies involved.

I have made a countless PRs to many of the most popular react-native dependencies because they were a buggy mess.

In fact at this very moment I’m helping a team fix a memory leak/crash in the “react-native-permissions” dependency. It’s obvious this package was not written by someone with experience. All it does is request permissions in a paragraph of code and it’s totally broken! Give me a break

I have plenty of nightmare stories to tell you about native deps.

For some apps, I can see this. Question is, did the startups regret taking the shortcut upfront, or were they fine paying later for the improved version?

Btw, sometimes I think about how much I've been paid by various people to move a backend from SQL to NoSQL then from NoSQL to SQL, despite me telling them not to.

Btw I don't think of it as a shortcut, I think it's actually the ideal end-state.

When I was still doing contract work I rescued a bunch of native code iOS app disasters. For most apps cross platform solutions are fine.

Like you dont have to know native components anyway?

In one way you centralise as much logic as you can and are encouraged to write clean code that doen't depend on platfrom quirks. In the other way you... give up and just do whatever.

I can see how some devs find it hard to not give up and just write the same logic in multiple languages, great job security!

I can think of a few others where you have to do that; most of them are the kind of languages whose fans say they're impossible to write bugs in.

Rust is hard but I've never had the compiler just throw up its hands and tell me it's up to me to figure out what's wrong.

That's not the one I was thinking of.

https://anthony.noided.media/blog/haskell/programming/2020/0...

Something like Idris or Coq would have even more complex messages, though I don't have an example on hand.

Ok but these are mainly academic research languages. Swift has the backing of the most valuable company in the world and is what they're pushing as the right way to develop for their platform.

Haskell is definitely a real industrial language!

Many of the other languages in the formally verified/dependent type space are academic, but there's government interest in things like Ada too because they don't want their planes to crash. Couldn't say how good its error messages are though.

I've seriously used Erlang for a while, and Haskell looks kinda similar. Ingenious ideas there, cool features, but in the end it's cumbersome to use. So I can see why these are niche and wouldn't consider them next to big ones like Swift or C++.

If Rust is one, yeah I have to fight that compiler but it's because it's doing its job and not letting me do invalid things. Not because the compiler has some feature "not yet implemented" or has bugs.

Also, is anyone familiar with the weirdness with tuples in Swift? All I remember is they never worked the way I expected, and for some reason something in our code specifically worked for tuples up to size 5.

Swift only got variadic generics fairly recently, and before that you couldn’t write code which was generic over tuple size. Instead you had to codegen versions for each size of tuple you needed to support.

I think that was it. There was also something about tuples inside of dictionaries that Swift 1 or 2's compiler segfaulted on.