I’ve been pretty on board with SwiftUI and have adopted it liberally in 2 apps but I’m a little disappointed with the state of it right now. Apple is seemingly dusting their hands after this years WWDC leaving us with something thats still half baked and filled with bugs, some that haven’t been fixed since the first announcement.
I made the mistake of choosing iOS and SwiftUI for the first platform of a niche app, a few months ago. Trying to do things in the way Apple wants seems a good strategy in general, but the experience was bad in countless ways. The developing&publishing approval barrels don't help. I succeeded, but only by throwing vastly more experience and energy at it than should've been necessary.
One of the engineering culture surprises was realizing that a lot of iOS developer chatter seemed to be repeating PR talking points, rather than the frank critiques that I'd expect in analogous situations in many other software development communities.
Besides a theory of fandom or Stockholm Syndrome, or dreaming of a job at Apple, or fearing being deplatformed... maybe there's an incentive for someone with hard-earned knowledge in something marketable to play along and be reassuring about their own expertise in it?
There is plenty of critique in the community but it’s usually done in private. It doesn’t pay to be on Apple’s bad side and it’s a promotion opportunity to advocate for the newest and shiniest. Also, experience shows that you need to look at Apple with a multi year lens especially nowadays. Sometimes it takes them a couple of years to get things right.
> It doesn’t pay to be on Apple’s bad side and it’s a promotion opportunity to advocate for the newest and shiniest.
This tends to be overestimated. There's rarely a good reason to fear criticism. Apple is too huge to notice you, unless you're famous yourself. Also, Apple is a very bureaucratic organization especially now. The App Store editorial team is in its own silo and doesn't necessarily pay attention to this, and isn't influenced by other teams within Apple (except when top executives step in, of course).
Ironically, the rational fear of criticizing Apple comes not from Apple retribution but rather from all the random little Apple fans jumping all over you for criticizing Apple.
Thanks. I think the bad experience was partly my fault. When I picked iOS and SwiftUI, I think I extrapolated too much from the overall fit&finish of the user-visible iPhone universe, and consequently didn't vet SwiftUI (and some of the more general barrel aspects) as much as I should've.
pfft. The moment you accuse the "other side" of "fandom or Stockholm Syndrome", just because they don't constantly whine about something you dislike, you lost my respect.
You've already made up your mind if you're just going to slap such labels upon anyone who disagrees. Frank critique doesn’t thrive in echo chambers, and your preemptive polarization is just as guilty of such bias, just in the other direction.
What term should we use for your camp? "Haters?" "Lazy devs who don't bother to learn the intricacies of a new platform and expect stale knowledge they studied 10 years ago to apply everywhere?"
Electron is that way and have a nice day.
> Your comment is refreshing.
jamil7's GP comment was literally 2 sentences just saying "I'm disappointed, half-baked, bugs."
Disappointed how? Half-baked how? No details, just a string of some negatives and that's enough to make you happy. "Someone who agrees with me! Everyone else must be an Impostor!" (little Among Us reference there)
SwiftUI is a monumental project. Does any serious developer with real-world experience expect long-standing technologies like AppKit/UIKit/Cocoa/etc. to be completely supplanted within 2 years?
Any developer worth their bits would immediately notice the extensive support for incrementally adopting SwiftUI in legacy projects, or selectively falling back to existing tech in SwiftUI projects. You’re not supposed to go all-in if you're not fully comfortable with it, or if it doesn't serve all your needs yet.
And anyone even casually glancing at Apple SDKs will sense that this -is- the future. It's honestly fucking amazing to be able to target macOS, iOS, iPadOS, tvOS, watchOS and soon the rumored AR glasses with like 70% or more of the same code. Best of all, it not just spits out native widgets on each device (unlike Flutter or Qt), but also automatically adapts to the paradigms of each form factor (like navigation pages on phone/watch/TV versus sidebars on Mac/iPad).
Not to mention the rich support for adding internationalization and accessibility features to your app at a low cost, something that other major frameworks and companies generally ignore.
Yes, there are bugs. Yes, the documentation is appalling in many places. Yes, Apple doesn't communicate very well.
But hot damn, SwiftUI is the most refreshing UI framework I've seen since WPF, which Microsoft didn't even dogfood as much as Apple has done with their tech (both Swift and SwiftUI are already being used in core features of their OSes).
Shit that would take me a week on other frameworks I can now throw together in a day with SwiftUI, live previewing and incrementally improving and targeting multiple devices as I go.
I am not going back to any other framework. I would rather put my projects on hold if SwiftUI cannot handle them in its current state, than the other way around. The grass may seem greener on the other side for now but only because it's growing from a pile of rotting cow turds.
So I will just respond to the parts regarding my original comment. You're right I didn't put any details in but in my further comment in this thread I mention that I'm using it a lot and have been since it's annoucement. I wouldn't have introduced it to my apps if I hadn't thought it was a promising piece of tech and I agree it is the future I'm not simply dismissing it out of ignorance, I've used it a lot and I'm disapointed because of the potential I see in it. The interop with UIKit is appreciated and I'm not asking for something as fully featured or mature as UIKit in 2 years, what I would have liked to have seen from this years WWDC however was a refinement and bug fixes of pieces that we already had.
Fundemental building blocks of SwiftUI are broken and have been since it's annoucement, List, NavigationView and NavigationLink for example – these are the basis of SwiftUI apps and need attention from Apple developers, I've reported bugs, memory leaks and performance issues with these and they've been acknowledged, maybe they fix them during iOS14's lifecycle but maybe not. We got some much needed features at this years WWDC but I would have also liked to see these fundementals addressed and maybe even rethought (navigation). It's not like we're talking about a volunteer open source project here, we're talking about the future flagship UI framework for 2 trillion dollar company. Run and profile Apple's own Fruta example app if you want to see what I'm talking about.
When it works, then yes like I said I can't imagine a faster way of building for Apple platforms. But right now I would warn others not to adopt it at any meaningful scale for another 2 years.
I see it like Swift itself, which took at least 3 years to fully come into its own.
Apple's lack of documentation and communication doesn't help; the best resources have been from fellow developers who were groping around in the dark like the rest of us and managed to figure things out by themselves. [0,1]
But again, I've already been able to do many things in SwiftUI that I don't even want to attempt in AppKit/UIKit/other frameworks.
Right now I think it's good enough for small apps or personal convenience tools. One surprising application for it is in games, where it actually works quite well, compared to all the other alternatives for drawing scalable/animatable HUDs and text etc. [2]
In an year or two I don't think anyone would willingly choose to fumble around with legacy frameworks if they want to target phone, tablet, computer, watch, TV and glasses all with one codebase.
Curious how it compares with other reactive mobile frameworks like Jetpack Compose (which my colleague says is not at all ready for primetime) and Flutter (which he says is great). Any thoughts?
Conceptually it’s great and when it’s more stable I can’t imagine a faster way of building a cross platform Apple app that looks and feels correct. Styling a react native app felt tedious in comparison. Jetpack Compose appears to be going in a similar direction but last I checked it’s a long way off as you mention. Flutter is interesting but I have very limited experience, I was initially turned off by dart and the heavy focus on Android. I keep hearing positive things on HN and from other people though so I want to give it a another proper go. Overall it’s a bit of an awkward time for mobile development.
Thanks for the response. I have some personal experience with React Native which feels like a dead end to me. We've been building our apps with our small team with Swift (not SwiftUI) and Kotlin on Android, but the difficulty in keeping feature parity and UI consistency across platforms has tempted us to try Flutter, but as you say we're worried about how well the iOS widgets are replicated, also the accessibility story on Flutter seems not great, which is a moral problem for us as we don't want to exclude people with disabilities.
Why do you feel React Native is a dead end? I've built apps of all sizes with it and had a good amount of success. I love Swift as a language, but building the same app across platforms (Android/iOS) always feels so wasteful.
Background: I worked on the NFL mobile app and then worked on a search engine app both of which were in React Native. Specifically I worked on the team that did the developer tooling side for other teams. I made it so experienced JavaScript developers who had no experience with native mobile could create features more easily. Both get millions of downloads.
React Native is a pain to work with when the scope of your app becomes any larger than an agency level project (e.g. an app for an event that's only going to be used one weekend).
Once you start getting into requirements for a prime time production app (setting up APM tool, setting up tracking, setting up Google Analytics, native specific features that don't have a React Native hook yet) React Native is an extra layer of abstraction that slows you down. The experienced native developers hate working with it because they'd rather just use the related native platform themselves, but at the same time for any slightly complicated app you still need their expertise. Also, out of the box animations in React Native is difficult to work with, especially with less experienced developers, so you end up having to do a variety of work arounds to get animations between screens to look nice which you'd get out of the box just using Kotlin/Swift.
In 2020 if I needed to make an app quickly, cheaply, that worked on both platforms, I'd make a great mobile website and wrap it in a native shell. Any screen that needed a little bit extra "magic" I would do 100% native code for both platforms. This also allows you to ship updates to screens as you go without a complicated "codepush" JavaScript setup, as it's just a webview on the other end.
I'm still maintaining the React Native search app now, it works fine, but if we need to create an iOS version of it I'd definitely pitch doing it in native code.
I’ve just been building an app using react native (for web). We built the web app first and had it responsive and designed to match mobile interactions from the start (a stack view that keeps state) and it’s been quite nice. The other day went to get it running on native and was pleasantly surprised - was able to get all the main screens working smoothly and well in a matter of days.
Compared to SwiftUI it was far easier and even faster. Granted, I’ve worked with React a lot. But it’s really quite nice, I’m impressed with the whole ecosystem and how it’s grown.
It is not going to be as good out of the box as a native iOS app, but it is is workable with a little bit of effort. Unlike Flutter, react native does not have a fundamental architecture that makes accessibility tricky.
I recently started using swiftUI for a simple app. I loved it until i got a bug that causing a working app to stop working at all. I solved the bug by creating new app and copying everything to it. That's state of SwiftUI for me and i think it shouldn't be the case when you talk about Apple.
The calculator being the first app for which they used Swift... I’m guessing a calculator app was the first app many Swift programmers wrote after viewing the excellent Swift lectures from Stanford.
I recently did a side-project[1] as a chance to learn SwiftUI. Their docs were not so great and I didn't want to reverse engineer their API + document it. So I used React Native + Swift backend.
In the 12 years since the App Store, we've seen a plethora of languages become available for iOS. Swift has existed for half that time, and even in the past 6 years, we've seen more languages, more frameworks, and a LOT more non-Cocoa apps.
Meanwhile, the majority of the system remains based on C, C++, and Objective-C (accessible via C) APIs, the same that many of the other languages and frameworks tap into to access Apple's higher level frameworks.
Bit of a vague cop out answer, to me. If there’s been any evidence that Apple would crack down on other languages and frameworks, sure, but as the exact contrary has proven to be the case, there doesn’t seem to be any legitimate case for concern.
Apple has always taken a position something like "do it our way, or you're on your own" with their developer tools - but I don't see the situation getting any WORSE any time soon. Apple has so much code that's written in C, C++, or ObjC, that I don't imagine they'll ever be in a position to drop support for those languages. So as long as your language is able to interop with C/C++ or ObjC you're going to be fine.
C# and Java can be considered, at best, as branches in this evolution scheme.
C++ is by far the dominant language to create games today, and IMHO, for the foreseeable future.
Google tried to force every dev to use Java on Android for a while, but they finally and reluctantly added the NDK (C/C++) so that game devs would port their engines and games.
That is how C++ started to be used back in the 16 bit days.
Oh the arguments how it was an heresy to even think contaminating the source code with C++ constructs.
Track down any C vs C++ flamewar on Usenet back in those days.
NDK exists since Android 2.0, hardly anything new, as is currently more castrated than on those days.
It is impossible to create a production level game engine in Android without reaching out to Java, given the API surface.
Game devs will use whatever the platform owner puts them on the table, when the platform is enticing enough to refuse being part of the party.
Just like if enough Indies make money with HTML 5 games, some bigger studios will eventually suck it up and use JavaScript, WebGL, and whatever tooling targets WebAssembly.
Big Sur has some rough edges right now that I hope will get ironed out (fortunately, they're mostly UI issues and not performance/stability), but using it for the past couple months has made me a little more optimistic about the Mac's future. They've brought over a lot of common-sense features and design ideas from iOS, but in a way that embraces the Mac's unique features, rather than feeling like a refresh-for-the-sake-of-a-refresh. My favorite is a much clearer contrast between active and inactive windows.
None of those changes are SwiftUI though. It's a new skin. And very few of those changes are new apps.
In the past few years we've had anything from the new native AppStore that doesn't have a single consistent behaviour [1] to the plethora of half-baked barely functioning app stubs in Swift UI/Catalyst [2]. These are first-party apps by Apple themselves, and they are perfectly fine with the state they are in, and they had no qualms whatsoever when releasing them. That's what "obsessive attention to details"[3] has been on the Mac for the past many years.
The very few examples/exceptions (Big Sur's Messages) are exactly that: very few.
Big Sur has been moving closer to the look and feel of iPadOS so that the new Apple Silicon machines can run iOS-native apps under catalyst without it being too jarring a difference. They greatly increased the amount of code in catalyst to make this possible as well.
At the same time, they have been adding Mac features to iPadOS to make it easier to make a full-featured iPad app closer to a proper featured Mac app. One example there would be mouse/trackpad support. Another would be the multitasking support which, for all of its UX weaknesses on use, makes variable sized, multi window applications available on both platforms.
Messages is an example of the medium-term game Apple is playing here. I anticipate a large number of the built-in apps to be (finally) a single code-base under a single team. They are gaining more capability to do easy, deep customization per OS in each release - but also seeing the systems themselves move closer in terms of UX feature set.
> Big Sur has been moving closer to the look and feel of iPadOS so that the new Apple Silicon machines can run iOS-native apps
Look and feel has little to do with the ability to run apps. The primary reason Apple Silicon will run iOS apps natively because it will be the same processor architecture.
However, a desktop OS being shoehorned into a mobile-like design is a very bad thing for a great amount of extremely obvious reasons.
I can’t believe you’re downvoted for criticising Apple on a thing they objectively pooped the bed on in the past couple of years.
Mac apps released by Apple have been a mishmash of very inconsistent design lately, most people in the Mac enthusiast community even agree with this (think Gruber, Marco, etc.)...
I definitely found it easier to distinguish between active and inactive windows in Big Sur vs High Sierra. Not sure exactly what design elements caused that, as I haven’t used Big Sur since July, but it was noticeable.
Mind, Mavericks is still a lot better than both...
> It was like pulling teeth trying to convince developers to use Swift.
Huh? That was not what I witnessed at all. A lot of people were quick to adopt Swift when starting new projects, but still didn't replace Objective-C on the older ones. IMO it was one of the sanest language migrations I ever witnessed in this industry. (Java to Kotlin in Android also as nice and same, IMO)
Considering Apple still has a large Obj-C legacy, I doubt we'll see it deprecated any time soon. Carbon for example took almost 12 years to be removed!
I've seen plenty of people getting all upset that they think Swift 5.3 is still as broken as Swift 1 or 2 back when they last tried it. There are also those, some in this thread, who are proclaiming their high level language of choice as superior just because they're more familiar with it.
> You quickly get left behind in the Apple ecosystem if you don’t move with Apple.
The number of binaries and frameworks in iOS 14 using Objective-C vastly exceeds this relatively small list. Objective-C hasn't been jettisoned by Apple by any stretch of the imagination.
No, but they're releasing new frameworks with Swift-only APIs. They're not "jettisoning" Objective-C, and I'm sure teams at Apple will continue to write stuff in Obj-C for years to come. It'll likely never disappear entirely. But that number will continue to shrink.
That's only because WidgetKit uses SwiftUI. Granted, if more and more APIs become reliant on preexisting Swift-only APIs like SwiftUI or Core ML, that certainly leaves Objective-C out of the cutting edge.
> Objective-C hasn't been jettisoned by Apple by any stretch of the imagination.
True, but melling didn't say that Objective-C has been jettisoned.
My understanding is that you can't iOS home screen widgets in Objective-C, correct? If so, isn't that a reasonably-clear signal that Objective-C developers are starting to be left behind?
> My understanding is that you can't iOS home screen widgets in Objective-C, correct?
I don't know, I haven't looked into them. But Swift is now more than 6 years old, and iOS home screen widgets are literally only days old, so I'd say "You quickly get left behind in the Apple ecosystem" is an exaggeration.
If you're a fan of obj-c it's perfectly reasonable to pretend that swift is just a DSL for describing views and write all of the logic for your widget in obj-c. In that setup SwiftUI is replacing interface builder xibs rather than obj-c.
I started writing Swift within minutes of it being announced. I released my first Swift app on the store just about fifteen minutes after the RC of Xcode was released.
I did a lot of ObjC, but I've enjoyed using Swift. When I create frameworks and modules, they are Swift-only (no ObjC headers), because I like to leverage native Swift stuff, like enums and whatnot.
But I am writing app code. I think ObjC is a better systems language, so I don't think it's going anywhere, any time soon. It's a lot safer than "raw" C.
If you mean Objective-C code with minimal usage of C functions/structs/etc., then IMO Swift is actually the better systems language. Cf. the just-announced System library.
I love Swift, and it would be a great systems language, but it is important for system languages to have some kind of "bare metal" interfaces, with solid, predictable binary expression. Even C generally needs to be implemented in some kind of specialized embedded form for a lot of tools.
To me, Swift is a fairly high-level language, and I like that. I cut my teeth on the bare metal, and don't really miss working at that level.
Correct me if I'm wrong, but I'd bet Metal is almost entirely C++ with a little Obj-C sprinkled on top for the API. And of course C++ is still a better systems language than Swift.
My point was that Swift is better than pure Obj-C for systems programming. Admittedly, that might be a poor comparison, since Obj-C was specifically built to be used alongside C as the systems language.
But yes, I think the ultimate goal is that Swift will be better than C/C++ for systems programming too. It still has a ways to go, and there are a lot of libraries that will need to be written, but I do think it's possible.
I get this, but I also see people I'd describe as real experts saying "SwiftUI isn't ready for production, too buggy for serious apps."
I'm probably going to be all-in on SwiftUI but it does make me nervous -- what if Apple decides the bugginess level is acceptable and you should just code around it if you don't like it? That's a pretty terrible outcome for people like me who are investing now in the ecosystem.
>I get this, but I also see people I'd describe as real experts saying "SwiftUI isn't ready for production, too buggy for serious apps."
Well, there are all kinds of apps written in SwiftUI.
It might not be ready to write Photoshop or Final Cut Pro in it, but most apps aren't "serious" like that. Heck, apps written in even less supported/mature environments (like React Native) will be just fine...
I very much doubt Metal or Core Audio are implemented in ObjC. C++ or C are much more likely candidates, and is what Apple is generally using for low level code like that...
There are many reasons to favor Swift over Objective-C, but "Swift is less visually noisy" is both subjective and not weak. Conciseness and expressiveness can be a reason, sure, but the article also lobs the tired "look at all those square brackets and lack of syntactic sugar" critique.
Having written prod code in asm, fortran, pascal, c, c++, java, basic, objc, and swift, I'm weary of arguments about better languages. But what is inarguably true about Apple (and before it NeXT) technology is they are not afraid to jettison what they decide is behind them, though it may linger a long time. Swift and SwiftUI is clearly the path forward.
Objective-C on UIKit in 2020?! You should absolutely be using Swift for all new UIKit view controllers, note that SwiftUI is not a requirement for usage of swift.
Advantages of Swift and SwiftUI? Nevermind, I'll try to answer both:
For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had. It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc. It has a modern type system with type inference, string templating, Option type, tuples and simpler closures. It's pretty nice actually.
SwiftUI is just a way of writing UIs using Swift and a reactive paradigm. It looks and feels like React but instead of the embedded HTML of React it only uses plain Swift. The previous recommended method used XML (in XIB files) and needed special tooling (Interface Builder), which was nice but not perfect. Also doing git merges in the XML files are much harder.
> For Swift it's a modern language that doesn't need to have backward compatibility with C that Objective-C had.
That doesn't seem accurate. Interoperability with C and Objective-C was a fundamental design requirement of Swift. C interoperability is not particularly pleasant in Swift, but it's certainly there. It has to be there.
Apple has been creating some easier to use Swift wrappers around old UNIX C API. For example, their Network framework, and the just-announced Swift System.
I think GP meant syntactic compatibility. Objective-C is an embedding within C and C++ code and has to be (mostly) compatible with them for the free mingling of each language. Swift is freed from that need, but that doesn't mean it isn't designed for interop (calling between each language).
In any case, I'm not fully convinced which language has the advantage and which the disadvantage in this case. You still have to call C API in Swift, and it's rather painful.
I would also say that Swift by design is very much constrained, you might say held back, by the needs of Cocoa compatibility. For example, Swift takes features that are mere conventions in Objective-C, such as initializer patterns (which can be ignored when they're inconvenient), and makes them into built-in language requirements. This becomes very awkward at times.
Perhaps the worst, "ugliest" feature of Swift is optionals. Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility. The language would be so much nicer without them.
Optionals doesn't exist because of ObjC compatibility. They are a hallmark feature in functional languages like Haskell and Scala, and in other modern languages like Rust and Kotlin. Even C++17 introduced std::optional.
And I completely disagree, they are one of the best features of any language and are able to remove a whole class of very annoying bugs.
And sorry, but I didn't understand the part about the initializer pattern... are you talking about constructor overloading? This has also been a traditional feature of OOP languages for decades.
> Optionals doesn't exist because of ObjC compatibility.
The problem is that every Objective-C type is essentially an optional, so any Swift code using Cocoa frameworks, based on Objective-C, is a deluge of optionals. Your entire code base is constantly dealing with them. It's a mess.
> I didn't understand the part about the initializer pattern... are you talking about constructor overloading?
I'm pretty familiar with the Objective-C internals, and Swift optionals are not there because of Objective-C, as there are multiple ways of having compatibility between the two languages (but none as safe as having Optionals).
Like I said, Optionals are an extremely popular feature in most modern languages, and Swift would be very criticized if it had not included it.
Ok, you are talking about constructor overloading, which is a pretty common and uncontroversial feature present in pretty much every OOP language made in the last 30-40 years.
> Ok, you are talking about constructor overloading
No, I'm not. I'm talking about, for example, "Classes and structures must set all of their stored properties to an appropriate initial value by the time an instance of that class or structure is created." Which is not the case in Objective-C.
Also the concept of a "designated initializer", which is again simply a convention in ObjC.
EDIT:
To be clear, I'm not trying to make statements about the history of programming languages, or about general programming concepts. I'm trying to say that the very specific way that Swift implements general programming concepts (which may vary greatly in different languages) was obviously inspired and constrained by backward compatibility with Cocoa and Objective-C. If you were to design a new programming language from scratch, without those backward compatibility requirements, you most likely wouldn't implement things exactly the way Swift does. It would be strange if you did. Swift is very much constrained by backward compatibility, and very much non-ideal as a result.
If you read that entire long initializer document from top to bottom, it's clear that this is all specifically based on Objective-C patterns — as it needs to be for Cocoa compatibility — regardless of whether there are historical antecedents of the general concept.
Sorry but let's maybe agree to disagree? You seem to be pointing to Swift features that are very different from ObjC (as you said yourself), but are very close to other similar multi-paradigm languages. You asked "Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility" and I'm answering that other languages have it. It's not that Swift turned ObjC conventions into requirements: it's that in ObjC they were mere conventions, in almost every other new language similar to Swift they are already requirements.
Sure, Swift has ObjC baggage, but those two specific features would be present in any multiparadigm language launched in the same period. Check out Scala, Kotlin and even C#, for example, and you'll see lots of similarities. Swift is going exacly where other languages are converging to.
In fact, the inspiration for the ad-hoc initializer pattern in ObjC you're mentioning probably came from other contemporary languages... maybe C++ or Smalltalk. Optionals in Swift have nothing to do with ObjC: in Swift they come from functional programming tradition, nullability in ObjC is a virtue of being a superset of C. The fact they work together is a virtue of compatibility, but those two Swift features were not specifically designed to serve ObjC.
I think the truth is somewhere in the middle–Swift was not created in a vacuum, of course, but it does have to take Objective-C into account and thus we have the concepts of designated and convenience initializers, or implicitly unwrapped optionals. However, if you look at them more closely it's pretty clear they exist to bridge Objective-C to Swift concepts–fully initialize your objects before you use them, or annotate your code for nullability, which is where Swift wants you do go.
> Perhaps the worst, "ugliest" feature of Swift is optionals. Why would you even add optionals to a new language if not for the necessity of Cocoa/ObjC compatibility. The language would be so much nicer without them.
Conceptually, the ability to represent the lack of a value is quite a common requirement. Swift has specific language syntax and compiler data structuring around the Optional type, but it is just a swift enumeration with an associated value at its core.
IUO (implicitly unwrapped optional) is mostly a compatibility feature however, for languages which were designed around the idea of nullable pointers like objc and C. UIKit and AppKit, for example, assume views have properties which can be nil before the view loads and non-nil afterward. IUO allows you to rely on this convention rather than have to safe or force-unwrap every property for use.
There was an interesting discussion about reactive UIs yesterday (https://news.ycombinator.com/item?id=24599560). Sounds like Swift have it fairly sorted. Is there anything like React Native for Swift rendering to html? A sort of “Swift Non Native”?
I think SwiftUI is still settling, so I expect to see more movement in this are in the short-term future. But I don't see Apple releasing an HTML-emitting-SwiftUI by themselves.
> The previous method used XML (in XIB files) and needed special tooling (Interface Builder)
This isn't really true. Interface Builder was an alternative to writing UI code, but programmatic UI is still allowed and is well-supported. Many developers prefer it to IB.
> It has a very expressive syntax and uses modern idioms you see in JS, Kotlin, Rust, Scala, C#, etc.
Yeah and that's exactly what I would call a disadvantage. I prefer dumb programming languages like Java, C++11 without the auto keyword, and Objective-C. They're much easier to understand because there are fewer ways to achieve the same thing and they don't require keeping as much context in your head while reading the code.
IRL example with Swift: I wanted to fix a logic bug in someone else's code and spent an hour trying to get a field from an object. I could see it in the debugger but every way to get it I could think of produced an uninformative syntax error. There was nothing to google because there were no keywords around it, even. Then the author of the code in question came online and explained that it's an "enum with associated value" (wtf?!) and you have to use this `if let` or `case let` abomination to extract the fields into local variables.
Another IRL example with Swift is that this whole immutability-by-default thing was just driving me insane because I'm too used to the fact that I can overwrite function/method arguments but Swift won't ever let me.
Another problem of these languages is that you have to actually learn them, and there's too much to learn. And good luck understanding anything without that encyclopedic knowledge.
To me, it's all just abstractions that get in the way more than they help, tbh.
C++ has most of its complexity in the standard library, and that is easy enough to look up if you don't understand something. It's relatively barebones as far as the syntax goes. Swift, on the other hand, has way too many features a.k.a. syntactic sugar in the language itself.
Uh, no? Just parsing the language is undecidable, there's problems with "vexing parses" and strange overloads, there's like twenty seven ways to initialize things, there's new syntax every release to do something that has already existed in the language…
Sorry, but in a previous comment you mentioned that you prefer "dumb programming languages like [...] C++11 without the auto keyword". However "too much to learn" and needing "encyclopedic knowledge" is exactly how most people with different levels of familiarity with the language would describe C++ (with or without auto).
To me it sounds as if your problem is purely lack of familiarity with modern languages, rather than them lacking some specific property that your usual languages have.
I mean you can say that for any language. If someone has to learn C or Java, you still need to learn how those languages work, build domain expertise and so on.
Swift is a very nice general purpose language and I’ve been writing code decades in almost most mainstream languages. I much prefer writing Swift code, in face some of my back end projects have been written in 100% swift, this allowed me to reuse models and APIs with the iOS and MacOS counterparts.
How have you written backend code in Swift, were you able to use it in places you would normally use e.g. C++?
I'm asking because I like Obj-C/Swift, and am wondering if it's possible through some clang/LLVM magic to be able to code Obj-C/Swift in environments that expect C or C++, for example like in Qt. Like, could I have a traditionally C++ app (Qt app) but have most of my code be in another LLVM-compatible language.
> Like, could I have a traditionally C++ app (Qt app) but have most of my code be in another LLVM-compatible language
It is possible! I mix Swift and Rust in my day job. I use the C ABI to interface between the two. The Swift layer is very thin and pretty much just a bridge between Rust and Cocoa/UIKit/Metal, but there's nothing stopping you from doing the opposite.
If you're going to bridge Swift with Qt, the sanest way is to use Objective-C++ to wrap Qt calls and call it from Swift.
However keep in mind that the Swift experience in other Operating Systems might not be as good as in Macs. That's why I went with Rust for this project. But things might have changed in the meantime!
I did some searching to see people's experiences substituting other languages for C++ through LLVM, and didn't find much other than samples of translated calls.
Given that there would be a big benefit to this (not having to learn a new language, less manual memory management), are there good reasons this isn't way more common?
If you use the C ABI you can just link a bunch of object files together.
Rust people are doing it a lot for graphics/game stuff, and there's lots of production MacOS apps mixing ObjC/Swift (because they're transitioning), or consuming C/C++. Of course in this case it's mostly Xcode doing the magic, but behind the scenes it's just calling clang.
How worse? How would you even begin to understand this line without an IDE?
auto something = someObject->someFunction();
// and then 10 lines of various operations on "something"
// also imagine that someObject is also auto and returned from somewhere
I've had to deal with code like this. It wasn't pleasant, even with an IDE. There are very few cases where type inference is good and doesn't make your code an unreadable mess.
Step number one is not naming your things "something". I for one am glad I can use "auto" instead of "std::vector<int>::size_type" in my code–in this case the actual type this couldn't matter less; all you need to know is that it's some kind of unsigned integer. The same is true for Swift, where it's generally a lot more useful to know you have some type of sequence rather than "I have a LazyMapSequence<LazySequence<[Int]>.Elements, String>". Plus, C++ is one of those languages where certain things have types that you cannot write down, so auto is required to use certain parts of the language!
Type inference is the usual tradeoff for being able to write statically-typed code efficiently. I think it's better than
MyType something = new MyType(...);
like in old-school Java, is it not? IDEs and LSP-enabled editors are pretty much the standard nowadays, although I agree that it's nice to be able to read code without one.
Also, that code you mentioned seems like bad style with the auto keyword; the type should be obvious.
> IDEs and LSP-enabled editors are pretty much the standard nowadays
There are many places where you see code without IDE-like features. One that comes to mind is everything related to git. Web-based git tools like github, git GUIs, command-line git, you name it.
Besides, it's nice to be able to read and understand the code without needing to download the entire project and importing it into an IDE just for that.
My idea is that you almost always write in an IDE, but not necessarily read in one. Thus, for verbose languages, the IDE would generate most of that example for you (I know for sure IDEA does this exact completion) but it will be perfectly understandable in a git diff.
> There are many places where you see code without IDE-like features. One that comes to mind is everything related to git. Web-based git tools like github, git GUIs, command-line git, you name it.
Both git and web-based git+ services like Github are frequently used through deep editor/IDE integrations, so, no, I disagree that “everything related to git” is a good example here.
I do. The problem is, others don't necessarily do. A good-in-my-world language makes it take more effort to write unreadable code than readable.
Everyone seems to only be judging languages by the code you write yourself, totally oblivious to the fact that reading and understanding someone else's code, including in projects you don't influence, is also an important part of being a software developer.
1. Modern language with conventions that will feel "normal" to ambitious younger programmers.
2. Lots of special language features to support the specific use-cases of iOS apps. As Go is to writing for server farms at Google, so is Swift to writing for Apple devices.
3. Very simple UI programming paradigm, at some point, maybe now? SwiftUI is or isn't production-ready depending whom you ask, but if we treat this as the future for iOS then it means any kind of data-centric or CRUD app will be trivial to bootstrap.
4. Sooner or later you will have no choice.
Granted, #4 is not an advantage to the language, but maybe to learning it?
Consider it's also possible to use other languages like JS/TS (via React Native, Phonegap, etc), Dart (via Flutter), C# (via Xamarin) or even Delphi (via Embarcadero RadStudio), among others, so even in the unlikely event of Apple deprecating Objective-C, choice is not really going away.
