Hacker News new | past | comments | ask | show | jobs | submit login
Swift Playgrounds for macOS (apps.apple.com)
434 points by rock_artist 16 days ago | hide | past | web | favorite | 228 comments

Now, Apple, can we please have the opposite? XCode on the iPad (even if some features had to be removed, like VS Code is to VS), with a containerized shell to run code we write in?


I've argued for a while that they need to do, as part of their services push, is a "cloud compile" service. I know they want to sell hordes of Mac Pro boxes to devs, but what a cool way to open up development (like, on the iPad). Write code, save in iCloud Drive, tap "compile my app". It handles all the signing and so on, and then boom, it's on my home screen. You limit distribution to your devices at first - maybe you still need a Mac to sign it for everywhere distribution, but you let any device you own run it. You can share source via the usual open-source methods, since everyone just needs to get the code onto their iCloud Drive to build it.

There's a huge number of moving parts to get an MVP and we mustn't cannibalize desktop and laptop sales, but it seems like an obvious part of their services push AND "make the iPad a 'real' computer".

I’m not even sure the Mac Pro boxes are for devs. They seem pretty laser focused on Hollywood and similar for whatever reason, to my estimation anyway.

They are for devs, Apple eco-system devs, not devs using macOS as pretty GNU/Linux.

They are not for devs. Few workplaces are gonna pony up $10-20k for a developer box. The 16" MBP is Apple's developer machine.

The workplaces that develop commercial software for the users that need those boxes, will buy them.

Well, they're first workstations for video/3D/ad/music/etc production houses (the ones who would need the accessory 6K screen), and secondary for Apple ecosystem devs.

That software is written using macOS and iOS APIs, not GNU/Linux ones, so Apple ecosystem devs.

Meh, I wish they said if you have one registered mac device already and are part of the apple developer program, you can legally run MacOS vmware on a non mac device with 4 VMs and just be done with it.

They will still get mac sales because corps want to be legal and not use hackintosh and all their developers are getting macbooks anyway. The vmware compute licences would be used for CI and for beefy compile machines to run xcode that will run on whatever thread ripper equivalent.

The cheap small shops would do hackintosh vmware either way, so they won't be missing much in sales in practice. MacStadium and huge iOS / macOS development must only represent what, 50k-100k unit sales? Which is a drop in the bucket for apple either way, but a very important partner in making good stuff for apple.

A "Pro" device shouldn't have so many limitations built in, just give me a regular UNIX-y environment with a (pro-)user-friendly UI on top (meaning: just put macOS on the iPad Pro and attach a proper keyboard... wait a minute...).

How do you imagine the coding UI would work? It strikes me that coding is extremely keyboard dependent, and also a case where screen space is important, so it's like a worst case scenario for a soft keyboard.

Take a look at the Continuous IDE for iOS and iPadOS. It's C# based, but it will compile and run any code supported by the platform, including UIKit, SpriteKit/SceneKit and Xamarin.Forms. The compiler is the Roslyn compiler. The only limitation is that it uses an interpreter to run the code.

There are plenty of (fairly reasonable) hard keyboards for iPads.

And of course there are alternate paradigms for programming that rely on a lot less typing.

> there are alternate paradigms for programming that rely on a lot less typing.

Sure, but I have yet to see one that beats a shell in a VT for ergonomics, discoverability (most GUIs are just the opposite here,) or documentation.

As someone who travels a lot and often has very bad internet no thank you

Presumably you only need internet for the compilation step, which would be as seldom/often as pushing to a git remote repository, for example.

Do you every time you check a file in? I certainly don’t. I make a bunch of edits / changes / new code, compiling as I go, checking the code in when I am at various useful sequence points, and only push upstream when appropriate.

Well, mostly people aren't travelling through zero-wifi all the time, as they're escaping the CIA in the developing world...

For the majority of coders working in homes, offices, cafes and such, including most digital nomads, it would be just fine...

I for one (used to) hit compile / run dozens of times a day, because everything I write has to be tested after all.

It would literally take less bandwidth than opening any newspaper.

This highly depends on where the code is executed, and how debugging is implemented. A medium-sized project (say, 300K lines of code) would require to transfer hundreds of megabytes of data to be able to debug things.

Logs are highly compressible.

We keep hearing every year from the Apple tech press how powerful the iPad Pro is, shouldn’t it just be able to handle compilation itself?

I say hearing because because the real world examples of this supposed power are few and far between.

The day they provide this, is the day they are clearly signalling the end of macos.

I would argue that a phone, tablet, and computer can all have the same OS, just with different UI.

So the "end of macos" is unlikely in my book.

I'm waiting for the day we can "dock" a phone to a monitor with a mouse/kb & have a full desktop OS experience.

Samsung Dex is this. I can dock my phone and get a desktop experience. I have Visual Studio Code running now (though code-server[1]) and Ubuntu userland (via Termux/Andronix). Plus all other Android apps running in detached windows.

It's unfortunately not even as useful as it sounds but it is a start. I'm still at the early stages of setting it up for real work.

[2] https://github.com/cdr/code-server

How responsive is it? Would you mind being limited to your Dex without another desktop or laptop to use?

It's definitely responsive enough; performance is not the problem. It is software availability that the biggest problem -- Android doesn't even really have a decent desktop-class text editor. But email, web browsing, games, etc is all fine; I can multitask all these things in a Dex desktop.

I used DeX (the non-Linux version) while my main laptop was in for repairs, and it got me through. There were even positive surprises, like discovering it supported external hard drives and some of my pro audio gear. I could connect my Focusrite Scarlett USB audio interface which is connected to my JBL 305P studio speakers.

If you're able to do all your work on Android or the web, it would work. But for me there's still a ton of Windows and Mac software I need to get the job done. The other problem is DeX doesn't really work in a laptop form yet, and I like to do work from cafes a lot.

The Samsung Tab S6 with the keyboard cover would give you DeX in a laptop form factor.

Better not update it to Android 10 though, as they canceled the project.

They cancelled Linux on Dex but that's not what I'm using. Dex works fine on Android 10.

Current iPhone has the power to do so, and can connect via ApplePlay and bluetooth. So the only holdup is software.

Maybe this year's WWDC will show us something closer to that.

I'm holding out hope for this, since they "added" mouse support to iPadOS in 2019. There has to be a reason for that plus Universal apps, plus SwiftUI, right?

1. You mean AirPlay.

2. You don't need AirPlay, you could drive a monitor and keyboard/mouse directly, using an HDMI/USB dongle. But yes, as you said, software is the hold up. The rest is ready.

They might also mean CarPlay, which is closer in idea to “plug cord in get desktop UI”

Yup, we need "DesktopPlay", "TVPlay" (think nintendo switch) and "CameraPlay" so you can sync photos via AirDrop on your SLR.

Maybe they plan to support it for iPadOS devices and either no support or stripped down for iPhone. It’d be cool if we at one point had desktop power in our pockets though. (Yes I know we do to some extent, but it’s still a bit of a stretch for a daily driver.)

What is the benefit?

Most people who need a desktop OS, want a desktop or notebook that performs faster than a smartphone. Otherwise they can just get an iPad or low end laptop and it won't set you back much more than keyboard + mouse + display. Cloud sync takes care of the rest.

Smartphones are probably pretty close to being powerful enough for 80% of desktop use cases. Having one device that can dock to a "laptop" shell and give me a full screen desktop OS would be amazing.

current iPhones and iPads are quite powerful


yes! Microsoft and Android products have sort of done this in the past, but didn't do well in the market or the user/dev experience was not great.

Like Windows Phone Lumia, or many Windows tablets.

I want to see pen-on-tablet experience that allows working without a keyboard.

Then, plug tablet to monitor and “type/write” on the tablet.

Why? Writing is much slower than typing and less accurate to boot. There are also a lot of problems to solve for a variant input which have long been settled with keyboard. For example code completion, jumping to the definition, showing errors where they keyboard focus is, etc.

Unless someone were to come out with some kind of massive productivity gain by switching input types, people aren't going to switch and these supplemental technologies will never get built.

I often typo and get corrections from the text editor I used, when I write not-code text.

When I write code, I don’t need to type fast. However, I like to layout things quickly: proper indentation, docstrings, spacing, order/position of functions.

I think those can be solved.

Ever sketched a quick diagram in a notebook to try and work out a problem? Handwriting isn’t dead.

Writing + voice input + Soli gestures + Selfie type would go a long way.

I could live without a keyboard.

Like what Ubuntu tried to do

The problem is that the "just" is an unsolvable problem.

Your phone and to some extent tablet are limited screen estate with the finger as the primary method of interaction.

Your desktop is nearly unlimited screen estate with high precision input methods (mouse and keyboard).

The "just different UIs" mean "entirely different UIs tailored to specific interactions and completely changing behaviour of an app in all but the simplest cases"

All of this is true, but with processing power and disk space increasing, you could envision a world where a phone simply has a copy of a desktop OS that it could boot into for docking, like a Mac with a Windows partition.

I’m sure you could do this with Linux now, it’s just such a niche use case nobody has mass produced it.

Exactly: it's such a niche thing, no one is mass-producing it. Because you would still have a problem.

Let's say, you started editing a document on your phone. You then put it in a dock. Now what? The separate desktop OS starts, and?...

>Let's say, you started editing a document on your phone. You then put it in a dock. Now what? The separate desktop OS starts, and?...

And you edit the document in a desktop UI now.

Apple already has this feature (moving data and open files and apps and such from mobile to desktop transparently), called Continuity.

Yes. And it's different apps (one on desktop, on on mobile), and both apps have to support Continuity.

So a phone in dock would have to run two OSes in parallel, and the apps in both OSes would have to run and support continuity-like hand-off.

It could sync from the cloud.

Yup, this will work fast enough work for most apps.

If MSFT can make Excel run on my iPhone, then I have a lot of hope.

When I can edit a freaking PowerPoint presentation on an iPhone (in a pinch - I wouldn't want to do it all day), then I have to think it's not only possible, but already done.

Email is probably the best example. Every major email app is on multiple platforms, and I'd be very surprised if most of the code is not already the same among platforms except for the UI.

So I'd submit that it is a solved problem.

I believe you misunderstood. The issue is not whether software can be ported to a touch platform. It is that keyboard/mouse-oriented UI and ergonomics and a touch-oriented UI and ergonomics cannot successfully co-exist. It’s not a programming challenge.

> "keyboard/mouse-oriented UI and ergonomics and a touch-oriented UI and ergonomics cannot successfully co-exist"

I'm not sure that's necessarily true. Are you aware of Mac Catalyst?


(Of course, the user experience will always be somewhat different on a small phone screen compared to a big Mac screen. But that doesn't mean you can't build an app that works well on both from one code base. And certainly an iPad app is not all that different from a Mac app.).

Again, you are thinking of porting a touch app to a non-touch device when the issue is that good touch and non-touch UI and ergonomics cannot co-exist on the same device.

And I am familiar with Catalyst. I think Catalyst is a good example of how software suffers in a K/M-oriented environment when it came from a touch environment without many modifications. Even the Apple-developed apps have too many controls and views designed for tactile screens. The Catalyst development team is introducing UI elements that make more sense in macOS, like a compact calendar picker to replace the touch-style picker wheel, but it’s going to take a long time before a Catalyst app lets a developer quickly make a macOS version that feels designed for macOS, and again, there is a need for that native macOS feel because quality touch UI interfaces are slow and difficult to use on a laptop or desktop.

Well, let’s use our imagination...

... and hope that Apple reinvents user input on mobile.

A little Soli for advanced gestures:


A selfie keyboard?


Better voice commands. For example, why can’t I say “build app”

“Rename function foo to bar“

Voice certainly seems like a viable solution to some of that. In some ways it’s imminent if the accessibility improvements pushed to iOS, iPadOS and macOS are advanced just a bit further.

However, we should also expect to see PC use pushed into more advanced and specialized territory on our most powerful and versatile devices as phones and tablets assume more traditional PC work. That specialized use will advance as fast as the most attuned interface for that platform (keyboard+mouse) and the others will necessarily lag behind.

All of this won't solve the mobile/desktop dichotomy.

I rename things dozens of times a day. Saying "rename function A to B" dozens of times a day is unviable on desktop and is nearly unusable on the phone. And this is a fundamentally different UI.

>Again, you are thinking of porting a touch app to a non-touch device when the issue is that good touch and non-touch UI and ergonomics cannot co-exist on the same device.

Sure they can, just not on the same screen sizes/input methods.

You could have Excel that looks like iOS Excel when opened in the iPhone that automatically turns into Excel that looks like macOS Excel when the iPhone is connected to a larger screen with a mouse and everything.

You couldn't. Not without exceptionally complex UI code amounting to writing two different apps inside of one.

Since you have both of those apps already, you can trivially combine them.

In the process you'll also get to reuse large parts of both UI code, and almost all of the non-UI code.

And if you've started from scratch, it would be even easier to find ways to reuse more UI code -- e.g. components could come in "auto-dual" versions that adapt.

> can trivially combine them

Could you explain to me how can you trivially combine two apps?

> In the process you'll also get to reuse large parts of both UI code, and almost all of the non-UI code.

Yes to the non-UI code. Hard no to the UI code.

You will need to design a completely different set of interactions, components, layouts etc. for the mobile version compared to the desktop version.

>Could you explain to me how can you trivially combine two apps?

You already have the UI code for mobile and desktop. All you need to do is switch to one or the other when the user connects/disconnects an external monitor.

At the most basic, you could just save the spreadsheet state (staying with the Excel used as an example), and load in the background and switch to show the desktop version of the app with it pre-loaded. Same way as if the user manually saved their spreadsheet, closed the mobile version of the app, and opened the same spreadsheet with the desktop version - but more transparently.

Between this and "sharing UI" there is a big spectrum. If you already have the mobile and desktop version, and the backend is more or less the same (as can be the case with apps like Excel for macOS and iOS), then compared to the work you've already done its trivial to add an intelligent way to switch from one UI to the other keeping all the other state (working spreadsheet, clipboard, current executing action, etc).

>You will need to design a completely different set of interactions, components, layouts etc. for the mobile version compared to the desktop version.

Not necessarily. A sphreadsheet cell is a sphreadsheet cell. Whether you click on it with touch or the mouse pointer doesn't matter. You could easily share the same underlying widget (and e.g. just show more of them). The formula editor that appears can similarly be shared. Other forms might need some extra padding, or some widgets to become larger or smaller etc.

We already have apps that run the same in iOS and macOS, through Apple's translation layer + layout constraints and switches on widgets. The "Voice Memos" apps is basically the exact same thing between iOS and Mac.

> You already have the UI code for mobile and desktop. All you need to do is switch to one or the other

There's no "just switch". I wish people stopped hand-waving at complex technical problems with "just"s and "all you need"s.

What you're saying is: "you have two completely different UIs with completely different modes of interactions, completely different layouts, affordances, a myriad other things. 'All you have to do' is ship them together and switch them on the fly".

> then compared to the work you've already done its trivial to add an intelligent way to switch from one UI to the other

It is not "trivial"

> A sphreadsheet cell is a sphreadsheet cell. Whether you click on it with touch or the mouse pointer doesn't matter.

It does matter. Because interactions are completely different. Just for the most trivial example: once you've selected a cell, you can immediately start typing you can immediately start typing when you're on a desktop. On a mobile device you have to do an additional tap (double tap in Excel) or tap a different area (entry box in Google Sheets) on the screen to start typing. And that's just one interaction. There are hundreds of other interactions which will be different.

> We already have apps that run the same in iOS and macOS, through Apple's translation layer + layout constraints and switches on widgets.

Yes, and almost all of them fail in the most basic ways on the desktop: they provide incorrect widgets (dates for example), they break user input, they handle focus incorrectly, they don't have keyboard shortcuts, they use interaction patterns that are alien to the desktop and so on and so forth.

Let's take a look at "voice memos":

- No shortcut to delete a Voice Memo, but a slide-to-reveal Delete button. Alien to desktop

- Esc doesn't work to exit editing screen or recording screens

- Cmd+W quits the app which is against the HIG

- Once search input has focus, you can't Tab out of it (but you can Shift-Tab)

- In the editing screen the Crop Button is inside window chrome which is against HIG if I'm not mistaken.

Yes, this app runs "the same on iOS and MacOS", and that's precisely the problem: it shouldn't run "the same". It must be different because the desktop is different.

And note: this is a first-party app with next to zero functionality: a few buttons, a screen that shows one thing at a time. That's it. And it already is filled with inconsistencies and bad behaviour on the desktop. It will only be much, much worse for any app with more complex functionality (unless developers take conscious and specific steps to address this).

Also see, "Catalyst and Cohesion" [1]

[1] https://wormsandviruses.com/2019/12/catalyst-and-cohesion/

>There's no "just switch". I wish people stopped hand-waving at complex technical problems with "just"s and "all you need"s.

Well, and I wish you've read my whole comment before the BS about hand-waving. I explicitly describe what I mean.

>What you're saying is: "you have two completely different UIs with completely different modes of interactions, completely different layouts, affordances, a myriad other things. 'All you have to do' is ship them together and switch them on the fly".

Yes. Nothing particularly special about it. You could do just that: it's technically feasible (trivial even), and it would still be an adequate experience.

>It is not "trivial"

Well, agree to disagree. I've done it for apps and it's nothing much. What would be trivial for you, just flipping a compiler flag or changing 10 lines of code? Well, you ain't gonna get that.

>It does matter. Because interactions are completely different. Just for the most trivial example: once you've selected a cell, you can immediately start typing you can immediately start typing when you're on a desktop. On a mobile device you have to do an additional tap (double tap in Excel) or tap a different area (entry box in Google Sheets) on the screen to start typing.

That's a bogus difference. If the mobile device is connected to an external BT keyboard, you can already "just start typing".

Even if that wasn't the case, 99% of the widget is the same. The fact that to get the virtual keyboard to show up cell focus on mobile is not enough, is a negligible difference (not to mention it will probably not even touch the cell widget code, but be in another part of the UI dispatch, even handle directly by the framework).

>Yes, and almost all of them fail in the most basic ways on the desktop

And they are still perfectly operable, and people (including me) use them every day. So there's that.

Please explain how email fits your mode but fails mine.

Sorry, but I’m missing something in you comment.

Basically, it’s really hard to actually develop totally separate UIs in the same app, e.g. another user brought up the Catalyst project, which is bringing poor-fit touch paradigms into macOS despite the developers’ intentions in many cases. One paradigm will be dominant. Care must also be taken to not load too many unused resources.

Interactive workflows also differ between UIs.

Since so much of an OS is the native UI and the first-party applications, even if the mobile, tablet and PC versions of an OS share some libraries, they can’t really share enough to meaningfully call them one OS without compromising the experience on all three.

So while there may be three pane email on the iPad as well as Mac, and email on iOS, they don’t really share enough to be called the same app, and if they did, at least one of them would suffer. And some of the interactions on the macOS version effectively can’t be brought over.

There’s still an unsolved problem related to desktop publishing and that’s writing a document with a citations from an EndNote or Zotero database.

I included EndNote only because there’s deep integration in Pages.

Microsoft seem to be heavily invested in react native (and possibly election?) as their UI layer.

You're confusing the technology to create UI with the UI itself.


iOS is still much lighter weight than MacOS, uses less memory, doesn’t have swap, optimized for battery use, and optimized more for security than flexibility.

And yet you can edit video on it.

It’s powerful enough. The UI isn’t that big of an issue.

Yes. But what happens when you start adding swap, unlimited background processes, etc.?

All of the advantages of an iPad go away - you get Windows 2-1.

Performance vs. battery life toggle could be implemented. A lot of this stuff has already been implemented in the jailbreak community over the years.

iOS has had that for years - low power mode.

Low power mode is only available on the iPhone.

Why ‘unlimited background processes’?

Modern desktop operating systems don’t limit the number of processes actually running. iOS limits the type of apps that can run in the background and will kill a process that uses to much cpu or RAM.

iOS is optimized to consume as little power and memory as possible.

>Modern desktop operating systems don’t limit the number of processes actually running.

Yes. But no reason we need "unlimited processes" to use iOS for development and other stuff.

A few processes with a hard limit would be doable...

For me personally to do any type of development, I either need a constant network connection or the ability to run my stack locally including databases and Redis.

I also need to be able to launch a web browser or Postman to debug interactively. I personally hate developing on a laptop with no external monitors (preferably two). I would definitely hate trying to do that with iOS’s simplistic multi app/multi window support.

Also, while the Files app is okay for one off documents and sharing between apps. How would that work in a development scenario?

You would also need to allow apps to communicate with each other over TCP/IP locally.

Now you’re back to a multi window GUI (making iOS more complex) and apps having random access to the file system (less secure).

If you want an iPad to behave like a laptop - why not just buy a laptop? Alternatively, if you want a laptop with the power of MacOS and the power/performance capabilities of ARM, wouldn’t it make more sense for Apple to port MacOS and create ARM laptops?

The iPad is so light, I have no trouble throwing one in my laptop bag along with my laptop and syncing files between apps on both using cloud storage.

Actually that is the trend for modern versions of Windows and macOS.

Modern versions of MacOS and Windows don’t try to get rid of swap nor do they arbitrarily kill/block background processes.

Actually they do arbitrarily kill background processes That opt-in to it.

It has to be opt-in because otherwise legacy processes would break, but it is definitely present.

If you opt in for it, can it really be called “arbitrary”?

Yes - the killing is done arbitrarily without warning. Just like on iOS. It is the recommended behavior.

Better have a look at what is in the box for Windows 10X and post-Catalina roadmaps with the increasing app sandoxing.

Well, unless you have inside knowledge about Apple’s roadmap, sandboxing is only required for the Mac App Store.

Or are you believing the same 10+ year old conspiracy theory that Apple plans to make it mandatory for apps to be installed from the Mac App Store?

Also Windows 10X is just another failed gimped version of Windows that is suppose to make Windows run better on tablets and low power devices.

I happen to have good guesses reading between the lines, and it quite obvious where required notarization, user space drivers, application entitlements and iOSification of macOS are heading to.

MSIX is what is driving Windows 10X security, which coincidently is the future of Windows package management.

Application entitlements were required shortly after the Mac store launched - over 10 years ago and only for App Store apps. If Apple wants everything to be App Store only, they really are taking their sweet time.

Signed drivers have been a requirement for Windows forever. Apple is actually late to the game.

It’s also well understood that from a security and stability standpoint that moving drivers into user space was preferable.

Catalina has changed that, notarization is now required for everything, not only App Store.

Well, first there is a difference between “notarization” and “sandboxing”. Notarization just requires you to have your app signed, is a completely automated process, and in no way restricts what your app does.

Sandboxing restricts what your app can do and you have to use entitlements to use certain features.

But no, notarization is not “required” and as an end user you can ctrl-click the first time you run an app to bypass it.

Still, give it more 5 years or so.

They said the same thing back when it was announced in 2010....

They also said that Apple would never make notarization a requirement, then came Catalina.

They never said that and in fact it is still not a requirement. You can use the same control click to bypass it that you always could.

Doubtful, there's still a wide difference between MacOS and iPadOS, if anything they've diverged more in recent years. The multitasking workflow on iPadOS is flux, and has complexity issues.

Would be good for testing on device I suppose, but ooooh, I am not too sure how pleasurable coding on a touch interface might be, even with physical keyboard. Also, I would hate to de-incentivize one of Apple's remaining motivations for paying attention to their non-mobile hardware!

Well good news you can use a mouse on the ipad now, along with remaping capslock to esc in ios 13.4, all in a 1.5lbs computer.

I have got used to control-[ for escape on the iPad Pro keyboard. I use Prompt for SSH (I am used to it, should probably try other options) and I find opening Emacs and using control-x 3 to split the screen vertically works well. I then esc-shell in one window and edit in the other, or just have two files open for editing.

If you have a high resolution USB-C interfaced monitor, plugging in the iPad Pro works fine also, but is I am in my home office I just use my laptop. A big external monitor is great though for watching HBO Now, Netflicks, and Prime.

Oh man. Mouse support. How did I miss that? How is it with VNC? Might finally be time to move to my iPad Pro + some remote BSD & Linux VMs on a cheap, beefy used workstation tower in a closet for all my personal computing needs. Sell this aging macbook. Maybe a little Rpi4 or something stuck under my desk and connected to Ethernet for when I just need ports. I mean shit now that macOS murdered most of my games by removing 32 bit it has little to recommend it over iOS, aside from native app dev and mouse support, and the latter may now be moot and I can rent a remote Mac if I actually need it to compile iOS apps, iOS dev support's probably showing up on iOS in the next 1-3 years anyway.

... I think I've got some experimenting to do this weekend.

Oh shit I didn’t know about remapping. My iPad Pro is my main personal computer now but I’m constantly toggling capslock. Next up, assignable hotkeys for switching between apps??

I’m most excited about remapping the “globe” (switch keyboards) key which I always hit when I mean to hit Control.

I've used Pythonista on my iPad and I adore it. The physical keyboard is a personal must-have, but the experience is great otherwise.

I agree, a great product. Pip install only works for all native python libraries, but that is a limitation of not having a C compiler to build extensions.

The sad thing is I had a C compiler + UI designer for my ancient Palm device as a kid years ago, and the very simple Palm event loop (as best as I can remember) made development quite easy.


Fascinating find, thanks! I miss the "new" feeling of technology prevalent with Palm. We seem to have settled into gaudy client/server apps, where the control/power is in the hands of the server.

I am willing to bet nearly half of their Mac Sales relies on Xcode. There are over 20M iOS Developers, likely more assuming not everyone publish on App Store.

Which is one reason why Mac's user number are growing ( slowly), developers have no choice but to buy a Mac if they want a pieces of the App Store revenue.

And one reason why Apple completely neglect the Mac, because it will continue to sell even if they have crappy keyboard and Touch Bar. I could only wish they do something about the keyboard after Oscar winning Director Taika Waititi blast about their keyboard.

There's so much Next-y stuff left in Interface Builder that you can forget about using anything but SwiftUI if they would port it. It was a separate application for most of it's life. The build chain already exists thanks to Playgrounds, so it's down to the file system / build settings / text editor part to be ported.

Probably not until you see ARM Apple laptops. Even then, I'd imagine they want you to buy that mac to do development. A better feature would be to have hypervisor on the Ipad Pro and be able to spin up linux or ARM based macos.

I don't understand: what would be the advantage?

No need to transfer code across from your desktop to the iPad. You're developing directly on the target device, so no emulation and instant on-device testing. Also you can code in any setting where an iPad is easier to use than a laptop. I do a lot of coding in Pythonista on my iPad on the train.

This is similar to asking Apple if you can summon Alexa instead Siri on iOS. Not going to happen.

How is that remotely similar?

Inside the walled garden only Apple plays with the ball.

Playground is an Apple product.

And other similar sandboxed code environments already exist for iPad.

Playground is an Apple interface. Apple is not going to give anybody XCode with a shell environment on iOS.

What has a shell got to do with it?

> Now, Apple, can we please have the opposite? XCode on the iPad (even if some features had to be removed, like VS Code is to VS), with a containerized shell to run code we write in?

this was the OP.

It’s unclear what that even means. No reason it has to mean Apple allowing a general shell in the sense of a Linux shell.

This is a red herring.

XCode workflow on the Mac doesn’t involve shells. Why should it on iPad?

WTF would you want that for? I'm pretty sure the iPad is not designed for general purpose computing.

Is it designed for general purpose computing then?

The functions that needed to be removed have already been removed. What remains is comes already pre-loaded on your iPad with iOS/iPadOS. It’s called ‘Notes’.

The functionality removed was file management, version control, compilation, building, and interface design. All the rest (text editing) is still already there.

Ha ha, only serious.

Seriously, I doubt Apple is close to allowing a compiler to run on an iPad.

EDIT: Apparently a sense of humour is not a common attribute around here.

They already have the Playgrounds app on the iPad.

You’re right.

I’m curious to now whether it’s compiled; and if so, what the underlying architecture of the compiler and runtime is.


The evidence is that iPad Swift Playgrounds compiles to native code.

Presumably the compiler itself was compiled for ARM. The rest doesn’t really have to change as the Swift compile was already designed to compile for ARM for production builds of apps.

It's basically JIT compiled with special entitlements

Ofc Google had a similar project (with Javascript) but they scrapped it back in November... It was even available on Steam



You can still download the last full build (easier than compiling on your own) and it's actually really fun https://github.com/googlearchive/gamebuilder/tree/master/bui...

I pretty much hate when they abandon things like that

As a counterpoint, it’s labeled as “This is not an officially supported Google product.” Maybe this isn’t enough to stave off brand association?

Would you rather they never allow engineers to release it at all? When I worked at Apple, that was the fate of any internal effort or pet project that did not receive full executive buy in, and as an engineer I badly prefer the ability to open source projects in whatever state they were left, to be useful to anyone who wants to pick the bones or start something similar.

Disclaimer: I work for Google, but my opinions are my own.

It really bothers me that people so closely associate these "Not Google" projects with Google. I've seen repositories with not even a README, any documentation, or so much as an explanation of _what the project even is_ end up on the front page of /r/programming just because "Wow it's a Google project!! so interesting I wonder what it does???"

Google is a _huge_ company, not everybody that creates something there is showing some internal direction of the company..

But it doesn't say "Not Google", it says "This is not an officially supported Google product." I read that as saying "Google totally made this, but please don't call tech support if it breaks."

Or maybe it just means that someone spent 10% of their time at Google trying to make something cool and it's not a serious project.

It’s not really the same as a learning tool, but Google has FlutterPad [0] which is an online playground for Flutter app development.

Which if you’ve never played with, it’s extremely easy to see how Flutter and Dart work. Most online tutorials can be completed right in FlutterPad. So Google does know people want this, just seem to care more about other things right now.

[0] http://flutterpad.com/

they are conceptually different things.

i started exploring swift a few weeks ago and these playgrounds are quite handy. for python programmers: it's like a jupyter notebook but with outputs on the right & auto evaluation.

it's a generic instant feedback tool for swift but deeply integrated with xcode. i think, what apple did here is simply decoupling it from xcode. this is huge because swift is quite powerful and a complex language already. i am curious what direction they take this.

I’ve been a developer for about 8 years now and have even already learned a decent amount of Swift.

I still had a blast getting the adorable character (Byte-) to navigate around the puzzles.

They even get into some simple yet cool path traversal algorithms that I’m sure grow in complexity if you keep going.

I’m going to download these and have a lot of fun with them.

Would love to see this kind of paradigm evolve into more complex domains.

These types of things really are gateways into computer science. I’d like to see it grow too, because early adoption really does set students apart.

I wonder how many top students in compsci programs used to do things like install and tweak Minecraft plugins when they were younger.

QuartzComposer was the best playground. I really wish they'd give it some love.

Really, QC was one of the cooler things Apple has done since HyperCard.

I wrote a video editor that allowed you to use it to build plugins with it: https://vimeo.com/121663242

Unfortunately, life got in the way of finishing it.

I think Apple bought it and renamed it to Quartz Composer. I remember you could use it to make screen savers and could even write your own patches for it in Xcode.

My daughter has the Osmo, which has a coding challenge. It's very similar to this, except it's just arrow tiles and jump tiles that you lay out in front of the iPad and then the character moves the same way.

I'm going to have her try this (she's five) and see if it's too hard since it requires reading (or perhaps it will force her to improve her reading skills!).

> it's just arrow tiles and jump tiles

The obvious next step for her is Befunge.

Apple have been hiring a number of developer relations and community relations folks from Kubernetes-land lately; my suspicion was that they were planning to create some kind of public platform or runtime service and wanted well-positioned ambassadors.

Maybe this is it.

No. This is just a macOS port of an app that has been on iOS for years now.

This is nice, to be sure, just too bad it's only for Catalina.

It's built using Catalyst, their technology for running iOS apps on MacOS, which was only launched with Catalina, so there's a good reason for this.

I recently got a new Macbook and was dreading having to use Catalina, having heard horror stories online, but actually my experience has been fine. A few security popups to click through when you first run a new app, but some of the screen shots I saw online of hundreds of them must have been fake, it's really not a problem. Having to right click and open unidentified apps can be annoying, but I'd rather do that and keep Gatekeeper on personally, rather than disabling Gatekeeper entirely.

It actually feels really solid so far (granted its a clean install on a new laptop) and I am really impressed with the Sidecar feature in particular. Of course, if you depend on 32-bit apps or drivers, or certain apps which are meant to be buggy (e.g. Mail referenced in another comment), you may want to hold off for a while!

The reason you didn't see the bevy of popups was because you did a clean install. With an upgrade install all of your existing apps have to go through the same security steps as a new app, and they tend to do it all at once, especially if you have a lot of apps that launch at startup. That said my experience was not as extreme as some of the screenshots, and I think it would be even less for the average user. And of course this is only upon first upgrade, so while frustrating, you quickly get over it.

I upgraded last weekend and I think the only new security prompt I had was from Bartender 3, which needed some new "screen recording" permission to see what menuextras you have installed. Had to go into the Security preferences and turn that on manually rather than just having an "OK" button, but it wasn't hard.

Oh, and Terminal had a popup for permission to access ~/Desktop

Ahh, that makes sense I guess!

Damn! I really enjoyed Swift Playgrounds on the iPad, but found the lack of real keyboard irritating. I was about to download this until I saw your comment.

My email's too important to risk upgrading to Catalina still.

I've heard there were data store migration problems and haven't had any myself, but is this even an issue if you're using IMAP? It's all stored on the server anyways. (I can't imagine using POP in this age of multiple devices.)

Yep, definitely an issue with IMAP mailboxes. It's not a storm-in-a-teacup-because-it's-Apple situation, it's an Apple-really-done-fucked-up situation.


You can still create swift playgrounds in Xcode, but it won't have the coding lessons included in this app.

I am still on El Capitan so I share your disappointment. However iPadOS can be used for this app as well.

It is really frustrating that Apple does stuff like this.

Being built with the Catalyst framework which is only available in Catalina seems like a pretty good reason to only have this available in Catalina.

I stand corrected. I didn't read far enough to know that this was Catalyst.

Catalyst (née Marzipan) apps first appeared in Mojave.

Likely didn’t have the required apis then for this to run.

Catalyst != Marzipan, not even architecturally.

That they develop new products that show off the capability of their new products? It would seem odd to me if they did not.

Some larger screenshots (and more info): https://developer.apple.com/swift-playgrounds/

I visited Apple store to get wife an Apple watch ( I tried to dissauade her, but it was what she wants ) and played with the Playground toys.

Neither my brother's nor my cousin's kids are ready age-wise, but it seemed like a ton of fun. I would love to be a kid today.

You might change your mind about the Apple Watch, especially with a data plan so you don’t have to carry your iPhone when going out and about.

Your wife will need AirPods to squeeze all the functionality out of her new Apple Watch; required for playing music, pod casts, audio books, and more pleasant phone conversations using the watch.

My wife and I have a ton of Apple gear and we agree that the Apple Watch is a game changing product. It is so convenient for a lot of supported things to not have to get your iPhone.

They'd probably be watching YouTube nonstop, like all the rest of the kids though. There are downsides to being a kid today, ones that kids don't even realize are downsides.

Looks very nice! It almost made me want to learn Swift.

The only thing is that it's used only on iOS systems. If I'm going to spend the time to learn a new programming language, I'd like to use it everywhere like I do with JS.

The Mac app "syncs" with the iPad app. That's useful!

I'm writing a Swift Cookbook on Github for anyone who's trying to come up to speed on Swift:


Trying to be more functional with my Swift:


I'm also working through Joel Grus' Data Science from Scratch book, but trying to rewrite the examples in Swift. I'm only a few chapters in:


Things I'm doing sitting on my couch with my iPad on the arm and the book in my lap.

Quick note about your functional examples - there's already a built-in version of `take` called `prefix` available on all Sequence types.

Thanks. There’s also a prefix(while:) that appears to be takeWhile(), which I also needed.


Does the app sync between different macOS computers though? My experience has been: no. Both computers are signed into the same Apple ID ...

It’s using iCloud. Basically, they work in the same directory.

Before I had to copy and paste into Xcode Playgrounds.

Thanks. So, for this to work, I have to enable iCloud Drive on both machines? Looks like it takes quite a long time to upload 375MB playground files to iCloud too.

> The only thing is that it's used only on iOS systems.

It's also used on the macOS, which is kind of the point of this HN posting.

In the magnitude of using a given platform, learning the language is a small part; the APIs and tooling will be a larger effort. If you already know those things for the iOS, the jump to macOS will be less.

Swift can be compiled and run on Linux. It's most prevalent on Apple platforms. It's usefulness outside of the Apple platform is a different topic though.


I suppose Swift is like a CLR language (e.g. C#) in that sense, then? The language itself will run in many places, but most of the library bindings anyone might care about, or want to use the language to get access to, are for platform-specific libraries.

For what it's worth, C# is very usable on both Linux and macos. Anything outside of UI is pretty much fully cross platform at this point (there are even some cross platform ui attempts, but they're not anywhere near as mature as wpf, xaml, winforms, etc)

These days there’s been a lot of movement towards cross platform C#, with .NET core etc. Whilst there isn’t any desktop application support (other than Xamarin), there’s a good ecosystem for ASP.NET.

That's true of most languages, like C++, rust, etc.

There's some momentum behind Swift-on-Server, I believe. And Tensorflow Swift seems to be a rather serious project.

You may just want to learn a touch of swift to experience nifty language features such as optionals. (Unless you have worked with languages that have all of swift's nifty features)

On the other hand there are quite a few ios devices out there...

More than a few, it's quite ridiculous so many devs are sniffy about it. If you can handle cpp, you can handle swift, one of my biggest gripes right now is having to deal with a cross platform cpp solution that just seems to throw out 10 years of progress so they can implement code like they're used too and reimplement built in solutions slower and harder to work with.

Is there a good age to start introducing stuff like this to kids? My niece is 7 and seems to have the personality that would be perfect for a programmer.

But I don't want to rush her into stuff like this when she's still a kid who should be having fun.

I was thinking around ~10 would be the ideal time. But I'm not a parent and know little about kids and childhood development.

The main thing is exposure + motivation. I learned to program about age 8 (not well, mind you, but that's when I started) with BASIC. We had a Tandy 1000 at home, and math textbooks had BASIC listings at the end of sections/chapters at the time (late 80s, early 90s). I was motivated to try the things out, my dad provided me access to the computer (showed me how to get to the command prompt, launch BASIC, open, save, and edit files, and run programs). He didn't do much beyond that (he hadn't programmed in 10 years or more, in college), but giving me access was the critical element.

If she's not interested in the motivating examples, like I was with the math-based examples, then she likely won't stay interested or engaged. So find something that she's interested in and can write her own programs (or program extensions) for. It could be more game-like stuff (controlling a character or bot on screen and having it do something), simulations, drawing (think Logo's Turtle Graphics or fractals), or something more physical (arduino + LEDs or servos controlling something).

And don't pressure her. Once she has access, and knows she can ask for help, if she's interested she'll pursue it. If she shows some interest but has little self-motivation, maybe keep providing little widgets or gizmos or games and inviting her to help out, but only occasionally.

> My niece is 7 and seems to have the personality that would be perfect for a programmer

I've worked with all sorts of good programmers, but now that I think about it, I don't think there is a "type"?

Curious what you meant about this?

Some kids like puzzles more than others. Programming is like solving a puzzle.

Start with scratch. Mine could do scratch at 7.

I really wish there were stuff like this for more advanced topics. Where's the gamified "write a compiler" course?


They have a game called "midterm" every few weeks where you can earn points towards a final score. :)

But more seriously, would gamification really help you at that point?

There's the nand2tetris course, which isn't exactly gamified, but it's a project-based course where you learn hardware fundamentals and assembly as you build a Tetris clone.


Honest question: to what extent is this a fancier-graphics version of Logo from the 1960s? (you know, the little turtle with which you can draw shapes, by using commands like pen down, pen up, move, turn, etc).

Does swift playgrounds teach one other stuff, in particular stuff relevant to the MacOS or iOS API?

Logo’s a Lisp. Swift’s an Algol. The latter are much more complex, and also much less expressive and customizable; alas, thanks to C they’re also firmly entrenched as the status quo. Logo emphasises compositional thinking; Swift Playgrounds algorithmic hoop-jumping.

Ironically, Apple did do a Lisp[-in-Algol-clothing] back in the 90s—Dylan—but abandoned it when NeXT took over. Shame. Closest thing since then was the “Objective” part in Objective-C, but that was always a bit smoke-n-mirrors (since it’s still C at the bottom) and is slowing going away now in any case.

I do not think Swift is a good K12 teaching language (it’s a nicer C++, roughly on-par with Java in complexity), but Apple’s goal here is to create lots of new (and preferably locked-in) iApp developers, not raise talented independent CS students†, so that’s not a problem for them.

Real-world Swift App development also gets varying degrees of ugly/tedious/painful when dealing with BSD/Foundation/AppKit/UIKit idioms and APIs due to the impedance mismatch between Swift and Obj-C worlds, so the sooner it has its own native APIs for everything the better. I don’t think SP can really prepare anyone for that tangled mess, though if/when SwiftUI is fully ready for primetime I can see SP boosting that. (Whether SwiftUI itself is particularly good remains to be seen.)


(† Mind, most K12 and college “computing science” courses nowadays are really “software engineering” and not really CS either; and even SE can be a stretch considering how much software today is garbage.)

Swift Playgrounds is essentially an interactive Swift REPL that ALSO ships with some prebuilt learning material, some of which is "fancy logo".

Swift Playgrounds is not a real REPL though as it re-evaluates the entire program after every code change†. While it nicely annotates the code with per-line results, program state is not persisted between edits and side-effectful operations are repeated each time. That seriously limits its real-world usefulness to little more than a cute toy.

Ironically, Swift does have a true REPL which you can invoke in Terminal (`swift`, unsurprisingly enough). That does persist state over the entire session while showing the output of each line, albeit with old-school CLI line editor. The Print bit really sucks though as it ignores `description` methods and does a full debug dump of complex structures every time.

(Plus, of course, users need to be comfortable finding their way around a 1970s shell, which Playgrounds’ audience won’t be.)

Two partial “REPL” implementations that could’ve been a single knock-it-out-the-park REPL had they bothered to consolidate and refine. Swift may be many things, but great at joined-up thinking it is not.


(†Unless they’ve changed that behavior since I last tried it. Probably not.)

Finally! I’ve been waiting for them to do this.

Has anyone read through the "Swift Playgrounds 3.2 License Agreement"? It's kinda long.

Would it have killed them to use a standard open source license like MIT or Apache 2.0? Don't they want as many people as possible to learn their pet language?

Playgrounds isn't free software, and for that matter isn't even source-available.

That's what I'm saying, if they want as many people to learn Swift as possible, why not open source this learning software? The Swift language is open source under Apache 2.0, clearly the license is not alien to Apple.

I don't disagree with you, but your comment was worded in a way that implied you thought it was source-available.

Frankly, Apple probably doesn't care how many people learn Swift. Playgrounds is aimed at children, who don't yet care about software licensing.

How will this limit people using it? Are there institutions that won’t allow it? I don’t fully understand the complaint.

Is the get button disabled for anyone else in the mac store?

You are probably not running macOS 10.15 Catalina.


yea but is it written in Swift is what i wanna know

If you download it and run `nm /Applications/Playgrounds.app/Contents/MacOS/Playgrounds | grep "_\$s"` from Terminal, you can see there is lots of Swift in there.

Yuck - needs 10.15

Real missed opportunity not calling this "Swifty Swift"?

  Animations introduce each new coding concept at a high level before you dive into the puzzles
This sentence says the opposite of what is meant to most non-technical people.

Wasn't it released in 2016 ? Why is it top of hacker news today?

They recently released it on macOS (via a Catalyst port of the iPad app)

All right! Thanks a lot. I was confused with their home page https://www.apple.com/swift/playgrounds/ "Learn serious code on your iPad." I guess it's just not up to date.

Anyone else here unpopularly wish they could write typescript/js & compile directly to native iOS machine lang?

I love prototypal inheritance & JS' syntax.

I don't enjoy the swift I'm doing now nearly as much as JS/TS.

Swift and JS/TS are practically interchangeable compared to the high learning curve of actually using UIKit/Cocoa/CoreData/Xcode/etc and building applications with it.

I don't think language syntax is very consequential, especially Swift vs JS which really aren't all that far apart. What I yearn for when I build mobile clients is the ability to bring my own abstraction like I can on the web. Instead we're stuck with old-school overly-OOP abstractions on mobile without any truly compelling alternatives.

Like, the whole ViewController + delegation abstraction feels like using Backbone.js in 2020. SwiftUI is one step in the right direction, at least.

>we're stuck with old-school overly-OOP abstractions on mobile without any truly compelling alternatives.

Agree. It's odd.

Javascript (and probably by extension Typescript) are too dynamic to really compile down to machine code while still retaining all features. The best you could do would be something Cythonish where every second line gets converted to a call to PyObject_blah. It's not clear that that would actually perform better than a modern JIT engine

In which case you've just invented a less portable way of doing electron type apps.

There's AssemblyScript (a strict subset of TS that compiles to WASM)

I'm still waiting for Apple to update Xcode to not include every single SDK for iPhone so the updates can reduce to 700mb instead of 6GB.

Xcode should have an SDK download manager so you get to choose which iOS version you want to install, rather than ship them all in Xcode.

They ship like one or two? If you want older ones, you need to go to the download manager to get them.

If you already had them installed, they remain available. You're probably getting confused by that.

Any chance Apple would make it possible to compile an iOS app without giving Apple any money?

I want to support my customers, but I don't want to support anti competitive FAANG

> Any chance Apple would make it possible to compile an iOS app without giving Apple any money?

Absolutely! It's called a "web application", and you can write them in a variety of languages, including compiled ones.

> I want to support my customers, but I don't want to support anti competitive FAANG

It's weird, because English is my first language, but I have no idea what that sentence means. Perhaps you could elaborate?

FWIW, here's the closest I could come to translating it: "I want to write applications that natively run on hundreds of millions of devices, which development for, and use of, directly supports and props up [an anti-competitive FAANG], but somehow as long as I'm exempt from paying them a small annual fee, I'm morally and ethically OK with that."

FWIW I would expect the OP's real objection is having to buy a Mac to develop iOS apps, not the annual fee.

They could buy a used Macbook.

The web on iOS is deliberately gimped.

If you mean not buying a Mac, I heard that is possible by virtualization of mac OS using some QEMU/KVM Hack.

I don't know if it needs modified builds of OS. if so, stay away from that..

Applications are open for YC Summer 2020

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact