Apple’s use of Swift and SwiftUI in iOS 15(blog.timac.org)
blog.timac.org
Apple’s use of Swift and SwiftUI in iOS 15
https://blog.timac.org/2021/1219-state-of-swift-and-swiftui-ios15/
169 comments
I needed to do some development in Swift mid last year. I liked it and would continue to use if it weren’t for the fact that it seems like the only current and useful learning resources are Apples WWDC videos and similar content.
> weren’t for the fact that it seems like the only current and useful learning resources are Apples WWDC videos and similar content
I don't know what you mean by "and similar content" but even though I agree that Apple's own documentation could be a lot better (though it is gradually improving), there is an enormously vibrant and flourishing ecosystem of learning materials at all levels, including people like Paul Hudson's Hacking With Swift (with website, tutorials, videos and books), Sean Allen (with YouTube videos and extensive Teachable tutorial courses), expert and in-depth discussions on SwiftUI from the programmers on pointfree.co, other in-depth resources including weekly video tutorials and books from the amazingly smart Chris Eidhof and Florian Kugler at objc.io, video tutorials and in-depth articles from Bart Jacobs at cocoacasts.com, not to mention the very advanced blog-posts from John Sundell at Swift by Sundell.
There are probably hundreds of other blog-resources - definitely more than I can keep up with on a weekly basis.
So lack of learning resources is definitely not a problem for Swift and SwiftUI if you just use some initiative to find it.
PS: people here often mention raywenderlich.com but my own experience is their content often boils down to "for networking use this external library..."
I don't know what you mean by "and similar content" but even though I agree that Apple's own documentation could be a lot better (though it is gradually improving), there is an enormously vibrant and flourishing ecosystem of learning materials at all levels, including people like Paul Hudson's Hacking With Swift (with website, tutorials, videos and books), Sean Allen (with YouTube videos and extensive Teachable tutorial courses), expert and in-depth discussions on SwiftUI from the programmers on pointfree.co, other in-depth resources including weekly video tutorials and books from the amazingly smart Chris Eidhof and Florian Kugler at objc.io, video tutorials and in-depth articles from Bart Jacobs at cocoacasts.com, not to mention the very advanced blog-posts from John Sundell at Swift by Sundell.
There are probably hundreds of other blog-resources - definitely more than I can keep up with on a weekly basis.
So lack of learning resources is definitely not a problem for Swift and SwiftUI if you just use some initiative to find it.
PS: people here often mention raywenderlich.com but my own experience is their content often boils down to "for networking use this external library..."
Hey, I do full time iOS development, there’s tons of great resources, but out of all of them my favorite is https://hackingwithswift.com
This is pretty cool, thanks.
Coming from Java and C++, I once wanted to fix a bug in a macOS app written in Swift that used my C++ library. It was a rather frustrating experience because none of my existing knowledge worked. I could see the field I needed in the object in the debugger, but for the life of me couldn't figure out how to get it. It turns out (had to ask the developer who wrote this) I had to write some really weird `if let ...` thing that would extract those fields into local variables that I could then use. Also, immutable everything by default. You can't overwrite function arguments within the function itself, like you could in Java and C++. And unwrap, unwrap, unwrap, unwrap, unwrap everything.
And yes, versions, as you said. I don't like moving targets. I enjoy stability. Java changes, but it at least does so carefully and doesn't drop features (but does sometimes drop obscure parts of the standard library). You can usually compile and run Java 6 code unchanged with JDK 17 just fine.
I like it when there's a clear line between the language itself and its standard library. Swift doesn't have one, neither does Kotlin.
And yes, versions, as you said. I don't like moving targets. I enjoy stability. Java changes, but it at least does so carefully and doesn't drop features (but does sometimes drop obscure parts of the standard library). You can usually compile and run Java 6 code unchanged with JDK 17 just fine.
I like it when there's a clear line between the language itself and its standard library. Swift doesn't have one, neither does Kotlin.
>It was a rather frustrating experience because none of my existing knowledge worked.
Well, it is a new language
>I could see the field I needed in the object in the debugger, but for the life of me couldn't figure out how to get it.
I would need more context to help you out here. You had SomeObject with a child SomeChild and couldn't do
let a= SomeObject.SomeChild ? Perhaps I'm misunderstanding.
>I had to write some really weird `if let ...` thing that would extract those fields into local variables that I could then use.
Sounds like this is importing from some file or something, and whoever wrote the code below you just made everything optional and chucked all the responsibility for that up the chain. I'd have to see the code but it sounds like bad design.
>Also, immutable everything by default. You can't overwrite function arguments within the function itself, like you could in Java and C++. And unwrap, unwrap, unwrap, unwrap, unwrap everything.
That's a feature not a bug. Maybe I'm misunderstanding you, but if you have
func twoStrings(a: String, b: String) -> String, _why on earth_ would you ever want to be able to override that func's params and feed it something else? a/b would be a completely unexpected type and blow up/fail to compile. If you're routinely needing to do this, you haven't embraced static typing I think. Swift Generics are a potential option.
Well, it is a new language
>I could see the field I needed in the object in the debugger, but for the life of me couldn't figure out how to get it.
I would need more context to help you out here. You had SomeObject with a child SomeChild and couldn't do
let a= SomeObject.SomeChild ? Perhaps I'm misunderstanding.
>I had to write some really weird `if let ...` thing that would extract those fields into local variables that I could then use.
Sounds like this is importing from some file or something, and whoever wrote the code below you just made everything optional and chucked all the responsibility for that up the chain. I'd have to see the code but it sounds like bad design.
>Also, immutable everything by default. You can't overwrite function arguments within the function itself, like you could in Java and C++. And unwrap, unwrap, unwrap, unwrap, unwrap everything.
That's a feature not a bug. Maybe I'm misunderstanding you, but if you have
func twoStrings(a: String, b: String) -> String, _why on earth_ would you ever want to be able to override that func's params and feed it something else? a/b would be a completely unexpected type and blow up/fail to compile. If you're routinely needing to do this, you haven't embraced static typing I think. Swift Generics are a potential option.
> I'd have to see the code but it sounds like bad design.
I think that dev called that "enum case with parameters" or something similar. Don't really remember at this point.
> _why on earth_ would you ever want to be able to override that func's params and feed it something else?
No, I meant overwriting function arguments within the function itself to avoid rewriting the code below that point. I do sometimes do that in Java and I find it a sensible thing to do. For example
I think that dev called that "enum case with parameters" or something similar. Don't really remember at this point.
> _why on earth_ would you ever want to be able to override that func's params and feed it something else?
No, I meant overwriting function arguments within the function itself to avoid rewriting the code below that point. I do sometimes do that in Java and I find it a sensible thing to do. For example
public String doSomethingWithTwoStrings(String a, String b){
if(some condition){
a=something else;
}
// do something with (possibly overwritten above) a and b
return result;
}
> enum case with parameters
Ah, this is a language feature of enums in Swift. Swift enums allow you to keep associated values with a specific case and you need to unpack them with a `let` when dealing with that value.
E.g.
E.g.
enum Animal {
case lion
case tiger
case bear
case ohMy(Int)
}
var a:Animal
switch a {
case .ohMy(let value):
// do something with `value`
...
}Ah, I see what you mean. Thanks for the explanation.
This is just my opinion but doing that seems to be very dangerous. You're probably fine for small functions with single-developers, but once you get complex and have multiple people working on the code it seems easy for one dev to confuse another.
If you insist on that pattern (lets call it the local variable method) you can define vars such as
var localA = a
var localB = b
at the top of the function and work on it there. Personally I prefer function arguments to be immutable, so that any time you call them you know what you're working on is what the function was given. Forcing you to declare a local var makes the code much more explicit and easy for another human to reason about what you're doing, whereas they could very easily miss an "a=something else".
This is just my opinion but doing that seems to be very dangerous. You're probably fine for small functions with single-developers, but once you get complex and have multiple people working on the code it seems easy for one dev to confuse another.
If you insist on that pattern (lets call it the local variable method) you can define vars such as
var localA = a
var localB = b
at the top of the function and work on it there. Personally I prefer function arguments to be immutable, so that any time you call them you know what you're working on is what the function was given. Forcing you to declare a local var makes the code much more explicit and easy for another human to reason about what you're doing, whereas they could very easily miss an "a=something else".
I think you should RTFM before jumping in and trying to code by guessing the language semantics. All of these things you dislike are easily achieved by a small change in keyword or function signature.
There's no clear line between language and standard library in C++ or in Java.
The only documentation that’s more frustrating than Apple’s “‘doYouReallyWantThat’ is an attribute. It returns ‘true’ if you really want that. We can’t tell you what’that’ means. Code samples are for lesser people” is Python, where I somehow, every time I want to look up if it’s ‘subst’ or ‘substring’, I somehow end up in either the C bindings or some ten-year old PEP on package management that was never implemented.
PHP in the late 90s did it right (and probably still does today), ruby gets it mostly right, although it, like python, somehow still hasn’t figured out how to get Google to rank the most recent version higher than the one that’s a decade out of date.
The popularity of video tutorials is baffling. Is it because it’s the only way to earn money with this content? Anyway, I’ll just add the observation that the three communities that seem to really embrace the format are QAnon, “men’s right’s”, and WordPress.
PHP in the late 90s did it right (and probably still does today), ruby gets it mostly right, although it, like python, somehow still hasn’t figured out how to get Google to rank the most recent version higher than the one that’s a decade out of date.
The popularity of video tutorials is baffling. Is it because it’s the only way to earn money with this content? Anyway, I’ll just add the observation that the three communities that seem to really embrace the format are QAnon, “men’s right’s”, and WordPress.
It's odd because when iOS development was new the docs and HIG were very comprehensive. Almost every answer regarding iOS on places like StackOverflow would be "here's a link to that part of the docs". They also had a lot of good examples.
And now they’re gradually making those old docs unreachable. I don’t know what Apple’s endgame is here, but it’s pretty sad.
Those of us that are old dogs can still find most of them on the archive, because we know kind of what to search for, but even those might disapeer one day.
Horizontal stack control - https://www.appcoda.com/learnswiftui/swiftui-gridlayout.html
Is that what you need?
Is that what you need?
This isn’t exactly what I was looking for - basically I wanted an HGrid with a bunch of items that would automatically wrap rather than overflow. (In the WPF world that I’m more accustomed to this would be called a “WrapPanel”).
I eventually found a package on GitHub called WrappingHStack that did exactly what I needed but this struck me as odd that something like this wasn’t out of the box functionality.
I eventually found a package on GitHub called WrappingHStack that did exactly what I needed but this struck me as odd that something like this wasn’t out of the box functionality.
Ahh I see. I would agree, still a lot of missing components.
>Swift itself is also quite nice - although it’s evolving really, really fast and tutorials/howtos and such go stale really quickly. Swift can and will drop language feature at the drop of a hat. Just today I wanted to do a simple C++ style for loop only to find this was removed completely from the language.
What are you talking about? Swift has had (and still has) basic for loops since 1.0. What am I missing here?
What are you talking about? Swift has had (and still has) basic for loops since 1.0. What am I missing here?
Details: https://github.com/apple/swift-evolution/blob/main/proposals...
There were plenty of alternative ways to accomplish my scenario but they ended up being pretty clunky and overly expressive for what I was trying to do at the time.
It seems like the Swift language designers have no qualms about removing language features and breaking old code as a result - which is certainly their prerogative but it’s not something I’m accustomed to.
There were plenty of alternative ways to accomplish my scenario but they ended up being pretty clunky and overly expressive for what I was trying to do at the time.
It seems like the Swift language designers have no qualms about removing language features and breaking old code as a result - which is certainly their prerogative but it’s not something I’m accustomed to.
Wait, is this some kind of a joke? That's swift evolution number *seven*. They're on hundreds now. That was committed in 2015. This is what, Swift 1.x days? Before?
What production code was even using swift back then? The vast majority of people didn't _start_ using swift until 3.x.
I know we're supposed to take the best-possible interpretation of someone's comments here, and in my opinion a joke is the best possible take on the above post. The alternative is you're being disingenuous.
What production code was even using swift back then? The vast majority of people didn't _start_ using swift until 3.x.
I know we're supposed to take the best-possible interpretation of someone's comments here, and in my opinion a joke is the best possible take on the above post. The alternative is you're being disingenuous.
Not sure where these accusations are coming coming from but no joke or disingenuousness was intended here. You replied to my comment originally and I answered your question with more details.
I’ve said before that Swift is a relatively new language to me. I’m not up to date on its many “evolutions” or particularly familiar with its history and nuances. I am not even sure what Swift version I’m on right now other than “whatever the latest version of Xcode uses”. I’m just trying to learn the Swift/SwiftUI stack by writing some code for MacOS and iOS as part of a hobbyist project that I’m working on during my downtime.
When I was trying to do something that’s worked fine in many other languages the Swift compiler literally told me “no” because it had been removed from the language in version X. I mean whatever - I found how to work around this - it was a kind of clunky and overwrought one versus the simplicity of the original code but it met my needs and it was a teachable moment.
My overarching point originally wasn’t meant as a hard criticism of Swift. I’m fact I quite like it. It was an observation that Swift is unlike other languages I work with regularly where it’s rare that language features are ever removed (or at worst hidden behind compiler or feature flags).
Swift’s designers clearly think it’s ok to remove things they don’t like or they don’t think meets their vision. That’s fine and valid. My point was that as a result of this stance that means tutorials and samples can become stale in a way that I don’t see with the other languages I work with where you’re more likely to be using old methodologies or obsolete APIs - that can/should emit compiler warnings or IDE refactor hints - but otherwise won’t fail to compile because something was removed completely.
I’ve said before that Swift is a relatively new language to me. I’m not up to date on its many “evolutions” or particularly familiar with its history and nuances. I am not even sure what Swift version I’m on right now other than “whatever the latest version of Xcode uses”. I’m just trying to learn the Swift/SwiftUI stack by writing some code for MacOS and iOS as part of a hobbyist project that I’m working on during my downtime.
When I was trying to do something that’s worked fine in many other languages the Swift compiler literally told me “no” because it had been removed from the language in version X. I mean whatever - I found how to work around this - it was a kind of clunky and overwrought one versus the simplicity of the original code but it met my needs and it was a teachable moment.
My overarching point originally wasn’t meant as a hard criticism of Swift. I’m fact I quite like it. It was an observation that Swift is unlike other languages I work with regularly where it’s rare that language features are ever removed (or at worst hidden behind compiler or feature flags).
Swift’s designers clearly think it’s ok to remove things they don’t like or they don’t think meets their vision. That’s fine and valid. My point was that as a result of this stance that means tutorials and samples can become stale in a way that I don’t see with the other languages I work with where you’re more likely to be using old methodologies or obsolete APIs - that can/should emit compiler warnings or IDE refactor hints - but otherwise won’t fail to compile because something was removed completely.
> Swift itself is also quite nice - although it’s evolving really, really fast
Coming from C# you should feel right at home (though the documentation seems better).
If I compare the C# code I was writing 12 years ago to the current one, it feels like 2 different languages.
Coming from C# you should feel right at home (though the documentation seems better).
If I compare the C# code I was writing 12 years ago to the current one, it feels like 2 different languages.
I think the primary difference is while C# evolves, old language features don’t just get removed. Old code samples will still work even if they aren’t “modern” or optimal solutions anymore.
For contrast, Swift will drop support for features that can render old code samples useless. I’ve written code fails to compile with an error literally saying what I am trying to do was removed from the language in version X. Things like that can be aggravating for a newbie like me to deal with.
For contrast, Swift will drop support for features that can render old code samples useless. I’ve written code fails to compile with an error literally saying what I am trying to do was removed from the language in version X. Things like that can be aggravating for a newbie like me to deal with.
Swift is a language that feels right to me in ways that others don't. I code on Linux and Windows, not on Macs. Swift on Linux works OK, but it's there that you really see how few pure Swift libraries there are. For example, on the project we were exploring, the only Swift library for handling zip files--and we asked the community several times--was a personal project with 14 stars. That was not going to work for our enterprise.
The port of Swift to Windows barely functions and in every dimension is in worse shape.
It's a shame b/c the language is truly beautifully designed.
The port of Swift to Windows barely functions and in every dimension is in worse shape.
It's a shame b/c the language is truly beautifully designed.
Don't swift and rust share a few of these things that make it "feel right"? With rust the whole ecosystem thing seems to be a lot better. Also rust has C(++) interop (so you have every library you could wish for), does swift not have that?
It does have c interop so you could just use libarchive. Though writing c in swift is a bit less magical.
While technically true you then have to use pointers in swift and they made it hard by design to do that.
Last time I looked, Swift didn't have a stable way to export C-compatible ABIs.
@_cdecl exists, although it's underscored.
I was under the impression that this feature wasn't stable, but it's been years since I've thought about it.
Second this. IMO Swift is extremely easy to pickup, especially if you're coming from C++ land like me. But sometimes I feel its ecosystem being...obscure.
well yeh if you can pick up c++ then swift is easy, but apple is positioning it as a first language which it is definitely not.
I don’t think the story is ever going to change much on non Apple platforms. It just doesn’t make sense for them.
> It just doesn’t make sense for them.
It does though. As least for me. Better support on Windows and Linux would increase the number swift developers which would the in turn result in more and better open source libraries.
For Apple this could mean that their own open source libraries could get better, they have more tools/libraries to choose from, or simply that they have a greater pool of talent for hiring.
Looking at Go (and Rust) I think this is somewhat shown. There are a lot of different factors, but I think the development tools of Go is the #1 reason why it is basically the only "new" language in a long time that gained a large enough popularity to become mainstream - as in you actually find jobs developing in Go. Which is in some ways sad. It seems like Swift could be the very good fit for backend/serverless development.
I guess the real question is how much effort would it take to get the development tools like editor support to the next level?
It does though. As least for me. Better support on Windows and Linux would increase the number swift developers which would the in turn result in more and better open source libraries.
For Apple this could mean that their own open source libraries could get better, they have more tools/libraries to choose from, or simply that they have a greater pool of talent for hiring.
Looking at Go (and Rust) I think this is somewhat shown. There are a lot of different factors, but I think the development tools of Go is the #1 reason why it is basically the only "new" language in a long time that gained a large enough popularity to become mainstream - as in you actually find jobs developing in Go. Which is in some ways sad. It seems like Swift could be the very good fit for backend/serverless development.
I guess the real question is how much effort would it take to get the development tools like editor support to the next level?
Swift is designed to be a lock-in to Apple development for Apple. If it was otherwise, why WOULDN'T you also provide compilation to Wasm and Javascript, etc., if you are a company with the resources of Apple? Don't get me wrong, Swift is great, but it is a big lock-in.
I have programmed for the last 4 years or so almost exclusively in Swift, but I am now switching to TypeScript in general. Writing my libraries in TypeScript, I will still be able to access them from Swift and other languages via embedded browser engines.
I have programmed for the last 4 years or so almost exclusively in Swift, but I am now switching to TypeScript in general. Writing my libraries in TypeScript, I will still be able to access them from Swift and other languages via embedded browser engines.
> why WOULDN'T you also provide compilation to Wasm and Javascript
Because it's useless save for a single kind of development (websites) and the main issue is not even in spitting out WASM but making the language runtime and libraries work in the browser. Most languages have no first-party WASM or Typescript support either.
Because it's useless save for a single kind of development (websites) and the main issue is not even in spitting out WASM but making the language runtime and libraries work in the browser. Most languages have no first-party WASM or Typescript support either.
Yes, because those other languages are made by other companies with equally vested lock-in aspirations.
You are right, Apple has no interest in supporting Javascript, what good would it do them except more work and hassle?
It would help many programmers though, to make their code more portable and available on more platforms. It would not be that easy to do, but also not that difficult. Rust is supporting WASM, Scala is supporting Javascript. Kotlin as well. Apple can't do it? Come on.
Just stating the obvious: The interests of Apple and programmers are aligned in some aspects, and opposed in others.
You are right, Apple has no interest in supporting Javascript, what good would it do them except more work and hassle?
It would help many programmers though, to make their code more portable and available on more platforms. It would not be that easy to do, but also not that difficult. Rust is supporting WASM, Scala is supporting Javascript. Kotlin as well. Apple can't do it? Come on.
Just stating the obvious: The interests of Apple and programmers are aligned in some aspects, and opposed in others.
If you are still looking for a pure Swift ZIP handling library, you can check out ZIPFoundation: https://github.com/weichsel/ZIPFoundation
You could take a look at either Rust or OCaml, Swift feels like it's between the two.
[deleted]
[deleted]
Is swift docs still bad? I remember developing for swift was a pain when you need to look for docs. Most of my resource came from Raywenderlich instead of official apple docs lol.
I have since moved away, but current company wants to move from RN to Native dev so i'm confused if i should be onboard with mobile or move to other dev teams.
I find it weird how big companies like Microsoft and Apple have these small flaws. Apple has really bad docs, but good in using its own tech. Microsoft on the other hand has good docs, but almost never uses its own tech (yes, i'm talking about xamarin).
I have since moved away, but current company wants to move from RN to Native dev so i'm confused if i should be onboard with mobile or move to other dev teams.
I find it weird how big companies like Microsoft and Apple have these small flaws. Apple has really bad docs, but good in using its own tech. Microsoft on the other hand has good docs, but almost never uses its own tech (yes, i'm talking about xamarin).
Apple’s iOS libs (not swift ui) although not well documented in parts, is probably the most complete and self consistent set of ui dev libraries around to develop against. Android and web are far more chaotic. I haven’t done windows dev so maybe that is better but nobody does windows desktop anyway.
Worst part of it is the lack of a full open source stack and build speed / xcode stability for swift, but its not bad if your just 1-5 engineers in one app. But if you scale to 30+ with +1 million lines after a few years it starts getting real bad unless you architect your app with devapps like airbnb did: https://medium.com/airbnb-engineering/designing-for-producti...
Worst part of it is the lack of a full open source stack and build speed / xcode stability for swift, but its not bad if your just 1-5 engineers in one app. But if you scale to 30+ with +1 million lines after a few years it starts getting real bad unless you architect your app with devapps like airbnb did: https://medium.com/airbnb-engineering/designing-for-producti...
Windows Desktop has much more documentation than both Android and iOS.
It does take a bit of practice to find things in MSDN, but if it exists^1, then I'll be very surprised if it's not documented. (Except Azure APIs, I don't know why Azure seemed to miss out)
1: By exists I mean a public API. Even some APIs that aren't intended to be used by applications have documentation. Eg: RtlGenRandom.
1: By exists I mean a public API. Even some APIs that aren't intended to be used by applications have documentation. Eg: RtlGenRandom.
I saw someone mentioning that in some places the MSDN documentation was light on detail because because in the early days (Win32/MFC/AFX) they were trying to sell training and certifications with the actual detail in it.
The original MSDN came on a bunch of CDs but it moved to online only a long time ago.
It has always been comprehensive.
The problem I have found lately is some of the more esoteric stuff seems to have disappeared. That and the urls changing and poor SEO.
It has always been comprehensive.
The problem I have found lately is some of the more esoteric stuff seems to have disappeared. That and the urls changing and poor SEO.
I'm from germany and it makes me so mad that they automatically redirect me to some shitty autotranslated german site. I have to manually change the "de-de" to "en-us" in the url all the time when browsing microsoft docs.
> but nobody does windows desktop anyway
That much is fairly true now though. It just doesn't make sense to build an enterprise app that is windows native and can't run on any other OS/be accessed via web.
That much is fairly true now though. It just doesn't make sense to build an enterprise app that is windows native and can't run on any other OS/be accessed via web.
android isn't more chaotic back then for me, probably because java docs are literally everywhere. Hard to find and navigate, but most of the time I know where to find things.
Swift is its own language and libraries, but I can't seem to find stuff in apple's website. I remember many times I am literally stuck, don't know where to read the definition or how to do stuff, then I end up having to ask people in reddit / SO. I actually still find people constantly complaining about the the docs in reddit every now and then.
Docs is really really important, having developed with laravel, moved to django, and react for FE, I just realise that their docs are really really good
Swift is its own language and libraries, but I can't seem to find stuff in apple's website. I remember many times I am literally stuck, don't know where to read the definition or how to do stuff, then I end up having to ask people in reddit / SO. I actually still find people constantly complaining about the the docs in reddit every now and then.
Docs is really really important, having developed with laravel, moved to django, and react for FE, I just realise that their docs are really really good
Android is even more so, because Android Java isn't Java, and there are lots of issues with stuff that just gets dumped into some github repo from Google where we are supposed to learn from sample code and that is it.
There's a free book "The Swift Programming Language" that should answer most questions about the Swift language and its standard library. The web version is here: https://docs.swift.org/swift-book/index.html
Hacking with swift is my go-to for tutorials / quick how-tos. Much simpler to follow than the docs or Ray https://www.hackingwithswift.com/
SwiftUI's docs have been notoriously bad. I have heard that they are improving, but I haven't done anything "ship" in SwiftUI yet, so I don't have much to go on.
I know that the docs were so bad, that one chap wrote this site and app: https://swiftui-lab.com
They are really nice.
I know that the docs were so bad, that one chap wrote this site and app: https://swiftui-lab.com
They are really nice.
Xamarin is not a Microsoft own tech per se, well actually it is since they bought it, however their crossplatform teams have always been about C++ and JavaScript (C++ rulez at WinDev, no matter what).
Actually I think it was more of a strategic move to "own" mono runtime and provide a starting point for Visual Studio for Mac (which is anyway being rebuilt).
The fact that Xamarin is now trying to be Swing for .NET 7, and still failing on Linux (if the community wants they should build it), and on macOS (using Catalyst instead of proper Cocoa APIs), doesn't seem it is getting that much love overall.
Specially now apparently we should all be using Blazor either directly on the browser, via Electron or WebWidgers as per their own marketing.
In the end it boils down that there are many UI teams, each of them trying to make a point of still being relevant to managment while fighting for resources.
Actually I think it was more of a strategic move to "own" mono runtime and provide a starting point for Visual Studio for Mac (which is anyway being rebuilt).
The fact that Xamarin is now trying to be Swing for .NET 7, and still failing on Linux (if the community wants they should build it), and on macOS (using Catalyst instead of proper Cocoa APIs), doesn't seem it is getting that much love overall.
Specially now apparently we should all be using Blazor either directly on the browser, via Electron or WebWidgers as per their own marketing.
In the end it boils down that there are many UI teams, each of them trying to make a point of still being relevant to managment while fighting for resources.
Swift.org is decent, framework docs are still very bad. Bridging RN - Apple is a hell of a market at the moment though, getting the transition on your resume is worth a look.
it has become significantly better, especially that of SwiftUI. When I followed the doc this summer, I actually got up to speed very quickly on swiftUI. I will say Rayenderlich has a habit of either over-engineering things, or engineering things in a way that's not needed in my use case. So I find his tutorials to be a reference at best.
>Out of all the binaries in iOS 15:
89% are using Objective-C
17% are using C++
13% are using Swift
8% are entirely written in C
2% are using SwiftUI
Objective C looks healthy.
89% are using Objective-C
17% are using C++
13% are using Swift
8% are entirely written in C
2% are using SwiftUI
Objective C looks healthy.
They have like, at a minimum, 10+ years of a whole OS built on objc. Of course it's going to be a high percentage.
I would be weary of any team who decided to rewrite an OS in an emerging language.
I would be weary of any team who decided to rewrite an OS in an emerging language.
More like 20+ given the NeXT heritage.
[deleted]
Wouldn't most binaries not have UI anyways? Probably better to compare Swift UI to previous UI frameworks.
Swift was conceived and sold as an all purpose language.
To an extreme degree, in fact. Lattner has said many times that it's intended from scripting to system programing[1]. Currently it's good at neither.
I think a language that's simultaneously productive at this two extremes is impossible, but it was their goal.
[1] https://developers.slashdot.org/story/17/01/23/085232/slashd...
“In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead.”
Jan 2017
I think a language that's simultaneously productive at this two extremes is impossible, but it was their goal.
[1] https://developers.slashdot.org/story/17/01/23/085232/slashd...
“In short, I would NOT say that Swift is an extremely compelling systems programming or scripting language today, but it does aspire to be great for this in the years ahead.”
Jan 2017
I’ve had very few complaints with Swift as a backend language in all honesty.
I can see it as a backend/systems language. It is not a scripting language.
The issue is the stewardship of the ecosystem.
The fact the Foundation library is closed source is a complete joke in this day and age.
Apple’s lack of effort towards fostering a broader community for its language is a comedy of errors.
A Swift developer will spend much time dealing with undocumented closed source packages.
It’s almost comedic how retro it is. It’s like coding in the 1980s.
I can see it as a backend/systems language. It is not a scripting language.
The issue is the stewardship of the ecosystem.
The fact the Foundation library is closed source is a complete joke in this day and age.
Apple’s lack of effort towards fostering a broader community for its language is a comedy of errors.
A Swift developer will spend much time dealing with undocumented closed source packages.
It’s almost comedic how retro it is. It’s like coding in the 1980s.
The Foundation library on non-Apple platforms is open source: https://github.com/apple/swift-corelibs-foundation and intended to reach parity with the Apple version.
> Our primary goal is to achieve implementation parity with Foundation on Apple platforms. This will help to enable the overall Swift goal of portability.
> Our primary goal is to achieve implementation parity with Foundation on Apple platforms. This will help to enable the overall Swift goal of portability.
But why are these even two separate libraries? Is it normal for different platforms to have different implementations of the standard library? I'd assumed that most of the library would have been written in Swift itself, which should theoretically make it be as platform-independent as Swift is.
Foundation is not the standard library of Swift. Swift has its own standard library that is bundled with the language on all platforms that are supported.
And Foundation itself isn't written in Swift, a good portion is written in C.
> A significant portion of the implementation of Foundation on Apple platforms is provided by another framework called CoreFoundation (a.k.a. CF). CF is written primarily in C and is very portable. Therefore we have chosen to use it for the internal implementation of Swift Foundation where possible. As CF is present on all platforms, we can use it to provide a common implementation everywhere.
https://github.com/apple/swift-corelibs-foundation/blob/main...
And Foundation itself isn't written in Swift, a good portion is written in C.
> A significant portion of the implementation of Foundation on Apple platforms is provided by another framework called CoreFoundation (a.k.a. CF). CF is written primarily in C and is very portable. Therefore we have chosen to use it for the internal implementation of Swift Foundation where possible. As CF is present on all platforms, we can use it to provide a common implementation everywhere.
https://github.com/apple/swift-corelibs-foundation/blob/main...
This is assumption from first principles
The Apple versions of foundation have to be compatible with the Foundation/CoreFoundation equivalents. They also have more than a decade of binary compat to maintain
The Apple versions of foundation have to be compatible with the Foundation/CoreFoundation equivalents. They also have more than a decade of binary compat to maintain
If it were extremely well documented with a lot of nice examples the open/closed nature of the libs would be a secondary question.
> The fact the Foundation library is closed source is a complete joke in this day and age.
Foundation is open source https://github.com/apple/swift-corelibs-foundation
Foundation is open source https://github.com/apple/swift-corelibs-foundation
Sometimes I think an Objective-C 3.0, that would break with some of more problematic C flaws would have been better, even though I dislike @ and [] everywhere.
The question is, where does ObjC end and where does Swift start? When Apple announced an Objective-C without the C, I assumed they'd keep the Smalltalk object system and message passing. It still boggles my mind that they took a hard turn into the world of value semantics and extremely static types, with all the ABI problems that we know from C++, plus all the interop hacks to bridge both worlds. The syntax almost seems like a superficial detail compared to the new object model.
On the other hand, the Smalltalk model would not have worked for SwiftUI. It really feels like Apple has bet the farm on the next generation of libraries/frameworks.
On the other hand, the Smalltalk model would not have worked for SwiftUI. It really feels like Apple has bet the farm on the next generation of libraries/frameworks.
Not sure if they bet the farm as such, there are plenty of rants regarding how unsuitable SwiftUI is outside iOS for macOS workflows.
It’s not impossible — Lisp exists and has been used in both contexts for decades.
Swift needs some work to get there. There are a huge number of gaping holes, but these would be a start:
- scripting: a native RegEx literal type
- systems: replace Codable with something easier to use/more performant
- systems: better logging interface
Edit: formatting
Swift needs some work to get there. There are a huge number of gaping holes, but these would be a start:
- scripting: a native RegEx literal type
- systems: replace Codable with something easier to use/more performant
- systems: better logging interface
Edit: formatting
How successful are Lisp OSs?
Came here to post the same. We tend to spin around the shinny and new. These numbers, even if a but inaccurate, are sobering and show who's really running the show.
Every year the supporter of Swift will claim new project are all going to be Swift right down to system level. And every year they have been wrong. It doesn't seems Swift is replacing Object-C in system level usage anytime soon. And only even partly in applications. May be Swift 6, when they finally introduce ownership. But that is looking more like 2023 at the earliest.
It will be worth looking at the stats again in 2024, 10 years after Swift was introduced.
It will be worth looking at the stats again in 2024, 10 years after Swift was introduced.
If even Apple is writing more new software in Obj-C than they are in swift, its probably still a fantastic time to learn obj-c and use it to develop applications.
Or at the very least, use Swift + UIKit rather than SwiftUI.
Or at the very least, use Swift + UIKit rather than SwiftUI.
I think this the wrong take from the data.
Apple is writing 'more Obj-C' because it's their incumbent language, and they are 'writing a lot more software'. As the basis expands, it's going to expand along the normative vector, which is ObjC.
But for outside devs, Apple has almost frozen ObjC in favour of Swift, and Swift is 100% the future for apps built for iOS/MacOS.
Even externally, ObjC will probably be supported for a 'very long time' and maybe even perpetually at this point, it's really not the future.
Internally, the sands have not shifted, but I suggest that within about 5-7 years Swift will be on even footing with ObjC even within Apple.
So if you're an Apple focused Dev. not working for Apple ... then Swift is probably your #1 focus with a 'Healthy Knowledge' of ObjC - at least enough to access arcane and un-ported APIs as a nice thing to round out your skills.
ObjC is losing popularity, it will be a 'well supported' niche language going forward. You can probably bank on your ObjC skills for a long time to come, but in a more narrow range of opportunities.
Apple is writing 'more Obj-C' because it's their incumbent language, and they are 'writing a lot more software'. As the basis expands, it's going to expand along the normative vector, which is ObjC.
But for outside devs, Apple has almost frozen ObjC in favour of Swift, and Swift is 100% the future for apps built for iOS/MacOS.
Even externally, ObjC will probably be supported for a 'very long time' and maybe even perpetually at this point, it's really not the future.
Internally, the sands have not shifted, but I suggest that within about 5-7 years Swift will be on even footing with ObjC even within Apple.
So if you're an Apple focused Dev. not working for Apple ... then Swift is probably your #1 focus with a 'Healthy Knowledge' of ObjC - at least enough to access arcane and un-ported APIs as a nice thing to round out your skills.
ObjC is losing popularity, it will be a 'well supported' niche language going forward. You can probably bank on your ObjC skills for a long time to come, but in a more narrow range of opportunities.
> But for outside devs, Apple has almost frozen ObjC in favour of Swift
In my experience, Apple doesn't even have to freeze anything because the iOS developer community (outside of Apple) is full of proud Early Adopters. Sometimes it feels like a race to use the latest tools on day one. I haven't seen anyone looking for ObjC developers from the day Swift was announced.
In my experience, Apple doesn't even have to freeze anything because the iOS developer community (outside of Apple) is full of proud Early Adopters. Sometimes it feels like a race to use the latest tools on day one. I haven't seen anyone looking for ObjC developers from the day Swift was announced.
[deleted]
It's not 'who's running the show' it's just 'incumbency of legacy'.
Modules that are complicated and not broken, are extremely expensive to fix esp. when they need to develop new stuff.
Legacy and backwards compatibility have a way of keeping things around.
Modules that are complicated and not broken, are extremely expensive to fix esp. when they need to develop new stuff.
Legacy and backwards compatibility have a way of keeping things around.
Have you seen the graphs? From what I’ve gathered, the amount of ObjC has been steadily increasing.
It’s not in maintenance legacy mode. It’s thriving.
It’s not in maintenance legacy mode. It’s thriving.
Nobody is going to do a 'new start' in Obj-C outside of Apple so it's now a language used for 'One Companies Internal Purposes', moreover, swift in just the last 2 releases has gained significantly - they're just starting to use it.
My bet is that even then, most ObjC use is due to legacy - most of those binaries are probably related to apps that are already in ObjC.
I looks like they plan to keep it around for the foreseeable future, but I wonder if it will mostly be eventually replaced by Swift for new starts.
My bet is that even then, most ObjC use is due to legacy - most of those binaries are probably related to apps that are already in ObjC.
I looks like they plan to keep it around for the foreseeable future, but I wonder if it will mostly be eventually replaced by Swift for new starts.
ObjectiveC is slowly dying [1] I think it will flatten out and not go away for a long time but it's going to eventually become and adjunct to Swift 'outside' of Apple.
Within 5-7 years Swift will rival ObjC within Apple, and from then on it's hard to tell.
There are no foreseeable plans to rewrite the OS, and so ObjC has to stay around, but that's in a clearly limited capacity.
[1] https://www.benfrederickson.com/ranking-programming-language...
Within 5-7 years Swift will rival ObjC within Apple, and from then on it's hard to tell.
There are no foreseeable plans to rewrite the OS, and so ObjC has to stay around, but that's in a clearly limited capacity.
[1] https://www.benfrederickson.com/ranking-programming-language...
They better rewrite Metal by then than.
Yes, ObjC will have to stick around for as long as those things.
But Metal will eventually be re-written. Not for a while, but eventually.
But Metal will eventually be re-written. Not for a while, but eventually.
I don't think so, it is like the .NET uptake at Microsoft, after 20 years, no matter what, the WinDev is C++ deep down to their bones, nowadays even more since COM has won the Longhorn wars.
Objective-C will be just the same at Apple, specially since their creators decided to go search for other adventures outside Apple.
Objective-C will be just the same at Apple, specially since their creators decided to go search for other adventures outside Apple.
Facebook is writing all their iOS apps in Obj-C(++).
Facebook can afford it.
Very few companies can.
Very few companies can.
[deleted]
Whats really surprising is if you look at the results, the only pure swift binary (that isn't under libswift*) is a protocol buffers library, rather then adapting the existing c++ one maintained by google.
/System/Library/PrivateFrameworks/CloudKitCodeProtobuf.framework/CloudKitCodeProtobuf |Swift
While ObjC is far from dead, I’m not sure these metrics paint an accurate picture.
For a Swift-first app or binary, there are a few reasons that you might see ObjC as part of the binary:
- easier interop with ObjC
- Xcode code generation (CoreData, Intents, etc)
- legacy code (no real benefit to rewriting if it works fine with Swift)
I’d expect most Swift-first binaries to have even a small amount of ObjC for one of the reasons above. I’d also expect that binaries already containing ObjC would rarely drop it, even if new development is done in Swift.
For a Swift-first app or binary, there are a few reasons that you might see ObjC as part of the binary:
- easier interop with ObjC
- Xcode code generation (CoreData, Intents, etc)
- legacy code (no real benefit to rewriting if it works fine with Swift)
I’d expect most Swift-first binaries to have even a small amount of ObjC for one of the reasons above. I’d also expect that binaries already containing ObjC would rarely drop it, even if new development is done in Swift.
Metal is a mix of Objective-C and C++, while most examples use Swift, they are actually bindings to the implementation.
there are definitely a few problems crippling swift adoption in the mobile app dev community (which seems like the easier market for growth) but to me the most important one is this:
it's still a apple frontend PL only. There are absolutely no story for cross-platform development, not even business logic (foundation on android is non-existent).
After 18 months developping a first version of an app using swift ( for optimal performance and OS integration) i am now investigating more seriously the different options for reusing the maximum amount of code, and so far the result is : 0.
0 code reuse in today's world is absolutely unbearable. I'm at the point where i'm seriously thinking about tools for automatically converting the code to kotlin.
it's still a apple frontend PL only. There are absolutely no story for cross-platform development, not even business logic (foundation on android is non-existent).
After 18 months developping a first version of an app using swift ( for optimal performance and OS integration) i am now investigating more seriously the different options for reusing the maximum amount of code, and so far the result is : 0.
0 code reuse in today's world is absolutely unbearable. I'm at the point where i'm seriously thinking about tools for automatically converting the code to kotlin.
I really don't see this as an issue to be honest. Swift is the first class native development language for the Apple ecosystem, (eventually) superseding Objective-C. That's it's one job. Anything beyond that is a bonus. I don't expect Google to port the Android runtime, SDK and tooling to iOS either.
That's probably the view of Apple execs, but it is not the rhetoric that comes out of the Swift Org itself:
https://www.swift.org/ > a programming language to empower everyone to turn their ideas into apps on any platform.
https://www.swift.org/about/ > the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services
> a web-based REPL can when working with Linux server-side code
> it is now free to be ported across a wide range of platforms, devices, and use cases. Our goal is to provide source compatibility for Swift across all platforms ... extend the cross-platform capabilities of Swift ... source compatibility for Swift code across all platforms ...
> Open-source Swift can be used on Linux to build Swift libraries and applications
> We’d love your help to bring Swift to even more computing platforms.
https://www.swift.org/ > a programming language to empower everyone to turn their ideas into apps on any platform.
https://www.swift.org/about/ > the best available language for uses ranging from systems programming, to mobile and desktop apps, scaling up to cloud services
> a web-based REPL can when working with Linux server-side code
> it is now free to be ported across a wide range of platforms, devices, and use cases. Our goal is to provide source compatibility for Swift across all platforms ... extend the cross-platform capabilities of Swift ... source compatibility for Swift code across all platforms ...
> Open-source Swift can be used on Linux to build Swift libraries and applications
> We’d love your help to bring Swift to even more computing platforms.
Except google chose kotlin which is developped by another company, which itself has interest to widen the language support to the maximum. As a consequence we have kotlin native and kotlin multiplatform.
Apple used an 100% in-house solution but with the official long-term of having it run on the widest range of platform, and an open-source model. In reality, the language is driven toward things nobody gives a damn (swiftUI would have been almost just as good without the syntax sugar), whereas the official initial goals don't have any steam from Apple.
Apple used an 100% in-house solution but with the official long-term of having it run on the widest range of platform, and an open-source model. In reality, the language is driven toward things nobody gives a damn (swiftUI would have been almost just as good without the syntax sugar), whereas the official initial goals don't have any steam from Apple.
> Apple’s use of Swift is progressing faster than ever. Last year Swift surpassed C. This year Swift is getting closer to C++.
Which is yet another reason why clang is now lagging behind the other compilers, for Apple C++17 is good enough[0], and all other contributors don't seem to be in a hurry to contribute C++20 features to upstream.
[0] - IO and driver Kit use the embedded C++ subset, whereas MSL is a C++14 dialect.
Which is yet another reason why clang is now lagging behind the other compilers, for Apple C++17 is good enough[0], and all other contributors don't seem to be in a hurry to contribute C++20 features to upstream.
[0] - IO and driver Kit use the embedded C++ subset, whereas MSL is a C++14 dialect.
Are Swift and SwiftUI different languages? I naively assumed SwiftUI was just a library to create and render UI components, but I’m not familiar with iOS/macOS development. Just surprised to see a distinction between the two in the article.
You’re correct in that SwiftUI is just another library built on top of Swift. SwiftUI heavily takes advantage of a relatively new Swift feature: result builders. So while SwiftUI code is technically Swift code, at times it does feel like a different language as control flow operates differently.
All the @State, @Published etc. pragmas look to me like they hacked the compiler to do the stuff they couldn't do in a regular library....
Those are just property wrappers; another feature of the language accessible to everyone.
Incorrect. The SwiftUI property wrappers, most notably @State, use internal knowledge and non-public reflection. They are not stably implementable by outsiders.
swiftui is the latest UI framework for building user interface. it's not a language.
However it uses a lot of swift constructs that makes it feel like a Domain Specific Language to describe UIs (like html).
is anybody doing anything with swift outside of iphone or mac app development? I recall there was some effort to make it something more than that but I think that's been mostly abandoned at this point since there are so many much better languages already
I am! I'm building a complete backend in Swift for an app i'm working on. It's actually been really great so far. I develop on my mac in xcode and deploy on linux via docker. See: https://vapor.codes/
I'm a little bias because I really like Swift as a language but Vapor is growing and there are lots of plugins to fill the gaps.
I'm a little bias because I really like Swift as a language but Vapor is growing and there are lots of plugins to fill the gaps.
I love Swift too, but dislike Xcode enough to where I wouldn't use it unless I was doing iOS. Even in a medium sized project basic functionality like syntax highlighting or clicking into functions is unreliable. You get used to it being an iOS dev, but switching into something like Intellij is a sobering wake up call where that stuff just works.
Indeed you are right. XCode absolute induces some stockholm syndrome as an iOS dev. Maybe anecdotal, but I do find swiftPM based projects to have far fewer issues than cocoapod + Cocoa based apps.
I'd love to see sourcekit-lsp (the swift lsp) to further develop. Though last time I checked it wasn't exactly usable day to day.
I'd love to see sourcekit-lsp (the swift lsp) to further develop. Though last time I checked it wasn't exactly usable day to day.
You can use emacs + lsp along with the Xcode lsp server. works great and is way more stable the XCode. I just use XCode for storyboard editing.
(add-to-list 'exec-path "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin")
(use-package lsp-sourcekit :ensure t :after lsp-mode :config (setq lsp-sourcekit-executable "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/sourcekit-lsp"))
(use-package swift-mode :hook (swift-mode . (lambda () (lsp))))
(add-to-list 'exec-path "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin")
(use-package lsp-sourcekit :ensure t :after lsp-mode :config (setq lsp-sourcekit-executable "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/sourcekit-lsp"))
(use-package swift-mode :hook (swift-mode . (lambda () (lsp))))
Try AppCode from intelli-j, it's also cross platform
I wrote about my unconventional use of Swift on Linux (i.e. not a web app) a few months ago: https://liuliu.me/eyes/data-science-setup-with-swift-in-2021...
There was a large effort to bring it into machine learning in place of python, but the team that was over that was restructured and it looks dead.
IBM tried to make it work for web and server. Google tried to use it for ML. Both were abandoned.
"There are dozens of us" but seriously, there is some interest from users but most projects done by companies have been abandoned, SwiftUI feels almost like a language divergence, which is frustrating. I'll list what I know about but it's by no means comprehensive.
The good news is that server side on Linux is still working well, Vapor 4 is solid, growing and looks like it has a bright future and Perfect is still going too, though Perfect seems disjointed from the main community. IBM's Kitura and involvement with Swift is over though. Server side seems like it's best future right now, since it's more performant than Javascript and uses less cycles, which can have a lot of cost benefits.
Static site generation looks good too, Publish by John Sundell being the most famous (https://github.com/JohnSundell/Publish) but a lot of others have started springing up lately.
"Swift for Tensorflow" by Google has been shut down. Though that was mostly Google giving advice on how to evolve Swift to work better for ML. It's a shame too, since it felt like Fast.Ai was adopting it and starting to teach it at one point, so the shutdown felt a bit premature, but this is Google after all, shutting things down is what they do.
Swift 5.0+ seems to have stabilized the language quite a bit too(ABI Stability and other things), which is a good thing, as hopefully the tutorials/docs from now on should remain more consistent. The built in package manager "Swift Package Manager" seems to be working better too, though there are still a lot of complaints/missing features, but on the whole I like it.
Swift on Linux seems to be officially supported by more flavors of Linux than it used to be. Meanwhile Swift on Windows works right now but I wouldn't use it in production yet, it throws errors that are the sort that if you ask anyone they will answer "that's normal, ignore that". Some have even gotten modern Swift to run on older MacOS's leveraging LLVM.
Swift WASM seems to have had a big update with Swift 5.4 https://forums.swift.org/t/swiftwasm-5-4-0-has-been-released... though I've not yet tried it having given up on Swift WASM about a year ago.
Youtuber Stega's Gate(https://www.youtube.com/channel/UCBXFkK2B4w9856wBJfCGufg) is building a cross platform game engine in swift.
IntelliJ has a decent alternative to Xcode now too, using Clion with an app made by them(though it's still not as integrated as Xcode, nothing would be).
Getting it to run on android is technically possible, but the workaround it too much, but that's mostly on Google actually, since the support for writing things in C for Android is so depreciated it's a joke.
The Docs are still terrible though, have been to my knowledge since 3.0 became outdated. That said the official books are alright and there are tutorial communities that are pretty good too, but it's shameful that the docs should be that useless.
So yeah, Swift is nearly viable for non Mac things, but there aren't much for libraries outside of backend. Some are tinkering and making cool stuff, but at times it's difficult when even the non app related programming tutorials for those are like "let's do it on MacOS using Xcode".All of that said, it's my favorite language, I want it to have a community similar to Rust's but I don't think Apple supports it the right way for that happen, they seem ok with it staying inside their ecosystem, like they are ok if the community does stuff outside of it, but they aren't helping it or encouraging it, is the general feeling. Ironically I was recommended to Swift initially because of the community that it had at the time, the caveat being "if you want to make apps for Apple's ecosystem", which isn't terrible, but it's not what I want. I'll probably give up on it if it doesn't change in the next year or so and go all in on Rust is likely what will happen, but again it's a shame.
The good news is that server side on Linux is still working well, Vapor 4 is solid, growing and looks like it has a bright future and Perfect is still going too, though Perfect seems disjointed from the main community. IBM's Kitura and involvement with Swift is over though. Server side seems like it's best future right now, since it's more performant than Javascript and uses less cycles, which can have a lot of cost benefits.
Static site generation looks good too, Publish by John Sundell being the most famous (https://github.com/JohnSundell/Publish) but a lot of others have started springing up lately.
"Swift for Tensorflow" by Google has been shut down. Though that was mostly Google giving advice on how to evolve Swift to work better for ML. It's a shame too, since it felt like Fast.Ai was adopting it and starting to teach it at one point, so the shutdown felt a bit premature, but this is Google after all, shutting things down is what they do.
Swift 5.0+ seems to have stabilized the language quite a bit too(ABI Stability and other things), which is a good thing, as hopefully the tutorials/docs from now on should remain more consistent. The built in package manager "Swift Package Manager" seems to be working better too, though there are still a lot of complaints/missing features, but on the whole I like it.
Swift on Linux seems to be officially supported by more flavors of Linux than it used to be. Meanwhile Swift on Windows works right now but I wouldn't use it in production yet, it throws errors that are the sort that if you ask anyone they will answer "that's normal, ignore that". Some have even gotten modern Swift to run on older MacOS's leveraging LLVM.
Swift WASM seems to have had a big update with Swift 5.4 https://forums.swift.org/t/swiftwasm-5-4-0-has-been-released... though I've not yet tried it having given up on Swift WASM about a year ago.
Youtuber Stega's Gate(https://www.youtube.com/channel/UCBXFkK2B4w9856wBJfCGufg) is building a cross platform game engine in swift.
IntelliJ has a decent alternative to Xcode now too, using Clion with an app made by them(though it's still not as integrated as Xcode, nothing would be).
Getting it to run on android is technically possible, but the workaround it too much, but that's mostly on Google actually, since the support for writing things in C for Android is so depreciated it's a joke.
The Docs are still terrible though, have been to my knowledge since 3.0 became outdated. That said the official books are alright and there are tutorial communities that are pretty good too, but it's shameful that the docs should be that useless.
So yeah, Swift is nearly viable for non Mac things, but there aren't much for libraries outside of backend. Some are tinkering and making cool stuff, but at times it's difficult when even the non app related programming tutorials for those are like "let's do it on MacOS using Xcode".All of that said, it's my favorite language, I want it to have a community similar to Rust's but I don't think Apple supports it the right way for that happen, they seem ok with it staying inside their ecosystem, like they are ok if the community does stuff outside of it, but they aren't helping it or encouraging it, is the general feeling. Ironically I was recommended to Swift initially because of the community that it had at the time, the caveat being "if you want to make apps for Apple's ecosystem", which isn't terrible, but it's not what I want. I'll probably give up on it if it doesn't change in the next year or so and go all in on Rust is likely what will happen, but again it's a shame.
I always wondered why the creator of Rust switched to Swift and just now found my answer by Graydon Hoare himself:
https://old.reddit.com/r/rust/comments/7qels2/i_wonder_why_g...
tl;dr it has nothing to do with the relative merits of the two languages
---
Edit: I watched a couple of Lex Fridman podcasts this week with Chris Lattner (creator of Swift) that I thought were interesting
Chris Lattner: Compilers, LLVM, Swift, TPU, and ML Accelerators | Lex Fridman Podcast #21
https://www.youtube.com/watch?v=yCd3CzGSte8
Chris Lattner: The Future of Computing and Programming Languages | Lex Fridman Podcast #131
https://www.youtube.com/watch?v=nWTvXbQHwWs
https://old.reddit.com/r/rust/comments/7qels2/i_wonder_why_g...
tl;dr it has nothing to do with the relative merits of the two languages
---
Edit: I watched a couple of Lex Fridman podcasts this week with Chris Lattner (creator of Swift) that I thought were interesting
Chris Lattner: Compilers, LLVM, Swift, TPU, and ML Accelerators | Lex Fridman Podcast #21
https://www.youtube.com/watch?v=yCd3CzGSte8
Chris Lattner: The Future of Computing and Programming Languages | Lex Fridman Podcast #131
https://www.youtube.com/watch?v=nWTvXbQHwWs
“I've always been a language pluralist -- picture my relationship towards languages like a kid enjoying a wide variety of building blocks, musical instruments or plastic dinosaurs -- and I don't think evangelism or single-language puritanism is especially helpful.”
What a great statement!
What a great statement!
> C++ and C still play an important role. These languages are typically used by binaries related to audio, video, telephony, web, and other low-level frameworks.
Even so, a C Audio API like AudioGraph was deprecated a few years back and its replacement, AVAudioEngine, is Objective-C/Swift.
The skills that you develop while working with one of these platforms, the familiarity you develop with the libraries, the conventions, the ecosystem, the tools, none of that effort is portable.
Even so, a C Audio API like AudioGraph was deprecated a few years back and its replacement, AVAudioEngine, is Objective-C/Swift.
The skills that you develop while working with one of these platforms, the familiarity you develop with the libraries, the conventions, the ecosystem, the tools, none of that effort is portable.
AVAudioEngine is laughably buggy and incomplete though.
Coming from a Ruby background, I got into Swift by first learning SwiftUI right around when COVID started. I know that sounds backwards but it actually made understanding Swift a lot easier. Overall, I was impressed (specifically with SwiftUI) as it was fairly easy to understand. Sometimes I wish I could do web layouts using SwiftUI. Clojures, Grand Central Dispatch, and Decodable in Swift took a bit longer to get used to.
I went down a similar path during covid from Ruby and decided to look at native development options for the first time and landed on Flutter instead.
I have to say reading through this thread I am so glad I didn’t go down the Swift route it sounds incredibly frustrating which is honestly the opposite of what my Flutter journey has been so far.
I have to say reading through this thread I am so glad I didn’t go down the Swift route it sounds incredibly frustrating which is honestly the opposite of what my Flutter journey has been so far.
Search around, there are projects on GitHub which are using result builders for the web. SwiftUI is a result builder too. Not a web developer, so can't tell if those projects are really useful.
This was a great write up.
My hunch is that older binaries will stay Objective-C forever, until the app is completely replaced. It will linger around, similar to C and C++. There is no major win to just write something in a different language, but using he same frameworks/ui system. Swift is used in brand new apps, and eventually will take over.
Swift UI is just too immature, and it is still doesn't provide some of the more advanced components. Great for a toy app, but not for a production level. I hope Apple keeps improving on it, and it doesn't return another niche like IB (Interface Builder), which is used only for small apps, and larger corps just don't use it.
----- Out of all the binaries in iOS 15:
89% are using Objective-C
17% are using C++
13% are using Swift
8% are entirely written in C
2% are using SwiftUI
If Swift was a better designed language, it would have taken over by now. The fact that after 7.5 years, Objective-C still persist, means Swift has soured many devs by its complexity, and sheer amount of shortcuts, (like Scala), and it is not necessary loved or is that much more productive, or gets people exited for. *but used a necessary tool as it is the way most community will move forward.
My hunch is that older binaries will stay Objective-C forever, until the app is completely replaced. It will linger around, similar to C and C++. There is no major win to just write something in a different language, but using he same frameworks/ui system. Swift is used in brand new apps, and eventually will take over.
Swift UI is just too immature, and it is still doesn't provide some of the more advanced components. Great for a toy app, but not for a production level. I hope Apple keeps improving on it, and it doesn't return another niche like IB (Interface Builder), which is used only for small apps, and larger corps just don't use it.
----- Out of all the binaries in iOS 15:
89% are using Objective-C
17% are using C++
13% are using Swift
8% are entirely written in C
2% are using SwiftUI
If Swift was a better designed language, it would have taken over by now. The fact that after 7.5 years, Objective-C still persist, means Swift has soured many devs by its complexity, and sheer amount of shortcuts, (like Scala), and it is not necessary loved or is that much more productive, or gets people exited for. *but used a necessary tool as it is the way most community will move forward.
> If Swift was a better designed language, it would have taken over by now.
So, a company that is selling over two hundred million devices per year that depend on a stable software stack, should have thrown away millions of lines of working code just to port it all over to a language that was still undergoing massive evolution over that 7.5 year period. Really? Sorry, but that would have been a disaster.
So, a company that is selling over two hundred million devices per year that depend on a stable software stack, should have thrown away millions of lines of working code just to port it all over to a language that was still undergoing massive evolution over that 7.5 year period. Really? Sorry, but that would have been a disaster.
Java 1.1 was released in 97, and by 2001 java was a defacto language for web services. (php and python where the other two). Then by 2002 starting taking over mobile (J2ME).
It even forced MSFT to create .NET.
That's the hallmarks of a good/revolutionary language for the time. It got adoption even in places that wasn't meant to.
Swift has failed in the web, and in AI/ML. That's the hallmarks of a mediocre language, that people have to use it because the platform. It doesn't stand on its own.
It even forced MSFT to create .NET.
That's the hallmarks of a good/revolutionary language for the time. It got adoption even in places that wasn't meant to.
Swift has failed in the web, and in AI/ML. That's the hallmarks of a mediocre language, that people have to use it because the platform. It doesn't stand on its own.
The MSFT story is a bit different, they already had Java with J++, with several extensions like the C# P/Invoke and events that you know and love.
Sun made a lawsuit against them and won, thus .NET was born and there was even J# as transition period to port J++ code into .NET.
In fact most Java devs could code in C# 1.0 almost without bothering to read any manual, just by changing the capitalization.
Ironically, Microsoft is now an OpenJDK contributor and owns a Java distribution (after buying jClarity), whereas Google is cheered for creating their Android Java coffee flavour.
Sun made a lawsuit against them and won, thus .NET was born and there was even J# as transition period to port J++ code into .NET.
In fact most Java devs could code in C# 1.0 almost without bothering to read any manual, just by changing the capitalization.
Ironically, Microsoft is now an OpenJDK contributor and owns a Java distribution (after buying jClarity), whereas Google is cheered for creating their Android Java coffee flavour.
> If Swift was a better designed language, it would have taken over by now.
7.5 years might seem like a long time but it isn't possible to rewrite a stack like Apples in under a decade or two. I also suspect that Swifts lack of interoperability with C++, which is required for audio, video, and math-heavy libraries such as Accelerate, means a layer of Objective-C is still needed to make use of those APIs.
7.5 years might seem like a long time but it isn't possible to rewrite a stack like Apples in under a decade or two. I also suspect that Swifts lack of interoperability with C++, which is required for audio, video, and math-heavy libraries such as Accelerate, means a layer of Objective-C is still needed to make use of those APIs.
The fact that Swift is not being used in anything than apple's econsystem, tells you that is a mediocre language.
Java, JDK 1.1. was released in 97. It was the first fully featured version of the language. Java was not initially meant for the web (but for midlets, and such), but by 2001 it took over all web services. Then mobile (with J2ME). It even forced MSFT to create its copycat, .NET.
Python has survived and thrived in many places that people 'don't have to use it by force'. That's the hallmarks of good languages and people like using.
Swift failed outside the iOS/MacOs ecosystem. it is a mediocre/overcomplicated language. It is like Scala, which introduced lots of concepts, but went overboard with them and made the language too complex to use.
Java, JDK 1.1. was released in 97. It was the first fully featured version of the language. Java was not initially meant for the web (but for midlets, and such), but by 2001 it took over all web services. Then mobile (with J2ME). It even forced MSFT to create its copycat, .NET.
Python has survived and thrived in many places that people 'don't have to use it by force'. That's the hallmarks of good languages and people like using.
Swift failed outside the iOS/MacOs ecosystem. it is a mediocre/overcomplicated language. It is like Scala, which introduced lots of concepts, but went overboard with them and made the language too complex to use.
> Java, JDK 1.1. was released in 97.
Things were very different 24 years ago, the language ecosystem was not as competitive as it is today. There are more people writing code today and a greater variety of use cases when it comes to web services. Python is even older than Java (1991). A language being developed today must pass a higher bar.
For example Rust has nowhere near the same level of adoption as Java did back then, but it is by no means a mediocre/overcomplicated language for systems programmers. Same with Go for web services and many others.
> It is like Scala, which introduced lots of concepts, but went overboard with them and made the language too complex to use.
What concepts are you referring to here? I'm not deeply familiar with Scala.
Things were very different 24 years ago, the language ecosystem was not as competitive as it is today. There are more people writing code today and a greater variety of use cases when it comes to web services. Python is even older than Java (1991). A language being developed today must pass a higher bar.
For example Rust has nowhere near the same level of adoption as Java did back then, but it is by no means a mediocre/overcomplicated language for systems programmers. Same with Go for web services and many others.
> It is like Scala, which introduced lots of concepts, but went overboard with them and made the language too complex to use.
What concepts are you referring to here? I'm not deeply familiar with Scala.
You could replace Swift with C# or .NET in your argument, but I'd guess you aren't about to say that C# is a mediocre language.
Sure, .NET and C# are technically cross-platform, but in reality they're almost exclusively used by Windows-based developers. Especially in the case of .NET Core, it was only released as a cross-platform framework because Linux servers have been replacing Windows Servers in data centers ever since the Web 2.0 era. Microsoft knows that Windows Server is not the future of the company, Azure is. That's why they happily make tools like VSCode, PowerShell, and .NET Core for Mac and Linux.
Swift is used in Apple's ecosystem because it was designed for Apple's ecosystem. That business decision has nothing to do with the merits or demerits of its language design.
Sure, .NET and C# are technically cross-platform, but in reality they're almost exclusively used by Windows-based developers. Especially in the case of .NET Core, it was only released as a cross-platform framework because Linux servers have been replacing Windows Servers in data centers ever since the Web 2.0 era. Microsoft knows that Windows Server is not the future of the company, Azure is. That's why they happily make tools like VSCode, PowerShell, and .NET Core for Mac and Linux.
Swift is used in Apple's ecosystem because it was designed for Apple's ecosystem. That business decision has nothing to do with the merits or demerits of its language design.
Even if you imagined a world where Swift existed and ObjC didn’t, it would still make sense for ObjC to be invented. In fact it would be an utterly inspired way to build a glue layer between Swift and the masses of C (and C-compatible) libraries out there.
With your logic most languages would have been dead by now. Python was created in 1991, Ruby in 1995, Erlang in 1986 and opened sourced in 1998. Just a few examples to consider. They took a lot more than 7 years until they peaked and gathered wide adoption.
Java 1.1. (JDK 1.1) (the first true full featured java) was released in 97. It was meant for applications such as midlets, but it was such a good language that took over in the web, and forced the hand of MSFT to create .Net.
By 2001, in just 5-6 years Java became the de-facto language of the Web Services (php, and python were relegated to smaller web pages).
What has Swift realized in 7 years? It failed in the web, and also in AI/ML framework. It is being used because you have to use it. While both Java and Python flourished everywhere because people wanted to use them as they were good languages.
By 2001, in just 5-6 years Java became the de-facto language of the Web Services (php, and python were relegated to smaller web pages).
What has Swift realized in 7 years? It failed in the web, and also in AI/ML framework. It is being used because you have to use it. While both Java and Python flourished everywhere because people wanted to use them as they were good languages.
In 2001 Java was far off from being "de-facto language of the Web Services". cgi was the dominant setup back then and php, and particularly perl was on the top list. Amazon ran on perl back then.
More importantly, your statements are clearly a selection bias to confirm your subjective conclusion. You're picking 1 language out of thousands to reassert your statements instead of taking a step back and rethink your conclusion.
More importantly, your statements are clearly a selection bias to confirm your subjective conclusion. You're picking 1 language out of thousands to reassert your statements instead of taking a step back and rethink your conclusion.
> If Swift was a better designed language, it would have taken over by now.
If you look closely at the most used languages in different domains right now it'll become clear that the design is not what led to their wider adoption.
If you look closely at the most used languages in different domains right now it'll become clear that the design is not what led to their wider adoption.
Swift / objc interop is very natural, so if it ain’t broke, why fix it wrt to swift rewrites.
I would love to see a (rough) breakdown in bytes of code, and then by new libraries vs old libraries (maybe split out by iOS version)
That would require distinguishing the code emitted by the swift compiler from that emitted by clang. I don’t know how hard that is. Are function prologues and epilogue different, for example? Can we semi-reliably infer that from function names? Do they prefer using different registers first?
That would require distinguishing the code emitted by the swift compiler from that emitted by clang. I don’t know how hard that is. Are function prologues and epilogue different, for example? Can we semi-reliably infer that from function names? Do they prefer using different registers first?
ObjC isn't going anywhere, anytime soon. The same for UIKit and IB.
Lots of people want them to go away, but we don't always get what we want.
Lots of people want them to go away, but we don't always get what we want.
Does this mean that Apple is using the same libraries they are asking third party developers to use? I used to do Windows development and it always bugged me that MS wasn’t using MFC and later on Winforms or WPF for their own apps. The libraries would be much better if they dogfooded their own stuff.
Visual Studio used MFC until it was rewriten in WPF.
SQL Server Studio used MFC until it was rewriten in WPF.
The Ribbon on WPF was originally designed on Office, then made availalble as a COM library on Windows 7 and wrapped as WPF bindings.
MFC was replaced by ATL, given how much Windows and Office teams love COM, and they keep loving it, via WRL and now C++/WinRT and WIL.
SQL Server Studio used MFC until it was rewriten in WPF.
The Ribbon on WPF was originally designed on Office, then made availalble as a COM library on Windows 7 and wrapped as WPF bindings.
MFC was replaced by ATL, given how much Windows and Office teams love COM, and they keep loving it, via WRL and now C++/WinRT and WIL.
> Does this mean that Apple is using the same libraries they are asking third party developers to use?
Yes and now. Apple still has and uses private APIs, which by license agreement 3rd party developers cannot and should not use.
Additionally SwiftUI is only ~3 years old, so it does not yet have 1:1 parity needed to fully migrate all of Apple's apps over.
That said, I to was disappointed that Microsoft had their own internal UI libraries for WindowsPhone7/8 which were not exposed to developers, such as the Map tile libraries.
Yes and now. Apple still has and uses private APIs, which by license agreement 3rd party developers cannot and should not use.
Additionally SwiftUI is only ~3 years old, so it does not yet have 1:1 parity needed to fully migrate all of Apple's apps over.
That said, I to was disappointed that Microsoft had their own internal UI libraries for WindowsPhone7/8 which were not exposed to developers, such as the Map tile libraries.
> an app I developed, Clatters, where I use Swift, SwiftUI, Objective-C and C, the most appropriate programming language being used to solve each specific problem.
Slightly OT, but when might one choose to write part of a new app in Objective-C instead of Swift? From my understanding, Swift can call any ObjC code.
Slightly OT, but when might one choose to write part of a new app in Objective-C instead of Swift? From my understanding, Swift can call any ObjC code.
The Swift naming convention makes it more difficult to learn, discover, and use large, complex APIs like AppKit and UIKit, so I'll often revert back to Objective-C when writing AppKit (and to a lesser extent, UIKit) when given the choice. It's common for me to still mix the two languages in a single app.
For example, this the AppKit API for pulling a URL off of the pasteboard:
The Swift version gets melted down to this:
The Swift version of AppKit is littered with this kind of obfuscation. Since I don't code in AppKit very regularly, I usually just throw my hands up and switch to Obj-C whenever I start running into these kinds of road blocks.
The Obj-C naming convention has advantages and disadvantages, but has always been considered verbose. The Swift designers considered this a problem in need of a solution. As is almost always the case in software development and language design, the solution was a giant overreaction and overcorrection that just replaced one problem with another.
For example, this the AppKit API for pulling a URL off of the pasteboard:
+[NSURL URLFromPasteboard:]
The Swift version gets melted down to this:
URL(from:)
The Swift version of AppKit is littered with this kind of obfuscation. Since I don't code in AppKit very regularly, I usually just throw my hands up and switch to Obj-C whenever I start running into these kinds of road blocks.
The Obj-C naming convention has advantages and disadvantages, but has always been considered verbose. The Swift designers considered this a problem in need of a solution. As is almost always the case in software development and language design, the solution was a giant overreaction and overcorrection that just replaced one problem with another.
Huh? That makes no sense.
The Swift API is
Compared to the obj-C version:
The Swift API is
init?(from pasteBoard: NSPasteboard)
Compared to the obj-C version:
+ (NSURL *)URLFromPasteboard:(NSPasteboard *)pasteBoard;
> Which should autocomplete/hint while writing code
It does not. Parameter types and alternate parameter names are ignored by Xcode autocomplete.
If you want to use init(from:), you have to already know that it exists and does something good. Typically, you only find a method like that by looking at the Obj-C header. And that method is declared in the NSPasteboard header, not NSURL.
It does not. Parameter types and alternate parameter names are ignored by Xcode autocomplete.
If you want to use init(from:), you have to already know that it exists and does something good. Typically, you only find a method like that by looking at the Obj-C header. And that method is declared in the NSPasteboard header, not NSURL.
So, the problem is not the naming, but autocomplete in Xcode?
Or is it impossible to write a good auto-completer for Swift because Swift is rather unique in splitting function names into multiple strings?
IIRC, Xcode uses LSP; is that a bottle-neck?
Or is it impossible to write a good auto-completer for Swift because Swift is rather unique in splitting function names into multiple strings?
IIRC, Xcode uses LSP; is that a bottle-neck?
I use Objective-C when using interfaces that require lots of C-style parameters. In particular Metal requires unsafe pointers to vertex and fragment data and I find the contortions you have to use to get Swift to send such data to Metal to be too much work. It’s just more straightforward in Objective-C. It can be done in Swift, but it ain’t pretty. (Or at least, it wasn’t the last time I tried, which admittedly was about a year ago. Maybe it’s better now?)
I prefer to use Objective-C when using a C API that involves heavy use of pointers (buffer pointers, pointers to structs, requires mallocing things, etc.). It’s not that Swift can’t be used, it’s just that doing all of that is painful in Swift, and completely straightforward in ObjC.
I also occasionally need to use C++, which ObjC makes easy in the form of Objective-C++. Swift doesn’t (yet?) have any ability to interface with C++.
I also occasionally need to use C++, which ObjC makes easy in the form of Objective-C++. Swift doesn’t (yet?) have any ability to interface with C++.
At my employer we use Objective-C++ to interface with some shared C++ code. Swift can use C directly but it can be useful to wrap a C library in an Obj-C interface to be easier to use in Swift.
I'd love to see the language breakdown for new development. The binary analysis pulls in a lot of legacy code, so it doesn't really reflect emerging code composition.
Swift and SwiftUI are very nice
I don't get to use macOS anymore, but i'm envious of them whenever i need to write some UIs
native, fast, memory efficient, memory safe and easy to build nice things
I don't get to use macOS anymore, but i'm envious of them whenever i need to write some UIs
native, fast, memory efficient, memory safe and easy to build nice things
The distinction this article wants to make does not exist. Even if your app chrome is written in Swift, what good is that if any image you show can end up in someones C PDF parser that Apple includes wholesale.
Think of it as "Swift + Objective-C + C++ + C" versus "Objective-C + C++ + C".
Think of it as "Swift + Objective-C + C++ + C" versus "Objective-C + C++ + C".
I’m sure Swift is great but I wouldn’t want to devote a significant amount of time learning a language that is effectively only for a single platform.
Wait... Apple is still adding new stuff in Objective C?
And after about 7 years only 13% of the iOS binaries are in Swift?
Quite ironic considering Apple is constantly deprecating stuff and pushing everyone to the latest thing.
And after about 7 years only 13% of the iOS binaries are in Swift?
Quite ironic considering Apple is constantly deprecating stuff and pushing everyone to the latest thing.
Xcode, of course is a big wildcard. Often times I find myself spending more time just fighting with the IDE than getting any real work done. Maybe I’m just used to Visual Studio, but Xcode has some really baffling design decisions or omissions that never fail to confound me.
SwiftUI is really cool and it’s really simple to string together some pretty UX. I really like its approach to data binding and sharing. It makes it really easy to share models across many different views with minimal fuss. That being said, it still feels immature with its out of the box controls. Just the other day I found myself wanting a simple wrapping horizontal stack control only to find nothing like this was provided out of the box. Layout can also be really frustrating - getting things where I want them is often very fiddly.
Swift itself is also quite nice - although it’s evolving really, really fast and tutorials/howtos and such go stale really quickly. Swift can and will drop language feature at the drop of a hat. Just today I wanted to do a simple C++ style for loop only to find this was removed completely from the language.
I’m also perpetually frustrated by the terseness or incompleteness of Apple’s docs. I would prefer to read docs rather than watch hours of WWDC presentations just to understand how something works but that seems to be the best way to get this information.