Swift Playgrounds for macOS
apps.apple.com
apps.apple.com
Please?
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.
... I think I've got some experimenting to do this weekend.
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.
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.
So the "end of macos" is unlikely in my book.
Then, plug tablet to monitor and “type/write” on the tablet.
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 could live without a keyboard.
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.
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?
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.
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.
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.
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.
https://www.macrumors.com/2018/11/01/2018-ipad-pro-benchmark...
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"
I’m sure you could do this with Linux now, it’s just such a niche use case nobody has mass produced it.
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.
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.
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'm not sure that's necessarily true. Are you aware of Mac Catalyst?
https://developer.apple.com/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.).
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.
... and hope that Apple reinvents user input on mobile.
A little Soli for advanced gestures:
A selfie keyboard?
https://www.cnet.com/news/samsungs-selfietype-creates-a-magi...
Better voice commands. For example, why can’t I say “build app”
“Rename function foo to bar“
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.
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.
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.
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.
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.
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.
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/
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.
Sorry, but I’m missing something in you comment.
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.
I included EndNote only because there’s deep integration in Pages.
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.
It’s powerful enough. The UI isn’t that big of an issue.
All of the advantages of an iPad go away - you get Windows 2-1.
iOS is optimized to consume as little power and memory as possible.
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...
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.
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.
MSIX is what is driving Windows 10X security, which coincidently is the future of Windows package management.
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.
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.
It has to be opt-in because otherwise legacy processes would break, but it is definitely present.
And other similar sandboxed code environments already exist for iPad.
this was the OP.
This is a red herring.
XCode workflow on the Mac doesn’t involve shells. Why should it on iPad?
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".
For the majority of coders working in homes, offices, cafes and such, including most digital nomads, it would be just fine...
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.
And of course 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.
I say hearing because because the real world examples of this supposed power are few and far between.
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.
https://github.com/googlearchive/gamebuilder
http://web.archive.org/web/20191017085801/http://store.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
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.
Google is a _huge_ company, not everybody that creates something there is showing some internal direction of the company..
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.
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 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.
I wonder how many top students in compsci programs used to do things like install and tweak Minecraft plugins when they were younger.
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'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!).
The obvious next step for her is Befunge.
Maybe this is it.
My email's too important to risk upgrading to Catalina still.
https://tidbits.com/2019/10/11/beware-mail-data-loss-in-cata...
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!
Oh, and Terminal had a popup for permission to access ~/Desktop
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?
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.
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.
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.
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.
I'm writing a Swift Cookbook on Github for anyone who's trying to come up to speed on Swift:
https://github.com/melling/SwiftCookBook
Trying to be more functional with my Swift:
https://github.com/melling/SwiftCookBook/blob/master/functio...
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:
https://github.com/melling/data-science-from-scratch-swift
Things I'm doing sitting on my couch with my iPad on the arm and the book in my lap.
Before I had to copy and paste into Xcode Playgrounds.
https://developer.apple.com/documentation/swift/sequence/312...
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.
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.
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?
Does swift playgrounds teach one other stuff, in particular stuff relevant to the MacOS or iOS API?
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.)
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.)
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?
Frankly, Apple probably doesn't care how many people learn Swift. Playgrounds is aimed at children, who don't yet care about software licensing.
I want to support my customers, but I don't want to support anti competitive FAANG
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."
I don't know if it needs modified builds of OS. if so, stay away from that..
Animations introduce each new coding concept at a high level before you dive into the puzzles
I love prototypal inheritance & JS' syntax.
I don't enjoy the swift I'm doing now nearly as much as JS/TS.
In which case you've just invented a less portable way of doing electron type apps.
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.
Agree. It's odd.
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.
If you already had them installed, they remain available. You're probably getting confused by that.