Swift Playgrounds 4
apple.com
apple.com
> 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
As for links, there are very few subscriptions published – and probably none yet that work with Swift Playgrounds 4.0.
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
- 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
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.)
This is really cool.
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
> 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 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.
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
Maybe for iPadOS 15.2.1?
can you share what you find 'brilliant' about it?
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.
https://www.swiftbysundell.com/articles/property-wrappers-in...
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 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 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)
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.
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.)
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.
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).
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.
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.
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.
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 thought that the Apple "claiming inventorship of unoriginal ideas" meme was over.
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.
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".
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.
Thanks!
I would use it for prototypes and in-place testing.
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...
- 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.
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...
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...
A language needs an eco-system, just the compiler + stdlib won't go far.
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 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
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. 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
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.
I think I am used to comparing it to Android Studio as I mostly do native mobile development for Android and iOS
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".
I'm far from an apple fanboy, but I strongly respect and appreciate that stance, especially in a culture that promotes its antithesis.
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.
Now it is a full development tool that lets you release commercial apps.
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.
Apple is not the only tablet maker.