Swift Playgrounds 4(apple.com)
apple.com
Swift Playgrounds 4
https://www.apple.com/swift/playgrounds/
99 comments
"A Young Lady's Illustrated Primer", anybody?
https://en.wikipedia.org/wiki/The_Diamond_Age
https://en.wikipedia.org/wiki/The_Diamond_Age
This sounds interesting! I didn't know browsers could execute Swift. Do you have any links to share of examples? (I don't see any examples in the documentation)
It's not executed in-browser, it runs in the Swift Playgrounds app. Think of it like an RSS feed that you can add to the app, and it'll show you new chapters of the book once they're published.
If you're interested in it you can compile swift to wasm (webassembly) which can run in the browser natively
https://swiftwasm.org/
This won't be it executing editable Swift like on the website and it'll require some binding to send and receive data to the website but it will indeed be swift being executed on the website
https://swiftwasm.org/
This won't be it executing editable Swift like on the website and it'll require some binding to send and receive data to the website but it will indeed be swift being executed on the website
Browsers can't execute Swift code. The books are loaded directly into the Swift Playgrounds app.
As for links, there are very few subscriptions published – and probably none yet that work with Swift Playgrounds 4.0.
As for links, there are very few subscriptions published – and probably none yet that work with Swift Playgrounds 4.0.
This is so fun! And you’re right, I had no idea even though I tinker around in playgrounds a bit. Thanks for sharing!
The biggest new features with version 4 are (according to Apple):
- Build iPhone and iPad apps with SwiftUI right on your iPad (requires iPadOS 15.2 or later)
- App Store Connect integration lets you upload your finished app to the App Store
- App Preview shows live updates as you make changes to your app
- Full-screen preview lets you see your app edge-to-edge
- Smart, inline code suggestions help you write code quickly and accurately
- App Projects make it easy to move projects to Xcode and back
- Project-wide search finds results across multiple files
- Snippets Library provides hundreds of SwiftUI controls, symbols, and colors
- Swift Package support lets you include publicly-available code to enhance your apps
- Build iPhone and iPad apps with SwiftUI right on your iPad (requires iPadOS 15.2 or later)
- App Store Connect integration lets you upload your finished app to the App Store
- App Preview shows live updates as you make changes to your app
- Full-screen preview lets you see your app edge-to-edge
- Smart, inline code suggestions help you write code quickly and accurately
- App Projects make it easy to move projects to Xcode and back
- Project-wide search finds results across multiple files
- Snippets Library provides hundreds of SwiftUI controls, symbols, and colors
- Swift Package support lets you include publicly-available code to enhance your apps
> Build iPhone and iPad apps with SwiftUI right on your iPad (requires iPadOS 15.2 or later)
Maybe it's no Xcode, but you can actually build "real" apps!
I still wish we had a full version of Logic for the iPad (though there are lots of iPad DAWs and some of them are pretty good.)
Maybe it's no Xcode, but you can actually build "real" apps!
I still wish we had a full version of Logic for the iPad (though there are lots of iPad DAWs and some of them are pretty good.)
I was hoping to see support for adding shader files. There are some workarounds I’ve seen for being able to test shader code in playgrounds, but it would be nice to have native support that doesn’t require a workaround and allows for syntax highlighting.
So Roblox… but Swift…
This is really cool.
This is really cool.
Unfortunately Google shelved it but they had a very similar project called Game Builder for Windows
Here is the original introduction video https://www.youtube.com/watch?v=l9Mf_XEZq-A
And a tutorial https://www.youtube.com/watch?v=L1hpFRztQGY
Got open sourced so you can still download it https://github.com/googlearchive/gamebuilder
Works perfectly under Linux with Wine or Proton.
The last full Steam release is also included if you don't want to compile it (7z.001-7z.002-7z.003) https://github.com/googlearchive/gamebuilder/tree/master/bui...
It's really fun and worth a try if you are looking for something similar not on Mac
Here is the original introduction video https://www.youtube.com/watch?v=l9Mf_XEZq-A
And a tutorial https://www.youtube.com/watch?v=L1hpFRztQGY
Got open sourced so you can still download it https://github.com/googlearchive/gamebuilder
Works perfectly under Linux with Wine or Proton.
The last full Steam release is also included if you don't want to compile it (7z.001-7z.002-7z.003) https://github.com/googlearchive/gamebuilder/tree/master/bui...
It's really fun and worth a try if you are looking for something similar not on Mac
first impressions by Steve Troughton-Smith:
> I can already tell that Swift Playgrounds 4 is a big deal. It is pretty much exactly what I was hoping for from an ‘Xcode for iPad’, more than just an upgrade to previously slow & clunky Playgrounds app. It dramatically reframes what iPad is capable of even in this first offering
https://twitter.com/stroughtonsmith/status/14712166828070502...
https://twitter.com/stroughtonsmith/status/14711965734177587...
> I can already tell that Swift Playgrounds 4 is a big deal. It is pretty much exactly what I was hoping for from an ‘Xcode for iPad’, more than just an upgrade to previously slow & clunky Playgrounds app. It dramatically reframes what iPad is capable of even in this first offering
https://twitter.com/stroughtonsmith/status/14712166828070502...
https://twitter.com/stroughtonsmith/status/14711965734177587...
ryeights(2)
Does anyone have personal experiences of seeing beginner using Swift Playground to learn to code and understanding programming ideas? How effect is it? How ready are they to enter "actual programming" after completing the playground?
my 9 year old son loves it - he's learned basic programming ideas in it for sure - loops, functions, etc. gives him a sense of accomplishment and we do it together which is nice.
At least the previous iteration so much about “completing” anything. It didn’t use the gamification-like mechanisms (“challenges”). And it was not “not real” programming. It left out a lot of the complexity of a project and focused on writing source code, the very heart of the definition of programming.
I use them the way I use the REPL in languages that have it: to quickly try out an idea, or to improvise some single-purpose one-off data munging.
I use them the way I use the REPL in languages that have it: to quickly try out an idea, or to improvise some single-purpose one-off data munging.
I worked for an edu tech startup that built a series of playgroundbooks for learning robotics programming.
It is a solid, top-tier learning environment for kids and beginners. Apple has high standards for content you produce in a playgroundbook if you want to be in the main subscription set. And that pays off big time in the lesson sizes, the consistency, and the accessibility of the material no matter which publisher
It is a solid, top-tier learning environment for kids and beginners. Apple has high standards for content you produce in a playgroundbook if you want to be in the main subscription set. And that pays off big time in the lesson sizes, the consistency, and the accessibility of the material no matter which publisher
Legit beginner here, I only read a little of some beginner python books but never got far. It was more fun than working through a book, more engaging. I think I may go back to it after seeing some of these updates. There is also a decent variety of options beside just going through the tutorials.
I tried to use it during development to test code in a sandbox but it always felt unstable and unnatural.
I've messed with it and my initial impressions are very positive... except that I've managed to find one bug, and that's that my experimental app appears in Siri App Suggestions and can't open because, well, that app isn't actually installed.
Maybe for iPadOS 15.2.1?
Maybe for iPadOS 15.2.1?
My kids love Swift Playgrounds. It is a wonderful way to introduce young kids to programming, in a safe and exciting environment.
How's swift doing as a language? Is it being adopted by developers in a way Apple was hoping?
Mixed - it's my personal favorite language to work with but it's like it's torn between two sides. First it's finally working on most systems, Windows & Linux and even a few old versions of MacOS, probably some more niche systems too but those are the ones I know for sure.
Vapor is still very good for back-end work and I've heard a lot of success stories for lowering costs due to less cycles being used so a lower power consumption. But even with all that Apple seems to be pushing their own direction with SwiftUI, their support for other operating systems is minimal, support for editors other than Xcode, and having separate frameworks like Metal aren't helping either.
In short I want to use swift for everything, as a Rust or C++ replacement, and I don't think I'm alone in this, but it will never have the momentum within Apple to actually get out of the Apple stratosphere enough to be it's own thing. This is probably exactly what they want, but it's a shame.
Vapor is still very good for back-end work and I've heard a lot of success stories for lowering costs due to less cycles being used so a lower power consumption. But even with all that Apple seems to be pushing their own direction with SwiftUI, their support for other operating systems is minimal, support for editors other than Xcode, and having separate frameworks like Metal aren't helping either.
In short I want to use swift for everything, as a Rust or C++ replacement, and I don't think I'm alone in this, but it will never have the momentum within Apple to actually get out of the Apple stratosphere enough to be it's own thing. This is probably exactly what they want, but it's a shame.
I actually initially tried Rust because perversely it had wider macOS support than Swift. Swift started dropping Mojave support as soon as Catalina shipped. Swift is great as long as what you're doing fits neatly into Apple's current product priorities otherwise you're on your own.
I would bet that near 100% of iOS and macOS developers are using swift in some way so I think it's been very successful in their eyes.
As for other platforms? There's work being done, but it's still not terribly useful since so many of the foundational frameworks are iOS and macOS only. (I'm unaware of any major projects doing server side swift for instance.)
As for other platforms? There's work being done, but it's still not terribly useful since so many of the foundational frameworks are iOS and macOS only. (I'm unaware of any major projects doing server side swift for instance.)
A lot of major iOS apps still use ObjC
Definitely, but how many actually use ZERO Swift?
Saying you were Obj-C only made some sense a few years ago but I can't imagine many places are doing it any more.
Saying you were Obj-C only made some sense a few years ago but I can't imagine many places are doing it any more.
But how many of them are ObjC only at this point.
As a language, it’s quite nice but slow. Runtime speed is so-so, compilation speed is awful. I really wish it were actually swift!
Feels very similar to Kotlin on the whole.
It’s definitely being adopted by Mac and iOS developers for apps (although the only real alternative is Objective-C). And there are a few build tools and the like using Swift -- many with installation instructions for Linux! -- although I think on a very small scale compared to C/C++, Rust, Go, Java and Node.
If anyone’s seriously using Swift on the server, I’d be surprised (but interested to hear about it).
Feels very similar to Kotlin on the whole.
It’s definitely being adopted by Mac and iOS developers for apps (although the only real alternative is Objective-C). And there are a few build tools and the like using Swift -- many with installation instructions for Linux! -- although I think on a very small scale compared to C/C++, Rust, Go, Java and Node.
If anyone’s seriously using Swift on the server, I’d be surprised (but interested to hear about it).
> compilation speed is awful
This really needs to be addressed, it's one of the few real bummers about the language which I otherwise love and use everyday. I'm also concerned the way more and more language features (mostly for library and framework authors) are getting piled on, it can't help compilation speed.
This really needs to be addressed, it's one of the few real bummers about the language which I otherwise love and use everyday. I'm also concerned the way more and more language features (mostly for library and framework authors) are getting piled on, it can't help compilation speed.
Strongly agreed. Swift isn't alone, the Kotlin compiler is very slow too (and yoked to Gradle, which is itself very slow). Rust as well. Maybe the Go authors are onto something after all.
When Go first came out, I thought their emphasis on compilation speed was just an overreaction to C++, because a) C compiles plenty fast, b) C++ is only slow if you overuse templates, c) other languages compile faster than C++, right? and d) Moore's law!
But a) hardly anyone uses C now, b) everyone overuses C++ templates, c) other languages compile way slower than C++, d) compilers got slower faster than computers got faster.
Even now, Xcode can feel very slick and fast in a tightly-written C/C++/Obj-C project.
When Go first came out, I thought their emphasis on compilation speed was just an overreaction to C++, because a) C compiles plenty fast, b) C++ is only slow if you overuse templates, c) other languages compile faster than C++, right? and d) Moore's law!
But a) hardly anyone uses C now, b) everyone overuses C++ templates, c) other languages compile way slower than C++, d) compilers got slower faster than computers got faster.
Even now, Xcode can feel very slick and fast in a tightly-written C/C++/Obj-C project.
> How's swift doing as a language?
It's okay. It's just a programming language like million others. Gets the job done.
> Is it being adopted by developers in a way Apple was hoping?
Apple does not negotiate, when they make up their mind you have to either adopt or die.
It's okay. It's just a programming language like million others. Gets the job done.
> Is it being adopted by developers in a way Apple was hoping?
Apple does not negotiate, when they make up their mind you have to either adopt or die.
Not too much seems to be happening outside of Apple ecosystem but it should because it's brilliant. I don't want to write in any other language.
> it's brilliant
can you share what you find 'brilliant' about it?
can you share what you find 'brilliant' about it?
I'm not an expert on programming languages and for me they are the format that I obey to express myself to the computer to make it do things, Therefore I won't be able to tell you what are the strong points and advantages of Swift over other alternatives.
What I can tell you though, is that the language is easy to read thanks to the choices they made in the way the syntax is and the language has enough abstraction tools to let me keep the parts of the code that I'm not actively working on away. For example, I like to use the property wrappers and extensions to put away the code that I'm done working on.
I also like that its strongly typed but also gives me enough wiggle room with generics.
I like the concept of protocols to vaguely define the basics of some kind of data structure and be able to pass around different flavours of it as if I'm on a weakly typed language where functions can take whatever you throw at them.
Another thing that I like about swift is that the toolset Apple provides. I used to do JavaScript as my main language but I got sick and tired of the amount of effort to keep the stack together. Endless number of tools that have many alternatives that do the same thing in a slightly different way, hours and days spent in configuring them is something that I don't want to go through anymore.
With Swift and the tools that Apple provide(various frameworks and xCode) starting something new to thinker on is as simple as creating a new Word document. It reminds me of the PHP workflows a bit, where you type your code in a text fil, put it in a folder and see the results immediately.
Essentially, I like the comfort of using Swift.
What I can tell you though, is that the language is easy to read thanks to the choices they made in the way the syntax is and the language has enough abstraction tools to let me keep the parts of the code that I'm not actively working on away. For example, I like to use the property wrappers and extensions to put away the code that I'm done working on.
I also like that its strongly typed but also gives me enough wiggle room with generics.
I like the concept of protocols to vaguely define the basics of some kind of data structure and be able to pass around different flavours of it as if I'm on a weakly typed language where functions can take whatever you throw at them.
Another thing that I like about swift is that the toolset Apple provides. I used to do JavaScript as my main language but I got sick and tired of the amount of effort to keep the stack together. Endless number of tools that have many alternatives that do the same thing in a slightly different way, hours and days spent in configuring them is something that I don't want to go through anymore.
With Swift and the tools that Apple provide(various frameworks and xCode) starting something new to thinker on is as simple as creating a new Word document. It reminds me of the PHP workflows a bit, where you type your code in a text fil, put it in a folder and see the results immediately.
Essentially, I like the comfort of using Swift.
Because it's a bit of a pet peeve of mine, what you term "strong" and "weak" are more typically called "static" and "dynamic" typing. They do not correspond to "strong" and "weak" as a general rule. Python, for instance, is "strongly" typed (try printing the result of `2+"3"` in its REPL) but also dynamically typed. Neither "strong" nor "weak" typing is well-defined, but the most consistent differentiator is about implicit conversions or casting. Like in Perl you would get "5" as a result of printing out that previous expression.
Thanks for the elaboration.
“Endless number of tools that have many alternatives that do the same thing in a slightly different way”
I think that is a risk that almost invariably comes with being open and popular. I saw the same thing with C# vs Java. In Java, you don’t have a logging API, you have a meta-logging API into which you can plug multiple logging libraries. Similarly, there used to be (maybe still are) zillion of viable options for parsing XML, json, different build systems, etc.
That brings flexibility, but at the price of having to spend time picking the best tool and anxiety about the grass at the other side, maybe, being greener.
Often, eventually, the dust settles and a clear winner emerges, but that’s not a given, and doesn’t help you when you have to make choices before the dust has settled. I don’t follow JavaScript closely, but I think it definitely still is in the “before the dust has settled” phase.
I think that is a risk that almost invariably comes with being open and popular. I saw the same thing with C# vs Java. In Java, you don’t have a logging API, you have a meta-logging API into which you can plug multiple logging libraries. Similarly, there used to be (maybe still are) zillion of viable options for parsing XML, json, different build systems, etc.
That brings flexibility, but at the price of having to spend time picking the best tool and anxiety about the grass at the other side, maybe, being greener.
Often, eventually, the dust settles and a clear winner emerges, but that’s not a given, and doesn’t help you when you have to make choices before the dust has settled. I don’t follow JavaScript closely, but I think it definitely still is in the “before the dust has settled” phase.
Property Wrappers seem pretty neat, I wasn't aware of that new feature. Thanks for mentioning it.
https://www.swiftbysundell.com/articles/property-wrappers-in...
https://www.swiftbysundell.com/articles/property-wrappers-in...
Not the OP but someone who also finds Swift brilliant
I really enjoy the value types — real structs with copy-on-write behaviour (internally). So there's a lot of freedom to model your application with a single source of truth that can be updated in a transactional way, diffed, unified, intersected, without worrying about any leftover state causing bugs
Protocols and protocol extensions are very powerful. Allowing you to write a generic interface and then add explicit functionality to anything which adopts that interface in a very clear way
In combination with pattern-matching enums which can store uniquely typed data with their cases, it makes it very easy to model complex systems in a readable, maintainable way
The combination of all these things, plus powerful generics and a very thoughtfully designed set of foundation APIs, makes it very pleasurable to write and read Swift code
The new async/await functionality also seems like it was considered for a long time. It manages to stop you from doing stupid things with threading at compile time by being conservative about how you can use structures concurrently
I really enjoy the value types — real structs with copy-on-write behaviour (internally). So there's a lot of freedom to model your application with a single source of truth that can be updated in a transactional way, diffed, unified, intersected, without worrying about any leftover state causing bugs
Protocols and protocol extensions are very powerful. Allowing you to write a generic interface and then add explicit functionality to anything which adopts that interface in a very clear way
In combination with pattern-matching enums which can store uniquely typed data with their cases, it makes it very easy to model complex systems in a readable, maintainable way
The combination of all these things, plus powerful generics and a very thoughtfully designed set of foundation APIs, makes it very pleasurable to write and read Swift code
The new async/await functionality also seems like it was considered for a long time. It manages to stop you from doing stupid things with threading at compile time by being conservative about how you can use structures concurrently
I switched to almost pure swift for a new app after having worked with obj-c a couple of years ago. TBH, when I first encountered swift I hated it, mostly because I felt it was always nagging me about optionals coming from rather fast and loose obj-c code.
I eventually embraced it and the new App greatly benefitted, hardly any bugs out in the wild compared to our other apps, we mostly just get crashes from Apple code.
Code is reeadable and easy to understand (although there is still some terrible code in the app from when I was still getting my head around it, but it works fine).
It has some frameworks and protocols I've started to use extensively, the codable protocol is especially useful for web interface, combine is coming on in leaps and bounds.
I still don't trust SwiftUI, even Apple's demo projects don't always implement things correctly and don't display properly if you use the wrong device in the wrong orientation. So I still use IB (New swift developers don't like it, it is a pain and hard to use for apps that run on all devices in multiple orientations, but for what it is, I've used worse in my career)
I eventually embraced it and the new App greatly benefitted, hardly any bugs out in the wild compared to our other apps, we mostly just get crashes from Apple code.
Code is reeadable and easy to understand (although there is still some terrible code in the app from when I was still getting my head around it, but it works fine).
It has some frameworks and protocols I've started to use extensively, the codable protocol is especially useful for web interface, combine is coming on in leaps and bounds.
I still don't trust SwiftUI, even Apple's demo projects don't always implement things correctly and don't display properly if you use the wrong device in the wrong orientation. So I still use IB (New swift developers don't like it, it is a pain and hard to use for apps that run on all devices in multiple orientations, but for what it is, I've used worse in my career)
No idea, but the compiler engineers are wizards.
It's been adopted like crazy. I can't imagine new projects being started in Objective-C. Certainly, I'd never join such a project, for sure.
I think the rapid adoption is because you can basically just inherit any Objective-C class in Swift, and then add functionality. And that's just one way of mixing Swift into an existing code base, there are others.
I think the rapid adoption is because you can basically just inherit any Objective-C class in Swift, and then add functionality. And that's just one way of mixing Swift into an existing code base, there are others.
Used Swift Playgrounds with my then 8 year old, it was neat except that it was actually pretty buggy. The game would get into a bad state somewhat often.
That gem collection game looks like a fairly direct rip-off of https://lightbot.com/ If you have kids that you'd like to introduce to some programming concepts in a fun way, I highly recommend it.
The copying may not be in the direction you believe.
The Playgrounds app was released in 2016 and that game looks like it came 2017. I was on the beta of the first Playgrounds release and seem to recall that the gem game was there from the beginning or at least very early on. But my memory may be fuzzy.
Regardless, the mechanic of the game is one that has existed since the earliest programming tutorials.
The Playgrounds app was released in 2016 and that game looks like it came 2017. I was on the beta of the first Playgrounds release and seem to recall that the gem game was there from the beginning or at least very early on. But my memory may be fuzzy.
Regardless, the mechanic of the game is one that has existed since the earliest programming tutorials.
> [Apple's Website] revolutionary app
I thought that the Apple "claiming inventorship of unoriginal ideas" meme was over.
I thought that the Apple "claiming inventorship of unoriginal ideas" meme was over.
Has anyone used AudioKit in a playground? I’ve had some ideas kicking around for ages about what I want from a live looper. Since I’d run it on an iPad it seems like a good place to try building it, if it has enough access to the microphone/file system.
Someone on Twitter points out that the interface has been localized into, among other languages, French: https://www.twitter.com/twostraws/status/1471257758666211328
But is it just me or is the translation of "Comment selection" into "Sélection de commentaire" faulty? The English version uses "comment" as a verb, like as in "take the selection and comment it out", not "here you can find a selection of comments".
But is it just me or is the translation of "Comment selection" into "Sélection de commentaire" faulty? The English version uses "comment" as a verb, like as in "take the selection and comment it out", not "here you can find a selection of comments".
Spanish has same bug
I think that Swift Playgrounds is a really neat idea (especially the books thing).
That said, I don't really have much interest in it, for myself. I am stuck in the dark world of Xcode.
What I would like (and have submitted the idea to Apple as a feature request), is to have a playground as an Xcode project target. I want to be able to link in modules and resources, without editing the playground file by hand.
That said, I don't really have much interest in it, for myself. I am stuck in the dark world of Xcode.
What I would like (and have submitted the idea to Apple as a feature request), is to have a playground as an Xcode project target. I want to be able to link in modules and resources, without editing the playground file by hand.
Xcode 13.2 (and maybe earlier) contains a project template for a "Swift Playgrounds App" in the iOS category.
Awesome! I’ll check it out!
Thanks!
I would use it for prototypes and in-place testing.
Thanks!
I would use it for prototypes and in-place testing.
Found it, but it's not what I need.
I need a target to be a playground; not a project.
The idea is to be able to assign resources, files, and SPM modules to a playground, so they are available to the code running in the playground (an example might be an SPM module like my Generic Swift Toolbox Module[0]). I can then work with the code I'm prototyping in a lightweight text file.
[0] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...
I need a target to be a playground; not a project.
The idea is to be able to assign resources, files, and SPM modules to a playground, so they are available to the code running in the playground (an example might be an SPM module like my Generic Swift Toolbox Module[0]). I can then work with the code I'm prototyping in a lightweight text file.
[0] https://github.com/RiftValleySoftware/RVS_Generic_Swift_Tool...
When will it come to iPhone though? It's crazy that the far and away best programming experience on iPhone is Python!
[deleted]
What happened to Swift on sever ? Looks like Rust sucked the air out of Swift in recent years.
Apple is investing a lot in it, but Swift is much younger than Rust (especially as an open source project). There is a working group that meets every few weeks to shepherd the various projects. Most of the recent activity has been (AFAICT) about orchestration. Well, that and transitioning projects to use async/await and structured concurrency. Here's some recent activity in the Swift on server space:
- the proposal for distributed actors is currently in-review (https://github.com/apple/swift-evolution/blob/main/proposals...)
- a metrics API for backends like Graphite, Prometheus, etc. (https://github.com/apple/swift-metrics)
- HTTP/2 support for SwiftNIO (https://github.com/apple/swift-nio-http2)
- a new service discovery API (https://github.com/apple/swift-service-discovery)
- a new distributed tracing API (https://github.com/apple/swift-distributed-tracing)
- a Linux implementation of Apple's CryptoKit API on top of BoringSSL (https://github.com/apple/swift-crypto)
I'm not pretending that it's taking the server-side world by storm, but there is a fair amount of ongoing activity Personally, I'm using it for a couple personal projects and it's been solid, but I'm already a macOS developer, so it wasn't a big stretch for me to reach for it.
- the proposal for distributed actors is currently in-review (https://github.com/apple/swift-evolution/blob/main/proposals...)
- a metrics API for backends like Graphite, Prometheus, etc. (https://github.com/apple/swift-metrics)
- HTTP/2 support for SwiftNIO (https://github.com/apple/swift-nio-http2)
- a new service discovery API (https://github.com/apple/swift-service-discovery)
- a new distributed tracing API (https://github.com/apple/swift-distributed-tracing)
- a Linux implementation of Apple's CryptoKit API on top of BoringSSL (https://github.com/apple/swift-crypto)
I'm not pretending that it's taking the server-side world by storm, but there is a fair amount of ongoing activity Personally, I'm using it for a couple personal projects and it's been solid, but I'm already a macOS developer, so it wasn't a big stretch for me to reach for it.
Swift predates Rust by a year (2014 for 1.0 of Swift vs 2015 for 1.0 of Rust)
That's just a version number. It's like saying Gmail launched in 2009, because that's when they removed the "beta" label, when people had actually been using it since 2004.
Rust was available in 2012[0], and Swift wasn't until 2014. In reality, since we're talking about using it on the server, Swift wasn't available until almost 2016[1].
[0]https://mail.mozilla.org/pipermail/rust-dev/2012-January/001...
[1]https://www.swift.org/blog/swift-linux-port/
Rust was available in 2012[0], and Swift wasn't until 2014. In reality, since we're talking about using it on the server, Swift wasn't available until almost 2016[1].
[0]https://mail.mozilla.org/pipermail/rust-dev/2012-January/001...
[1]https://www.swift.org/blog/swift-linux-port/
They are either the same age or Rust is considerably older, depending on how you look at it:
Rust was publicly announced in 2010, after ~4 years of development in private (starting sometime in 2006, though I don't know how fast that went).[0]
Swift development started that year, 2010, in secret at Apple.[1] It became public in 2014 (some would say it was still in a beta state despite the 1.0 label).
[0]:https://en.wikipedia.org/wiki/Rust_(programming_language)#Hi... [1]:https://en.wikipedia.org/wiki/Swift_(programming_language)#H...
Rust was publicly announced in 2010, after ~4 years of development in private (starting sometime in 2006, though I don't know how fast that went).[0]
Swift development started that year, 2010, in secret at Apple.[1] It became public in 2014 (some would say it was still in a beta state despite the 1.0 label).
[0]:https://en.wikipedia.org/wiki/Rust_(programming_language)#Hi... [1]:https://en.wikipedia.org/wiki/Swift_(programming_language)#H...
Thank you !
It is as famous as Objective-C on server.
A language needs an eco-system, just the compiler + stdlib won't go far.
A language needs an eco-system, just the compiler + stdlib won't go far.
The app is probably great but I hate how Apple calls everything they do revolutionary. Calm down, it's okay to just be great.
I’m curious enough to give this a try, but can it really be good when Xcode is so bad? Are they written by different teams?
A lot of people say this but I find Xcode quite good. I can load a huge project and be editing in around 5 seconds, compared to waiting several minutes in Android Studio. It has very clear in-line diffing, incredibly fast project-wide search, and very consistent hotkeys making keyboard navigation very simple (especially if you like to spatially arrange your editors via hotkey). I also find that its UI is responsive and well designed, good aesthetic choices, consistent stroke widths on icons, consistent typography, etc
Some of the "badness" of Xcode comes when you have to deal with a huge, mixed-language project (Objective-C, Objective-C++, C++, C, Swift). But then, I don't know of an IDE that handles that situation gracefully, and in a unified way. Xcode still manages to parse and autocomplete all the above languages with a good degree of grace, but the clunkiness comes in knowing how to connect them all together and why the damn thing won't build or link — it's pretty hard to shield the programmer from that complexity
Some of the "badness" of Xcode comes when you have to deal with a huge, mixed-language project (Objective-C, Objective-C++, C++, C, Swift). But then, I don't know of an IDE that handles that situation gracefully, and in a unified way. Xcode still manages to parse and autocomplete all the above languages with a good degree of grace, but the clunkiness comes in knowing how to connect them all together and why the damn thing won't build or link — it's pretty hard to shield the programmer from that complexity
I have some major gripes with Xcode as it is now (though otherwise I find it to be quite good):
1. Startup time is too long. Often I find myself double clicking a code file in Finder to preview it only to be greeted with jumping Xcode icon. Riiiight, here we goooo, boss. Just 2-3 seconds, boss. It should open the file straight away, and then lazily load the rest of its frameworks if necessary.
2. Code editor is very bad with large files. Be it large JSON data, or C++ files from Unity's code generator, navigating and editing those is painful. Every typed symbol will incur a delay, every switch to different place in that file is noticeable too. This is by far the worst of all other code editors I used, but I get it, few people have to work with huge amount of text.
3. pbxproj format for project. Ever worked in a team where several people adding and removing files in their commits? Happy project merging then. Or rather, happy searching for a tool to auto-regenerate the project. This format has to go.
1. Startup time is too long. Often I find myself double clicking a code file in Finder to preview it only to be greeted with jumping Xcode icon. Riiiight, here we goooo, boss. Just 2-3 seconds, boss. It should open the file straight away, and then lazily load the rest of its frameworks if necessary.
2. Code editor is very bad with large files. Be it large JSON data, or C++ files from Unity's code generator, navigating and editing those is painful. Every typed symbol will incur a delay, every switch to different place in that file is noticeable too. This is by far the worst of all other code editors I used, but I get it, few people have to work with huge amount of text.
3. pbxproj format for project. Ever worked in a team where several people adding and removing files in their commits? Happy project merging then. Or rather, happy searching for a tool to auto-regenerate the project. This format has to go.
Agree on all three points
1. I certainly wouldn't use Xcode for editing single files from the Finder. For opening a huge project with thousands of files, ready to build and fully indexed for autocompletion and finding, it still only takes a few seconds. That's the metric that impresses me
2. Yeah I have one long file in my current project (hundreds of thousands of lines) and it isn't pleasant to edit in Xcode
3. I am quite good at merging pbxproj after 10 years of doing it, even when files are added and removed. But yeah, it is a bit hairy
1. I certainly wouldn't use Xcode for editing single files from the Finder. For opening a huge project with thousands of files, ready to build and fully indexed for autocompletion and finding, it still only takes a few seconds. That's the metric that impresses me
2. Yeah I have one long file in my current project (hundreds of thousands of lines) and it isn't pleasant to edit in Xcode
3. I am quite good at merging pbxproj after 10 years of doing it, even when files are added and removed. But yeah, it is a bit hairy
I'm curious about (1), because that isn't my experience at all! For me it takes its time to open, and indexing is not very fast. I'm only on x86 rather than an M1, but even so...!
In comparison, I've found that VS Code is fast; after opening a workspace, opening any file by name or doing a live search by content is more or less immediate.
In comparison, I've found that VS Code is fast; after opening a workspace, opening any file by name or doing a live search by content is more or less immediate.
You're absolutely right, compared to VS Code or Sublime Text, Xcode is much slower to open a large project. It's a fixed cost of about five - ten extra seconds for me, once it's open it is fast to navigate
I think I am used to comparing it to Android Studio as I mostly do native mobile development for Android and iOS
I think I am used to comparing it to Android Studio as I mostly do native mobile development for Android and iOS
I think a lot of Xcode’s issues stem from it being a 20+ year old program with a lot of the legacy baggage that comes with that. I’ve actually found it not too bad with the recent updates. If they could get rid of the stupid project file format then I might actually like it.
They are written by different teams (source: I know people who have worked on each team). They share things, of course. In fact, the "new" (as of a few years ago) source editor in Xcode came out of Swift Playgrounds for iOS originally.
What's so bad about Xcode? I use Xcode for my day job--honestly curious which parts people don't like.
It’s the Internet - if someone says “I use <X>”, then inevitably you’ll see a handful of passionate comments along the lines of “<X> is the worst technology created since the dawn of man, and <creator of X> really should admit failure and redo it from scratch to make ME, an Internet Commenter, happy”. I’ve learned to just tune them out and use my own judgement and preferences to decide if a tool is effective for me.
Thanks. I like Xcode even if others don't. And I have used many other IDEs (IntelliJ, VS Code, even NetBeans). I'm honestly curious what the sore points are.
I do use it in my day job, so I'm not saying it's the worst, but I have been pretty frustrated with it for some time now! Very happy to share :)
This is from my experience working with a couple of large iOS team projects written in Swift, with CocoaPods dependencies. YMMV for other setups. I've hit a bunch of problems in the IDE itself, the Swift toolchain, the iOS Simulator, and in the integration between them.
First, it's slow: compilation is slow, running tests is slow, starting the app is slow, debugging is slow (generally tens of seconds to attach when it hits a breakpoint), inspecting the view hierarchy is slow (and often just doesn't work). Code completion is slow and unreliable (and currently doesn't work at all for third-party frameworks in Xcode 13).
Besides the slowness, things get out of sync a lot, I think because it's doing tasks in parallel in an attempt to do them faster. I frequently see out-of-date compile errors and warnings highlighted in the IDE, because it hasn't finished the appropriate bit of the build yet, or because you're currently working in another target. Production code and unit tests are in different targets because that's how Xcode wants it, but because they drift out of sync so much and the tooling is slow, test-driven development is really tedious and slow. It's usually easier just to build and run the whole app.
The UI is usable, but tabs are very clunky and limited compared to other popular IDEs (e.g., you can't just drag to create a new split in any direction). The "assistant editor" for things like associated header files isn't necessarily a bad idea, but again it's clunky and limited. There are too many "mystery meat" icons with no labels attached -- I constantly get mixed up between Issues, Test and Debug.
The monolithic project file format is really awful, especially if you're working in a team. It's not usefully human-readable or editable, and every so often Xcode will make random changes to random GUIDs; you just have to shrug and check it in and hope that nobody else gets a merge conflict. The same applies to Interface Builder and all the other embedded rich editors. Just opening an icon or color resource will likely make some random meaningless edit -- why?
Adding a file to the project takes an age. "New File...", wait several seconds, "Choose a template for your new file", I don't care, type a filename, delete it again because that's actually the search field for templates, press Next, wait a few more seconds, and finally you're at the file dialog.
Why do files even need to be added? It would be so much better if it just reflected the file system. As it stands, files can be reordered (does anyone take the trouble to arrange them in a sensible order? if so, how on earth do you maintain that in a team project?), accidentally omitted from the project, in a different group than its actual position on disk... why?
Finally, some of this stuff might get better with more familiarity (e.g., if you set up keybindings) except that the UI tends to change substantially on each release! If you look for advice on StackOverflow on fixing some obscure problem with certificates (and I bet at least 90% of iOS developers have done this) you'll find five completely different solutions for five different versions of Xcode. Oh, and each new release is ~10GB and takes hours to install, literally hours of Archive Tool opening and verifying something called a .xip file.
There's no perfect IDE, and I'm not even saying Xcode is uniquely bad, but for each of my complaints here there's another tool that does it better. VS Code is really fast (I'm increasingly using it as a companion editor for everything other than .swift files); Android Studio for all its flaws has nicer tab management, and its interface builder equivalent works really well.
This is from my experience working with a couple of large iOS team projects written in Swift, with CocoaPods dependencies. YMMV for other setups. I've hit a bunch of problems in the IDE itself, the Swift toolchain, the iOS Simulator, and in the integration between them.
First, it's slow: compilation is slow, running tests is slow, starting the app is slow, debugging is slow (generally tens of seconds to attach when it hits a breakpoint), inspecting the view hierarchy is slow (and often just doesn't work). Code completion is slow and unreliable (and currently doesn't work at all for third-party frameworks in Xcode 13).
Besides the slowness, things get out of sync a lot, I think because it's doing tasks in parallel in an attempt to do them faster. I frequently see out-of-date compile errors and warnings highlighted in the IDE, because it hasn't finished the appropriate bit of the build yet, or because you're currently working in another target. Production code and unit tests are in different targets because that's how Xcode wants it, but because they drift out of sync so much and the tooling is slow, test-driven development is really tedious and slow. It's usually easier just to build and run the whole app.
The UI is usable, but tabs are very clunky and limited compared to other popular IDEs (e.g., you can't just drag to create a new split in any direction). The "assistant editor" for things like associated header files isn't necessarily a bad idea, but again it's clunky and limited. There are too many "mystery meat" icons with no labels attached -- I constantly get mixed up between Issues, Test and Debug.
The monolithic project file format is really awful, especially if you're working in a team. It's not usefully human-readable or editable, and every so often Xcode will make random changes to random GUIDs; you just have to shrug and check it in and hope that nobody else gets a merge conflict. The same applies to Interface Builder and all the other embedded rich editors. Just opening an icon or color resource will likely make some random meaningless edit -- why?
Adding a file to the project takes an age. "New File...", wait several seconds, "Choose a template for your new file", I don't care, type a filename, delete it again because that's actually the search field for templates, press Next, wait a few more seconds, and finally you're at the file dialog.
Why do files even need to be added? It would be so much better if it just reflected the file system. As it stands, files can be reordered (does anyone take the trouble to arrange them in a sensible order? if so, how on earth do you maintain that in a team project?), accidentally omitted from the project, in a different group than its actual position on disk... why?
Finally, some of this stuff might get better with more familiarity (e.g., if you set up keybindings) except that the UI tends to change substantially on each release! If you look for advice on StackOverflow on fixing some obscure problem with certificates (and I bet at least 90% of iOS developers have done this) you'll find five completely different solutions for five different versions of Xcode. Oh, and each new release is ~10GB and takes hours to install, literally hours of Archive Tool opening and verifying something called a .xip file.
There's no perfect IDE, and I'm not even saying Xcode is uniquely bad, but for each of my complaints here there's another tool that does it better. VS Code is really fast (I'm increasingly using it as a companion editor for everything other than .swift files); Android Studio for all its flaws has nicer tab management, and its interface builder equivalent works really well.
Some interesting replies in this thread! I want to expand on my flippant "Xcode is so bad" a bit.
A lot of the stuff I dislike about Xcode impacts large, complex, multi-team, multi-language projects, with nib files and storyboards and other resources. I guess a lot of that is simply irrelevant to Swift Playgrounds, so it could be better just by dropping those features!
On the other hand, another big complaint I (and others) have is that the Swift compiler is too slow. That does affect Playgrounds; I've tried using playgrounds within Xcode and been very underwhelmed, so I'm skeptical that the standalone app would be any better.
But people here are reporting how much their kids enjoy using Playgrounds. I do like Swift on the whole, but I wouldn't have thought it to be pleasant as a first language for beginners. So I'm curious!
I wonder how big a difference good hardware makes -- recent iPad hardware is very good indeed, so I can see how a more focused app on an iPad might outperform Xcode on an x86 Macbook "Pro".
A lot of the stuff I dislike about Xcode impacts large, complex, multi-team, multi-language projects, with nib files and storyboards and other resources. I guess a lot of that is simply irrelevant to Swift Playgrounds, so it could be better just by dropping those features!
On the other hand, another big complaint I (and others) have is that the Swift compiler is too slow. That does affect Playgrounds; I've tried using playgrounds within Xcode and been very underwhelmed, so I'm skeptical that the standalone app would be any better.
But people here are reporting how much their kids enjoy using Playgrounds. I do like Swift on the whole, but I wouldn't have thought it to be pleasant as a first language for beginners. So I'm curious!
I wonder how big a difference good hardware makes -- recent iPad hardware is very good indeed, so I can see how a more focused app on an iPad might outperform Xcode on an x86 Macbook "Pro".
Swift playgrounds is really cool and all (I really want to copy it for D!) but when can I build GCC on my iPad. The things so fucking fast but I basically only watch movies and read pdfs.
Oftentimes the answer to "when can I do X on Apple hardware?" is "when it's ready".
I'm far from an apple fanboy, but I strongly respect and appreciate that stance, especially in a culture that promotes its antithesis.
I'm far from an apple fanboy, but I strongly respect and appreciate that stance, especially in a culture that promotes its antithesis.
On the other hand, the answer to "when can I run a compiler or JIT runtime on iDevices" has historically been "never", and I wouldn't be surprised if that answer eventually applies to Mac devices too.
Xcode Cloud[0] feels like a manifestation of everything Stallman warned us about...
[0] https://developer.apple.com/xcode-cloud/
[0] https://developer.apple.com/xcode-cloud/
So now we can program on the iPad, but only with Apple’s approved language, on its approved ide.
Can’t a government go there and knock the wall down?
There's actually a whole host of iPad apps that will give you programming environments for Python, JavaScript, and so on. iSH will give you a full x86 Linux box and a-Shell supports compiling and running WASM/WASI binaries in a simulated shell environment. They've been around for some time, too; Apple really does not give these things the fanfare they deserve.
The main wall that I can see needing to be knocked down would actually be technical, not political. Something like OAMA[0] absolutely would not fix the lack of JIT entitlements or virtualization support accessible to third-party developers in iPadOS. I would not be surprised if Swift Playgrounds is either relying on lots of Apple-only entitlements or compromising on performance[1]. If we had proper virtualization, then we wouldn't need iSH; we could load up a real Linux distro and run a LAMP stack or Docker containers on iPads.
[0] Open App Markets Act; similar provisions were in the EU Digital Markets Act at one point
[1] The screenshots I'm seeing suggest that, at a minimum, your code runs in the same sandbox as the editor. Which means Apple hasn't added any sort of private API that would let Swift Playgrounds properly provision your app. Without a JIT entitlement, the editor would also need to include an AArch64 emulator inside itself in order to provide the App Preview feature. These sorts of things won't matter to casual programming use-cases but would kill a lot of the benefits of an on-device development environment.
The main wall that I can see needing to be knocked down would actually be technical, not political. Something like OAMA[0] absolutely would not fix the lack of JIT entitlements or virtualization support accessible to third-party developers in iPadOS. I would not be surprised if Swift Playgrounds is either relying on lots of Apple-only entitlements or compromising on performance[1]. If we had proper virtualization, then we wouldn't need iSH; we could load up a real Linux distro and run a LAMP stack or Docker containers on iPads.
[0] Open App Markets Act; similar provisions were in the EU Digital Markets Act at one point
[1] The screenshots I'm seeing suggest that, at a minimum, your code runs in the same sandbox as the editor. Which means Apple hasn't added any sort of private API that would let Swift Playgrounds properly provision your app. Without a JIT entitlement, the editor would also need to include an AArch64 emulator inside itself in order to provide the App Preview feature. These sorts of things won't matter to casual programming use-cases but would kill a lot of the benefits of an on-device development environment.
I haven’t looked closely at the new implementation in Swift Playgrounds yet but historically it’s compiled your app in debug mode to native ARM64 code, then run it directly using a private entitlement.
Would love to see a JetBrains IDE on iPad. Not holding my breath though.
Why not just buy a tablet from someone else if you don’t want a managed environment?
Apple is not the only tablet maker.
Apple is not the only tablet maker.
https://codea.io and others have been around longer than Swift Playgrounds.
Pythonista is a lot better and more powerful than Swift playgrounds. It's also available on iPhone. So you're just flat out wrong.
Swift Playgrounds has been around for quite some time.
I’d also hesitate to think of it as a way to “program on an iPad.” It’s a slimmed down IDE + visualization pane intended to be an educational environment for people wanting to learn programming fundamentals, Swift specifically, or how to program one of the robots/drones/programmable devices that have a companion lessonbook.
I’d also hesitate to think of it as a way to “program on an iPad.” It’s a slimmed down IDE + visualization pane intended to be an educational environment for people wanting to learn programming fundamentals, Swift specifically, or how to program one of the robots/drones/programmable devices that have a companion lessonbook.
That’s what it was before this update.
Now it is a full development tool that lets you release commercial apps.
Now it is a full development tool that lets you release commercial apps.
On what grounds? It's their platform
Apple has a natural monopoly on Apple's products.
> You create content for the Swift Playgrounds app by writing playground books. Like traditional books, playground books are made up of chapters and pages. Unlike traditional books, they include executable Swift code that displays the results live, right on the page.
> Swift Playgrounds subscriptions, like podcasts, are a sequence of episodic content arranged in an order that builds knowledge while allowing more advanced learners to skip content. Subscriptions exist on the internet as feeds—downloadable lists of items that apps and websites can deal with. You publish a set of playgrounds as a feed that the Swift Playgrounds app can download, process, and display.
You publish them on your own website, via a JSON feed. No App Store review needed. You could treat it like a Jupyter Notebook, or an interactive story world - whatever you want.
[1] https://developer.apple.com/documentation/swift_playgrounds