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.
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.
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.
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.
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.
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.
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.
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?
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.
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.)
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.
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.
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.
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.
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.
(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.
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.
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.
>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).
>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.
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.
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.
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.
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.
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.
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.
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!
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 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.
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.
> 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?
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.
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.
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."
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.
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 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!).
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.
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
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.
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.
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.
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.
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)
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.
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 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.)
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?
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.
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.
> 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."
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.
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.
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.
Please?